News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

[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.

Max-Max

Quote from: TurfIt on August 29, 2013, 10:22:41 PM
SDL2 appears to have some sort of support for touch/gesture events. They're disabled in the current testing SDL2 backend, but might be worth investigating if someone wants better tablet support...

To handle this as transparent as possible I think the best would be to translate these events into Simutrans events, like swipe_left, swipe_right. A long press could be translated to a right_click etc...

In an embedded project I wrote a GUI system where all sensors (encoder and a button) was scanned and translated into several messages. This allowed me to create virtually controls.

The button produced:
button_down
button_up
button_click
button_repeat
button_long_click

After the button_up message the button_click or button_long_click was sent depending on how long the button had been down.
button_repeat was sent periodically as long the button was down.

The encoder produced:
button_right
button_left
button_forward
button_backward

On each clock wise turn the button_right message was sent and on counter clock wise turns, the button_left.
If the encoder was turned fast, it sent forward and backward messages instead.

So here I could create 5 buttons from only 2 available controls.

You may ask why button down/up was sent, even if a click message was sent right after?
It is not up to the translator to decide what the system should trigger on. It was each individual GUI component that decided what messages to react on. Some needed just the button_up or button_down messages, other only listened to a button_click message.

By using the same technique in Simutrans we can simulate gestures on a desktop system or a mouse on a tablet.
- My code doesn't have bugs. It develops random features...

Ters

A challenge with programs portable across different systems is dealing with the different standards for each platform. Simutrans clearly has its own look, but should it have its own rules for input or just rely on higher level input from the OS?

Dwachs

Maybe you figured the answer for these questions already...
Quote from: Max-Max on August 18, 2013, 11:36:38 PM
Why are we "registering" each image? Is it here we unpack them from the PAK file format? (recode?)
Images are stored internally as 16bit numbers to reduce memory footprint of map structures. Registering generates the id from the pointer (and fills internal structures for further use).
Quote
Why are the registered images stored with realloc and not in a std::vector or other stdlib container (or is this code from the C version of Simutrans)?
The realloc is only used for the growing list of pointers to image structures.

As to the getter-setter discussion: Did not read much of it, but I would prefer public member variables for trivial members instead of get/set methods (just for code brevity).
Parsley, sage, rosemary, and maggikraut.

Fabio

Quote from: Ters on August 31, 2013, 06:09:38 PM
A challenge with programs portable across different systems is dealing with the different standards for each platform. Simutrans clearly has its own look, but should it have its own rules for input or just rely on higher level input from the OS?
Quote from: Ters on August 31, 2013, 06:09:38 PM
A challenge with programs portable across different systems is dealing with the different standards for each platform. Simutrans clearly has its own look, but should it have its own rules for input or just rely on higher level input from the OS?

Maybe it's time for Simutrans to virtualize mouse gestures. Gestures (and key presses) could be registered and associated to commands at runtime, as mapped in a tab file.
click, ctrl-click, right click, long press, drag, ctrl-drag and so on could be mapped to Simutrans GUI events in a simuevents.tab file so that it can be OS consistent or player customized.
Even individual tools could have custom settings for their behavior: base, ext1 (ctrl), ext2 (shift), ext3 (ctrl shift). They could be custom mapped according to the device or player preferences.

Max-Max

Quote from: Fabio on August 31, 2013, 09:24:27 PM
Maybe it's time for Simutrans to virtualize mouse gestures. Gestures (and key presses) could be registered and associated to commands at runtime, as mapped in a tab file.
click, ctrl-click, right click, long press, drag, ctrl-drag and so on could be mapped to Simutrans GUI events in a simuevents.tab file so that it can be OS consistent or player customized.
Even individual tools could have custom settings for their behavior: base, ext1 (ctrl), ext2 (shift), ext3 (ctrl shift). They could be custom mapped according to the device or player preferences.

You described exactly what I meant :thumbsup:

With a layer in between translating mouse/keyboard/gestures into "standard" Simutrans events would take care of the platform differences.
- My code doesn't have bugs. It develops random features...

Max-Max

#285
Quote from: Dwachs on August 31, 2013, 06:26:25 PM
Maybe you figured the answer for these questions already...Images are stored internally as 16bit numbers to reduce memory footprint of map structures. Registering generates the id from the pointer (and fills internal structures for further use).The realloc is only used for the growing list of pointers to image structures.
Yea, I figured that out. How ever, by storing the bilt_becht_t as an array makes it cumbersome to delete images and I guess this is why we keep adding them at the top. One "simple" solution would be to replace the array with a std::map<image_id,bilt_becht_t*> container object. To get the pointer we use the find(KEY) member. In this way we can delete and add images as we like on the heap.

Quote from: Dwachs on August 31, 2013, 06:26:25 PM
As to the getter-setter discussion: Did not read much of it, but I would prefer public member variables for trivial members instead of get/set methods (just for code brevity).
Ahh, good to hear that some one shares my opinion :)
- My code doesn't have bugs. It develops random features...

