General GUI re-stylization
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: General GUI re-stylization
Do you not want any visible transition between the title bar and the background of windows like the galaxy setup? No gradients in the title bar, even?
A gradient across the body of the window or near the edges might look interesting.
Please illustrate mouseover feedback for everything that should have it, and how things change when being clicked on.
When do widgets - pictures or buttons or droplists - get border outlines that are dark then light or light then dark or just dark when moving outside towards their insides?
A gradient across the body of the window or near the edges might look interesting.
Please illustrate mouseover feedback for everything that should have it, and how things change when being clicked on.
When do widgets - pictures or buttons or droplists - get border outlines that are dark then light or light then dark or just dark when moving outside towards their insides?
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
I was thinking that the gradient title bar would be a distinctive of the moveable windows, but now i'm not so sure that works. At least for the moveable windows there needs to be some boundary between the grabable title bar and the rest of the window, which i haven't done yet because the content disguised the need.Geoff the Medio wrote:Do you not want any visible transition between the title bar and the background of windows like the galaxy setup? No gradients in the title bar, even?
I'd rather use gradients somewhat sparingly for emphasis. Also because a GUI with lots of gradients will probably have some odd issues when different elements are combined in different ways. Anyway its something that can be added later without otherwise changing the design.Geoff the Medio wrote:A gradient across the body of the window or near the edges might look interesting.
Of course, but that will probably be the last thing.Geoff the Medio wrote:Please illustrate mouseover feedback for everything that should have it, and how things change when being clicked on.
* Droplists are somewhat special because they need to be visible when intersecting any other UI element. I need to redo them because i hadn't thought about the occasional need for scrollbars.Geoff the Medio wrote:When do widgets - pictures or buttons or droplists - get border outlines that are dark then light or light then dark or just dark when moving outside towards their insides?
* Pictures are probably fine with a single black stroke... I just unthinkingly re-colored the strokes that were on my "galaxy setup" screenshot.
* Buttons of course depend on their status, mouse-state, etc. Text buttons and little wiget-y buttons like the ones to change the number of stars are probably different.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: 0.3 Production Screen
That's not really what I meant...eleazar wrote:Other examples: Giving the sidebar a "view mode" so that it displays only all your inhabited planets in all systems, or allowing the player to switch between a list and box of icons when choosing buildings or ship components.Geoff the Medio wrote:Having a small set of window template that can be the base for other windows is possible. Easiest is if a window always uses the same template, but if the templates are similar enough, we could swap which a window uses during runtime in response to user actions. (eg. "docking" a window to make it non-draggable and updating its apperance accordingly, although there's presently no window-docking functionality anywhere...)
A window rendering template (perhaps it needs a different name...) could be a bit of code that draws a window background with curved corners and a solid fill. It would be fairly easy to set up an option to switch between that bit of code and another bit that draws pointed corners and a blurred version of the stuff behind it as the window fill.
A slightly more complicated, but probably doable option might alter the position and size of widgets or controls in a window, or define how they resize and (using simple rules) how they reposition if the window enclosing them is resized.
But the key distinction here is that these examples just change how the existing window is rendered, or the position of wigits and controls. It is much more complicated to add or remove subwindows or widgets or change the content or behaviour of the contents of a window or control. Doing anything like that is would need to be done by changing the C++ code significantly right now. Doing it with a scripting language or XML file or similar would probably require a script or XML file almost as complicated as the equivalent C++ code, and the associated parser to be written.
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: 0.3 Production Screen
I guess i missed your point there, i wasn't suggesting that it should be doable in something like XML. Those were just scenarios in which we would want to transform a window.Geoff the Medio wrote:....Doing anything like that is would need to be done by changing the C++ code significantly right now. Doing it with a scripting language or XML file or similar would probably require a script or XML file almost as complicated as the equivalent C++ code, and the associated parser to be written.
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
I think i've covered all the major "box" elements, but perhaps i've missed some?
EDIT: added ship slots. The 3 different types of techs might also need better shapes, but i'm still kinda hoping for another solution that i haven't yet though of.
All the angles are 45º angles, but don't take the proportion of angle cut off to normal edge too seriously, these are just approximations.
EDIT2: scrollbar angles changed.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: General GUI re-stylization
There are slot controls on the design screen detail panel into which the user can drag part controls to define a shipdesign. I'm not sure if these should be treated with standard UI elements, though... In particular, a different appearance for external and internal slot controls would be good, since some parts can only go in one or the other. Other than what parts can be put in them, all slot controls act the same though, so using UI elements that normally indicate movability or resizability probably isn't best. Also, I'm not clear on whether "text-bearing Drag-able item does not include dragable icons (tech or production queue item)" includes queue panels or not. If not, what do queue panels look like?eleazar wrote:I think i've covered all the major "box" elements, but perhaps i've missed some?
What about panels within another window? In particular, each planet has a separate planet panel on the sidepanel, but the planet panels can't be dragged around independently of the sidepanel, but can be scrolled through within the fixed-position sidepanel. Currently there's no distinction between the background of the planet panel and the sidepanel that contains it, and the top of the planet panel is just indicated by the title bar, and the bottom by where the bottom of the bottom-most container within the planet panel is.
Would there be a way to distinguish the planet panels' extent from the sidepanel that ocntains them? If the planet panel's widgets are black background, then the planet panel would need to be dark gray to be distinct from the widgets, but then the sidepanel would need a third colour to be distinguished from the planet panels.
I don't want to extend the background of the planet panel around the rendered planets, but connecting them to the rendered icon somehow (besides being adjaent) and highlighting both when the planet is selected (eg. on the production screen) would be better than the current method of just encircling the rendered planet with an outline.
(We also have some planet selection indicator art, similar to the system icon selection indicator, that's not used.)
Edit: A possibility would be to not render anything for the sidepanel background where the planet panels are shown, and just have the planet panels be fixed to the right edge of the screen, and scroll through them with the scrollbar. There would be a small transparent gap in the space between adjacent plane panels. Planet panels would then use standard window shape and colours, and there would be no need for another set of colours to indicate the sidepanel's own extent. The top portion of the sidepanel that shows system-specific (not planet-specific) info would be a separate, with a border at the bottom, below which the planet panels would appear.
I'm not sure whether all instances of window-within-window could be avoided in this manner, though./Edit
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
Added to the previous post.Geoff the Medio wrote:There are slot controls on the design screen detail panel into which the user can drag part controls to define a shipdesign.eleazar wrote:I think i've covered all the major "box" elements, but perhaps i've missed some?
Heh, not the most lucid description. I was just trying to say that pure icons, like ship components, don't need to have that shape. It's supposed to include queue panels at least for the production queue.Geoff the Medio wrote:Also, I'm not clear on whether "text-bearing Drag-able item does not include dragable icons (tech or production queue item)" includes queue panels or not. If not, what do queue panels look like?
There are a lot of things that should change about how the sidepanel looks to make it easier to use, and consistent with the this new scheme. However, there's aren't many horizontal pixels to spare, so it is quite likely that it's design may need to be somewhat special. Generally i would make the scrollable area background the dark grey that's in the text box, and use the lighter (but still dark) background grey for the non-scrolling part.Geoff the Medio wrote:What about panels within another window? In particular, each planet has a separate planet panel on the sidepanel, but the planet panels can't be dragged around independently of the sidepanel, but can be scrolled through within the fixed-position sidepanel. Currently there's no distinction between the background of the planet panel and the sidepanel that contains it, and the top of the planet panel is just indicated by the title bar, and the bottom by where the bottom of the bottom-most container within the planet panel is.
Yes, but it wouldn't be by leaving the black background which is problematic for all the same reasons previously discussed that other things should no longer be black. A bunch of lines, words, and icons floating on black just doesn't give you much room to express the interrelationships.Geoff the Medio wrote:Would there be a way to distinguish the planet panels' extent from the sidepanel that contains them? If the planet panel's widgets are black background...
I've work on mock-ups for the sidepanel too. I just haven't shown them yet because they are pretty messy, and would at this point probably cause more confusion than understanding.
I agree about the highlighting. The problem is that extending the background is the most obvious means of accomplishing what you've just described.Geoff the Medio wrote:I don't want to extend the background of the planet panel around the rendered planets, but connecting them to the rendered icon somehow (besides being adjaent) and highlighting both when the planet is selected (eg. on the production screen) would be better than the current method of just encircling the rendered planet with an outline.
Also, I've long been dissatisfied with the way that the sidebar planets can easily get jumbled and obscured by the stuff on the galaxy map. And having bits of intractable map between the planets and the sidepanel proper is just weird. Like this, outdated, but still relevant screenshot:
This design works fine for "window-within-window", but would break if we had to do "window-within-window-within-window".Geoff the Medio wrote:I'm not sure whether all instances of window-within-window could be avoided in this manner, though.
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: General GUI re-stylization
Did you intentionally swap the corners of the scrollbar that are cut off?eleazar wrote:Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.
Otherwise, looks pretty good, IMHO.
- The Silent One
- Graphics
- Posts: 1129
- Joined: Tue Jul 01, 2003 8:27 pm
Re: General GUI re-stylization
I agree. Nice work, Eleazar!Geoff the Medio wrote:Otherwise, looks pretty good, IMHO.
If I provided any images, code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0.
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
Yeah, somehow it didn't look right the way i had it in the "shape vocabulary". Updated.Geoff the Medio wrote:Did you intentionally swap the corners of the scrollbar that are cut off?eleazar wrote:Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.
In order to be able to mix-n-match all these elements in the most efficient and consistent way possible, i mentally employed something i'm calling "default minimum inset". This controls how far away different elements are from each other, for instance the distance of buttons from each other or the distance of a text-box from the edge of its containing window. It's called "default" because 90% of the time you'll want to use the same minimum inset for an instance of a "button", but occasionally you'll want to give it a special value.
How it works: When two elements are next to each other, you use the largest inset value, unless one of the elements is set to ignore inset. For instance, the scrollbar and resize-tab are theoretically set to ignore other insets, and thus can get jammed up against the right and lower-right (respectively) corners of the box that contains them. However, while buttons have a default minimum (DMI) inset of 2 pix and the entire window has a DMI of 6, the buttons end up 2 pixels away from each other and 6 pixels away from the edge of the window.
Does that make sense? Basically it is supposed to make consistent placement easy, as well as global changes to the interface.
Type styles used:
Standard Title Bar Title = FFFFFF, Bold, 13pt, Shadow
Enabled Button Text = FFFFFF, Book, 12pt
Disabled Button Text = "Enabled Button Text" + 747474
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: General GUI re-stylization
It makes sense as described, but it's not clear how you want the values to be used.eleazar wrote:How it works: When two elements are next to each other, you use the largest inset value, unless one of the elements is set to ignore inset. For instance, the scrollbar and resize-tab are theoretically set to ignore other insets, and thus can get jammed up against the right and lower-right (respectively) corners of the box that contains them. However, while buttons have a default minimum (DMI) inset of 2 pix and the entire window has a DMI of 6, the buttons end up 2 pixels away from each other and 6 pixels away from the edge of the window.
Does that make sense? Basically it is supposed to make consistent placement easy, as well as global changes to the interface.
If you're expecting some automatic layout based on rules in a text file, that might not be realistic. There is a window contents Layout mechanism built into GiGi, but it's rather limited in what it can be used to do and how configurable it is... at least as far as I know. Figuring out a more general-purpose system is probably a lot more work that specifying exactly where everything should go in code...
In particular, a widget put onto a window won't automatically know about the other widgets in the window, and won't know which ones to check if it's too close to, or how they should all rearrange themselves if they are too close or how to deal with conflicting restrictions. There also needs to be a way to tell them collectively that "these ones go at the top in a single row and are about this wide unless there's not enough space and then they can go into two rows, and this one spans the width below them and this one is at the very bottom right and doesn't care if it overlaps other things..." etc.
What I mostly do now in window layout code is specify a top left position based on an EDGE_PAD constant, and then loop through the things I need to place, moving the placement position by placed_thing.Width() + SPACING_PAD or placed_thing.Height() + SPACING_PAD depending on the situation, and jumping down to a new row if I run out of space in the direction I was stepping.
We could standardize the use of EDGE_PAD (between window border and nearest control) and SPACING_PAD (between adjacent controls) values throughout the UI and make it an option in the options screen, but making layout scriptable in the sense of "these ones go at the top and this goes below" is much harder.
That said, a currently glaring omission from the GUI toolbox is a general-purpose media window. There is a multi-line edit (text) control that can display formatted text, like is used for tech descriptions, but there's no way to embed an image in this text. What we need is something that can process HTML-like picture + text layout directives to make much more readable help text, among other uses. (This would also let us use full-sized tech icons on help screens, embedded in the text, rather than smaller ones up on the title bar...)
If we had something like that, hopefully it would be set up in such a way that it could be used to do the same for layout of controls in a window. The use would be more limited, since you could add controls to a window that aren't defined in code already, but you could specify their layout with HTML-like directives...
What do you mean by Book and + 747474 ?Standard Title Bar Title = FFFFFF, Bold, 13pt, Shadow
Enabled Button Text = FFFFFF, Book, 12pt
Disabled Button Text = "Enabled Button Text" + 747474
Re: General GUI re-stylization
Not sure about "book" either, but 747474 is most probably a color.Geoff the Medio wrote: What do you mean by Book and + 747474 ?
- eleazar
- Design & Graphics Lead Emeritus
- Posts: 3858
- Joined: Sat Sep 23, 2006 7:09 pm
- Location: USA — midwest
Re: General GUI re-stylization
Yeah, 747474 is the hexadecimal color... a lightish grey.pd wrote:Not sure about "book" either, but 747474 is most probably a color.Geoff the Medio wrote: What do you mean by Book and + 747474 ?
"Book" is what some fonts (including dejavu sans) call the "normal" or "standard" form of their font, i.e. not bold or oblique.
Re: General GUI re-stylization
I'm going to be a stick in the mud, so get ready. How is this thread different from a new member dropping by the Design subforum and suggesting off-starlane travel? Admittedly, the UI could use prettifying, but just as we say that we must accept existing designs in order to maintain forward progress, we should also say that we must accept the existing graphic design (or even lack thereof) in order to progress.
I am specifically saying this because the proposed changes are good, but would require substantial graphics and coding time to accomplish, and we are in desperately short supply of both. I have a huge laundry list of graphics assets I need to keep working on 0.4's combat engine, and I don't have all but few of them. (I also don't have much time to work on FO, but whenever I do get time, the stuff I can work on is a bit limited due to this list being unfinished.) I also have a long-ass list of stuff that needs to happen coding-wise. I feel that redoing the entire look of the game at this point is a little crazy to be honest.
I am specifically saying this because the proposed changes are good, but would require substantial graphics and coding time to accomplish, and we are in desperately short supply of both. I have a huge laundry list of graphics assets I need to keep working on 0.4's combat engine, and I don't have all but few of them. (I also don't have much time to work on FO, but whenever I do get time, the stuff I can work on is a bit limited due to this list being unfinished.) I also have a long-ass list of stuff that needs to happen coding-wise. I feel that redoing the entire look of the game at this point is a little crazy to be honest.