News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

[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

- Should not the gadget size be taken from the actual gadget?
Yes it will even be its own button type, for now it is only there for test purpose.

- Should not gui_image_t also get an alignment parameter; in this case even ALIGN_CENTER_V and ALIGN_CENTER_H makes sense? It would then align the element in the middle.
Good point! I will have a look at it.

- editfield and normal button different height will almost certainly lead to ugly dialogues. Furthermore, if too small to be caught be finger for switching, it will be also too small for editing, or?
No, the dialogues looks beautiful with larger buttons and smaller edit fields :)
If you create a theme targeting touch devices you can of course configure it to be a large edit field. The point is that the edit field can now have its own size.

Thank you for the trunk update.
- My code doesn't have bugs. It develops random features...

Max-Max

I saw that you had changed the default divider style from lowered to raised. I know that the raised was the previous, but the lowered is more discreet and doesn't clutter the GUI as much as the raised version does. I'm especially thinking when it is between buttons.

Have a look in my sample picture above this post to see what I mean.
Should we change it to default lowered?
- My code doesn't have bugs. It develops random features...

Ters

Smaller edit fields works as long as they're not on the same line as buttons. But in that last screen shot, I find that the edit fields, arrows and check boxes are a bit too small compared to the buttons and the title bar.

Max-Max

I'm breaking the relation between the elements sizes. All element types can have an individual size for maximum customisation.

If you want everything to be of the same size, no problem. If you want everything to be in different sizes, no problem either it is up to you how you customize your GUI interface. Above is my test case for the moment, so I can spot if I have converted each dialogue correctly.

Back to the last question, dividers, lowered or raised as default?
My argument is that a divider is a subtile GUI element and a raised divider makes the GUI cluttered.
- My code doesn't have bugs. It develops random features...

kierongreen

Raised/lowered makes no difference as far as I'm concerned. I've seen both styles in different GUIs so I'd stick with what we have.

Max-Max

Here is the adjusted Banner dialogue.

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

Max-Max

Here is the adjusted Option dialouge.

I did some minor rearrangement to group them a bit better; One column with settings and one with game related files.
(see attached picture).
- My code doesn't have bugs. It develops random features...

prissi

#147
I just put the changes to the divider you proposed previously. So what init do you want?

And while smaller edit fields than buttons work on this dialogue, they look simply ugly as anything to me. Hence if all elements have custom sizes, designing a good and visual pleasing dialogue becomes almost impossible.

Looking at the banner patch:
At which state this dialogue was not scaleable previously? Just exchanged some magic numbers with some local defines. I am somewhat confused I admid. Also why removing the right alignment (according to the comment) of the image?

The Option should better become just a toolbar, it would be more Simutransish now. Thus I am ok with this layout anyway.

EDIT: Maybe one should change the dimenasion of banner too, so it gets as close as possible to the standard simutrans dialogue size.

EDIT: Your patch messes up convoi dialogues, station dialogues, depot dialogues. So far the slow transition is not working. Or you have to fix the scrolling regions.

Max-Max

#148
QuoteAt which state this dialogue was not scaleable previously?
I'm not sure I follow you here... As far I have been playing Simutrans, this window has always been of a fixed size without possibility to scale it. Or have I misunderstood you... Did I step on someone's toes?

QuoteJust exchanged some magic numbers with some local defines. I am somewhat confused I admid.
As the comment state, these are there for tweaking and should be replaced when we have solved linespace vs shadow text "issue".
By replacing them with defines you only have to make the changes in one place, not every row where it is used. It will also make it easier to find % replace with the proper solution later.

The same goes for the banner scroller. With the defines you can set how many lines of text you would like to display and as the comment says, this should be a control on its own.

QuoteAlso why removing the right alignment (according to the comment) of the image?
I'm confused too... I can't find any notes on removing right alignment in banner.cc or banner.h
The image is right aligned, so I don't know what you mean here.