kierongreen

That would make it much much slower to look up images though!

Max-Max

Quote from: kierongreen on September 01, 2013, 12:15:21 AM
That would make it much much slower to look up images though!
I'm not 100% sure what algorithm is used, but I think it is b-tree. It might be surprisingly faster than you think. There is only one way to find out ;)

I guess we have to think about the pros and cons... Be able to use the memory more effective or a faster lookup...
Well, it was just a thought...
- My code doesn't have bugs. It develops random features...

Max-Max

Another thought on virtualisation.

For the theme we would need to detect mous_enter and mouse_leave to implement the hover state (also called 'hot' state in some GUI's)
- My code doesn't have bugs. It develops random features...

Max-Max

#289
Prissi and Ters...

I'm trying to use the scr_rect as Prissi changed it but it is really a huge pain in the xxxx to always have to use function calls for everything. The code looks more cluttered and hard to read than ever.

Can we please ( ~big round puppy eyes~ ) go back to have x,y,w,h as public members! I will agree to almost  everything else ,if we can get back to make these public...  ;)

I can add a bottom() and right() function to get my absolute positions (not used for margins).
- My code doesn't have bugs. It develops random features...

kierongreen

QuoteI'm not 100% sure what algorithm is used, but I think it is b-tree
Whichever algorithm is used that will be signifcantly slower than simply loading a value from an array. Considering that Loading/Unloading images will be done rarely a better way would be to have a variable pointing to the next free location in the array. Pseudo-code:

images[MAX_IMAGE];
next_free_image = 0;
...
init_images()
{
  for(i=0; i<MAX_IMAGES; i++) {
    images[i]=NULL;
  }
}
...
unload_image(image_number)
{
  <image deleting code>
  ...
  images[image_number]=NULL;
  if(image_number<next_free_image) {
    next_free_image=image_number;
  }
}
...
load_image()
{
  image_number = next_free_image;
  ...
  <load image code to images[image_number]>
  ...
  for(i=image_number; i<MAX_IMAGES; i++) {
    if(images[i]==NULL) {
      next_free_image=i;
      break;
    }
  }
  ...
  return image_number;
}

Ters

Quote from: Max-Max on August 31, 2013, 11:59:00 PM
Yea, I figured that out. How ever, by storing the bilt_becht_t as an array makes it cumbersome to delete images and I guess this is why we keep adding them at the top.

Simutrans doesn't delete images once they are loaded. Changing this has so wide-reaching consequences that it can easily take a year. And it doesn't really keep adding images at the top, it's just too stupid to know how big to make the array before filling it.

Looking up images is likely so performance critical that it has to be O(1). There is a possible alternative solution, but it would take quite some time to implement and may ruin carefully packed data structures. At the moment, there should be focus at stabilizing the code for a new release rather than pick more things apart.

Max-Max

The theme manager will create new images and the original images will not be used after that. I thought it would same some space if we could free up the memory.

As I said, it was only a thought and I wanted to raise the subject if some one felt the urge to do something about it ;)
- My code doesn't have bugs. It develops random features...

