box size type...

[Max-Max]

I would like to add a new type for size as in box size (width and height). I know what you will say...
- We have koord and it has worked fine for 14 years...

But the point isn't only about storage, it also serves as documentation.
- the inexperienced coder don't know what is expected if a param is koord.x and koord.y, there is no hint in the description to tell him that it is a width and a height that is expected, not an x.y coordinate.
- We can easily change everything related to a size (dimension?) by modifying the type.
- We can do operations on it, related to width and height.

[Ters]

I thought there was agreement that koord is for world coordinates only.

[Max-Max]

I thought there was agreement that koord is for world coordinates only.

Well, it isn't more clear if it is called screen_coord either, when it refer to a size 

The question/proposal was not about koord, it was about a new type for size (dimension)...

[kierongreen]

Dimension of what? If the dimension is of screen coordinates use that type, else if it's map coordinates use that type. Unless koord is used for size of something else in game?

[prissi]

Most drawing routine would still need screen_coord, with the exception of boxes. If you provide an easy conversion between screen_size and screen_coord, then I see no gain by implicit type safety.

Also while a type is a size, is has to be added to coordinates very frequently. Hence typewise I feel that size will be quickly became ambigeous. If you want to handle sizes, then I think they are better handled as screen rectangles as an own class. You can then add rectangles and intersect them and so on. Also clipping and stuff would be less ambigeous and such rectangles may come handy also for event handling too. Like zeichnen would get a rectangle, clipping would get a rectangle and so on.

[Max-Max]

I have already made a rect_t. It has a position and a size and this is one of the steps towards the client concept. It can add, merge rectangles etc...

I'm thinking about set/get groesse that only deals with a size. It cost so little to make a new type for size and it improves the readability for those just learning the code.

I have hesitated to implement the rect_t and screen coord because everything I do is met with such a criticism and I have to spend hours to argue about small insignificant details. I spend more or less 40 hours a week on this and it feels pointless if it never gets implemented because it "looks ugly", -this is not how we have don it for the past 13 years, this and that are a few pixels wrong or there is a wrong number of spaces.

But if one of you guys merge in code that screw up things, it passes almost unnoticed. To be more specific I can mention the dirty updates that doesn't work so well and the map border that screwed up the graphics quite a lot (I have a few save games that looks really screwed up with slopes pointing in the wrong directions), the combobox that stop to work and I wasted a day to figure out that it wasn't me.

It would be nice with some positive feedback once in a while.
My enthusiasm has really faded a lot and turned into frustration, and you guys wonder why there are so few developers...

With all this said, I hope we can move forward and that my enthusiasm will return.

About screen_coord... Is it okay if we call it gui_coord? It is mainly used for the gui overlay and it is short and easy to write. The most gui components, that will be using this type, also start with gui_ so I feel a natural and self documenting reason to call it gui_coord.

Maybe we should call it gui_rect for the rect_t class?

Prissi
I have merged your trunk with mine and found out that you have removed my test cases. Is there another way for me to switch between theme test and default? You talked about a .tab file, is this implemented?

I saw that you have changed the divider to 2 pixels. A divider's, or separator's, purpose is to divide or separate section of controls. The divider doesn't need to be of the same size as its graphical representation because it also serves as a separator (replacing the need of D_V_SPACE). I found that a divider of 2*D_V_SPACE gave a balanced look and feel where D_V_SPACE + divider + D_V_SPACE gives a little bit to big spacing. This would of course be configurable through them later on (do I really need to state this all the time?)

[kierongreen]

All contributions are appreciated you really have to believe that. Understand that Simutrans has been around for a while, one reason it has been around for so long is that one person (hajo then prissi) has had the determination to keep it going. That does have it's disadvantages though and one is their limited time. Although any (core) developer can commit patches to the SVN there is a general agreement to not do that unless consensus has been reached or it's a bug fix. Anyway - I think discussion of that nature can be continued in your thread: http://forum.simutrans.com/index.php?topic=11947.25. But please don't stop contributing.

Maintaining patches is hard work, I understand that but the end result is worth it If the end result gives the possibility for something like your mockup that will be great - Simutrans has to work on a range of devices and while some people prefer the existing interface and it is good for small screens I can understand how some people feel it looks old fashioned and the choice given by your patch would go a long way to addressing that

gui_coord and gui_rect sound reasonable to me.

[prissi]

I am sorry that I am demotivating you. This is not intention even lame it may sound to you; as consolidation I offer you my side. I could just integrate all patches without any changes. But then I would be a manager which would have let my quite simutrans five years ago.

I validate your input. But you should be aware that there are different views. Hajo built simutrans very much around esthetics, and I tried in many places to keep this while being as ergonomically and pleasant as possible. As such a divider with different spacing on top and bottom is ugly for me.

The same is with the concept of inner and out bounding boxes. This confusion should be imho kept away from simutrans. In the end the GUI programming should be easier, not more difficult than currently. Because in the end I have to maintain it and explain it to any new contributors. Having more initializer, and more stuff to take care is not making stuff for new programmers easier. Hence my reluctance to incorporate additions.

gui_coord is not a good name, as all drawing routines will use gui_coord, inclusive all the tile rendering. As such scr_coord seems more reasonable to me.

If you want to change consequently to rects, then resize, get/set fenstergroesse, zeichnen etc. should just get a rect (or scr_rect) This will indicate (and handle) position changes within elements too more easiy than calling set_pos, set_groesse as done now frequently and will make the class interface easier.

The code for testing can be now done with a theme.tab file, whcih is by default loacted in the program directory under "theme". This files should contains lots of lines with "gui_titlebar_height = 16" and so on. All currently supported lines are in simwin.cc. That should make testing rather easier I hope.

[Max-Max]

I almost forgot about this thread. If I want to test I have to edit the theme.dat file every time... I will implement something easier for debug purpose, i'm thinking of one theme file for each test case...

[neroden]

I would like to add a new type for size as in box size (width and height).

I wanted to add something similar too.  I was going to call the screen coordinates "gui_coord".  I submitted a patch for this.  It got ignored until it no longer applied due to other code changes.

I think it's neat that you also wanted to call the screen coordinates gui_coord; apparently great programmers think alike.  scr_coord would be a fine name too, though.

My enthusiasm has really faded a lot and turned into frustration, and you guys wonder why there are so few developers...

You're not the first.  Where's your patchset maintained, is it on github?  I'd like to take a look.

[Max-Max]

Well, we are moving forward... I'm on vacation right now, but I do some coding during the hot nights here

My Theme project is rather "huge" and it has also become to include some restructure of the whole gui. I'm submitting smaller patches that goes straight into the SVN trunk (so far)

Right now I'm more focused on restructure of the gui than theme implementation. The theme project is discussed in patches&projects->LargerProjects->ThemeGUI.