News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

GUI overhaul

Started by prissi, May 31, 2010, 08:44:59 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

prissi

Since everybody has different ideas about what a GUI can do, I want to open a discussion to give the current overhauls so broader acceptance.

Currently only text field can receive a focus. Should button accept a focus and allow space to switch the state? Surely then the focus of a button must be indicated, maybe by a white box around it?

Any other brainstorming stuff, when it comes to the GUI and you want to have from you favorite window manager, please be free to speak up. No guarantees for implementation, but we want to hear your input.

VS

Focus... I'd say the best case is when all input elements can receive focus (checkboxes etc.), as usual elsewhere. But is that even needed? There is no getting around the fact that this is a game. There aren't many windows with lots of controls, where good "tab order" can help against RSI. Advanced settings are closest to what I have in mind, and that's only one example.




Slightly offtopic: What irks me somewhat are multiple info windows - some way of closing everything from "lower gaming class" objects would be nice. Think trees (so many per tile), citycars, pedestrians, ways... everything that does not really generate data for player. On one hand there are situations when I want to see them, on the other it's not convenient to edit simuconf and restart game every time I do...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

sdog

With wide angle screens having taken over the pc display market, in a little while they will be the predominant display used by simutransplayers, if they aren't already. Since vertical space is limited, but horizontal space plenty on them rotating the gui elements would be advantageous.

Instead of long floating horizontal bars with icons in a line, vertical tool panels with more strongly grouped icons (2 to 3) columns.

The next idea is a bit more substructuring to reduce clutter. This applies particulary to tools like tracks, stations etc. Here the idea is click+hold on the icon brings up a list with different alternative icons, the player chooses one wich becomes active and is used on the next direct click on it. This is often seen in tool selection buttons of graphic editing software. A double-click either expands the panel with those options or ads a new column/row with the options to the panel.

Something that's possible already, and seems to depend on the pakset: Some options are used quite often, but are hidden rather well (turn on station coverage overlay, hide city buildings) while other rarely used options are relatively prominent (some station/airport additional buildings, found city button, screenshot).

Consolidating all remove-waytype buttons into the one remove button on the main gui, in the way described above.

Quicksave, with hotkey!

yobbobandana

I think it would be very useful if you could "roll up" the windows so that just the titlebar was displayed.

This would allow the player to keep windows accessable while interacting with the game environment. For example, roll the depot window up while adding waypoints to a line, then unroll it when done to send the convoy on its way.

Also it would be nice if windows remembered their sizes :). I resize the Line Management window almost every time I use it.

knightly

Quote from: yobbobandana on June 02, 2010, 04:02:16 PM
I think it would be very useful if you could "roll up" the windows so that just the titlebar was displayed.

This is already possible. Just right-click on the title bar and the window will be rolled-up. Probably because there is no separate button for this, so few people notice this very convenient feature.

skreyola

Quote from: sdog on May 31, 2010, 11:15:37 PM
The next idea is a bit more substructuring to reduce clutter. This applies particulary to tools like tracks, stations etc. Here the idea is click+hold on the icon brings up a list with different alternative icons, the player chooses one wich becomes active and is used on the next direct click on it.
:support:

I'd also like to see roller buttons (like on the map selection area in the new game screen, or the fill requisite in the schedule window) on the slice mode button, so I don't have to open the options menu (three-four clicks) when slice mode doesn't open on the right level.

Also, I think the zoom has too many accesses. It zoms with PgUp/PgDn and with the mouse wheel (which I would rather did other things, such as change the slice mode, at least when the cursor is over it.

Quote from: Knightly on June 02, 2010, 05:28:44 PM
This is already possible. Just right-click on the title bar and the window will be rolled-up. Probably because there is no separate button for this, so few people notice this very convenient feature.
I use this all. The. Time. :)
--Skreyola
You can also help translate for your language with SimuTranslator.

prissi

Change the slice can be done (at least in pak64) by + and -.

sdog

Station Coverage, Buildings visibility, Underground View, Slice View, Change Slice*

Enough view related elements, i think, to put them in their own menu bar.

*having a gui element saves you a lot of questions how to change the slice.

skreyola

Thanks for the info, prissi.
--Skreyola
You can also help translate for your language with SimuTranslator.

VS

sdog: Add tree visibility and I have my toolbar of dreams :)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

yobbobandana

Quote from: Knightly on June 02, 2010, 05:28:44 PM
This is already possible. Just right-click on the title bar and the window will be rolled-up. Probably because there is no separate button for this, so few people notice this very convenient feature.
Yikes. I had even tried double-clicking the titlebar and right-clicking the buttons to no avail. I change my request to a button for this tremendously useful functionality :).

After a while playing, I assumed the right mouse button wasn't ever used in the simutrans GUI, as it never seemed to do anything when I tried it on elements.

skreyola

Quote from: yobbobandana on June 03, 2010, 07:31:20 AM
Yikes. I had even tried double-clicking the titlebar and right-clicking the buttons to no avail. I change my request to a button for this tremendously useful functionality :).