Max-Max

Quote from: kierongreen on September 01, 2013, 08:20:00 AM
Whichever algorithm is used that will be signifcantly slower than simply loading a value from an array. Considering that Loading/Unloading images will be done rarely a better way would be to have a variable pointing to the next free location in the array. Pseudo-code:

images[MAX_IMAGE];
next_free_image = 0;
...
init_images()
{
  for(i=0; i<MAX_IMAGES; i++) {
    images[i]=NULL;
  }
}
...
unload_image(image_number)
{
  <image deleting code>
  ...
  images[image_number]=NULL;
  if(image_number<next_free_image) {
    next_free_image=image_number;
  }
}
...
load_image()
{
  image_number = next_free_image;
  ...
  <load image code to images[image_number]>
  ...
  for(i=image_number; i<MAX_IMAGES; i++) {
    if(images[i]==NULL) {
      next_free_image=i;
      break;
    }
  }
  ...
  return image_number;
}


This looks like an excellent idea! Since this is mainly done at startup, it really doesn't matter that much if it takes little bit of time to lookup the next free image index...
- My code doesn't have bugs. It develops random features...

Max-Max

Theme manager patch!!!

Here is an early proof of concept path of the Theme manager.
It reads the original skin-PAK format and creates the images needed to draw an arbitrary framed rectangle with the skin.

In this patch only the round button is using the theme manager. It can be tested and used if you add this theme.tab file to the theme directory:

gui_button_width      = 100
gui_button_height     = 24


You will see that the buttons size changes and still have the same design as in the skin-PAK.

As, I said this is only a proof of concept so it is a bit hackish and the so debated scr_rect was modified a bit to work better with my needs. scr_rect still needs some redesign and is now in a hackish state.

I have attached a picture of the comic style with the above theme.tab parameters.
Well, we are getting to our target bit-by-bit... :)
- My code doesn't have bugs. It develops random features...

Ters

Quote from: kierongreen on September 01, 2013, 08:20:00 AM
Whichever algorithm is used that will be signifcantly slower than simply loading a value from an array. Considering that Loading/Unloading images will be done rarely a better way would be to have a variable pointing to the next free location in the array. Pseudo-code:

images[MAX_IMAGE];
next_free_image = 0;
...
init_images()
{
  for(i=0; i<MAX_IMAGES; i++) {
    images[i]=NULL;
  }
}
...
unload_image(image_number)
{
  <image deleting code>
  ...
  images[image_number]=NULL;
  if(image_number<next_free_image) {
    next_free_image=image_number;
  }
}
...
load_image()
{
  image_number = next_free_image;
  ...
  <load image code to images[image_number]>
  ...
  for(i=image_number; i<MAX_IMAGES; i++) {
    if(images[i]==NULL) {
      next_free_image=i;
      break;
    }
  }
  ...
  return image_number;
}


My biggest worry is that all code expects image handles to be valid forever. Identical images are also merged, so one would also need reference counting to ensure that the image isn't freed until all copies have been requested deleted.

For now, it's best to just live with that images are loaded at startup, and never changed after that. Users probably change pak sets more often than gui themes, and they don't compain too much about having to restart Simutrans in order to do so.

kierongreen

Well yes - the main benefits from my point of view are greater ability to customerise look of paksets and also greater easy of use on tablets and portable devices without compromising ease of use on desktops. So not being able to switch themes while simutrans is running isn't really a huge drawback for me.

prissi

#297
It is very easy to switch themes during runtime, as those images would be added on top, or else would be reused. The overhead of adding another 50 images is neglible. Furthermore, switching themes will only mostly happen once (like language selection). So I am not worried about some extra images.

As written at east twice before: if the images are loaded from a pak, then it is trivial to have some roundbutton, colorbutton, ... skin_besch_t which always is pointing to the correct entry without using an additional layer in between. As such the thememanager seems not usesful. Rather first we have to decide which skins are needed, i.e. which images we need.

