[Project] GUI Theme

[Leartin]

While I am interested in the GUI topic, this thread is way to technical for me to follow. However, as Max-Max asked for a picture of a half scrollbar:


this is r6658, but I guess if Max-Max hasn't seen it before, it has a low chance of being fixed by now.

I believe the mistake here is that the broadness of the scrollbar seems to be read out of the image, while our approach was to let the slider rest on a thinner rail, as seen in the skins.png. As this is a version not officially released I can't give you access to it, but using a window skin similar to this should recreate the effect.



As for a solution... well, I guess thats more or less a problem of the intermediate state. We plan to release the next pak version around christmas, so if at that point your work at the GUI-themes is advanced enough to fix the issue with a theme.pak instead of the skin file, I (we) can bear the half scollbars (or rather extend the rail with a color similar to the background, that should work as well)


Another Mistake was found by Sybill, I'll just link to the thread instead of the image:
http://www.simutrans-forum.de/forum/index.php?page=Thread&postID=96956#post96956
( I don't know what happened there, but the button is to far on the left, not really gone, so I suppose it's a similar mistake)

[Max-Max]

@Leartin

Thank you for the update. This is probably why I haven't seen it. I'm using the standard skin file and the 96Comic.
I think you are on to something, I will have a look at it ASAP.

Is it possible for you to send me the WindowSkin-PAK so I can test? If you don't want it to be public, just send it to me in a private message. I will keep it to myself for test purposes only...

[Leartin]

Sent you the skin pak.
On closer inspection of sybills button, I realized it's offset fits my assumption. Probably the rightmost button hides some pixel, which make that button effectively 64px broad, centered in the middle.

If this is the same for other mistakes as well, I think it would be fair to say it is a mistake of the image, which shouldn't have any pixels beside the button graphik in the 64x64 box. Though it's different for the scrollbar - Maybe you could check the size of the slider and the arrow buttons as well, using the broadest/highest size you got. Or, if no other pak has this particular problem, leave it as it is. It's a compatibility-thingy, so if the old stuff is compatible that should fit the bill. This design is fairly new, and it can adopt for the time before it is changed into a theme pak.

[Max-Max]

Thank you. With your skin PAK I can see the problem and I have a quit good clue to what it might be. I will get to it ASAP.

[prissi]

As to the theme manager: Ters put it much better. We have the skinverwaltung. New object will always reside in the same structure. Hence it is a very convenient abstract, as there is alway a valid thing in the same location. The only thing left is to notify the button routine (and scrollbars) that they need to recalculate their sizes.

Since loading themes requires parsing the theme.dat as well as the loading theme paks (which load themeselves into the skinverwaltungs) very little extra code to simwin.cc would result in a dynamic loading of themes. Then the UI to it coudl derived from the savegame frame; especially if there is a preview image savegame frame requested in some other places as well. So it is only on this certain case I do not thing to replicate a something that is already there and rather use the code fully.

NB: verwaltung <-> administration/management.

[Max-Max]

The theme manager is not only loading images, it also keeps track of how a theme element should be drawn. The Artist could for example have configured a background to be transparent, Blended, Solid Colour or Image filled. The GUI control doesn't need to know this, it only tells the manager to draw the background for theme x.

I'm separating the theme from the GUI control so the GUI doesn't need to know how to draw the theme. As it simplest form now, it might look like it doesn't do more than load images, but it will do more than that when it is implemented.

Further down the road when the structure start to settle in, it might be an idea to derive the theme manager from the skinverwaltung class. Just bear with me while the theme manager start to settle in.

[Max-Max]

After some request I have created a GUI Theme thread aiming artists, no code discussions 

@Prissi
If you haven't started yet, I have soon a new patch ready, fixing the half scrollbars.

[prissi]

I am only halfway through, I had a nasty bug when loading games before internal rev. 111005 failed with out of index errors. Anyway, this is fixed, so hopefully a patch tomorrow.

[Max-Max]

