CEGUI integration project

[Markohs]

oh, good news, CEGUI has been chosen this year for Google Summer of Code, so looks like we did a good decision using it.

http://www.cegui.org.uk/phpBB2/viewtopic.php?f=10&t=6032

Btw, a question for the forum administrators. Where do you think I should keep this topic in the board? It's nto a Bug report, I think hehe.

I'd like to keep posting when I make some advances I can show, but I'd also like coders to be able to review it if the fancy and have the time. The topic is ok in this forum?

[Fabio]

Btw, a question for the forum administrators. Where do you think I should keep this topic in the board? It's nto a Bug report, I think hehe.

It is in Larger projects, now

I'm moving there also 3D. The purpose of that board is to host threads for complex projects, spanning for several months. There there'll be few of them, so they are harder to lose, compared to the other development boards.

[Markohs]

It is in Larger projects, now

I'm moving there also 3D. The purpose of that board is to host threads for complex projects, spanning for several months. There there'll be few of them, so they are harder to lose, compared to the other development boards.

Thanks!

[Markohs]

I've been stuck a bit on this because I was unsure on how to retouch simwin.cc the less possible to be able to manipulate the new "gui_frame_templated" windows, that will replace "gui_frame_t" gradually.

At the end, I've decided replicating the code when necessary to make the routines to interact with both types of windows, it's all a bit dirty now but for the time it will sufice until I find a new and cleaner way of handling this.

Well, here you can see the new Loading Screen and banner, not very artistic, but well, progressing again.

http://youtu.be/AMReL9lstv8

Had to add templated versions of win_is_open,destroy_win,destroy_framed_win, create_win, and add code to destroy_all_win, process_kill_list. The good thing is that new templated frames have the event handling and drawing refresh routines built in automatically, so I won't need to mess the rest of the routines I think (and hope).

[Vonjo]

Nice. It gives Simutrans a much more modern look.

[Fabio]

Nice! There is no comparison between the new dialog (although it needs tweaking, of course!) and the standard ones.

[Markohs]

Yep, needs some work with aesthetic taste. I can scale, move, blend, animate the logo and everything and can't figure how to do it making it look good!

I'll finish the dialogs first, and give them a second look when they are functional.

[Markohs]

btw, happy birthday, Fabio. Facebook told me!

[Markohs]

A more modern look, just copied a MIT licensed one (it's more for RPG games) to see how it can look here, looks pretty cool, specially the transparent progressbar!

http://youtu.be/8908IJ-2D3k

[Fabio]

Thank you Markohs

By the way, this latter look is very, very cool! Simutrans indeed deserves better than current UI.

[Zeno]

This semi-transparent style doesn't like me as much as the other. Our gui needs a bit of love, but that last one looks confusing to me... maybe it's the colour, which is dark (rpg style, as you said). We might look for an average between both though...

[isidoro]

Choosing among an external library or a self-made one has both advantages and disadvantages.  When ST was created, the situation was also different.  We must be kind to the present GUI...

If you make your own GUI, the program is not bloated with unneeded functionality you don't use, you get rid of an additional external dependency that may make your program unusable if the external library is upgraded, you get exact control on what is done and how it looks like, and you are sure that the program will work for a larger variety of systems, now and in the future.

The main disadvantage of your own GUI is that, of course, you reinvent the wheel, and not a very good one if you compare it with more mature libraries.

[sdog]

semi transparent! splendid. It works also with light windows, when the opacity is a bit reduced.

[Zeno]

We must be kind to the present GUI...

I try to be kind, actually it works... but it's old fashioned, that's all

Anyway I agree there are pros/cons by both using own and external library for the gui, and I agree with the ones you exposed. I'm not involved in order to give an opinion in favor or not though.

[Markohs]

@Isidoro: what you say is true. Even I try to abstract the simutrans GUI code from CEGUI in itself, of course they are inherently coupled together, mainly because each gui sheet it's written in a XML form that's only interpretable with CEGUI.

What I did was creating a class where the forms inherit from, it needs a string parameter in the constructor. That's the name of the .XML file that will be loaded and shown on screen. Later, the sub-class defines some "actions", and hooks them to "labels". The actions are basically a enumeration of possible general actions (LOAD_PAK, QUIT_GAME, .... ) and a optional parameter. They are stored as a void * so you can store anything there. The "labels"are just identifiers taht will be searched on the templated loaded frame, and it will hook the action there, if the item is found.

When CEGUI receives a event, my code checks whether the triggered element has a action hooked, and fires it. CEGUI does some actions by itself anyway, like hover, mouse, taking care of the scrollbars...

It's a bit more generic that using CEGUI straight, and can maybe be implemented with other external GUI libraries. But yes, this is a dependency.

Implementing the same actual working where the GUI forms are created programatically could have been done, but it lacked flexibility.

But look, for example, there is quite a lot of code about filesystem access already coupled to the GUI classes, for example in gui/loadsave_frame.h and gui/savegame_frame.cc . This is imho a sign that a ad-hoc GUI like the one we have, has some deficiencies, also.

But I plan to add this in a way that the old code can coexist with the new ones, that's the best way. I want to see both versions working, and we'll see where does the project ends going to.

[Markohs]

About the style Fabio,Zeno and sdoc comment, I agree this theme is not suited for a game like simutrans, it was just to show the ponential of this new UI, with the advantage that we can just create a defaul skin that resembles the current one closely, just with some transparencies where we think it's good to use it (I like it on the progress bar, for example, but we can also use it for for example more sophisticated graphics on the loading screen, or on the window frames, or on inactive toolbars/windows, even on the ticker).

The goood thing about this system is that we open the door for some artists creating alternate skins or give the pak creators the chance to refine the GUI even further, like for example on the pak.britain they could use some patterns, shapes and effects typical from there, the pak.scfi could use a more futuristic GUI and the comic another one. Not just replacing bitmaps, this even allows for font changes.

I know this window dragging effect is horrible, but ilustrattes possibilities we can explore:

http://www.youtube.com/watch?v=5mf7H_IDMS8

[isidoro]

@Zeno: my comments didn't refer to yours explicitly.  It was general and not to give a biased view on this, but a more balanced one.

Markohs' efforts will give more configuration and, most probably, a better look to the program, but it doesn't come at no price.

[Zeno]

@Zeno: my comments didn't refer to yours explicitly.

I wasn't offended either, no problem Just wanted to note that we are respectful with what we have, but we talk about how improving it anyway.

[Fabio]

Please note that ongoing GUI rewriting renders this project obsolete. 

Moved to denied board.