On the fly rendered images will make it impossible for an artist to design on a consistent look. Hence a theme manager should not touch the images, just load them. I do not recommend to work against artists.

And before opening the problem with the theme manager, I would be very grateful if first the full functionality of dialogues is restored. As it stands now, there are still half hidden scrollbars and similar things around.

Max-Max

Quote from: prissi on September 01, 2013, 08:53:29 PMAs written at east twice before: if the images are loaded from a pak, then it is trivial to have some roundbutton, colorbutton, ... skin_besch_t which always is pointing to the correct entry without using an additional layer in between. As such the theme manager seems not useful.
The theme manager is converting skin format into the new internal format, and later on when we have a new PAK format it will seeming less take care of it. It also has the responsible to substitute non mandatory elements. In its current prof of concept form it doesn't do much yet... The theme manager also centralise the code for basic  theme drawing and all a GUI component need to do is to supply a rect and what theme id should be drawn in, the manager takes care of the rest. I thought the prof of concept would give a hint that it isn't finished, only a prototype, hence to early to complain about its existence or functions. I did stated before that there will be a theme manager...
The theme manager will create new images...
I have created a theme manager that prepares all the GUI images.
Anyway I doing some "thinking" around the theme manager and experimenting a bit.
The Theme manager will chop up this image in 9 uniformed pieces.
...and no one was arguing about the theme manager's existence. Another reason for implementing the theme manager at this stage is that we can use it in our GUI and not have to change the GUI classes when we move to a new format (it will save me a lot of work). Since the theme manager is storing the theme elements in its internal structure, just the same way it will do in the new format, I can develop the GUI controls and adjust the interface to the theme manager as I need. Then we can experiment with PAK formats without having to update every single GUI control and/or dialogues.

The theme manager will also have the Theme selector dialog and a simple editor to tweak the selected theme, such as button sizes...

Quote from: prissi on September 01, 2013, 08:53:29 PMRather first we have to decide which skins are needed, i.e. which images we need.
I explained earlier that I will use the current skin-PAK to work out what we need, before we start to code a new theme-PAK format. By using the current skin and convert it to a theme format I can cut corners and show progress much faster.

Quote from: prissi on September 01, 2013, 08:53:29 PMOn the fly rendered images will make it impossible for an artist to design on a consistent look. Hence a theme manager should not touch the images, just load them. I do not recommend to work against artists.
The theme manager is not changing the artist's images or replacing them with some random images. As long you don't override anything in the theme.tab file, it will be just the way as the artist intended it to be. I thought you understood this when we discussed how we can change button sizes and colours with the theme.tab file. The theme manager simply prepares the the images needed to draw a frame from one single picture. It is a lot easier for an artist to see the whole button as a whole and not have to chop it up in small images spread out in a grid, this is what the theme manager does for the artist. The only images that will be rendered by the theme manager are images that can't be substituted by anything else. This is no surprise for the Artist because I'm pretty sure he/she will test the design before releasing it.

Quote from: prissi on September 01, 2013, 08:53:29 PMAnd before opening the problem with the theme manager, I would be very grateful if first the full functionality of dialogues is restored. As it stands now, there are still half hidden scrollbars and similar things around.
I have not seen any half hidden scrollbars and I asked TurfIt to show me where and maybe post some screen shots to show, but I never got any answers. If you have noticed something, please show me a screen shot and tell me where. I have gone through every dialogue I can find in the game and not seen anything...
I have intentionally left all the list dialogues untouched because Prissi explicitly told me to stay away from them:
Quote from: prissi on June 10, 2013, 10:08:18 PMI also explicitely reserved the list windows several time for rework. Really, no need to touch them at all, I am planning to write them more or less new from scratch (same for line management window).

I thought every one would be excited over this progress and I put a lot of hard work behind this. Although my expectation became true, not so positive response, as usual... ~sight~
- My code doesn't have bugs. It develops random features...

Markohs

I don't agree of what I've read about the theme selection will just be made once, and to change theme we might require a game restart.

It makes no sense not developing to change themes on the fly, ingame, even previewing each theme. About images not being freed, well, there are various aproaches to the issue, it needs coding ofc.