Failing load games are quite an important issue

Okay I will wait for you, merge and make a new patch then...

[prissi]

Ok, I deferred so far the themeslector GUI do to lack of time, sorry. You will find here a theme. Copy standard.tab and menu.standardtheme.pak into the program theme folder (need to create it). Then rename standard.tab to theme.tab It should look like before. YOur can pak the skin.dat with "makeobj pak menu.standardtheme.pak" and create other themes in the same way. The diff is also in the zip.

[prissi]

A version with some bugfixes and a theme selector (work in progress). You need to define a "name="", and size="") in the tab file of the theme.

[Max-Max]

@prissi

The Simutrans installation is not longer valid because of a missing image. It complaints about the square button, but I think it does that because it is at the end of the list.

I think this happened when you added the pos button to the structure. I have always tried to be compatible with the current skin format, just to avoid the situation where Simutrans wont start without a PAK update.

I thought we would focus on what we already have and put the underlay theme structure in place before we started to add new features?

Was this you intention or an accident (not to start Simutrans without the new pos image)?

***EDIT***
I used makeobj pak menu.standardtheme.pak with the skins.dat and images from your standard.zip:

back.png
button.png
gadget.png
posbutton.png
scrollbar.png
squarebutton.png

I created the theme folder in the Simutrans root and copied menu.standardtheme.pak and your standard.tab.
I renamed standard.tab to theme.tab.

Still same error on startup...

You need to define a "name="", and size="") in the tab file of the theme.

name is the theme name, right? but what is size?

PS. how is it going with my last patch? If you haven't started yet let me know and I will send you the next instead.

[eipi]

Try moving menu.standardtheme.pak into the pakfile directory, this has worked for me.

[prissi]

Assuming you are using the latest patch and the previous files. You need a new directory, named "themes" in the folder where the executable is. Copy menu.standardtheme.pak and the tab file there. Simutrans will (by default) now load this theme.tab and will ignore all skins.

Not using skins is intended. When you use 9 component buttons, and titlebar images, it has to go anyway. As said before, we will get plenty of themes fast. I am not worrying about braking the compatibility. The next simutrans will have some default themes in the themes folder.

About the patch: Well I missed it somehow, so I would not mind an updated version.

[Max-Max]

Copy standard.tab and menu.standardtheme.pak into the program theme folder (need to create it)

I just followed your instructions
Okay so the folder should be themes not theme

When I renamed it to themes it started, thank you.
I will merge your patch into my code before I post the patch...

[prissi]

Use this please, it will load and apply themes, and you can call the dialogue from the display options. You can have a themes folder either in user settings or in the program folder.

[Max-Max]

Maybe it's me, but I'm no expert on SVN.
When I try to apply your patch it complains about the path differs in the patch from what is installed on my system. Whatever solution I chose I end up with either a directory called trunk with all the files or half the patch wouldn't apply (for reasons I don't know).

Can you make a patch without the trunk path?

[prissi]

As it contains the base.tab below trunk. To apply (I assume commandline and directory is below trunk)

patch -p0 -i thememanager.diff

If you do not care about base.tab, cd to trunk to and then

patch -p1 -i ../thememanger.diff (or where your file is)

But I happily commit it, if you are ok with it. Makes things easier.

[Max-Max]

What is the size parameter you refer to in the theme.tab file doing?

I have not yet tried your instructions, I'm refining error handling in the theme manager first...

[prissi]

I am not sure what error handling. My patch load new themes and instantaneously applies them by just replacing the images in skinverwaltung automagically. No need for an explicit theme manager. Although it would make sense to have the size definitions as well as the images and the loading of the theme.tabs in their own file.

[Max-Max]

I'm improving the error handling in my theme manager, not your patch. I will fix this before I apply your patch.

But what is the size parameter in theme.tab referring too? Size of what?

As I said so many times before, some parts of these small updates doesn't make sense yet...
They are still work in progress and a part of a greater plan which may not be 100% clear at this point. I could spend a few weeks on writing a draft to explain all this, but since no one even wants to spend 5 minutes to read the current draft, I see no point in writing it further.

