First of all, the majority of the gui komponents are returning their bounding
box on get_groesse(). I have found one exception and that is the chart_t control.
The window's get_groesse() (actually called get_fenstergroesse) is returning the bounding box and get_client_windowsize() is returning the window's bounding box - title bar, so the gui isn't consistent.
I think we all agreed on that the GUI needs a deep overlook, this will also mean that some things will change. If we want everything to be like before, their isn't any point in remaking the GUI
What I have seen is that we need to make the GUI consistent:
get/set groesse deals with the bounding
get/set client size deals with a components client area
. This has to be implemented in all gui controls, not only in the window.
The frame_t needs to be a more like a Window class, an aggregation of basic gui components to build the window.
Most of the gui components are derived from the base class komponente_t, even in cases when it is clear that they would benefit more from being derived from another gui component. There are also some very common component combinations that could be a component on its own. I have already sketched on a gui class hierarchy that would reduce code and take more advantage of OO Design.
The "active" border option in simutrans has always made me a bit puzzled... What is it good for? The active window changes colour anyway and it makes the tool menus look silly if the rows are of different length. I think we can let this one go to the history and instead improve the look of the active window. This thin line is also drawn outside
the window's bounding box, it draws over the neighbouring window when snapping.
Now when we are targeting small screens as well (portable devices), all windows must be able to handle the given bounding box in the best way it can. If a windows border is thin, thick or borderless, the whole project would have failed if the window cant handle that
I have Google both BeOS, KDE, Mac OS and GTK, the majority of themes have a window border. In those rare cases where the scrollbar has been at the very edge, it was a borderless theme.
If MS screwed things up or not isn't really relevant. Today we are used to see things in a certain way and we have become to accept this as the "standard". You asked for the community's view in this subject and the few who left a comment where in favour for scrollbars inside the border.
I think this isn't really the time to argue about this because what it becomes at this stage is only temporary. I think it is more important that we can move on with the project and as I have explained several times; as long you want small patches, there will be some phases that looks a bit odd, this is one of them.
I will go through all the dialogues several times to slowly update them with the new gui stuff and structure, this isn't the final look and behaviour. I first need the tools to work with (client concept, gui components and structure) before we can get into details if a scrollbar should be placed a few pixels here or there. The best would of course be to make even this configurable
I think I have spent more time to create mockups, write specifications and explain myself then I have been coding. So can we please move along?