I know you guys use to like simplifity, and do do I, but in this case it's really pointing to a poor quality solution then, imho.

I agree with prissi's point that dynamic image rendering in game it's not so good idea, and should just be done if absolutely required technically.

Max-Max

Quote from: Markohs on September 02, 2013, 02:07:44 AM
I don't agree of what I've read about the theme selection will just be made once, and to change theme we might require a game restart.

It makes no sense not developing to change themes on the fly, ingame, even previewing each theme. About images not being freed, well, there are various aproaches to the issue, it needs coding ofc.
Well, this was my intention, to be able to preview the theme in the theme selector, but this will have to be addressed in the end of the project I think. Mean while we can do a restart...

Quote from: Markohs on September 02, 2013, 02:07:44 AM
I know you guys use to like simplifity, and do do I, but in this case it's really pointing to a poor quality solution then, imho.
I agree with prissi's point that dynamic image rendering in game it's not so good idea, and should just be done if absolutely required technically.
I have repeatedly stated that images generated entirely by the theme manager are the fall back images. A fallback can be done in several steps before it starts to draw its own images. We can have it to use other theme components images in several fallback steps. These fallback steps aren't random, it will follow the same structure always! So, yes, generating images on its own is the very last resort...

How ever, we aren't there yet. The benefit of having these fallback steps is that we can release new enhanced versions of Simutrans without waiting for the theme/skin-PAK files to be updated, or Simutrans won't start :o
- My code doesn't have bugs. It develops random features...

Markohs

Quote from: Max-Max on September 02, 2013, 02:19:24 AM
Well, this was my intention, to be able to preview the theme in the theme selector, but this will have to be addressed in the end of the project I think. Mean while we can do a restart...

You are the programmer, I'm just stating my oppinion, ofc. ;)

Well, it's not like we need to release now, I'd go for the complete solution and not the partial. Having a partial and a post-patch feature planned usually ends on not being even implemented ever, or having to rewrite a lot more, and refactor a lot, simply because you'll end finding a lot of information you don't have now.

Quote from: Max-Max on September 02, 2013, 02:19:24 AM
I have repeatedly stated that images generated entirely by the theme manager are the fall back images. A fallback can be done in several steps before it starts to draw its own images. We can have it to use other theme components images in several fallback steps. These fallback steps aren't random, it will follow the same structure always! So, yes, generating images on its own is the very last resort...

How ever, we aren't there yet. The benefit of having these fallback steps is that we can release new enhanced versions of Simutrans without waiting for the theme/skin-PAK files to be updated, or Simutrans won't start :o

No problem then. :)

Ters

I wasn't arguing that we shouldn't be able to switch themes, but that it is postponed until a later release, or we won't be able to make a stable release for another year or so. For now, the goal should be to complete the new GUI rendering part and preferrably the associated PAK formats. Artists can then start making themes while programmers hammer out things like theme selection dialogs and ensure that the game is OK with things being swapped out underneath its feet.

An_dz

If so, here are two patches making two new dialogs follow the new system.

There are some changes and additions that I think might help, will discuss later.

Max-Max

Welcome back An_dz and thank you for the patches :thumbsup:

In my earlier work we fine tuned the system a bit more:
  • For all buttons (button_t) the init() and set_type() initializes the button to its default size. As long the button should have the default size, we don't need to specify the size at all. The size parameter in init() can be omitted to get the default size.
  • Now when we can override various GUI controls default size and colours through the new theme.tab file, you will find more D_XXXX_HEIGHT/WIDTH defines to refine how the GUI controls can be tweaked. I suggest you have a look in gui_frame.h for more details.
  • The divider only needs to be set by set_width() to get the default height and look. The height can be changed but there are some divider style enums that can be used instead. Have a look in gui_divider.h
  • There are now some defines for system colours; SYSCOL_XXXX. Have a look in simcolor.h to see what system colours are available.

