Why a post about UI, GUI makers, etc. without a single screenshot in the github's README.md??
Please give us a mean to understand in 10 seconds what it's about, by adding a screenshot or an animated screenshot (http://www.cockos.com/licecap is cool for this) :)
+1 to why no visuals? Having a GUI maker without a single still or animated screen shot is perplexing. Can you add a couple screen shots to the GitHub repo?
dragonwriter said it here but the actual reasoning went something like this:
1. I need to add some documentation and explanation.
2. I might as well document the different parts using screenshots since the elements are visual.
3. I might as well make videos (or gifs) to show what the actions do.
4. I might as well make the video interactive to drive home the points that the user can customize the interface to look like whatever they like. (This incidentally also perpetuate the joke about this program being meta.)
If this were Javascript, I think the guided tour wouldn't be an issue (but I understand that it isn't and the further step with virtualenv makes it even less approachable).
There's also the issue of time. That I'd probably only make one of these, at least at first. I chose 4. Maybe it was not the best choice.
I'm still trying to think of a good way to also add 2 or 3 but my gut feeling says that people are less likely to try the interactive version if I add that. I suppose this is the sort of thing that needs testing to find out.
Also, most visual tools have a clearly define "this is the toolbox" and "this is the stuff the tools apply to" so some though is needed to be able to show that there isn't even such a division. For example the default first screen is probably really confusing to look at on its own (so the natural next thing to ask for it an explanation of what the viewer is supposed to be looking at!).
tkui is one of my joke side projects but it does run and serve a purpose. I was trying to make some quick GUIs in Python for my own use but always restarting the program when small details in the layout changes makes for a slow workflow (closing and reopening the program).
So I wanted to use a GUI editor. I don't remember exactly but I think I didn't find anything that suited (I know I at least looked online for a while). So I decided to make my own, which became tkui.
Now the editor is itself a GUI so it'd be awfully helpful to have a GUI editor to make it. Because time travel isn't an option, I started from scratch and tried to add useful elements for create tkui itself. Of course, those elements are also the elements of tkui. So now tkui is a tkui maker.
If anyone have suggestions for "build orders" for recreating similar programs from scratch, I'd be interested to know.
I tried to make it so I need to restart tkui/the current project as little as possible. I also tried to the keep the project small, although with both dependencies, its getting larger.
I use wxFormBuilder and export the GUI using XRC (instead of Python). I know it's not exactly 'dynamic', but it's pretty close.
First I build my whole GUI project with all the widgets in wxFormBuilder, and export the project as XRC (xml representation of the GUI widgets and hierarchy).
Then My wxAPP (Pyhton or C++) loads the XRC and builds every widget contained contained within my project. This is done by a simple call to 'xrc.XmlResource('mygui.xrc')'
This makes it super easy to maintain and test my GUI changes, without having to sift through a bunch of 'AddSizer...' GUI specific code. Building a GUI in code and maintaining it adds quite a cost and becomes quite tedious quickly.
wxFormBuilder does tend to crash once in a while, but otherwise allows for a fairly smooth GUI building experience, while decoupling your App code from your GUI 'scaffolding' concerns.
Indeed! Although I only recently learned of Squeak Smalltalk and variants like Pharo and Cuis (quite a bit after tkui was close to its current state). What GUI maker(s) do you recommend for Smalltalk?
Let me elaborate on your comment for other readers though. Smalltalk is a programming language in which an entire (graphical and audio) environment called Squeak was built. Smalltalk's dynamic nature and the nature of its global namespace (for classes and their methods) means that class and methods can be modified from within the environment at any time (and any future calls will use the new method). This is the part that make it similar to tkui (or perhaps rather tkui similar to Squeak).
Thanks! From the first example, it looks more like a UI toolkit than a (visual) editor though. At least it seem the layout can only be created using code.
I remember Squeak having a tree (I forget the name) but don't remember if it was easy to edit with it directly.
>I really do hope one day to return to the ease of smalltalk without the oddity of the software images it presents.
I've sort of noticed the opposite sentiment -- the things that software images can do (sharable consistent environment, dependencies and tools corralled into one place instead of polluting the host) are considered to be upsides of using docker containers for development; but people seem to prefer using languages and tools they already know inside docker, instead of learning Smalltalk.
(In case I am being too obscure: Run idle in "no subprocess" mode and then any TKinter widgets your script creates partake of the IDLE editor's Tk mainloop. You get instant dynamic GUI. Awesome for RAD.)
Just a medium quality animated gif that loads fast and gives people some idea of what it can do helps a lot. Most visitors spend only a few seconds, and don't want to click or go through the docs just to understand if they could use it. I had to read the comments here to understand, and it looks like a nice project, so it deserves this :)
Please give us a mean to understand in 10 seconds what it's about, by adding a screenshot or an animated screenshot (http://www.cockos.com/licecap is cool for this) :)