Author
Topic: [Project] GUI Theme (Read 53289 times)

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 box.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?

Sorry, the D_MARGIN_... is introduced as the space of an UI element from the border of the dialogue for esthetic reasons (balancing left and right borders).

Where the UI returns its bounding box? The only exception I can think of is the combobox, all other rather return their client area (and the chart is broken in this regard, agreed). Otherwise the internal event handling would not work. Thus for Simutrans I rather want to avoid the bounding box/client area altogether. It is simply not needed, and I see no sense in wasting time and adding complexity to add this to all controls.

gui_frame_t is not the place for drawing the border! Otherwise tool bars (cannot have meaningful border, as their size depends on the elements within) and banner could not be based on gui_frame_t. Simutrans is rather build like XWindows, where it is hard to get actually the size of your outer window. Thus window drawing is done by simwin.cc, and I see nothing to gain in changing it. Instead applying themes could be easily done by simwin (it must be anyway done by it through event handling requesting a resize of all windows).

Back to topic: Even in your mockup you drew the scrollbar with zero margin to the right. Same as all comments in this thread: Scrollbar margin is zero. D_MARGIN_ is not the margin to the outer window border, it is a border for the esthetics of the dialogue. You may want to introduce something like outer area for the window handler, but all simutrans dialogues were meant to deal only with client area.

The titlebar is a historic relic, since from the three original window classes one drew its titlebar itself, and not in simwin.cc. I am happy to set D_TITLEBAR_HEIGHT to zero at a certain point, I said this before. Then you have all get_groesse client area. No window should need to care about its outer diameter in simutrans, so please let us not add this to gui_frame_t. The window's outer extends belong to simwin.cc.

When you set a theme, the button and the sizes will change. The window has no need to find screensizes and the like. Dialogue layout (not just sizes) changing on screensize is imho neither realistic, nor feasible for simutrans, as such would void the existing documentation and the efforts to have ergonomically designed dialogues.

So lets get_groesse return the client area, and lets simwin.cc worry about drawing and overlapping borders and the like. Keep it simple and easy.

I think it should be easy for the user/theme designer, it doesn't really mean the code has to be simple. Sticking to simple solutions in code is not a good idea always and should not be a sacred design dogma.

It is not a dogma, but I still am not fully convinced that the concept of client area is helping for the relatively simple simutrans GUI. Especially since it did quite ok the last 13 years, and for scaling inside the dialogue I am not convinced the extra work is helpful. But again, you know I am slow to bent but can be convinced by arguments that the gain outweights the costs in complexity.

* Theme Colours configurable through the theme/themes.tab file.* Button's size are actual skin image size.* Buttons, labels, text area use the new theme colours for Text, disabled text and static text.* Various gui controls use the sizes set by button_t::gui_xxxx_size (set by skin image size).* Fixed a bug where a pressed button was drawn in the same size as the normal button state, even when the images differed in size.

Prissi take your time with this one, I know it is bigger than expected but it updates quite a lot of skin/theme related functions.

I have to admint that I had forgot all about SimWin and was thinking that gui_frame was the Window class, so it was all my mistake. gui_frame_t is the client of SimWin They do go into each others terrotory and it is a bit confusing.

I know the scrollers aren't where you want them, but I will get right on to it as soon this patch is implemented. I think thw GUI needs to be cleaned up first before I move on with the theme.

So next up; bring some order in SimWin and gui_frame...

PS. Not all dialogues are converted yet, so other sizes than the defult will screw some things up. But at least, you can play around with colours

I agree that the divider line in the language dialogue looks odd, but it is there in the original, it isn't simething that I have added.I have not come to the title bar yet, that will be a bit further down the road...

I added the picture to show where we stand at this point, still a lot of work to do, but at least yu can configure some the colours now.

Well done New theme certainly looks more modern (also important step to getting it working properly on tablets with larger buttons) although one thing I'd say that looking at the size of some of these dialogues I'm doubting that 640x480 will be that playable now. How easy is it for a user to configure simutrans to look how it does at present with the patch applied - to cater for players with old computers or who for whatever reason want smaller windows still?

I have been puzzled about that one too. I found out that it only works on vehicle info windows and has the same function as the "follow" button.

I had an idea earlier about to be able to pin a window in a "geo-stationary" position on the map. This would be very helpful when displaying stop and factory information (to pin the window near the stop or factory).

I guess the first step would be to just remove the pin where it isn't applicable for now.

Take your time Prissi, I'm studying the SimWin and frame_t right now...

This is my first thought in the matter from what I have seen so far.

A window can be owned by another window and thereby automatically be closed when the owner window close. It would be natural to derive the window from an appropriate komponente_t descendant and it will share the same code for message handling, hit testing, set and get size etc... as all the other components.

I'm aware of the magic number and the "class factory" that produce them. I will try to collect the relevant functions into a class.The frame_t class is more like what is called a panel in GUI terms. The window class is simply a collection of a panel, a toolbar and a label. By using components for this we nicely get all the hit test in their resp. objects.

