Font height, cell height and baseline

[Max-Max]

I'm trying to fix all dialogues to use the skin parameters. When it comes to fonts I saw that the font height is hard coded to 11 pixels.
It also seems to be only one font loaded in Simutrans, but the info struct is static and can't be reached.

Is there a way to get the font's baseline and line hight (from the font data)?

[prissi]

In bdf yes in bitmap fonts no. Dynamic resizeable dialogues are planed (and halfway actually done) but it is a very large task making them all dynamic in size. (Simutrans Iron Way has fully resizeable dialogue or so I was told btw.)

Since 90% of standard simutrans dialogues are identical to experimetnal, it would be only fair to do this in standard first; at least for the dialogue in both. (Just remember: simutrans experimental profits also a lot from bugfixes in standard; not to mention new features like the network code, minimap line display, or departure boards).

[jamespetts]

I agree with Prissi on this - Experimental does not generally change the base structure of dialogue boxes or the GUI, although does make changes where it is necessary for the GUI to work with some Experimental specific function. It will be easier for Experimental to stay in synchronism with Standard if the base code of the GUI remains closely similar to that in Standard.

[Max-Max]

I have not changed the structure of the GUI classes, only replaced as many magic numbers as possible to use the defined skin parameters. I'm try to make the GUI as consistent as possible.

The tab and chart control's exterior boundary was not aligned witht he graphical representation, so these are the only ones I have put some more efforts on so far.

I got the impression that the experimanetal more or less went on its own path and new features was transferred back to the standard edition if they was useful.

What I had in mind was to firts prepare the GUI for the skin system and then expand the skin system with more details.

For the moment I have all time in the world and can spend day and night on development, not just a few hours here and there.
My guess would be to have the first step done in a week or so.

So what do you suggest I do? Throw away my work or continue with phase one and then merge in the resize code?

[jamespetts]

I must confess, I am not particularly familiar with the innards of the GUI code. I do not know exactly what impact that this will have on merging changes in from Standard. I notice in the screenshot that you have the Windows-like GUI setting enabled; is that intended? Does your system work with the default setting?

The relationship between Experimental and Standard is that Experimental, whilst a permanent fork, frequently merges in the latest changes from Standard. The fewer differences that there are between Experimental and Standard, the easier that it is to merge in those changes. For that reason, I generally avoid non-functional changes in Experimental compared to Standard (in other words, changes to the code that do not substantially alter the features of the game). For the most part, if the code in Experimental is intended to do the same thing as the code in Standard, the idea is that it should do so in the same way. This rule is not entirely without exceptions, but any new exceptions would require a justification commensurate with the degree of difference from the Standard code and the consequent additional work required to merge it. In order to evaluate in this case what that level of difference and difficulty would be, it would be necessary for me to spend a considerable amount of time delving into the innards of the GUI code, which time I should rather spend on more functional activities, such as implenting the industry boost feature and fixing bugs.

This is the sort of idea that might work best if implemented in Standard first then merged back into Experimental. If you are really keen on this idea, you might want to look at creating a patch for Standard.

[neroden]

I got the impression that the experimanetal more or less went on its own path and new features was transferred back to the standard edition if they was useful.

Yes, but experimental has been focused on "under the hood" improvements, not on UI changes.

If you like working with git and have a github account, you might consider doing what I have done for a couple of projects.
(1) make a git branch from standard (on git, standard is "aburch/master") for your work (call it "standard-gui-fixes")
(2) make a git branch from experimental (on git, experimental is currently "jamespetts/112.x-private-car-merge", which is a little confusing, but there you go) for your work (call it "experimental-gui-fixes")
(3) do your fixes on "standard-gui-fixes" branch, compile and test
(4) then merge them to "experimental-gui-fixes" branch and do any further fixes needed there, compile and test
(5) when done, merge "aburch/master" into standard-gui-fixes, then diff aburch/master standard-gui-fixes, and send that diff to the 'standard' developers
(5) when done, ask James to merge your "experimental-gui-fixes" branch

This is easier than it sounds.  If there are long delays in getting the patch accepted in standard, you can just keep merging aburch/master into standard-gui-fixes and resubmitting the patch, and you can just keep merging those changes into experimental-gui-fixes.

[Max-Max]

I have a GitHub account but I'm used to subversion and I'm having a hard time to learn Git. I have already a clone of James latest branch, as you mentioned and made a new local branch called skin-fix.

Because the "Simutrans Iron Way" is implementing resizeable windows I put the project on hold to see what you guys suggests. If you think that my work isn't a waste of time I will be happy to continue.

So far I have not changed any functions or function calls, only make use of the predefined skin parameters such as D_MARGIN_LEFT, D_MARGIN_TOP etc...

I did introduced one new define: D_GADGET_SIZE to define the size of a gadget in the title bar. This is currently set to TITLEHEIGHT So other than this everything is the same as before.

I don't know what James mean with "Windows-like GUI setting enabled", is there another setting?
Are you referring to the button right feature? In that case, yes. I'm testing that option too. If there are more options to test with I will be happy to test them too, just let know how to enable them. The screen shot was taken from your 112.x.-private-car-merge with my GUI improvments applied. I don't know what configuration you have there...

I can switch over my work to the standard Simutrans version and then merge it into james version.

This is my roadmap for GUI.

1. Remove as many magic numbers as possible and replace them with the proper skin defines (such as D_MARGIN_TOP etc...)

2. Create client areas for controls. This will make it a lot more easy to work with. Now you need to include the TITLEHEIGHT and MARGINS for some controls but not for others, not consistent.

3. Expand the skin model so a window border, title and gadget buttons (new control) can be skinned too.

I will start with 1) and then we will see how we proceed...

Alright then, I will move my work to the Standard Simutrans and continue where I stopped...

[Max-Max]

By the way, is this the correct repository for the Standard Simutrans?

svn://tron.homeunix.org/simutrans/simutrans/trunk

It is a Subversion server 

[Markohs]

Yes.

[Max-Max]

Alright, then I'm on it... Back to what I love most, coding... 

[jamespetts]

There is indeed a setting for a Windows-like GUI: it is window_buttons_right in simuconf.tab. When this is set to 1, the windows have borders and the buttons are on the right, just as in your screenshot.

[Max-Max]

I enabled the borders to easily see the boundaries.
Yes, I'm testing different combinations of those settings, even with different langages to see the font behaviours.

It works fine so far...

Under my 14 years of developing thermal printers, I picked up one or two tricks to handle bitmap fonts. I will see if I can figure out a way to make a better estimation of the baseline and line height.