Down the road I realised that we really need to take a deep look at the GUI structure before we do something else. I felt that there was several GUI controls missing that needs to be implemented. I tried to not do this now but ended up in some hackish GUI changes instead. This is why I stopped to convert dialogues and focused on the GUI structure instead because we will certainly redo all the dialogues once again when this is done.
- My code doesn't have bugs. It develops random features...

An_dz

Quote from: Max-Max on September 02, 2013, 04:35:04 PM
  • For all buttons (button_t) the init() and set_type() initializes the button to its default size. As long the button should have the default size, we don't need to specify the size at all. The size parameter in init() can be omitted to get the default size.
Amazing, will help my work on the map window. I'm moving the map to the top and the buttons to the bottom, so the map is fixed in the window. It's working nice unless you click on scale, selections and/or factories.

Quote from: Max-Max on September 02, 2013, 04:35:04 PM
  • Now when we can override various GUI controls default size and colours through the new theme.tab file, you will find more D_XXXX_HEIGHT/WIDTH defines to refine how the GUI controls can be tweaked. I suggest you have a look in gui_frame.h for more details.
I did and on my working copy I included the D_ARROW_HEIGHT and D_ARROW_WIDTH for the button_t::gui_arrow_right_size, it could be left too but it's almost obvious that they will have the same sizes.

Quote from: Max-Max on September 02, 2013, 04:35:04 PM
  • The divider only needs to be set by set_width() to get the default height and look. The height can be changed but there are some divider style enums that can be used instead. Have a look in gui_divider.h
  • There are now some defines for system colours; SYSCOL_XXXX. Have a look in simcolor.h to see what system colours are available.
Ah, great. Will look into those.

Quote from: Max-Max on September 02, 2013, 04:35:04 PMDown the road I realised that we really need to take a deep look at the GUI structure before we do something else. I felt that there was several GUI controls missing that needs to be implemented. I tried to not do this now but ended up in some hackish GUI changes instead. This is why I stopped to convert dialogues and focused on the GUI structure instead because we will certainly redo all the dialogues once again when this is done.
Change or fix? If the changes will need a new rework then the new system needs work, but if only small tweaks from the converted version will be needed we can do it so once the new double height code is complete a new version can be launched.

prissi

@Madmax
Well, I mentioned in all those thread that the theme loading could be easily done by me, as soon as we finally agreed what images and what paks we actually want. Getting images for those from artists is usually never a problem, fourtunately. Rather we have artists waiting to provide images. No need for fallbacks.

And images added at the end are already releaseable anyway, so reloading several themes and previewing the will be not too difficult. You can leave this to me, if you doubt it, almost everything needed is there already.

But it would be really needed, if we discuss and agree on what graphics a theme must provide, and how they are names (i.e. what skin.xxx.pak are needed). And to involve everybody, I strongly suggest doing it here, and not via external files.

Currently I think a theme needs
button skins
pos buttons
scrollbars
gadgets
window bars (those need to be in player colors if recolered)
window background

Did I miss something?

Max-Max

Quote from: prissi on September 02, 2013, 09:24:48 PM
Well, I mentioned in all those thread that the theme loading could be easily done by me, as soon as we finally agreed what images and what paks we actually want. Getting images for those from artists is usually never a problem, fourtunately. Rather we have artists waiting to provide images. No need for fallbacks.

And images added at the end are already releaseable anyway, so reloading several themes and previewing the will be not too difficult. You can leave this to me, if you doubt it, almost everything needed is there already.

I have no doubt that you can contribute a great deal here and I have never argued that it won't be possible load/unload a theme, I just feel it is a bit to early to star that work yet. The theme manager will in the end replace the current skinverwaltung_t::window_skin so we need to add the Dialogue, loading/unloading in the theme manager.

Quote from: prissi on September 02, 2013, 09:24:48 PM
But it would be really needed, if we discuss and agree on what graphics a theme must provide, and how they are names (i.e. what skin.xxx.pak are needed). And to involve everybody, I strongly suggest doing it here, and not via external files.

Currently I think a theme needs
button skins
pos buttons
scrollbars
gadgets
window bars (those need to be in player colors if recolered)
window background

