The current samples have to be compiled and started seperately which is unconvenient for people who want to have quick look at the capabilities of the CEGUI library. The samples framework of the Ogre engine manages to put all samples together in one framework, where users can preview, select, and start demos from within a single executable. Something like this would be nice to have for CEGUI as well. Additionally a lot of the samples are not up-to-date anymore or do not represent CEGUI as good as it would deserve. These demos could be improved, removed or replaced with better demos.
As one part of the project i suggest to unify the samples/demos into one executable which would show all demos in side-reel, the specific visual implementation can be discussed. For example a couple of screens, each rendering a GUI would be an option. Then a specific screen could be selected, which will focus this demo in full-screen which will then be optimized to run in best render performance. Or a more distant view can be chosen that grants more overview and also shows a small summary next to each screen, telling the users what the specific sample will do. The demos/samples that are desired to be shown in the framework would be compiled as part of the project or be loaded as lua/python script files. The possibility to use Lua and Python projects would be offered by the samples framework.
The next part would be refurnishing the demos. First i would investigate which demos could be improved or replaced or which ones need to be fully removed. Then I will determine which functionalities are not yet covered by the demos, and would make a good addition to the demos. It might also be of interest to create a very simple and small demo, which will show the user a minimum but graphically and skin-customised case, so he/she won't be overwhelmed by the existing full-functionality look'n'feels, and might get a better feeling for what can be done in which of the xml files and to what extent modifications can and should be done.
If there will be time left after all this , i would like to create a visually appealing 3D viewer for the sample browser instead of a simpler 2D view.
Rework the samples together with the associated layout, looknfeel and imageset files. Eventually add samples.
I'm currently studying my master "Visual Computing" at TU Vienna and I am very interested in computer graphics, games and anything related to that. Since I've got acquainted with the CEGUI library, it has been the library of my choice for my leisure and university projects that needed a GUI. While working on my projects using CEGUI, I have also made a few contributions to the library in the past.
I am motivated to create this samples framework, as I think it would make people notice CEGUI's potential better. As for the requirements, I have a lot of experience with C++ and some experience with Lua, but I am interested to learn more about Lua and Python and how they work in relation to CEGUI.
Last edited by Ident on Tue Mar 20, 2012 16:06, edited 1 time in total.
Ident wrote: The demos/samples that are desired to be shown in the framework would be loaded as dll's, so all demos would have to be compiled as dynamic libraries beforehand.
I wouldn't force all samples to be shared objects or DLLs or .dylibs or whatever else. I know OGRE does it but it complicates the build and shipping process and I can't see any tangible advantages of it for us anyways (CEGUI users are unlikely to make their own demos and exchange just the DLLs around).
Also keep in mind that some of the demos might be in Python or Lua, not just C++. We want to be able to make demos with scripting languages because it's way faster than coding them in C++. It also demonstrates that CEGUI officially supports these languages. So I guess some form of DemoBrowser::registerDemo(..) would be preferred. This can easily be used from Python, Lua or other languages so you could just autoload all scripts in a folder and they would register themselves.
There aren't that many demos in CEGUI right now, do you have an idea which ones you would drop and which demos would be added?
I also think renaming demos would also be preferred, CEGUIDemo7 isn't very descriptive.
Are you willing to create a new looknfeel for the demo browser GUI or will you reuse an existing one?
Could you perhaps outline the C++ interface class (make sure it's easy to override it in Python and Lua (returning pointers and references will only work in certain cases, passing function pointers is a pain, ...). This interface would by no means be final, it would just give a us "meat" to discuss.
EDIT: I would also break the timeline up into smaller chunks, having month long entries there leaves too much slack and makes it hard to determine whether you are on time.
First of all we should look for a general demo naming scheme.
How do you suggest to use keywords - what is the benefit?
I would like to add a very basic new skin for the sample browser so it can be distinguished from the rest. I wanna keep the interface in the browser very simple, i only want to use a multi-line text box and a button and cursor, that should suffice. Also it should be possible to navigate just with mouse + mousebuttons. I will have to see what works best.
Summary: Displays the use of Listboxes. Also contains functioning tooltips. The colour sliders have no effect whatsoever on anything except the colour preview - might be nice to have an effect on the text colour with it.
Suggested Changes: I m not sure what this demo should display. If it is only about the listbox then the colour thing and other things should be removed. I would suggest removing everything except the listbox and the tooltip features, then making tooltips appear for the listbox entries (which they currently don't) and rename the demo to ListboxAndTooltipDemo or something like that.
Summary: Uses no layout file instead everything is initially created hardcode. Contains a window to which columns and rows with text can be added.
Suggested Changes: Again I m not sure what the demo should show us. Probably something like that you can dynamically add windows in a rows&columuns fashion and then modify the elements, and all that from inside c++ code. I found the interface to be not very appealing and very unintuitive. I think improvements can be made in this direction. Also a much simpler use case might be better. I think the demo contains too much functionality which is all just related to adding new elements to this window.
Summary: Shows animations of windows and also shows some CEGUI widgets.
Suggested Changes: Could be structured better, the windows overlap each other on start. Maybe put animation into an extra demo. Maybe a demo would be nice where the user can choose a CEGUI widgets (taharez skin) from a list, the list providing all elements of taharez. So the user can preview all the elements. This way all elements can be seen and tested in a simple one-at-a-time fashion. Better than having all on one screen without any overview or description.
Summary: Does what it says, simply shows some slots and some items that can be dragged from one slot to the other and dropped there, remaining in the new slot.
Suggested Changes: Visual improvements could be made, aside from that it is a good demonstration of this functionality.
Summary: Displays Multiline text display as well as XML display.
Suggested Changes: Maybe use as simplest-case layout-file-usage demonstration. Should maybe contain more descriptions for this case, for example inside the c++ code as comments.
Suggested Changes: Crashed for me when i selected "Korean". Otherwise useful demo.
Summary: Similar to drag-and-drop demo, but with items that span over multiple boxes that make up the inventory.
Summary: Perfect as it is.
Suggested Changes: It is nice to see a demo with application-like appearance.But the scrollable pane is not really in focus in this one. The demo should be merged with another demo in my opinion.
Summary: Displays usage of tabs of multiple pages, allows adding new tabs. Page can be selected over tab bar.
Suggested changes: Nice demo. Not much to change here.
Summary: Displays text formatting options, single-line editing and multi-line editing.
Suggested changes: None so far.
Displays text-items in a vertical expandable tree.
Suggested changes: None, it does what it promises.
Overall i would like to reduce too complex demos to simpler ones, merge some demos and remove some redundancies. Also i wanna add additional infos for each demo in the sample browser (content and purpose of each demo) and add some very basic demos to dsiplay certain features in smallest-case-scenarios and add a multi-feature demo showing a game HUD.
I cannot provide an interface yet because i do not know what requirements lua and python have for such an interface. Afaik they only use bindings for singular functions - so i assume by interface u meant a set of functions and not an abstract c++ class that would be bound to from python/lua as a class. I can not yet imagine such a set of functions because i do not have a specific plan for the browser structure in c++. I will provide it the next days.
edit2: i m not sure about the timeplan. University ends in end of june, i might have some tests and submissions in the time. I couldn't find information on when GSOC has to officially end so i do not know which timespan i have to set a plan into. I would prefer June,August,September so begin of june till end of september, a bit of pre-work in june.