I think for the themes to work, some more special images has to go into themes skins. I can work on that too. I will try to get this in at teh weekend, as this is very nice progress.

Actually I haven't added any new images yet, only implemented the use of the current skin definition. The current skin system wasn't fully implemented, I have only made it to respect the image size.

To make it work the dialogues needs to be updated so the buttons are align in relation to each other ...and not to a fixed position. But I feel that we are missing the layout class to make this align nice and tidy, even for an arbitrary sized theme.

...and to do the layout class I feel that we need to clean up the current GUI structure a bit. Now code is repeated for the same thing in some gui classes.

I have been puzzled about that one too. I found out that it only works on vehicle info windows and has the same function as the "follow" button.

I had an idea earlier about to be able to pin a window in a "geo-stationary" position on the map. This would be very helpful when displaying stop and factory information (to pin the window near the stop or factory).

I guess the first step would be to just remove the pin where it isn't applicable for now.

You're confusing the pin-button with the eye-button. The pin-button pins a window open so that it isn't closed by the close all windows function. A case where a sub-feature of a feature is more visible than the feature itself. Backspace is the hotkey for closing all non-pinned windows for me. As such, the pin is useful everywhere.

The majority of inexperienced players have no idea how to use that buttonWould it not be wise to make this option more practical?

That can be said for a lot of things in Simutrans, even the very basics like signals. The pin-button works more or less like any other pin-button I've seen. I must admit that I have never used the pin-button in Simutrans, but that is because I have never memorized the hotkey for closing all non-pinned windows.

it can be make better use of thisbecause normally this is used to keep a window always visible, even if we are working with other

I have never seen a pin used for this. Nor do I see much use for it, because it is hard to use a window you can't see. Perhaps the only window big enough to be interacted with even when partially covered is the minimap. One thing I have seen pinning used for is to prevent a window from being reused, but Simutrans always opens new windows.

is can take advantage advantage of this, especially when working with many windows

I haven't seen a pin used for this, and to me a pin is a non-intuitive icon for this, as they make things stick not float. (A binder perhaps, but that could also imply that a window should stay on top of a specific window and move along with it.) Having windows floating on top is sometimes useful on the OS level (Windows is lacking this as a general window feature), but I can't see which windows benfit from it in Simutrans. At least not useful enough that it can ursurp the pin, it would have to be another button or I can imaging people complaining about losing a feature. It would mean a lot of buttons in the title bar.

I haven't seen a pin used for this, and to me a pin is a non-intuitive icon for this, as they make things stick not float. (A binder perhaps, but that could also imply that a window should stay on top of a specific window and move along with it.) Having windows floating on top is sometimes useful on the OS level (Windows is lacking this as a general window feature), but I can't see which windows benfit from it in Simutrans. At least not useful enough that it can ursurp the pin, it would have to be another button or I can imaging people complaining about losing a feature. It would mean a lot of buttons in the title bar.

I'm leaving for a 2 week vacation this Friday. I was hoping to get a fresh trunk with me to code while I'm away

I have translated

get_groesse() to get_size()set_groesse() to set_size()koord groesse to koord sizezeichnen() to paint()set_fenstergroesse() to set_window_size()get_fenstergroesse() to get_window_size()getroffen() to is_hit()

The question is if I also should translate gui_komponente_t to gui_component_t ??

The simutrans way would be rather display instead paint, as there are so many display routines in the code.

Some comments:Scrolltext is not a gui component to have it harder to modify. Also one off stuff does not need to be a component imho.Clipping of buttons in a scrollpane was not working for too long button textsThe convoi filter is all entries oon the same line now. But do not bother too much filter dialoges. They will be anyway make by the new list control, as almost any of them has waytype, name and some other common filters.

Precisely because "display" is usually associated to routines that display images, I'd use "draw", that gives the idea that it might not use just one image, but lines and other artifacts too. Anyway if display is choosen, I don't mind, just not "paint".

I'm just guessing here, but I think the majority has some experience of Windows nomenclature. WM_PAINT is the message that does exactly what zeichnen does. In VCL and FireMonkey (C++ and Delphi) there is a callback named Paint(), doing the same thing.

Draw is more like shapes, such as DrawLine(), DrawPolygon(), DrawElipse() etc...

Regardless of what we all think about Windows, a lot of people have experience from Windows and would easily understand the concept if we use the same nomenclature for their equivalent. This might speed up the learning curve for new coders...

But the way, in halt_list_frame.cc you use the button directly. Wouldn't it make sense to use the defines, sicne any further changes could be better followed by this (and it make also the code clearer).

EDIT:Help frames scrollbars are almost gone.The text in numberinput was 1 too high in new world.Player list is very unbalanced now. I think this requires additional spaces between lines.Minimap is also draw wrongly.

Actually I submitted your code with those problems (as you have probably noted). I would be just grateful for a correction patch whenever you have a simple solution, especially for dialogues more or less severely misaligned as mentioned in the postings above.