My Window system, features list.

[Zuu]

As promised I have created a list of features in my window system that I created for my old project. I have both submited the file directly in the post with some formations, and the orginal textfile.

If you like to see the window engine in action I suggest that you download Junctioneer 0.0.0.6, which demostrates the commands best. 0.0.0.6 uses lua for defination of windows and commands, which the later versions dont do. (lua 5 is recured for all versions.)

Download page for junctioneer

One thing I forgot to mention is that it does not relay on any images, nor non vertical/horizontal lines.
=====START OF FILE======
Features:

General
* Close all windows with a single call (possibility to exclude ZTopLocked windos).
* Possibility to have another color of the head on the active window.
* Not well commented, althroght I can fix that quite easy.

Windows
Windows have these boolean properties:
* Rezisable.
* Minimizable
* ZTopLocked = no other window can steal focus. Click in terrain will have no effect when at least one window is Z top locked.
* Movable
* Closable
* Draw head
* Draw border

Windows have the close button at the top left corner of the window. No other buttons are implemented. In oposite to WinButton this button is not graphicaly pressed down. A double click at the list minimizes (Only head will be shown) the window.

Action system (a bit programming related):
To create costomized windows (all windows that are not blanc are costomized) you create a class that inerheit from the window base class. I have choosen this way becuse this makes it easier for action functions, which are members of the specialized class, to extract data from the window and its commands. This way have some drawbacks. But I have came to the insight that there is no nice solution on this problem, that looks nice, compiles fast, allow easy window creation, etc.

Actions: (other can easily be added)
* Closed
* Minimized
* Unminimized

Window Commands
A window can have serval commands. Commands is called WinCommands, short for Window Commands.

WinCommands have up to 2 actions. (a remnant from lua time)

List of WinCommands:

Implemented:
* WinButton (text or image)
* WinLabel
* WinTextbox (editable)
* WinCheck (checkbox)
* WinImage
* WinPushbutton (text or image)
* WinIsoview (not usefull for TEmpire)
* WinProgressbar

Planed:
* WinOption (option button)
* WinList
* WinDroplist
* WinScrollContainer
* WinTabContainer

Plans for containers:
To make a command scrollable or to implement tabs the window engine should use containers. A container is a WinCommand that contains another WinCommand. Parts of the contained WinCommand that overflows the Container is clipped away.

So to make a scrollable list put a WinList inside a WinScrollContainer.
=====END OF FILE======

[PJayTycy]

Is it my idea, or does this look a lot like the java swing system?

eg: windows are classes that inherrit from a base class, the ScrollContainer thing...

I'd like that, because java swing is about the only "graphical engine" I know

[Zuu]

Is it my idea, or does this look a lot like the java swing system?

eg: windows are classes that inherrit from a base class, the ScrollContainer thing...

I'd like that, because java swing is about the only "graphical engine" I know

Actually the idea behind the ScrollContainer came when I was reading the Wesnoth code, which is well written. If I had knew GTK when I started to code my windowing system, I probably have used their way to put content into buttons etc. For everyone that dont know how GTK works, buttons are contianers. In the button containers you can place a label to create a button with text. If you want a button with a progressbar you can do it.

[eis_os]

WinIsoview , hmm, reminds me to my own GUI System in WinRT

[jfs]

I have been working on a windowing-system earlier as well, pretty much a year ago.
In fact, it was originally though as a "might be used for TE", but the project died out. I do have some working code and a design document though.

Link: http://www.jiifurusu.dk/files/programming/tg-gui/

In the screenshots, the colored boxes are preliminary "windows". The system will be able to support full alpha blending and "masked" windows, ie. non-rectangular, by alpha masks.
IIRC, the most important thing to implement into it currently is full keybord event support. Otherwise mouse events alraedy work, IIRC. Also, I think the drag-and-drop support is incomplete.
Apart from that, some standard controls need to implemented. Also, it needs optimisation.

[Arathorn]

That link doesn't seem to work.

[PJayTycy]

It works for me...

But it mainly shows of alpha blending for different windows on top of each other. No UI components are visible. jfs, did you make some yet ? How are events implemented in your window system ?

[jfs]

But it mainly shows of alpha blending for different windows on top of each other. No UI components are visible. jfs, did you make some yet ? How are events implemented in your window system ?

As I wrote above, there's no actual GUI components implemented yet.
I haven't worked on the system for a long time, and can't bother to re-read my design document and code right now (those are also on the website btw.), so the following is purely from memory.

Mouse and keyboard events are handled slightly differently. For mouse events, the event is sent to the root window, which performs a hit-check against all of its immediate childs. If any of the childs are hit, the event is transferred to that child, otherwise it's processed by the root window. This process is then repeated for the new window. Each window only knows of itself, its immediate parent and its immediate childs. It can, of course, then traverse the tree.
Drag-and-drop is handled by telling the root-window (actually the parent-window which propagates the message, iirc) that you want to perform a drag-drop, and optionally giving an icon to follow the cursor. While a drag-drop is under way, all mouse events are passed directly to the requesting window. (Drag-drop isn't fully implemented, but the basics do work; it's used for moving windows.)

For keyboard events, the concept of input focus (actually just the topmost window) is used. Any window can request to get input focus through its parent, which will propagate the request until it reaches the root window. There is an active window at each level. All keyboard events are passed unconditionally from a parent to its active window until it reaches a window with no childs. That window can then choose to take the event or ignore it. If it's ignored, it's sent "backwards" through the chain again, to give earlier windows a chance of processing it instead. (A text input field could eg. discard anything that isn't suitable for input, so ie. hotkeys can be processed.
I don't know how mouse wheel events would best be handled, currently, because both approaches (mouse hittest and active window) can work for that.

Ragioned (shaped windows) are handled by an alpha test in the mouse hittest routine. If the alpha value of the pixel at the mouse is below a certain threshold, that point is considered to not belong to that child.

Rendering is handled by a window requesting to get the bitmap from each of its childs in bottom-up order. Those bitmaps are then overlaid each other. Bitmaps are cached, and windows that have changed are marked as "dirty", so they will be repainted on next screen update. Dirtyness is propagated down towards the root window.


One of the reasons I stopped working on the project was, that I never managed to compile it on Windows. The compiler (I think I tried mingw) didn't want to cooperate... for the previous testing I was running it on my Linux server and displaying it on an X server on my Windows machine, but that was hellishly slow. I once tried setting up an X server on my server (yeah, a bit stupid to overload it with that really) and ran it there, where it was much smoother, though still not perfect.
The other reason is my lazyness =)

On a sidenote, this was my first time coding something serious in C++, so the code might not be the best C++ style you can find. (I haven't used C++ much since. It's not really my favourite language.)

[jfs]

Ok, I've put up a new, cleaned up, version of tg-gui up on http://www.jiifurusu.dk/files/programming/tg-gui/ - it has build scripts for the test programs I've been writing and doesn't contain redundant files.
If anyone manages to compile the test programs on Windows I'd like to hear about it.

[charlieg]

There's also CEGUI which is getting a lot of plaudits, especially in OGRE circles.

[Zuu]

The first link isn't working. Did you mean http://crayzedsgui.sourceforge.net/ ?

[charlieg]

Indeed I did zuu, sorry about that.

[Hyronymus]

Maybe not a bad resource: http://www.cegui.org.uk/wiki/index.php/Main_Page

Jfs linked to it before but the SourceForge entry is dead.