Custom skins with official CEGUI Layout editor

[core]

Guys, i don't really understand how to use Falagard skins with editor, for example, build-in Vanilla skin. Any tutorial or maybe you already discuss it before (i searched but find nothing)?

Thanks.

[martignasse]

hi core,

For what i now, there is no way for now to directly use other skin than windowlook or taharez in the editor (kind of hard coded).

But it's pretty easy to change the skin used in the layout widgets in the xml file (after it was saved from the CELayoutEditor).


<Window Type="WindowsLook/Button" Name="Demo7/Window1/Quit">
can be changed to :
<Window Type="Vanilla/Button" Name="Demo7/Window1/Quit">


hope it help

[scriptkid]

Hi Core,

ATM Dalfy is working on a patch for the editor, which will allow you to load/use different schemes than the current hardcoded ones (windows and taharez).

But until then Martignasse's solution should do the trick. So hold on for a bit

[core]

Well, i tried Martignasse trick, worked, but anyway i can't work with it cause interface distort because of different controls boundary widths.

And some time later i find out that i can't edit any custom properties for even build in controls (for example max property for a slider). And can't insert a picture.. It makes this tool just useless, sorry.

Probably, GUI editor is the most important part of any GUI. Cause it doesn't matter what your XML can, it important what i see in result (WYSIWYG) and how flexible and easy i can reach it.

Right now, line:
.scheme -> .lookandfeel + .imageset -> .layout
it's too complex, guys. Dropping an image on a screen - it's really not a trivial operation, especially because u don't have automatically ImageSet generation software.

Grouping style code into .lookandfeel file is of course good, but only with assumption that all interface, all buttons will look like each other. In other situations, in startup, experiment stages, or in visually rich interfaces - i must do double work - create new "look and feel" and after that - create widget with it attached.

In best situation, user never should know what UI file formats u use, XML, binary - whatsoever, just WYSIWYG.

With respect.

[Clay]

CEGUI and the CEGUI editor are just babies right now. It takes a few years to reach some semblance of stability, and with CEGUI changing so rapidly it's very difficult for developers of tools to keep up with the library.

The layout editor is very good for where it is in development. I've found workarounds which make it very usable in my case, and it's still the best thing we have right now. (And there's really no competition for CEGUI. It's the best of its kind when it comes to embedded-3D GUI systems).

I wouldn't complain too much, you don't want to discourage the developers. =)

[core]

Yes, i agree with you, this library is currently best free (in bounds of LGPL of cource) GUI library, but, unfortunately, guys just moves into wrong direction, or, better to say, looks on a problem from a wrong side. Library is a child, but already very old and heavy child, time to change something.

I just offer to stop complexiting library more and think about the most usual operations, when GUI designer (not programmer!) want to create a GUI. For example - inserting picture on a screen - it probably (IMHO of course) takes a 95% of all operations with gui. 3% is a buttons and very very rarely all other controls. Also user first wants to put a button, than attach some pictures to it and, maybe maybe later, he will want to make a button template from it, but not vise versa.

I suggest that, now better start to create practically new GUI Editor, which hides operations with all xml files and imageset generation (thus user never see anymore this xml files), which also includes controls testing mode.

I think, this really increase popularity of this library. And it seems that guys don't have a work here Cause forum seems like a little bit dead.

Im also already implemented 2 commercial GUI libraries, and have some experience in it. I mean, that create such editor takes month at max for one/two people. And result will be enormous.

Thanks.

[Dalfy]

Hello, core maybe you can be one of the one/or two people needed ? You are experienced on the topic.


There's people working on the various parts of the XML description to create "visual" editors for almost any kind of xml resource file in CEGUI. The current editor focus on one aspect the layouts. Let's other project focus on other aspects and became efficient and mature. Then we will be able to create a do all stuff solution. For most system even commercial, being able to do thing from XML give the user a lot of fredom. Some works have to be done by the user at the end why not XML ?

[core]

Well, im already have my full time job + evening time job.

I think that creating pack of different editors for different .XML files it helps, but there is also more straight way..

What about XML - out second GUI also was based on XML, but don't catch illusion that XML decide all problems for you. During the long way of working with XML, interface files grows beyond 1000 lines of text. It's impossible to edit those files by hand.
We use it only because XML have tree structure, have unicode support, easy to test on development stage and XSD/XLST technologies.

Maybe shortly explain what we do:

Editor have one input XML (scheme, but not XSD) and one input/output XML (like your .layout).
XML scheme described tag structure for editor, what controls (widgets) can appear with full list of properties and subelements. We choose our custom format (not XSD) because of a 2 reasons: XSD too complex, and in XSD there is no way to create our own types that editor (thru the standart XSD parsers) can differentiate this types by type name (for example differentiate 'path' and 'string' types), and there is no way to add comments to every tag (for use in editor like tips). This XML scheme can have XSD (we just don't finished it yet) for checking and easily creating XML file in "XML Spy" like software.
Input/output XML just keeps a pack of screens, created from this controls. All pictures was in separate folders, 'path property' just keeps relative path on this pictures. Then, in resource compiling, we just pack pictures in number of imagesets, transorm XML into binary (for quick parsing and memory using) correcting picture paths on internal links in parallel, then all packs into one big resource file and that's all.
Input/output XML can also have separate XSD, automatically generated from XML schema, but we also don't started it cause there is no urgent need appeared in it - editor made syntax checking and gathering max possible information in load time anyway.
We don't make a button templates or something, cause copy/paste function in editor makes this easier and in program you anyway apply all template properties of an object + custom object properties, thus it don't makes any difference.
Im gladly could help you to do this, but i can't. Im already too busy and just searching a way to work in current situation more easily. Or maybe something changed in good side with time.
With respect..

[centipede]

You're getting off track. XML is not anything more fanciful in this context than a humble file format. A native one could shave half the text-matter out, but still it should and should and should be handled by a simple program.

Repeating myself: 95% of all GUI graphics doesn't require the bells and whistles of Falagard. A utility for this job could be done in a week if one keeps in mind that it should be a bit foresighted.

SPEAK UP CODERS OR BY GOD I WILL MAKE THIS SUCKER MYSELF.

But really, it should be done in C++/SDL/CEGui which is out of my league. (Perhaps LUA could be a choice, but I'm not really a fan)

[Tocs1001]

95% of all GUI graphics doesn't require the bells and whistles of Falagard

But the bells and whistles are what make CEGUI a game gui and not a regular gui, if i didnt want all these bells and whistles and customablity i would use Win32 GUI