Thank you Prissi
for the clarification of tabs & spaces, lets move on...
I could not download your zip file.
Strange, the url is http://simutrans-germany.com/files/upload/SimutransTheme_r28.zip
Maybe you can browse manually to get it? The link and zip archive works fine from here
Does any one else have a problem to get the document?
Regarding my smaller patches, what is the plan in your end?
To receive ALL the patches before a trunk merge or to merge them one by one? I'm trying to create patches that will not break the current GUI, so we can merge them "silently". If your plan is to wait for all the patches, I will have quite difficult to keep my main trunk (your trunk) up to date with my patches.
You can obvjously now have more than one display_proportional with different and default parameters without the ugly define, since simgraph16.cc is now C++ (since some time actually) and hence also get rid of these flags.
I do not know how these flags are used, but I will do my best to fix this. If the flags are to be removed, I have no objection at all to share alignment enum
For the hidden Init() function, it depends on the pointer type. If the pointer is of the base class type, all it knows is the init(pos,size) and that will be use. This makes sense because if you do use the base class you don't know what type of control it is, unless you do a dynamic cast that will give you the correct pointer. If you use a pointer of the correct type the Init(pos,size) will stay hidden and not be accessible. This makes sense because now you know the interface and how to use the extra params.
Do we have support for transparent images now?1 bit transparency since ages; but there could be a parameter in the theme tab (which for instance would define menu positions, tool sizes and so on) to draw the the background with xx % transparency. Such routines exist.
Yes I know about the transparent mask (1bit) and I have seen some Alpha drawing stuff in the code. The themes could really benefit from drawing with an alpha plane (24bit png). This would make it possible to do overlays and hence keep down the number of images. The question is, would it be to slow to draw?
To make window backgrounds semi transparent sounds like an excellent idea! There could be one transparent level for inactive windows and another setting for active windows
About alignment, I think we should have two align functions...
It might be very useful if I implement anchor points support further down the road. I think this would come naturally when needed. I will keep it in mind...
While you're rewriting the gui, do *not* use the koord class.
I was told to use it, but I think you are right. It feels a bit awkward to use the koord type.
I'm a bit used to Windows and they use a POINT
type for x,y screen positions and a RECT
type (x1,y1,x2,y2) to place a rectangle on screen.
I have seen a similar type for clipping regions in the code.
I might suggest a screen point class (SIMPOINT) similar to Win32 POINT and maybe a Rect class (SIMRECT) like (x1,y1,x2,y2) with helper functions like get/set width(), height().
Should a screen coordinate be of the type sint32 or sint64?
char* x; is a good declaration, char *x; is a hard-to-read muddle.
I totally agree with you.