I explained this before, the GUI component and the actual drawing are separated. The GUI component tells the theme manager to draw a theme element within a bounding rectangle. It doesn't need to know if this is a frame, horizontal, vertical or symbol theme type.

When the theme manager initialises, it creates theme element instances of the type fitted for the available images and later on to the artists specification. In this way the GUI controls doesn't need to have multiple code for different scenarios.

Handling this through polymorphism, the calling process becomes clean because the theme manager just pick the requested theme element instance and calls the virtual function display(), regardless of the theme type. No need for endless switch case statements.

When I get your patch in place I will move some of it into the theme manager, to handle load/unload and theme browsing from there. Encapsulating all theme related functions into the same object makes it more structured and clean.

I will implement your patch as soon I have finished some error handling in my theme manager...

[prissi]

OK, I submitted my final, cleaned up code to the svn. The gui_theme.cc may be already something, what you envision for your theme manager.

[Max-Max]

@Prissi

Thank you for the commit but  I can't compile due to the file gui_theme.cc and gui_theme.h are missing in the SVN trunk.

[prissi]

I knew I missed something with such a large patch. Sorry, you have to wait another 10 hours until I am home again.

[Max-Max]

I knew I missed something with such a large patch. Sorry, you have to wait another 10 hours until I am home again.

Maybe I need to get out from my cave for a while

[Max-Max]

@Prissi,

I saw that you had commited depot_frame.xx in 6703, but the Trunk can still not be compiled without the gui_theme.xx files
(I guess you forgot about it)...

[prissi]

No I fix it with r6701, updated it, commited and got back to 6701. Still at work, babysitting our growth reactor.

[Max-Max]

No I fix it with r6701, updated it, commited and got back to 6701. Still at work, babysitting our growth reactor.

Now you got me confused 
What did you fix in r6701? I'm browsing the HEAD rev. in repository and I can't find gui_theme.cc or gui_theme.h anywhere... Well I saw you had commit something in r6703 so I thought you where back home again...

Growth reactor, sounds interesting. Can we put Simutrans in it 

[kierongreen]

Prissi has said he will add gui_theme.cc and gui_theme.h when he gets back home this evening

[Max-Max]

Prissi has said he will add gui_theme.cc and gui_theme.h when he gets back home this evening

I kind'a guessed that too. Maybe you can explain what he meant with this "No I fix it with r6701, updated it, commited and got back to 6701." That was the confusing part...

[kierongreen]

It might be easy to forget but English isn't prissi's native language - just be patient wait for later this evening and am sure everything will be sorted

[prissi]

Code Select Expand


svn up -r 6701
[now fix depot, compile, test]
svn up
svn commit -m "..."


Anyway, gui_theme.* are submitted. (Actually, with my horrible spelling and sentences, it should be clear that english is far from being my strong side).

[TurfIt]

Did you submit the wrong files? r6704 still doesn't compile.

Code Select Expand


In file included from gui/display_settings.cc:29:0:
gui/themeselector.h:27:7: error: extra qualification 'themeselector_t::' on member 'rdwr' [-fpermissive]
make: *** [build/default/gui/display_settings.o] Error 1


[Max-Max]

I have never complained about any ones English, I'm not native English myself. I was just confused by the sentence which I understood probably must have been a typo, and I couldn't figure out what it was supposed to be.

I'm still confused what the fuzz about r6701 is? All I wanted was the gui_theme.cc and gui_theme.h that was just added today in r6704. Maybe I was unclear somewhere earlier in the thread...

Anyway, I have the files, thank you Prissi.

Mean while TurfIt seems to have problems compiling it, I will give it a try and see...

[Max-Max]

I can confirm that I got lots of compiler errors, but after I started over with a fresh checkout it compiled fine. I'm on VC++ 2012 so I have to manually update the project and solution files... But it compiled with success