New Names for Classes and Namepaces

To simplify both code and xml files, we are considering the following set of name changes for Types in VG.net. If you use VG.net, and have an opinion on these changes, please post a comment.

Note we will keep the name of the Type and the name of any property of that Type identical. For example, currently the Style class has a property named TextStyle, which returns an instance of the TextStyle class.

First, classes related to object appearances (styling).

Current Name

New Name

Notes

Style

Style

No change. A Style currently contains one of each: BrushStyle, PenStyle, TextStyle, and RenderStyle.

SubStyle

AppearanceProperties

SubStyle is currently the name of the base class for BrushStyle, PenStyle, TextStyle, and RenderStyle.

BrushStyle

Fill

This class specifies the appearance of filled interior areas in shapes, as well as the fill used within TextStyle (TextProperties) and PenStyle (Stroke). Since Fill is a base class, the name change would affect a number of derived classes: SolidBrushStyle becomes SolidFill, etc.

PenStyle

Stroke

Specifies the appearance of shape edges. Contains a BrushStyle (Fill).

TextStyle

TextProperties

Specifies the appearance of text. Contains a BrushStyle (Fill). We cannot simply change the name to Text, as there is a string Text property in each Shape.

RenderStyle

RenderProperties

Specifies rendering options: anti-aliasing, gamma-corrected or linear composting of translucent pixels, and the pixel offset mode.

Here are newly proposed names for various Shape classes.

Current Name

New Name

Notes

RectangleShape

Rectangle

This will cause a conflict with the integer rectangle System.Drawing.Rectangle. Because all coordinates in VG.net are stored as floats, we believe code using integer rectangles may rarely mix with VG.net code. If many people believe the conflict will cause problems, we can leave RectangleShape as is.

EllipseShape

Ellipse

 

ArcShape

Arc

 

PieShape

Pie

 

PolylineShape

Polyline

 

SplineShape

Spline

 

PathShape

Path

 

Finally, we are proposing changes to our namespaces and dlls:

Current Name

New Name

ProdigeSoftware.Drawing

Prodige.Drawing

ProdigeSoftware.Drawing.Styles

Prodige.Drawing.Styles

ProdigeSoftware.Drawing.dll

Prodige.Drawing.dll

6 Comments

  • Looks good to me

  • I think keeping *Shape can be a good idea... confusion with Rectangle or Win32 API (Ellipse, Polyline, etc... are win32 api) should be avoided.



    Mixing Style and Properties seems strange to me... is it style (sound more like something you can apply on many object) or properties (sound more like something actually applied to one object)? The class that inherit from style are properties, or sometimes not, sometimes they're just Fill and Stroke...?



    Also for GDI(+) users, Brush and Pen are something, Fill sound likes flood fill and stroke looks like a way to surround an object. Maybe it could be a good idea to keep and use "current knowledge" to soften the learning curve?



    ps: no I'm not against all change... :p

  • I say leave the Shape on the end of rectangle and etc., but I think all other changes seem worthy.

  • not bad

    but i would change Fill to FillProperties

  • My preference would be to use FillProperties rather than Fill and StrokeProperties rather than Stroke.



    As for the ..Shape argument: they're in a separate namespace from System.Drawing so why not use the same class names?

  • Hi Ben! Your idea is interesting, but adding another namespace to the mix makes every file a little more complex.



    It is possible to avoid importing Prodige.Drawing. But perhaps our namespace should be called something else, like Prodige.Graphics. This way, the technique you propose could still be used, but would look like this:



    using Prodige;

    ...

    Graphics.Rectangle = new Graphics.Rectangle();



    Perhaps the Drawing name was a bad choice.



    But the Graphics choice is not good either! There is a Graphics class in System.Drawing. Anyone have any good ideas here? "Shapes" really doesn't cover the richness of the API.

Comments have been disabled for this content.