QuoteThe Option should better become just a toolbar, it would be more Simutransish now. Thus I am ok with this layout anyway.
I agree with you, it is not optimal as it is now. For example, you have to press "New Game" twice before you actually can start a new game. I think we are missing a main menu, as the most games have, where you can set options, load and start a new game. Then in game you can load/save, change options and quit to main menu (also called retire in many simulation games).

But first thing first...

QuoteYour patch messes up convoi dialogues, station dialogues, depot dialogues.
Do you run with the THEME_TEST setting or not?
Do you mean the scroller margin tot he dialogue border? Strange, I will look at it right away.

QuoteSo far the slow transition is not working. Or you have to fix the scrolling regions.
Have you tried a "Clean solution" and build all? The scroller works fine here...
I have noticed that the graphic update (dirty areas) is not updated quite right. This issue has been there before I started to poke around in the code, so I don't think I'm to blame there...

EDIT: Oups, the last two answers got mixed up with the wrong questions, fixed now...
- My code doesn't have bugs. It develops random features...

Max-Max

#149
- messes up convoi dialogues, station dialogues, depot dialogues

I found it. I was a bit ahead of my own time :)
in gui_frame.h you will find

koord get_client_windowsize() const {
  return groesse - koord(
    D_MARGIN_LEFT + D_MARGIN_RIGHT,
    ( has_title()*D_TITLEBAR_HEIGHT ) + D_MARGIN_TOP + D_MARGIN_BOTTOM
  );
}


This returns the true client area of the window (inside the margins).
If you would be so kind and change it to:

koord get_client_windowsize() const {
  return groesse - koord(0, ( has_title()*D_TITLEBAR_HEIGHT ) );
}


This will fix it.
- My code doesn't have bugs. It develops random features...

Max-Max

#150
QuoteI just put the changes to the divider you proposed previously. So what init do you want?
I would prefer DIVIDER_LOWERED as I mention earlier. Just change the divider.h back to as it was in my patch.

It will only be visible at places using the divider class (very few for now), but as I update the dialogues, I'm replacing the direct drawn dividers (raised) with the divider class (default lowered). Meanwhile you will experience a little bit of a mix between dialogues, but I guess we can survive that... :)

EDIT: Yea that's right, I gave you instructions... Just change the constructor and init from DIVIDER_RAISED to DIVIDER_LOWERED Thank you.

EDIT: I attached the divider.h
- My code doesn't have bugs. It develops random features...

prissi

Ok, now it hits the pakselector: The lowest pak is not selectable. Maybe treat this dialogue next?

And for elements, which exist only once (like the scrolltext in banner) I would not bother with a control.


Max-Max

I saw that I have already fixed that in the pak selector dialogue (in my end), but this was an early conversion. I will run through it again to make some minor adjustments.
- My code doesn't have bugs. It develops random features...

Max-Max

I have fixed the Load/save dialouges.
They are now a bit more coherent. The Load Scenario dialouge's indentation is fixed.
The patch selector sets the button sizes to the needed text size. The Addon button will now always fit the text.
- My code doesn't have bugs. It develops random features...

prissi

#154
At this point we probably need some discussion: The aim of the last (on glacially ongoing effort) was to have all simutrans dialogues initially with the same dimensions for practical (tileability) and beauty. Buttons that scale their size with the containing text will break this.

For loading an saving, there may be very long savegame names, even wider than the screen; Hence they need a sensibly maximum. But then, those dialogues does not needed to be tileable.

EDIT: With variable font sizes, we probably rather need also a variable with of that area. Like to Linespace a equivalent if the width of the Capital M/W or a Kanji (if there).

EDIT2: Also the divider is now over the button/label at the bottom.

Ters

I agree that buttons should have a uniform size. (Toolbar buttons are considered distinct from normal buttons.) This is a rule in the vast majority of GUIs I have seen. The only exception I have seen are some confirmation dialog boxes where the safe button is larger than the unsafe button.

Max-Max

We are doing this in small steps, as requested. In the drafted specification I presented a solution of collapsing the GUI element when the space got cramped up. To be able to do that we need the client concept. At this point I'm only preparing for client step and later on the button text can adjust itself to the button.