Did I miss something?

This is very hard to discuss because I will add new GUI controls and change the GUI structure so we can benefit from class inheritance better. My aim is that each GUI class will have the possibility to have its own set of theme images.

If you star to break down what images are needed, we basically end up with a lot of frames. To demand that all these images has to be defined in a theme-PAK, other wise it won't start, can be cumbersome. Most of the GUI controls will probably use the same frame style anyway. It is here the first level of fallback comes in.

Example: if the artist wants to use the same frame for everything, he shouldn't be forced to define every GUI class to use that same frame. If the theme manager can't find any images for a specific GUI control, it will fallback and use the images of another GUI control, and if that one doesn't exist it will fallback again to the next and so on until a proper set of images is found. This fallback steps are not random and will be defined when we know what we have to work with.

Now as a last resort, the theme manager could draw a simple frame by itself. This frame doesn't need to be bigger than 9x9 pixels to cover all sizes. This is a very simple approach that will allow the game to at least start so a more appropriate theme can be selected.

The theme manager will handle all this when the theme is loaded so each GUI class doesn't need to know if something is missing or not. All GUI classes request their specific set of images and the theme manager does the rest.

Then there are other questions to solve. How to line up a component's background if it has a pattern? I do have ideas of how to solve this.
Then there might be controls where the frame is resized, but the background can't because it has a symbol. How do we handle this in the name of the artist's freedom? (well I do have a plan for how to handle this as well).

The artist must be able to define the client rectangle inside a GUI component, because it depends on his design of the frame how far in the client area starts. I do have an idea for this as well.

It would be awesome if we could do semitransparent windows, as some one suggested earlier. The artist must be able to define if a window should have this or not.


So to answer your question, I can't say what images we need and don't need because we don't know what the GUI classes will look like yet, there are still some questions that needs to be investigated and tested.

This is why I abandoned the Dialogue update because I needed the proper GUI components, and to make them I needed to create some rudimentary theme manager functions, and for this I needed the scr_rect type... everything is connected...

In the very first post of this thread I have included a link to the Theme document. I'm hosting the document on my own server and anyone can easily get it and read it in less time it takes to debate a geometrical definition. The document is full with pictures so there isn't really much to read, but the pictures explains quite a lot.

We can of course discuss the contents of the document here.
- My code doesn't have bugs. It develops random features...

Max-Max

@An_dz

Quote from: An_dz on September 02, 2013, 06:53:03 PM
...I included the D_ARROW_HEIGHT and D_ARROW_WIDTH for the button_t::gui_arrow_right_size, it could be left too but it's almost obvious that they will have the same sizes.
My strategy is that every single GUI image can have its own size, so in practice all the arrows can have different size. I found it very cumbersome to always keep track of each GUI component's size by manually adding the right D_XXX_HEIGHT/WIDTH.

My intention in the new design is that all functions that change a components position or size will return a bounding rectangle. This removes the need of matching constants with used GUI components, the component will instead tell its size.

To be able to do this I needed a rectangle type describing a components size. I made the scr_rect to be an easy type to work with for this purpose. How ever, there was a quite heavy debate about how this scr_rect should work and it ended up in something that doesn't make things easier for me, just more work.

The scr_rect is now in a hackish state and I'm going to adjust some parts of it back to what it was. Unfortunate the scr_rect will not be optimal for my needs any more, due to some geometrical definitions on Wikipedia that was more important to follow than its practical use :o

Quote from: An_dz on September 02, 2013, 06:53:03 PMIf the changes will need a new rework then the new system needs work, but if only small tweaks from the converted version will be needed we can do it so once the new double height code is complete a new version can be launched.

I'm trying to work on the new system right now but it seems like I spend more time debating than coding for the moment... :P
- My code doesn't have bugs. It develops random features...

Markohs

#309
Quote from: Max-Max on September 02, 2013, 10:49:18 PM
I'm trying to work on the new system right now but it seems like I spend more time debating than coding for the moment... :P

