JUI - Another GUI

[phibermon]

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.

[jdarling]

This looks really cool and interesting. How long till we can find a link on where to download/play with it?

- Jeremy

[phibermon]

Well that's the thing, I've never released anything before publicly except for code snippets and my opinions (oh and a telnet chat server called PHiNET which after all these years, still floats on software sites) What I'm trying to find out is if it's worth sharing the code in some form of version repository (CVS,GIT etc) to try and encourage submissions. But then if the interest is not there, it may be more appropriate to just create a site and offer the files.

I need to think carefully about how I release it and at what stage of development I release it. I mean it and many other things I have are perfectly usable right now, unfortunately I'm a perfectionist (at least to the bounds of my skill) who has classicly subscribed to "it's only finished when there's nothing else to add"; That now has to change.

I am going to push myself to release at least JUI after I've completed the work mentioned in the above posts. (I will probably leave scripting for a later release however. I've not seen a usage scenerio in anyones game projects that could justify scripting support past "because it's fun")

I want to get it out ASAP because there's an article I badly want to write for PGD

[virtual]

any chance to see the exe ?

[chronozphere]

Ok.. about versioning systems:

I think a lot of people from PGD don't use them so you could just release the files. However, there are some who use SVN so that might be an option too. I prefer GIT, so publishing the project on github would be nice (also gives the other users a normal compressed download).

[phibermon]

Thanks for the advice I believe github may be a good choice

Virtual : good idea! I think people would be more interested if they had somthing tangible that they could at least have a quick play with.

Anyone know any good free webhosts so I can throw together a bit of a page and provide some data? I think I shall release stable stuff on the site and sync with github after each coding session.

I'm also hoping that the coding style appeals to someone who'd like to contribute. I think I'd love to see more community projects like GLScene, even if it isn't my own