News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

[Project] GUI Theme

Started by Max-Max, May 31, 2013, 11:12:48 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Miziiik

Yep, it's working for me too  ;) Good job!

But what about saving the selected theme? Now I must choose theme with every start of game  :-[
http://msim.8u.cz/ Můj web o hře Simutrans - Moje addons, návody, odkazy, apod.

Max-Max

@Prissi

I have managed to merge and solved most conflicts but It seems like we are developing the same code in different directions...
I know that you think my theme manager isn't needed, but it is a part of a greater plan I'm working toward.

I'm having a quite difficult time to sort this out because all theme drawing is done by the theme manager and there isn't much code left in the gui_button_t class.

But what I see as the biggest obstacles is that you have divided skinverwaltung_t::window_skin into several lists, one for each GUI control what it looks like.
Why are we doing this?
Do we need this to solve a problem?

To add more theme elements we would need a new const skin_besch_t* skinverwaltung_t::xxxxx and when analysing these images we need to know in what list an image reside in, depending on the GUI control type.

Why not keep all them images in one skinverwaltung_t::theme_images? If we need to add more themes we just add one more enum.

Since we have control of both writer and reader, we could go away from the indexed image numbers and use real words instead like:
image[button,up] =
image[button,down] =
image[button,disabled] =
image[button,focus] =
image[button,hot] =


The writer would translate this to indexes (or even better, store the name with each image).
Can we go back to use a single skinverwaltung_t::theme_images instead?

The theme selector turned out great :thumbsup: just unfortunately that the other stuff collided as it did...
- My code doesn't have bugs. It develops random features...

captain crunch

Please fix the path separator.

Max-Max

Quote from: captain crunch on September 14, 2013, 02:05:17 AMPlease fix the path separator.
Consider it done... ;)

It's quite hard to merge code that has taken different development paths. I have now kept as much I can and reverted some parts back to what it was. But don't worry Prissi. I do see your intentions and I will go through your arrangements by hand and try to apply it into the theme manager. But on one point I'm afraid I have to revert back all teh way; one list for the theme images. I renamed it to skinverwaltung_t::theme although.

Further down the road when we know more of the new theme format we can discuss another solution. For me it feels natural to let the theme manager read the theme-PAK into a temporary list and then free it because it has reorganised everything internally in objects.

Well, now it compiles and run :) Next step to transfer your efforts...
- My code doesn't have bugs. It develops random features...

Yona-TYT

Quote from: Max-Max on September 13, 2013, 09:32:00 PM
I'm on VC++ 2012 so I have to manually update the project and solution files... But it compiled with success  :thumbsup:

The last time I had tries to compile simutrans with VC++ 2012, there were some mistakes ... I would greatly appreciate if I get the code ready for copirlo only with VC++ 2012

sorry for the inconvenience :thumbsup:

prissi

The array in skinverwaltung is named "menu" since it comes from menu.xxx.pak. Hence the names, the symbols in skinverwaltung_t cam from "symbol.xx.pak" Hence I would suggest to keep it "menu".

Anyway, I look forward to a cleaner button_t (or rather several button classes, like pos_button_t, check_button_t, scrollbar_t, color_button_t spring to my mind). The static button images are not needed any more and do not take up much time to lookup, since the lists are much shorter. Hence they can easily replaced via direct lookup.

Max-Max

Quote from: prissi on September 14, 2013, 08:52:06 AMThe array in skinverwaltung is named "menu" since it comes from menu.xxx.pak. Hence the names, the symbols in skinverwaltung_t cam from "symbol.xx.pak" Hence I would suggest to keep it "menu".
I'm not really sure I understand exactly what you refer too. It is still a menu "object" I only renamed skinverwaltung_t::window_skin to skinverwaltung_t::theme, it is still a menu "object", or did I misunderstand something?

Quote from: prissi on September 14, 2013, 08:52:06 AMAnyway, I look forward to a cleaner button_t (or rather several button classes, like pos_button_t, check_button_t, scrollbar_t, color_button_t spring to my mind).
You are absolutely right, this is the second phase, redesign of the GUI class structure.

Quote from: prissi on September 14, 2013, 08:52:06 AMThe static button images are not needed any more and do not take up much time to lookup, since the lists are much shorter. Hence they can easily replaced via direct lookup.
Are you referring to the fallback code? Everything that has to do with theme images (or their replacement) are handled transparently through the theme manager. At this point there is no fallback at all (except a proxy rectangle for debug purpose).
- My code doesn't have bugs. It develops random features...

