[Bf-committers] TableGUI - BUI -- update 20140109

[Arnaud Loonstra]

On 01/10/2014 12:38 AM, Felipe Ferreira da Silva wrote:
> @Hewi,
>
> Haha, yeah, the repository is getting bigger, and will grow faster from now
> on, because the core is very mature.
> Hey, about that grease pencil toolbar/menu, I plan to create floating
> widgets (a widget that is not child of any other child) later, something
> that may look like this:
> http://dribbble.com/shots/182088-TwitSpark-Betadesign-3?list=searches&tag=popup
> ... I think it fits perfectly for that toolbar & menu concept.
>
> "
> run_BUI(argc, argv); /* which will give you the basic screen layout */
> plugin_Python(argc, argv); /* embed python for the interface functions to
> draw all of the menus and buttons and ...*/
> "
>
> 1. I will make a worthy demo project using TableGUI later, better than the
> "main.c" file that I have in the repository.
> 2. I'm making a simple system to make possible integrate the TableGUI stuff
> (functions, objects, widgets, etc.) with a script language, such Python and
> Lua. The idea is to make possible to modify the layout (add widgets, remove
> or change) using script language too, and since the widgets are drawn using
> OpenGL, I believe that it is possible to use Python/Lua to draw on widgets
> too (using something like PyOpenGL or LuaGL).
>
> Days ago I was just wondering about how the community developers feel about
> this project...
>
> Regards,
> Felipe

Hey Felipe & Hewi,

My thoughts are currently mostly about the application loop. It's quite 
common in GL apps to have a draw loop based on. However I would just 
leave that optional. If an app does nothing it shouldn't be doing any 
thing. Often in GL the app keeps redrawing. It's very easy to let it 
redraw every now and then. It's very hard not to do so if it wasn't 
thought of before.

Then you would start thinking of how the application loop could be 
handled. Some options are the following:
* Do it as fast as possible
* Event based
** FD polling
** Time based
** Signal handling

I guess these are the most common but I would make sure the UI would be 
able to handle these methods.

Then if this UI system would have the goal of being implemented in 
Blender in the future I think it's very important now to stay as close 
to Blender as possible. Just to maintain compatibility and an easy 
adoption path.

I think it would be important if other developers share their thoughts 
if there would be any chance of implementing this UI in Blender in any 
future. But I guess there are other priorities.

Rg,

Arnaud

-- 
w: http://www.sphaero.org
t: http://twitter.com/sphaero
g: http://github.com/sphaero
i: freenode: sphaero_z25