After a while playing, I assumed the right mouse button wasn't ever used in the simutrans GUI, as it never seemed to do anything when I tried it on elements.
The RMB is one of the more useful commands in ST. Try dragging with the RMB... that's how I usually move the viewscreen around.
--Skreyola
You can also help translate for your language with SimuTranslator.

sanna

#12
Not really "overhaul" material, just minor tweaks:

I would love a button in the top bar for each of the dialogue to shrink it to smallest allowable size... I often expand windows facilitate looking at a long list (of f ex cargo) then want to shrink it back down to still be able to see the stats...

Also, specifically for the convoi information dialogue, it would be nice to  have the status for the convoi (all the things that show as popups when hovering the convoi) available here as well... somewhere close to the image...


EDIT: A "maximize" button would also be nice... expanding the window to show the entire content or the dimensions of the enclosing window which ever is smaller...

EDIT 2: Sticky windows would be nice.. I mean a way to specify that a certain window should "survive" close all windows with backspace...

wipi35

Quote from: sanna on June 04, 2010, 05:58:17 AM
A "maximize" button would also be nice... expanding the window to show the entire content or the dimensions of the enclosing window which ever is smaller...

I strongly support this.

prissi

Just a note. Originally was not about GUI extension requests. I wanted to know how people expect that GUI elements should behave. I would still like to hear about this more.

Combuijs

QuoteCurrently only text field can receive a focus. Should button accept a focus and allow space to switch the state?

What VS said: could be nice, but is not necessary.

It would be nice however to be able to set the focus to another field by using for instance TAB and Shift+TAB. That would make for example the new-game dialog and the settings dialog a lot easier to use.

QuoteSurely then the focus of a button must be indicated, maybe by a white box around it?

Something along those lines, yes. Same goes for text-fields then. Maybe a bit uncomfortable if the button is white itself (f.i. city statistics - citizens button). Maybe you could use the opposite color (black vs white, red vs green), but then the most-used grey color might be unclear.

Quote

Any other brainstorming stuff, when it comes to the GUI and you want to have from you favorite window manager, please be free to speak up. No guarantees for implementation, but we want to hear your input.

I've been always been a fan of context-menu's, e.g. using the right-mouse button to get a menu of possible actions related to the object at that place. For instance right-click on a building would give a menu with (delete, get info, buy etc.). Or while building track: start track, then right-click on a tile would give a menu with (connect, connect straight, electrify, maybe even remove) as an alternative to left-click resp. Ctrl+left-click.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Dwachs

Quote from: Combuijs on June 04, 2010, 09:53:40 AM
It would be nice however to be able to set the focus to another field by using for instance TAB and Shift+TAB. That would make for example the new-game dialog and the settings dialog a lot easier to use.
That is already available in the very recent nightly.
Parsley, sage, rosemary, and maggikraut.

VS

The only thing that I can think of and relates to controls themselves is a proper distinction between a checkbox and radiobutton.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

wlindley

Is it me or do most windows in standard nightly no longer close when you hit Esc ...?   Example, open game, click Settings; Esc does not close the dialog.

skreyola

per Combuijs' suggestion: If you use red opposite green, make sure you choose shades of these colors that contrast with each other, or you'll make the game inaccessible to people with color deficiencies.
--Skreyola
You can also help translate for your language with SimuTranslator.

Dwachs

#20
Quote from: wlindley on June 04, 2010, 03:06:18 PM
Is it me or do most windows in standard nightly no longer close when you hit Esc ...?   Example, open game, click Settings; Esc does not close the dialog.
this is/was a bug, fixed with revision 3406.
Parsley, sage, rosemary, and maggikraut.

sanna

Well, if  we are dreaming.... then freeing the information windows from the constraint of the main window allowing them to be dragged onto my second monitor would be nice....

TurfIt

Quote from: prissi on June 04, 2010, 08:48:13 AM
Just a note. Originally was not about GUI extension requests. I wanted to know how people expect that GUI elements should behave. I would still like to hear about this more.

Scroll bars - I would expect all scroll bars to continue scrolling when I hold the mouse button down on a scroll button. Some currently do, some don't.
               - pageup/down should also repeat when holding mouse button down on the scroll bar. None do.

Combobox - I would expect them to be a read only list. You can currently edit the text in the combobox and have the edit reflect back to the item. e.g. In the depot line selection combobox, the text field lets you change the name of the line. Not expected behaviour.

Keyboard focus - Most elements when clicked on now steal the keyboard focus entirely. Expected for a text entry box. Not expected for simple buttons. I would expect normal game hotkeys to continue functioning after simply clicking a button without needing to hit ESC first. Also, if ESC is defined to close the window, then I expect it to close the window - everytime. i.e. Multiple control functions assigned to the same key, a context sensitive keyboard in essence , is not expected.


TrainMith

#23
Quote from: TurfIt on June 16, 2010, 01:17:20 AM
Scroll bars - I would expect all scroll bars to continue scrolling when I hold the mouse button down on a scroll button. Some currently do, some don't.
              - pageup/down should also repeat when holding mouse button down on the scroll bar. None do.
I don't recall this being an issue with any version that I have used.  What part of the scroll bar are you holding the mouse upon; either of the up/down arrows at the top/bottom, the region above/below the slider, or upon the slider itself?

