Cross-platform version

[scriptkid]

Hi all,

as can be read on the news section, i have joined the CEGUI team. I am honored to be asked for this position!

The main reason for the more official apprauch is that someday a cross-platform version of the layout editor is required.

So at this moment i am both investigating which code can be re-used immediately (the code which has nothing todo with MFC), and what port possibilities are available for the MFC code. Any help and ideas are welcome! I will create a list which distinguishes between re-usable and must-port code soon.

After initial research i think i will:
-switch from the DX9- to the openGL renderer for cross-platform rendering.
-use wxWidget because it seems to have decent support for rendering openGL inside a frame. But i'm not sure yet if this will be the best way to go. Although it will result in the same look&feel as the current MFC application, i am not sure yet whether it requires code changes on different platforms.

I hope that anybody can suggest on especially the second idea i have. Maybe somebody knows of a better (suitable) cross-platform widget library?

Please use this thread for anything related to the editor's port.

Thanks

[CrazyEddie]

Not to derail your thread before it gets going, but what would your thoughts be on a modularised CEGUI editor which could combine the layout editor, a skin editor, font editor, and imageset editor?

This is not an 'official pitch' or anything like that, just something I was mulling over as a possibility

[spannerman]

Congrats on your new position Scriptkid

I have an idea for your editor. Its got to be a cross platform application with a nifty GUI right?
So how about OGRE + CEGUI?

I might not have thought this through properly...is this a stupid idea?

[lindquist]

I tried some time ago to create a simple layout editor using SDL,OpenGL and CEGUI itself.

The main issue I ran into, was that the editor interface and the user-created layout was essentially the same CEGUI system.

Many of the features could be implemented using some nifty event handlers, but the fact that the layout you was creating was "fully working" created some issues.

fx the framewindow's resize / moving feature was not exactly friendly...
I guess that some intelligent input injection could solve some of the issues if the area that is available for the created layout did not inject any mouse/keyboard events.

and then perhaps simple opengl commands could be used to render a "frame" around the widget that's being edited etc.

If two CEGUI systems could exist simultaneously, this would be alot easier, because as I see it, having the gui you're working on actually work is not what you'd want...

Just some thought I made on this some time ago, hope it's useful. Perhaps I missed something... Let me know

[scriptkid]

@crazyeddie
I doubt whether this could easily be pulled of. It would require some tight project management to find a sort of standard for the look&feel and such. And it looks like -when it comes to tools- everyone prefers his/her own language and orther tools. But i keep it in mind, i haven't started coding yet

@spannerman
To start with: Thanks
Another doubt (sorry guys) is that i think that Ogre is too "heavy" for people who are using CEGUI without ogre itself, for example with their own DX engine or something. And i'd like to keep the gui like it is now, like an ordinary windows/mfc application where most people are familiar with. But it will indeed be ported to a cross-platform program

@lindquist
Hi, i understand the problem you ran into. The current editor doesn't pass any input to the edited layout, so it's actually static. Resizing and moving also happens by just making getProperty and setProperty calls.

I'd like to have a "live" version too though, by using a different input handler, which inject all input to cegui. Like Visual Studio's dialog editing with the "test" button. So with just one gui system instance, just switch between input handlers.

Thank for the comment so far!

[_mental_]

I think the direction ScriptKid is taking on this is the correct one (i.e. OpenGL and wxWidgets). I also agree that OGRE is probably overkill for what we are trying to achieve here.

[scriptkid]

Hi,

good to hear that we share these thoughts

This is the first screenshot of a layout loaded inside a wxWidgets application:



It uses a wxGLCanvas with the OpenGLRenderer.

[CrazyEddie]

Looking good

I am also wrestling with wxWidgets at the moment, and using the OGL renderer for the multi-tool that I'm working on (imagesets/fonts/schemes/skins). It took me a couple days to figure out a few wxWidget bits, though things are just about starting to click now

Maybe we'll manage a simultaneous release

[scriptkid]

Thanks

Yeah i've had a good struggle too It seems that each new C++ project takes at least two evenings: the first evening to get everything compiled, and the second one to get everything linked. The biggest deja-vu in a coder's life

But now i'm up and running as well. I have done a little porting, but it won't be until next week before i can spend some more time on it. But wxWidgets works pretty fine, especially when you're used to MFC.

When do you want to release?

[CrazyEddie]

scriptkid wrote:
When do you want to release?

hehe

Not for a while yet. I'm kind of having a half-break from working on anything at the moment (kind of, day on, couple of days off, etc...), though hopefully we should start to see something usable within a few weeks.

[gcarlton]

Seems I've arrived a little late on this, but perhaps we could thrash out what the problems are in having an editor that uses CEGUI itself.

One of the huge advantages is that is its WYSIWYG. No matter what wacky widgets have been created (either as standard, or as game-specific add-ons in a dll), and no matter what falagard theme is used, it all just works. Alignment, animation, rotation, etc, whatever goes into CEGUI will show up in the editor. As another example, in my last project I intercepted CEGUI's loading calls to localise the strings. That sort of thing can be made to work if the editor uses CEGUI dlls itself, but not easily otherwise.

It seems like the basic idea would be to create the widgets under a particular root, and have the editor interface under a separate window root.

It seems the main alternative is wxWidgets, however if you are going to spend time fighting that system it may be better to invest it in a CEGUI powered editor - once its done, its done for good, rather than needing a mirror update cycle for every new CEGUI feature.

The main problems seem to be input injection (seems doable), and of course an extra-render over the top of the selected widget. But thats not too bad either, and as a plus it can get the exact rect from the cegui window. Plus, doesn't CEGUI now have a "save-out-xml" set of functionality that I spied recently. So move the widgets around, then Save() and thats it.

Another plus is that even if CEGUI needs a bit of tweaking to get it to work, every fix is making CEGUI stronger.

[scriptkid]

Hi,

thanks for arriving on this thread

At this moment, the editor (even the non-ported one) is already WYSIWYG. My main issues with going one step further (by making it CEGUI powered) all have to do with stuff which users are used to.

A menubar can be done with linquist's system already, but it would require manual work to get open/save dialogs for example.

Besides, wxWidgets is more then a gui system. Like MFC, it provides a very decent document/view architecture, which saves a lot of work to do yourself.

Please note that the editor only provides laying out widgets. You cannot create widgets in it, that's the type of utility CrazyEddie is working on.

About the exact rectangles: the editor provides common resolution settings, do you can work on exactly 1024x768 for example, ensuring a correct export of such property values

[gcarlton]

Now I'm a little confused. Which secret tool is CE working on, or is it a secret?

[scriptkid]

gcarlton wrote:
Now I'm a little confused. Which secret tool is CE working on, or is it a secret?

Nope, read message #8 in this thread

[scriptkid]

Hi all,

the new editor is coming nearby. As a teaser, here's a new shot, which shows that everything (now including the toolbar!) has been ported:



If the code proves to compile well on Linux and Mac, there's hope for a near-future release