this morning i was looking at the new instant replay system and thought: if only all of flightgear could look like that. so in about an hour of testing and trying out i got this. this gui was made by editing the other Flightgear gui's and copying some items from the replay gui style

yes it would be nice to have many Gui styles included with flightgear for diferent aircraft for people who can not read as good etc. that matches everyones styles or maybe a specific aircraft, i liked making my first Gui it has also made me more interested in XML (notepad in this sub-forum)

so if anyone has a suggestion for a Gui that can work for many send me it and i'll see what i can do

right now i am trying create a somewhat "light" gui type small yet readable also if anyone knows how to make the text less blurry under size 11 please help

I am aware that omega95 did a gui comparable with mine and infact i didn't copy it at all i was completely unaware when i started making it.but there are infact some differences: mine is more grey than black, i use blue instead of white for secondary color plus my text is a bit smaller than his. It wasn't my intention to copy anyone but i guess he just got to it before me.

Anyway i am creating another gui a "light" one it should be finished today.

Trez wrote in Sun Apr 08, 2012 11:43 am:I am aware that omega95 did a gui comparable with mine and infact i didn't copy it at all i was completely unaware when i started making it.but there are infact some differences: mine is more grey than black, i use blue instead of white for secondary color plus my text is a bit smaller than his ...

I can tell you, from a personal experience, that the two GUI referred to above offer different user experiences (pros and cons). Your contribution is undeniable!

I like to make it clear that you do not need to, and have NO reason to, justify whether or not you have used GPL ideas or material from other projects. We share an 'Open' environment: the focus is more on innovation and sharing. We do that by copying and innovating to evolve what has been copied. We welcome it. You just have to look around to see the many abandoned projects that are begging to be copied, debugged and evolved to a more usable state.

'Git' wit it - its the fun way

awexome.

When one thinks, one looks up to the skies. I inspire, think, and seek the skies ------- mijiny <aka awexome[2138]>

i guess i can make a tutorial on making gui's manually and i'll checkout the styler omega95 made and do a tutorial on that too. Making Guis is easy fun and it's something you made yourself. and with XML there are endless posibilities

It's kinda funny how people keep proving that the existing GUI can still be improved, even though there have been talks about completly replacing it for like over half a decade Given that more and more people mentioned a different approach (absorbing the PLIB PUI GUI library, making it a part of SimGear and improving it there), this seems like a sensible movement.

Hooray wrote in Tue Apr 10, 2012 1:11 pm:Given that more and more people mentioned a different approach (absorbing the PLIB PUI GUI library, making it a part of SimGear and improving it there), this seems like a sensible movement.

Just so you know, I'm working on this at the moment (but don't hold your breath) - but in the first instance the goal is to keep the visual appearance identical, and compatible with the style system, so I don't break many custom dialogs. In the future the way the styling is done may change to use textures for item, to avoid lots of OpenGL primitives, but that's months away - so this work is appreciated!

This style just give a new life to the gui system. It make the whole program looking much better, younger and a bit more modern!Please, try to create a merge request or post that to the mailing list or whatever to get this included into fgdata.Thanks for your share!Regards,

That's the sort of stuff that's defined by the GUI library used by FlightGear: PLIB's PUI.

In the description of each widget class below, there is a small screenshot of one example of that widget. You can see the code used to generate those screenshots in the PLIB example program widget_list.cxx. However, by changing the rendering style, you can make them look considerably different from this.

When the widget is drawn, the application has control of the drawing style and the colours in which the widget is drawn. Reasonable defaults are provided by PUI if you don't set them:

