Despite the midsummer celebration here in Sweden, I have put together some of my thoughts around the new Theme system in this draft
Remember this is only thoughts and ideas, not the law
Space instead tabs are on many places. Just open your file with notepad, and you will immeadiatly see ifs, that have tabs and three lines below spaces. For instance the case in line 187.
Line 187 in what file? Wouldn't be easier to just update the code document instead of pointing out all the errors, show how it should be done, not where it is wrong.
The DIRTY/CLIP flags with text could still be part of the alignment enums. Just use a higher number, 0x40 and 0x80 are not used
But they have nothing to do with alignment. Especially not GUI bounding boxes against other GUI bounding boxes. Imho I think these flags has less to do with my alignment, than my alignment has to do with text alignment. My routines don't use them at all. I still think that text alignment should be in its own enum, together with these flags.
There is 2 bits left and I do have a plan to use these two bits further down the road. That is why they are reserved.
Buttons were the oldest element; that is the reason they behave different and have an init. Also the world creation dialogue was (is) able to change its language on the fly; this is no longer needed. Hence a type changing the size of the element is really a nono. This is an unexpected side effects and should be really avoided. (As also said for the labels: Their size MUST NOT depend on the text it displays, but must be given on initialisation.) The only way for proper bounding boxes is, that those are set by the programmer (using the BUTTON_WIDTH and the like).
Almost all button init()
sets the size to koord( D_BUTTON_WIDTH, D_BUTTON_WIDTH )
. I made it possible to exclude the size and have the Init() to set them to the default size for that control. You can still override this in the init() by setting the size parameter. If this isn't still enough you can set a new size after the init() call.
An init routine in gui_komponente does not make much sense or? It has to have different parameter for each component. One could however argue for an init routine to be present for any implemented gui_komponent_t.
It makes all the sense in the world. All components has a position and a size, this can be set through the init() routine.
As you know, in C++ you can have more than one version of a function as long the number of parameters and types isn't the same as declared earlier. If you need more params to init a control, just make a new Init routine, call the old one and then handle the new parameters.
If you want to forbid calls to the older version of Init() you can move it to be protected or even private in the descendent class.
The skin (i.e. dialogue background) should be able to cope with any size (and even allow for now skin with transparency, like the chat window.) Its being 64 is rather tradition and not really needed.
Do we have support for transparent images now? The makeobj is complaining if it finds an alpha layer.
Why does the gui_frame_t needs to know the size of a gadget? Should this (and the titlebar) rather go to simwin.cc ultimatively?
I think I mentioned it earlier. I put some extra stuff in there so it would be easy to test, not having to open several files to tweak and test. This stuff will be moved later on...
Please elaborate. It seems you target are dialogues, which change their layout considerably when changing languages or switching sizes (instead just scale up). Or is this a misunderstanding?
Hmm, maybe. My alignment and window resize will not change the size of the GUI components other than outlined in the document I wrote. The collapse functions will be one of the last stages in this project.
Many simutrans dialogs have row of objects. Meaningful alignmet therefore would be a function like:
align( GUI_komopnenete_t *h_pos, gui_komponente_t *v_pos, alignenum a, koord offset );
To organise controls in rows, columns and grids will be handled by a layout control. The alignt_to() is the basic needs for the layout controls to work with. But who knows, maybe it changes down the road...
And for you Ters
Who wrote this?
Does it really matter? How would that information move this project forward?
Having the first indent level twice as large as the rest don't make any sense at all.
It might not make any sense to you, but it does to me and many others...
It's also a bit contradictory that it says use a tab character of four spaces. A coding style either uses tab character, or it uses spaces
In fact several IDE use tab characters as far as possible and then mix in with space to reach the intended indent.
Regarding this tab & space hickup...
If you guys had spent a few minutes to update the code style document, as I have requested several times, we wouldn't even have this discussion now...
I think you have spent more time, words and efforts to tell me how stupid my code is than it would have taken you to update the document.