GSoC 2012 - Samples Framework

[Ident]

Hi
I would like to work on a new samples framework for CEGUI, here is my proposal:

Motivation
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.


Project
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.

Timeline
April - June:

• Work out detailled plan with mentor(s) how the framework should be structured internally and how the samples should be loaded and be displayed in the viewer
• Look through all samples and make suggestions to the CEGUI team which ones should be changed and what demos could be added
• Work out a plan for the changes in the samples
• Setup a basic project for the framework, so the work can be started without delays in July

July:

• Setup a basic version for the samples viewer, so that the existing C++, python and Lua demos can already be displayed in the viewer
• If Python/Lua demos are not available, create simple ones so they can be used in the samples viewer

End of July - August:

• Rework the samples together with the associated layout, looknfeel and imageset files. Eventually add samples.
• Refurnish the samples viewer and its code, so it reaches a releasable status
  

September:

• Improve the samples viewer and the samples furtherly, according to suggestions of CEGUI team and the community
• Reach a status where the code and the other files are refactored, documented and the changes could be merged into CEGUI's trunk without problems

Why I would be a good choice
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.

Edit1: Timeline updated, edited the project description according to Martin's comment

... I will update the rest soon

[Kulik]

Just one nitpick for now

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.

[Ident]

updated

[Kulik]

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?

Will demos get some metadata? Like description, requirements, keywords, etc...

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.

[Ident]

I ve taken a look at the demos, here is a summary:

First of all we should look for a general demo naming scheme.
Also it would be nice to have meta-info like:
- Content of demo (What does it show, what can you do in it) and
- Purpose of demo (What should the developer learn from it, what features are used and how are they used)

How do you suggest to use keywords - what is the benefit?

Also in some demos i had weird tooltip issues, i dont remember having that before: empty small tooltip window appears when moving mouse, for example in minesweeper demo

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.

Now about each demo in specific:

-Demo8 :

• 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.

-Demo6:

• 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.

-Demo7:

• 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.

-DragndropDemo:

• 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.

-FalagardDemo

• Summary: Displays Multiline text display as well as XML display.
• Suggested Changes: Doesn't allow to copy and paste xml stuff so i could not try anything xml-related yet. I am not sure what the other 2 windows (aside from console window) do, also there is no feedback in the console window. I will have to check the code, but if the other windows are for displaying xml that was sent into the console window, then there should be more info about how to do this and copy-paste feedback must be added (would have to be implemented for each platform - i don't know a bout a multiplatform solution for accessing the clipboard)

-FirstWindow

• Summary: "Amazing demo"
• 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.

-FontDemo

• Summary: Displays usage of different fonts also cyrillic and asian fonts
• Suggested Changes: Crashed for me when i selected "Korean". Otherwise useful demo.

-Inventory demo

• Summary: Similar to drag-and-drop demo, but with items that span over multiple boxes that make up the inventory.
• Suggested Changes: Could be merged with the drag and drop demo because the effects are very similar. Better visuals could be applied to make it look like an actual bank robbery. (or at least a bit more like an actual one)

-Minesweeper demo

• Summary: Perfect as it is.

-ScrollablePaneDemo

• Summary: Has an application-style top bar containing 2 drop down Menus. One features a button for quitting the app, one for making new windows. Also contains a scrollable pane, which lots of other demos contain though
• 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.

-TabControlsDemo

• 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.

-TextDemo

• Summary: Displays text formatting options, single-line editing and multi-line editing.
• Suggested changes: None so far.

-TreeDisplayDemo

• 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.

edit: for the python&lua bindings i also would have to know what already exists in terms of functions - i ll need to check things more before i can propose a interface

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.