When it comes to dialogue/window size, we can elaborate with them when the GUI can handle the collapse function.
- My code doesn't have bugs. It develops random features...

Max-Max

#157
QuoteAlso the divider is now over the button/label at the bottom.
This can easily be adjusted through D_DIVIDER_HEIGHT in gui_frames.h

EDIT:
Hmm, where is it over the buttons? Is this in THEME_TEST mode or "normal" mode?

EDIT
I saw it in the pack selector now. It is only behaving like that in your trunk version. My local looks fine so something isn't merged right.
Since I'm a bit ahead of you it is difficult for me to compare my version with your trunk. If we can live with it for now we can continue until your and mine trunk are in synch, then I can investigate what is wrong here.
- My code doesn't have bugs. It develops random features...

eipi

It happens both in normal mode and in THEME_test mode, with and without the patch applied (at least for me).

Max-Max

#159
Where? What dialogue?

EDIT:
Have you applied the divider.h from (in SaveLoadDialogue.patch) and made a clean build?


Never mind, I started fresh and applied the patch, I can see it clear now... I have my suspicious...
- My code doesn't have bugs. It develops random features...

Max-Max

Okay, found it.

The gui_komponente_t serves as the base class for all components, but all members aren't virtual. The get_groesse() wasn't virtual and the divider's overloaded get_groesse() was never called.

As I'm a bit ahead of you, I had changed this in my end. You will find my gui_komponente.h attached here. Apply this path ontop of the previous one and it will fix the divider.
- My code doesn't have bugs. It develops random features...

prissi

Maybe you should use the OVERRIDE directive for the derived virtual get_groesse ?

Max-Max

Isn't override a C++11 keyword? I got the impression that we shouldn't use C++11 at all.

QuoteScoped enums is C++11 (and apparently a non-standard MS extension). Simutrans still uses C++98 - best to set your compiler to that (and disable MS stuff).
- My code doesn't have bugs. It develops random features...

prissi

There is OVERRIDE, which is defined of used and otherwise without function.

Back to the patch: The divider is fixed, but the scrollbar is not at the right window border. This makes the dialogue look very strange. Furthermore, while you at it: It would be nice if the scrollbar is hidden, if there is nothing to scroll.

Max-Max

#164
Quote...but the scrollbar is not at the right window border.
This topic has already ben up and commented here

...scrollbars are moved inside the margin. This is because the window border will be drawn in the margin and the margin will be decided by that border later on.

When the windows border is drawn with the theme images, the client area will be right next to the drawn border, and the margins you see now will be no more. When the client concept is in place, we can discuss if controls should move in one by one or if a padding inside the client should be applied. But that is further down the road...

EDIT:
Regarding override. Is it a praxis in this project to always use OVERRIDE after functions overriding virtual functions? As I understand, the keyword override is of none technical use other than telling sloppy programmers that they have done a mistake  :::)

EDIT:
It would be nice if the scrollbar is hidden, if there is nothing to scroll.
I have in fact already modified the scrollbar to hide the knob if it shows 100% of its content and I was thinking to disable the arrows as well. I can implement an auto scrollbar mode, meaning in auto mode the scrollbar is hidden completley, and in non-auto mode the scrollbar is empty and disabled. Sounds good?
- My code doesn't have bugs. It develops random features...

prissi

Sorry, the scrollbar not at the dialogue corner is really a show stopper. No one will expect a scroll bar at a random position without a visible box. This just breaks user expectation. (And just using the margin only for scrollbars makes some sense. Then would the useable area without a scrollbar (because everything is visible) be nearly the same as with a scrollbar.

Since we obviously disagree on this point, I would like to postpone any scrollbar repositioning until other commented too.

Following up my above comment: I would go for a completely hidden scrollbar, if the knob size is 100%. But also for this additional comments for others are highly welcome.

Max-Max

The scrollbar position inside the margin is not a permanent solution. It is one phase towards the theme implementation. When the client concept has been implemented, the scrollbar will end up line-by-line with the window border, just as it is now. If you want to wait for the client and border theme phase to finish, you will get a hell of a patch to implement later :)