Max-Max

Quote from: Yona-TYT on September 14, 2013, 04:04:30 AM
The last time I had tries to compile simutrans with VC++ 2012, there were some mistakes ... I would greatly appreciate if I get the code ready for copirlo only with VC++ 2012

sorry for the inconvenience :thumbsup:

I thought I was the only one on VC++ 2012 :) I can include the VC++ 2012 project file in the next patch.
- My code doesn't have bugs. It develops random features...

prissi

Getting offtopic, but does MSVC not update older project files?

Max-Max

It is a manual process that I have to do every time I update from the trunk. The update is irreversible so I can't include the project file when I commit (or do a patch) and I have to instruct every one if I have added or remove files from the project. You can't open a 2012 project with 2010 (I was told when I made my first patch).

Besides that, isn't it time to move on? ;)
- My code doesn't have bugs. It develops random features...

Max-Max

@Prissi

For the moment I need to change the theme.dat format back to what is was before as one named object. I will change the object from WindowSkin to Theme and go back to one indexed image array (in .dat file).

I can write a tokenizer and a scanner as the next step so we can classify each word and do some rudimentary syntax check. It would then be quite easy to read this kind of .dat file setup.

obj=menu
name=theme

Window[Background] => back.0.0

Gadget[Close]    => gadget.0.0
Gadget[Help]     => gadget.0.1
Gadget[Minimize] => gadget.0.2
Gadget[Previous] => gadget.0.3
Gadget[Next]     => gadget.0.4
Gadget[Unsticky] => gadget.0.5
Gadget[Sticky]   => gadget.0.6
Gadget[Resize]   => gadget.0.6
Gadget[Goto]     => gadget.0.8

Arrow[Up]
Arrow[Down]
Arrow[Left]
Arrow[Right]

Button[Up,Left]
Button[Up,Middle]
Button[Up,Right]
Button[Down,Left]
Button[Down,Middle]
Button[Down,Right]
#Button[Disabled,Left]
#Button[Disabled,Middle]
#Button[Disabled,Right]

Checkbox[Unchecked]
Checkbox[Checked]

Scrollbar[Vertical,Background]
Scrollbar[Vertical,Knobb,Top]
Scrollbar[Vertical,Knobb,Middle]
Scrollbar[Vertical,Knobb,Bottom]
Scrollbar[Vertical,Up]
Scrollbar[Vertical,Down]

Scrollbar[Horizontal,Background]
Scrollbar[Horizontal,Knobb,Top]
Scrollbar[Horizontal,Knobb,Middle]
Scrollbar[Horizontal,Knobb,Bottom]
Scrollbar[Horizontal,Up]
Scrollbar[Horizontal,Down]


With such format the Artists doesn't need keep track of index numbers and if we want to add something it is still grouped disregarding of where it actually ends up. The writer only needs to map the "words" to index enums and no changes are needed in Simutrans (other than adding new enums to the index list).
- My code doesn't have bugs. It develops random features...

Dwachs

You may want to check the besch/writer directory. There similar parsing tasks are performed, not all dats have things indexed by numbers. Vehicles use letters to indicate directions for instance.
Parsley, sage, rosemary, and maggikraut.

Leartin