I want you to take my comment as a constructive one, I think sometimes I sound too harsh.

I advise you to just code, avoiding discussions as much as you can. Getting comments to your work is time-consuming, and it's better to just focus designing yourself, implementing it, one-way.

Once you have it implemented, just post the patch, it will require minor tweaks, most of the times.

You will never reach a agreement, allways someone will ask for features or not like some aspects of what you did. It's better to just code, all will be more agile. The only requirement to code this way is writing code that's able to be changde easly, making it modular and very decoupled.

Just keep jitting milestones in your project, don't stop. It's easier to fix things than getting consensus over new code.

Also, it's easy to give oppinions, and asking for different aspects of the design, but once the code it's written, then it's already working code, they allways have the option of fixing or recoding it themselves.

On my last world limits patch, I know there were some things that were not polished, and some aspects were discutible, you'll see almost every current simutrans coder has slowly been modifying my code to make it better. This is how a open source community works, and it's great.

Don't be afraid, just code, code an code, and once you are happy, submit the patch for the review.

My oppinion, and my advise, ofc. This is just my point of view. ;)

prissi

I think a theme manager is not needed at all. Theme images would load into skinverwaltung, and missing images would just take from what was there previously. Again, do not worry about missing stuff, this was and probably will never be a problem. If images are defined twice, they will be reused and do not consume additional memory. It just needs another line in a dat file. Even if somethingg is missing: as long as there is a complete theme (which will be anyway distributed by the executable). Hence, no need for an extra theme manager layer. Keep it simple!

Moreover, the theme are defined the thmes.dat; hence specifying a transparency for the background there is straight forward. And before adding more complex code by changing gui elements, I would rather finish what there is.

So based on the list I made above I will add the theme with pak loading and the currently needed skins over the weekend, following Markohs advice.

Max-Max

@Prissi

Well, another point of the theme management is to encapsulate the theme as a separate system from the GUI components.
If "keep it simple" means no more classes, then why are we using C++ at all?

So please Prissi, tell me exactly what it is that isn't simple? Please point out what functions or design makes this so complicated?

...and I'm still waiting for some pictures on the half scrollbars that needs to be fixed.
Quote from: Max-Max on September 02, 2013, 12:31:31 AM
I have not seen any half hidden scrollbars and I asked TurfIt to show me where and maybe post some screen shots to show, but I never got any answers. If you have noticed something, please show me a screen shot and tell me where. I have gone through every dialogue I can find in the game and not seen anything...
I have intentionally left all the list dialogues untouched because Prissi explicitly told me to stay away from them.
- My code doesn't have bugs. It develops random features...

Max-Max

@markohs

I was told that the community was a democratic process and it should be involved (that was how interpreted it).
But it seems like you are right, maybe I should just do my thing on my own and post the milestones.

Well maybe I will do that from now on...
- My code doesn't have bugs. It develops random features...

kierongreen

Well, the community is not a dictatorship but we don't formally vote on changes. A consensus is arrived at generally when working out what features to add or how to add them.

In this case the consensus is clearly supportive of the concept of themes - the only question is implementation. I've tended to adopt the philosophy of developing patches more or less on my own, only releasing them when there are obvious new features. As these tend to be ones often requested there are then not very many arguments against adopting the patch.

Whoever develops patches though other people will make suggestions as to tweaks that might improve readability or performance, or fit in better with other code in simutrans. These suggestions are just that, suggestions. You don't necessarily have to follow them if you have good reasons not to and you can see in your own mind where you want the code to go.

Ters

Quote from: prissi on September 03, 2013, 08:04:27 PM
I think a theme manager is not needed at all. Theme images would load into skinverwaltung[...]

Quote from: Max-Max on September 03, 2013, 09:49:43 PM
Well, another point of the theme management is to encapsulate the theme as a separate system from the GUI components.

skinverwalterung more or less means theme manager, so Simutrans already has a theme manager class. It doesn't need another one, it should just evolve the one it has. But there is a question of drawing the line between skinverwalterung and the GUI components.