I made a mock-up (Mockup.png) of what it would look like with Prissi's request. The scrollbars are drawn over the window's border.
With my final implementation the scrollbars will end up just inside the yellow border (Client.png) where the window's client area is.

So what do you want; Mockup or Client?

QuoteNo one will expect a scroll bar at a random position without a visible box
I don't get it? What is at a random position and what box is missing?
- My code doesn't have bugs. It develops random features...

Markohs

Client looks way way better than mockup imo.

Fabio


Ters

Quote from: Markohs on July 05, 2013, 12:54:40 PM
Client looks way way better than mockup imo.

The light brown frame rules out any ability to disagree with that. With a frameless look like Simutrans has now, mockup might have a slight lead.

IgorEliezer

*faints*

Dear! What a nice UI we've got there.

It seems Simutrans 2.0 on the way.

Max-Max

#171
QuoteWith a frameless look like Simutrans has now, mockup might have a slight lead.

That is the whole point with a theme, if you want a window without a border, you just design it with a 0 pixel border in the theme image. The look and size of the border is not fixed at a built in size, it is decided by the theme. The "border less" look we have to day is in fact a 1 pixel border.

What Prissi is referring to as a show stopper, is that before we get to the point of a client concept, all controls are moved in from the border, as a preparation for the client concept. This looks a little bit ugly because there is no theme to paint yet.

Why not implement client concept right away?
In the client concept a parent translates the coordinate system to its own client area and passes this down to the children. All GUI controls needs to be adjusted to work with the fact that the coordinate system has already been translated.

I did that at first but was told it was unaccepted because the GUI was really screwed up. I could do it all at once, but then the patch would be to big to implement. It doesn't matter how much we debate about the implementation as long we want small patches, we do get some "ugly" phases before it is fully implemented.

To get an understanding of what Prissi actually is referring to, I have attached the picture "Ugly.png".
This can already now be less Ugly by just changing the D_MARGIN_XXXX and D_DIVIDER_HEIGHT to something more balanced like 5 or 3 for D_MARGIN_XXX and D_V_SPACE+2 for the DIVIDER as in this picture "LessUgly.png"

EDIT
Later D_MARGIN_XXX will be replaced by the client area, where the client area's origin and size is defined by the theme's border.
- My code doesn't have bugs. It develops random features...

Yona-TYT

@Max-Max

impressive work ... :thumbsup:
Greetings....!!

Max-Max

Thank you for all the response. I just want to make it clear that both the Mockup.png and Client.png are Mockups. This is the vision of the theme system and we aren't there yet.
- My code doesn't have bugs. It develops random features...

prissi

I think you concept of simutrans windows got something wrong. The border of a window should not matter. I.e. get_groesse is the CLIENT area. Almost any elements but scrollbars should not extend (for VISUAL reasons) into a margin D_MARGIN_RIGHT. Scrollbars must extend there, as the posters above stated and you showed in the lower mockup.

Simutrans has a 1 pixel surround theme by the way: If you enable simutrans active window borders in simuconf.tab, you get already the look of number 2. So there is not much of a discussion, that was the place where the scrollbar was before your patch.

Less ugly image is actually more ugly for me. With an editbox (save window) it would be EvenMoreUgly ;)

I.e. scrollbar right at the right border of the window get_groesse size (which is the windows CLIENT area). Scrollbars without any offset. Because any window border would be window manager and theme dependent and must not affect the position of the client elements. They should not even know about the corder. (Like X windows: The interior of a dialogue does not change when changing the window manager.)

As a sidenote: from an ergonomical standpoint (and not from the window brainwashed GUIs) scrolling is much more often done than resizing. As such, a scrollbar at the border (especially with maximized windows) would be ergonomically preferred. They were actually also on the first, more research driven GUIs before MS had to reinvent the wheel to circumvent patents.