PUSTYLE_NONE - No background is drawn for the widget - just the legend and the label. PUSTYLE_PLAIN - Just a plain solid-coloured rectangle. PUSTYLE_BEVELLED - The widget is drawn with a three-dimensional-looking bevelled edge around it - with the 'light' shining on it from the top left. PUSTYLE_SMALL_BEVELLED - Same as for PUSTYLE_BEVELLED but with a smaller border. PUSTYLE_SHADED - Similar to PUSTYLE_BEVELLED - but with the main rectangle counter-shaded. PUSTYLE_SMALL_SHADED - Same as for PUSTYLE_SHADED but with a smaller border. PUSTYLE_BOXED - A simple rectangle with a line around the outside. PUSTYLE_SPECIAL_UNDERLINED - A simple rectangle drawn with a thin line at the bottom, giving an "underlined" effect like you can see in the puMenuBar and puVerticalMenu widgets. PUSTYLE_DROPSHADOW - A simple rectangle - but drawn with a shadow below and to the right to make it look like it has been raised off of the page. PUSTYLE_RADIO - The bounding rectangle and the legend text isn't drawn at all - the widget is drawn as a small diamond shape which is filled in when the object has a non-zero value. This is only useful for puButton widgets.

In case of PUSTYLE_BOXED and PUSTYLE_SPECIAL_UNDERLINED, you can alter the thickness of the border around the widget / the width of the line at the bottom of the widget or retrieve the current value:

You should be careful to call the "setBorderThickness" routine after you have specified the widget style. The "setStyle" function sets the border thickness automatically and will overwrite any previous border thickness you may have set.

By default, a border thickness of two pixels is used in PUSTYLE_BOXED. For PUSTYLE_SPECIAL_UNDERLINED, a one pixel wide line is drawn.

In addition, you can use the negation of the style to swap the appearance of the selected and deselected versions of an object. Hence, using a style of -PUSTYLE_BEVELLED will produce a widget that appears to be pressed in when its value is zero and popped out when it's value is non-zero.

While most widgets default to a style of PUSTYLE_SHADED, some of the more complex types such as sliders and menus pick more complex defaults in order to look 'reasonable'. You can still override those defaults - but the results can often be less than desirable.

PUCOL_FOREGROUND, PUCOL_BACKGROUND, PUCOL_HIGHLIGHT - Depending on the style which you have set, these colours are used for different purposes while drawing the widget's ABOX. PUCOL_LABEL - Obviously, this is the colour which is used when drawing the label of a widget. PUCOL_LEGEND - The colour that is used when the legend string is drawn. For the puInput, puLargeInput and puListBox classes, which don't have a legend, PUCOL_LEGEND is the colour of other kind of text inside the widget. PUCOL_MISC - This colour is used for miscellaneous things in some classes. Currently, it indicates the colour of the arrow inside a puArrowButton, and it is used while drawing the circle that is inscribed in a puDial or the text cursor in the puInput and puLargeInput widgets.

Picking all of the individual colours for each widget can be tedious, so there is a handy function that sets a 'theme' colour for the widget and then picks suitable colours near to that theme for the other colours of the widget. This function works well enough that you will almost never need to set the colours individually.

Please note that these routines only affect the appearance of the widget itself in case of classes that contain subwidgets and are not menu widgets (currently puFileSelector, puLargeInput, puComboBox, puSelectBox and the obsolete puFilePicker class).

However, these classes are all derived directly or indirectly from puGroup, and thus you can use the appropriate puGroup functions in order to change the styles, colours or border thicknesses of the subwidgets.

In addition to the pre-defined styles, PUI allows you to create your own drawing function and save the related drawing data. This is done by means of the "render data" and "render callback." A render callback is a user-defined function that has the following definition:

The function takes four parameters: a pointer to the object whose render callback this is, the x- and y-coordinates of the lower left-hand of the widget, and a pointer to your render data. The user tells PUI to use his rendering callback instead of the usual drawing function by invoking the following function:

The two arguments are the name of the render callback and an optional pointer to the user-defined render data. If a render callback exists, the widget's draw function renders only the activity box (unless PUSTYLE_NONE is used) and the label (if you specified one) and calls the render callback afterwards instead of executing the code which would normally be used to draw the widget.

PUI also has functions to allow the user to retrieve and invoke the render callback: