JUI is now being modified so that threads will become members of elements. then you can enable/disable them at will for any object in the system. When a thread is disabled, the parent element is responsible for pumping the messages.
As fun as it is to play with this interconnected, multi-threaded madness, a real world usage scenario does not call for such mass multi-threading, at least not in a GUI. When desktops have more then 32 cores, then I'd recommend it as viable to overcome performance limitations but until then, only the window manager and windows will run inside threads, widgets message queues will be pumped from windows.
However it's not been a waste of time, not in the slightest. You can thread enable any element or derrived messenger object with a single property change, at run time. letting you choose when and if it's a good idea to use a thread. Nothing will change for the end user at all, other that any code run in a callback function (say from a button) will either block the parent, or not. Also creating a robust, stable system capable of handling such a complex hierarchy of threads and optimizing that system to work as fast as possible means that with widget threads turned off, the system won't break a sweat
Thanks to advice given to me by Carver413, I'm going to be implementing a scripting engine (not sure what I'll use yet) into JUI. At first it will be used to layout windows, widgets, set properties fonts etc but the eventual idea is to provide an interface to JUI within the scripting engine, so whole apps could be written in scripts.
All assignable callbacks and properties will be exposed to both the scripting language and compiled code meaning that, for example, you could set up a window and all the widgets in a script, then allocate callbacks in code. or the other way around, or exclusive to each option.
I think this along with control over the threads will increase the potential set of coders that will find JUI useful.
And that's me done
EDIT : there's no reason you won't be able to disable all threads entirely in this manner. I'll also wrap this up with some {$ifdefs} in the lock unlock routines, so when disabled in this fashion, you can get rid of locking unlocking overheads. All you have to do then is make sure you call the pump messages of the window manager every few frames
FURTHER EDIT : For scripting I shall probably use REM objects pascal-script so people don't have to learn the scripting language. It says it's free but I don't know if that's the same for commercial use, some of you may want a commercial friendly license in JUI, so if anyone has any info about this please let me know.
Reply With Quote
Bookmarks