Your dat structure gave me an idea. It might be useful to divide a theme pak into various parts, like gadget, button, scrollbar - so that you don't need to create a full theme to change parts of it. There isn't that much difference between two themes just because one has light gray buttons and the other beige buttons, or ones scrollbar is rectangular and the others rounded. Certainly, it wouldn't be worth to create 4 full themes, but if it's just spare parts as a bonus it might come in handy (if it isn't too hard to do. I guess now is a better time to mention it than when everything is in place)

Just because it strikes me, why do you only mention left, middle, right for buttons? Either those are done in nine parts and therefore nine pictures, or you set where they should be cut with another method - but in that case, why not do the same with left, middle, right? I think it's confusing to use two different methods for button-cutting and would prefer 9 seperated images, as you could understand an image just by looking at it and don't need to read the dat.

Max-Max

#363
Quote from: Leartin on September 14, 2013, 05:43:32 PM
Your dat structure gave me an idea. It might be useful to divide a theme pak into various parts, like gadget, button, scrollbar - so that you don't need to create a full theme to change parts of it. There isn't that much difference between two themes just because one has light gray buttons and the other beige buttons, or ones scrollbar is rectangular and the others rounded. Certainly, it wouldn't be worth to create 4 full themes, but if it's just spare parts as a bonus it might come in handy (if it isn't too hard to do. I guess now is a better time to mention it than when everything is in place)
I don't know if you knew this but all image parts doesn't need to be in the same theme image. You can take the button images from one image and scrollbar images from another, everything doesn't need to be in the same image. So if I understand you right, you can achieve the same thing by using separate image files for different parts of the theme. After makeobj everything is collected in one single theme.PAK file. After som earlier discussions we came to the conclution that it was probably best to have all theme images in one single PAK file, so it can be easily distributed.

Quote from: Leartin on September 14, 2013, 05:43:32 PM
Just because it strikes me, why do you only mention left, middle, right for buttons? Either those are done in nine parts and therefore nine pictures, or you set where they should be cut with another method - but in that case, why not do the same with left, middle, right? I think it's confusing to use two different methods for button-cutting and would prefer 9 seperated images, as you could understand an image just by looking at it and don't need to read the dat.
I have kept the current format because we do this in smaller steps and not change to much at once. My goal is in the end to use the same strategy as the Torque game engine uses; a guard color. This means that you don't need to split up a button in 9 images, you just draw one button and paint in how it should be divided. Depending on how it is divided, the theme manager can apply the frame (3x3), horizontal (3x1) or vertical (1x3) rule to it.

***EDIT***
I will give you an example of the current system:

# BUTTONS #######################################
Image[12]=> button.3.0
Image[13]=> button.3.1
Image[14]=> button.3.2
Image[15]=> button.3.3
Image[16]=> button.3.4
Image[17]=> button.3.5
Image[6]=> checkbox.0.0
Image[7]=> checkbox.0.1

# HORIZONTAL SCROLLBAR ##########################
Image[24]=> horizontal.0.0
Image[25]=> horizontal.0.1
Image[26]=> horizontal.0.2
Image[27]=> horizontal.0.3
Image[28]=> horizontal.0.4
Image[29]=> horizontal.0.5

# VERTICAL SCROLLBAR ############################
Image[30]=> vertical.0.0
Image[31]=> vertical.0.1
Image[32]=> vertical.0.2
Image[33]=> vertical.0.3
Image[34]=> vertical.0.4
Image[35]=> vertical.0.5


..and this is the same with the proposed new system towards the final solution:

Button[Up,Left]     => button.3.0
Button[Up,Middle]   => button.3.1
Button[Up,Right]    => button.3.2
Button[Down,Left]   => button.3.3
Button[Down,Middle] => button.3.4
Button[Down,Right]  => button.3.5

Checkbox[Unchecked] => checkbox.0.0
Checkbox[Checked]   => checkbox.0.1

Scrollbar[Horizontal,Background]   => horizontal.0.0
Scrollbar[Horizontal,Knobb,Top]    => horizontal.0.1
Scrollbar[Horizontal,Knobb,Middle] => horizontal.0.2
Scrollbar[Horizontal,Knobb,Bottom] => horizontal.0.3
Scrollbar[Horizontal,Up]           => horizontal.0.4
Scrollbar[Horizontal,Down]         => horizontal.0.5

Scrollbar[Vertical,Background]     => Vertical.0.0
Scrollbar[Vertical,Knobb,Top]      => Vertical.0.1
Scrollbar[Vertical,Knobb,Middle]   => Vertical.0.2
Scrollbar[Vertical,Knobb,Bottom]   => Vertical.0.3
Scrollbar[Vertical,Up]             => Vertical.0.4
Scrollbar[Vertical,Down]           => Vertical.0.5


At the final solution we could expect something similar to this:

Button[Up]   => button.0.1
Button[Down]   => button.0.2
Button[Disable]   => button.0.3
Button[Focus]   => button.0.4
Button[Hot]   => button.0.5

Checkbox[Unchecked] => checkbox.0.0
Checkbox[Checked]   => checkbox.0.1
Checkbox[Disable]   => checkbox.0.2
Checkbox[Focus]   => checkbox.0.3
Checkbox[Hot]   => checkbox.0.4
Checkbox[Multi]   => checkbox.0.5


etc...

In this latter format only one image per state (down, up, disabled, hot, focus etc...) would be required, painted with guard lines.
- My code doesn't have bugs. It develops random features...

prissi

Did you had a look at my pak files: The is a pak file for checkboxes, scrollbars, posbuttons. This is way more efficient than a single list, and in the program you request from posbutton in skinverwaltung the image.

And the numbers did not stop people from contributing skins (although most several years ago and hence hidden deep in the forum). If you want to change the poak system, then please open another thread. But I would like to focus on getting a releaseable version with scaling interface across all dialogues.

Max-Max

#365
Quote from: prissi on September 14, 2013, 08:10:17 PMDid you had a look at my pak files: The is a pak file for checkboxes, scrollbars, posbuttons.
Yes I could notice the new arrangement because it broke everything I had done. With your solution we get one list for each GUI control. Meaning when we have more GUI controls there will be a lot of small lists, and everytime we add a new GUI control we need to create yet another list. When I require an image, I can't treat them all the same because I have to know what GUI control I'm dealing with, so I have to select the right list. You also pointed out that the theme manager was redundant because the skin list does what ever you think the theme manager is doing. I replied that the Theme manager can replace the skin list completely, it is not needed at all once the pictures are in the theme manager. So it doesn't make sense to split up the one list into several list which are only used once at theme loading.
Nothing else in Simutrans are going to access the images directly, it is only the theme manager that has the images and does theme drawing.

Quote from: prissi on September 14, 2013, 08:10:17 PMhis is way more efficient than a single list, and in the program you request from posbutton in skinverwaltung the image.
Can you please explain to me in detail how several small lists are "way more effective than a single list"?

Quote from: prissi on September 14, 2013, 08:10:17 PMAnd the numbers did not stop people from contributing skins (although most several years ago and hence hidden deep in the forum).
Well, and two legs never stopped people from walking either. Don't you want to improve readability? Du you seriously think that magic numbers are better than an alias?

Quote from: prissi on September 14, 2013, 08:10:17 PMIf you want to change the poak system, then please open another thread. But I would like to focus on getting a releaseable version with scaling interface across all dialogues.
You must have misunderstood me. let me quote myself:
Quote from: Max-Max on September 14, 2013, 03:10:17 PMI can write a tokenizer and a scanner as the next step so we can classify each word and do some rudimentary syntax check. It would then be quite easy to read this kind of .dat file setup...
I mean that we will leave the current system just the way it is, no changes for the artist, no changes in the writer/reader, one list, just as before. I put the manager in place and transfer all responsibilities to the manager, regarding GUI theme drawing. At this stage the GUI has been separated from the theme responsibilities.
- My code doesn't have bugs. It develops random features...

prissi

The GUI often requires image number 22 in tha image list. Hence it has to travel through the list to get image 22. It is also easier to customize the theme, when I have small paks for single function. I could even lets the user cherry pick. The monlytic lists are also not very good for extensions.

Honestly, I do not understand: There is a system for image management in Simutrans, which every other part of the program is using. There are buttons for components, where drawing a components is what I would expect from an object. I fail to see how an extra layer in between helps to keep the code easy to understand and easy to maintain. But I will wait for your theme manager.

Yona-TYT

@Max-Max
Congratulations, the patch looks great :thumbsup: ..... regards!!


Max-Max

Quote from: Yona-TYT on September 17, 2013, 12:57:54 AM
@Max-Max
Congratulations, the patch looks great :thumbsup: ..... regards!!
Thank you, but I don't want to steal the credit from Prissi. It is Prissi that has done the Theme loader... My patch was never added, but I'm soon ready to send a new patch.
- My code doesn't have bugs. It develops random features...

Yona-TYT

Thanks to Prissi We also, Both worked hard at this :thumbsup:

prissi

As written before, the theme loading was rather a harm;less two evening patch. I would not have done it (despite on the eternal todo list) if Max-Max would not worked on theme support.

Markohs


Max-Max

#372
Quote from: prissi on September 17, 2013, 09:44:33 AM
As written before, the theme loading was rather a harm;less two evening patch. I would not have done it (despite on the eternal todo list) if Max-Max would not worked on theme support.
It wasn't done in vain. The separated image lists gave me a hard time. I have kept the most of your code, but rearranged it a bit. You did a good work all together ;)
- My code doesn't have bugs. It develops random features...

kierongreen

The fact that there's two developers working on this and combining the best ideas from both actually shows how important a feature this is :)

Max-Max

@Prissi

Can you explain your intention a little bit regarding the organisation in the themes folder when we have multiple themes.

As I understand there should be one xxx.tab file for each theme xxx.pak file + one global themes.tab file.
Does the themes.tab file points out the current selected theme pak file?

Are the intention that xxx.tab file and themes.tab file are cascading? Loading xxx.tab and then themes.tab (global)?
- My code doesn't have bugs. It develops random features...

Miziiik

I have a question... Is programmed saving of chosen theme?
http://msim.8u.cz/ Můj web o hře Simutrans - Moje addons, návody, odkazy, apod.

prissi

Not yet, when finished it would be added to simuconf.tab and the default.sve file.  Reusing what is there already, i.e. for language selection.

But the theme manager is still very much a work in progress, so I did not yet add it.

Themes at the moment will come with one pak file per theme. If teh graphics in it are sizeable then more tab file may refer to the same pak obviously. Teh are either stored in themes/ in the simutrans program folder or the user folder.

On startup, the previously used theme will be loaded (so a tablet always start with its matching theme, not matter what pak was selected). This can be overridden by simuconf.tab.

Again, if you like I could add this today. Saving themes.tab in the program dir coudl fail, because on Linux (debian) as well as standard windows installs simutrans cannot write there.

Max-Max

#377
@Prissi,
I'm very soon ready to submit a patch, so It would be good if you could wait until then.

Can you please answer your thoughts around this?
Quote from: Max-Max on September 19, 2013, 02:09:19 PM
@Prissi

Can you explain your intention a little bit regarding the organisation in the themes folder when we have multiple themes.

As I understand there should be one xxx.tab file for each theme xxx.pak file + one global themes.tab file.
Does the themes.tab file points out the current selected theme pak file?

Are the intention that xxx.tab file and themes.tab file are cascading? Loading xxx.tab and then themes.tab (global)?

*** EDIT ***
My intention was to include all Artist parameters in the theme-PAK file, when we have a new theme-PAK format. Then have one global theme.tab file set by the user to override the Artist's settings. This global theme.tab file is always loaded last regardless of selected theme.pak. This is because a portable device always want large buttons etc...

For example, the button size is defined in this way:

1. Read selected theme.pak.
2. Calculate the button size to the PAK image size for a button.
3. Override with the Artist's button size from the PAK file. (for now a .tab file)
4. Load the global .tab file.
5. Override again with the user's button size.

If no theme-PAK has been specified, load menu.default_theme.pak

Since we have no new theme-PAK format yet, we can use a theme.tab file for the Artist's. Later on when the Artist's params are in teh theme-PAK, this .tab file can be a user configuration for this specific theme-PAK.
- My code doesn't have bugs. It develops random features...

prissi

One pak can be used by mane theme.tab files; for instance if we use your 9 image buttons, you can either have non-scalable three button images (only top images, rest empty) or scaleable one. Then you could use a theme in standard, large and tiny (or whatever typical sizes there will be). If not scaleable (which will be probably more common, but I do not know) then you have on tab and one pak.

I think I would always load theme.tab (the global one) with a non-scaling theme and only an essential number of images and afterwards any special theme. The latter can fail, so theme.tab must be anywhere there. If this fails, well then the installation is damaged anyway.

I would not cascade themes. I do not see any advantage. But if ...

Max-Max

#379
Quote from: prissi on September 19, 2013, 11:04:33 PMOne pak can be used by mane theme.tab files.
Good point, sounds great :thumbsup:

Quote from: prissi on September 19, 2013, 11:04:33 PM...for instance if we use your 9 image buttons, you can either have non-scalable three button images (only top images, rest empty) or scaleable one.
I intend to simplify the image process for the Artist. The artist doesn't need to chop up the images in pieces. There are not 9 or 3 images for a button, only one. The artist then use a guard colour to paint in how the button will be divided, by drawing cut lines over it. I have posted a sample pictures for this many times now.

The theme manager can see, depending on how the guard lines are painted, what theme element style (theme_element_t class) to use for it. It will be chopped up in 9,3 or none pieces and stored internally. If no guard lines are painted at all, we have to decide if it means that no scaling will be done, just use it as a single picture, or if it by default means; chop in 9 pieces and allow scaling, or cop in 3 pieces along the largest side...

The guard colour scheme will be tailored for the theme type it represents. The fundamental idea here is to let the Artist draw the theme element as one single picture. Depending on what it is, we will expect different guard colour lines. For example a window frame will not only have borders and background, but also a caption (title bar).

There is no need to discuss how this is done now, because it is just ideas so far. When we get there we will see what guard colour scheme is the most practical per theme element.

In addition to this I intend to let the artist add parameters to more precisely control the behaviour of the specified theme element.
If several GUI controls are using the same image, I intend to let the Artist be able to specify a "link" to another theme image with the same set of rules or just the same image but a new set of rules to reuse the images and internally use the same theme_element_t object.

Quote from: prissi on September 19, 2013, 11:04:33 PMThen you could use a theme in standard, large and tiny (or whatever typical sizes there will be). If not scaleable (which will be probably more common, but I do not know) then you have on tab and one pak.
I think I need to make clear what I mean by scaling/resize. There are basically 3 types of "scaling" that I can think of;

1. Stretch
The images are streched in size.

2. Extended
The images are extended instead of stretched.

3. GUI scaling
When a window/dialogues is resized all GUI controls scale in proportions.

I have always been talking about 2 Extending. The actual size of a GUI control is set in the theme.tab and stay at that size. It will not stretch the images and the GUI will not scale when windows/dialogues are resized. Symbols will not stretch to fill the client area, it retain its original size but are centred within the client.

When we use a hires-device these symbols can be to small to see. To solve this I was thinking that the Artist could provide several images of the same theme element, but in different sizes. The theme manager will pick the image with the size best matching the client area.

This is also very useful for the collapse system to free up more space on small portable devices.

Quote from: prissi on September 19, 2013, 11:04:33 PMI think I would always load theme.tab (the global one) with a non-scaling theme and only an essential number of images and afterwards any special theme. The latter can fail, so theme.tab must be anywhere there. If this fails, well then the installation is damaged anyway.

I would not cascade themes. I do not see any advantage. But if ...
I didn't mean to cascade the PAK-images, only the parameters defining size and behaviour.

The theme manager can substitute missing images, or reload the default theme if there was just to few images available. For example, if there is only one frame image, it can be used for buttons, frames or anything with a rectangular shape. In worst case it can even create a 3x3 pixel frame image with the highlight, face and shadow system colours.

To illustrate the combinations I have attached 6 cases of how a the guard lines can be used in a button.

NoPadding
If no guard colour is detected, all padding are removed.

KeepPadding
The guard colour shows the bounding box and all padding are kept.

HorizontalStyle
If 3 vertical guard lines are detected, the button can be extended horizontally.

VerticalStyle
If 3 horizontal guard lines are detected, the button can be extended vertically.

FrameStyle
If a 3x3 grid is of guard lines are detected, the button can be extended both horizontally and Vertically.

NonUniform.
The 3x3 grid doesn't need to be equal in size. As long there is 9 rectangles, they can have any size so non uniform buttons can be created.
- My code doesn't have bugs. It develops random features...

Ters

The cutting lines is a good idea. I think makeobj should be the one to do the chopping, as it chops up all other images already.

Max-Max

That was my first intuitive thought too. But since the theme system is still under development we do not know yet exactly what makeobj have to do. To be able to test and develop I use the old skin format and have the theme manager to do the chopping.

Since we already have the functionality in the theme manager we could try to migrate that part to makeobj or just leave it as it is. If we place the intelligence in makeobj we have to update two programs if we improve and change stuff. If the intelligence is in the manager, It might be enough to only update the manager. In that case makeobj only need to pack the full images and doesn't need to worry about guard colours, lines overlays etc...

We will see when we get there...
- My code doesn't have bugs. It develops random features...

prissi

For the moment I would suggest to have the artist chopping the images, and worry about that later.

Max-Max

For this precise moment I will leave it exactly as it is...
- My code doesn't have bugs. It develops random features...

Max-Max

Okay, we are getting closer to the next patch and while I was testing it struck me...

Now when the theme is loaded, how can we select the skin from the pak-set? Maybe the easiest way would be for the artist to include a menu.xxx.pak + theme.tab file. The pack selector can then scan the pack directories for pak related themes.
A new setting "Autoload pak theme" could have a pak-theme to load automatically when the pak-set is loaded or not.

Thoughts?
- My code doesn't have bugs. It develops random features...