Quote from: TurfIt on June 16, 2010, 01:17:20 AM
Combobox - I would expect them to be a read only list. You can currently edit the text in the combobox and have the edit reflect back to the item. e.g. In the depot line selection combobox, the text field lets you change the name of the line. Not expected behaviour.
I rather enjoy this feature, so that I can immediately change the name without having to open the line management dialog.  My only frustration is that clicking it again closes the combobox, which prevents the text editing again.


Quote from: prissi on May 31, 2010, 08:44:59 PM
Currently only text field can receive a focus. Should button accept a focus and allow space to switch the state? Surely then the focus of a button must be indicated, maybe by a white box around it?
Tab key focusing with spacebar toggling would be nice, but make sure to have a definitive representation of a selected state.  Your suggestion of an encompassing white box indicating a selected state would seem to be conflicting with the indication of the focused control.  I recall a totally different windows application where a checkbox toggle button just changed color to indicate selection, and it was difficult to distinguish with the unselected state. 

Should checkbox toggle buttons have an X (or check mark) to indicate a selected state?  I would prefer so, with no opinion regarding which of the two marks to be used for the selected state.

VS

We should standardize a bit our terminology, I guess...

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

skreyola

In every other context I've ever seen, A = radio buttons, b = checkboxes. YMMV?
--Skreyola
You can also help translate for your language with SimuTranslator.

prissi

But simutrans has nearly no radio buttons with the execption of the langauge settings. Is there really a new button needed for that? (Implementing this would be easy, as radion buttons must be handled anyway by their respective dialogues.)

jonasbb

Could the scrollbars have changeable graphics? You could change all buttons and images, but scrollbars still look everywhere the same.

Frank

Quote from: jonasbb on June 17, 2010, 02:07:01 PM
Could the scrollbars have changeable graphics? You could change all buttons and images, but scrollbars still look everywhere the same.

scrollbars added in r3487

ӔO

#29
I don't know if this would fall under extensions, but there are 3 things I'd like to see.
1: In the line management window the "line list box" doesn't scale with the window size and I think it would be better if it did like the "lists" window.
2: Also in the line management window, is it possible to "jump to on keystroke"? Currently I have to scroll through the list and when you have... 300 or so lines and you want to find something in the middle, let's say "Huntsville", it becomes rather annoying to find it by scrolling, when instead "h" can be hit to jump there.

I would like to see a more obvious display for currently focused windows.

For the message centre options, can the words and check box be changed to more layman's terms?
Currently it's Ticker, Transient dialogue box, Non-transient dialogue box.
Might it be more obvious if it was Scroll at bottom, Pop-up Window, Message center main window? or something similar.
It might also be a bit confusing to use the check boxes, since it's just a button that is depressed and not really a check box. On? Off? which?
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Isaac Eiland-Hall

Dunno if this counts as the right topic, please forgive if not:

I'd really like to be able to select text with the mouse, and perform simple operations - delete, cut, copy, paste. Delete is most important... I remember when we couldn't even click in the middle of the text, and being able to do that helps a little, but in a perfect world:

- highlight text with mouse
- For highlighted text, delete key deletes

That's most important. But also nice:

- ctrl-a selects all text in a box
- ctrl-c copies to clipboard
- ctrl-x cuts to clipboard
- ctrl-v pastes text (overwriting any highlighted, if applicable)

I don't know how universal those keyboard shortcuts are, though...


skreyola

@Isaac: They work in 95% of programs I've used with those functions. But some emacs fan will probably say they need to be different. ;)
@AEO: All dialog boxes are "pop-up windows". I think your suggested replacements are less accurate than what is currently in place... but it should be possible (AIUI) for you to change them on your machine with a custom translation file.
--Skreyola
You can also help translate for your language with SimuTranslator.

sdog

Isaac, look at the picture again, it's turned off, i think.

Quote from: skreyolaBut some emacs fan will probably say they [the keyboard shortcuts] need to be different.
screw emacs users! They're just to dogmatic to learn vi, that's the standard anyone should immediately adopt.

knightly

Quote from: AEO on July 12, 2010, 10:42:43 PM
It might also be a bit confusing to use the check boxes, since it's just a button that is depressed and not really a check box. On? Off? which?

A checkbox in Simutrans is essentially button. As to its appearance, it can be changed by changing the skin -- it's up to the pakset maintainer to change it. For instance, Pak96.Comic has the kind of checkbox that looks like a traditional checkbox.

ӔO

Quote from: skreyola on July 13, 2010, 02:20:07 AM
@AEO: All dialog boxes are "pop-up windows". I think your suggested replacements are less accurate than what is currently in place... but it should be possible (AIUI) for you to change them on your machine with a custom translation file.

I think, "show in Transient window" gives the popup which takes away focus, while "show in non-transient window" will show messages in the message dialogue box, but you have to manually open this window. Technically it's the correct term, but I would have to say that it's not immediately obvious to someone who doesn't know the terms.


@Knightly
Aha, thanks for that information. I thought it wasn't part of the skin.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart: