Re: Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)
On Mon, Jun 11, 2012 at 5:37 AM, Dietmar Schwertberger
> Chris Angelico wrote (in two posts):
>> There was a time when that was a highly advertisable feature - "build
>> XYZ applications without writing a single line of code!". I've seen it
>> in database front-end builders as well as GUI tools, same thing. But
>> those sorts of tools tend not to be what experts want to use. You end
>> up having to un-learn the "easy way" before you learn the "hard way"
>> that lets you do everything.
> This time is not over.
> Especially when you look at data acquisition and control applications
> where tools like Labview are widely used.
> Personally, I would not want to use such tools as I find it quite
> complicated to implement any logic with a graphical editor.
> But when you want to sell an alternative to such tools, then you
> should not offer a tool which makes it almost impossible for a
> typical engineer to create a simple GUI.
> [chomp lots of other examples - go read 'em in the original post :) ]
Either these people know how to write code, or they don't. If they do,
then building a simple GUI shouldn't be beyond them; if they don't
know that much code, then anything more than trivial _will_ be beyond
them. Here's the window building code from something I just knocked
together, with all comments stripped out:
foreach (labels,string lbl)
If you're a complete non-programmer, then of course that's an opaque
block of text. But to a programmer, it ought to be fairly readable -
it says what it does. I'm confident that anyone who's built a GUI
should be able to figure out what that's going to create, even if
you've never used GTK before. (And yes, it's not Python. Sorry. I
don't have a Python example handy.)
Modern UI toolkits are generally not that difficult to use. Add just a
few convenience functions (you'll see a call to a "button" function in
the above code - it creates a GTK2.Button, sets it up, and returns
it), and make a nice, well-commented configuration file that just
happens to be executed as Python, and you've made it pretty possible
for a non-programmer to knock together a GUI. They'll have learned to
write code without, perhaps, even realizing it.
Re: Pythonic cross-platform GUI desingers à la
> object mainwindow=GTK2.Window(GTK2.WindowToplevel);
> (400,300)->signal_connect("destroy",window_destroy); GTK2.HbuttonBox
> btns=GTK2.HbuttonBox()->set_layout(GTK2.BUTTONBOX_SPREAD); foreach
> (labels,string lbl) btns->add(buttons[lbl]=button(lbl,mode_change));
> If you're a complete non-programmer, then of course that's an opaque
> block of text.
Thanks for that hideously appalling example of a ridiculously low-level
If you're an occasional Python scripting dilettant, this looks like a
heap of syntax garbage of exactly that kind that has made me avoid all
C-derived languages at university (I'm a mechanical engineer) and that
makes me avoid GUI programming with Python so far.
If a domain specialist needs an application with a GUI, (s)he
typically only wants to have to tell the framework three things:
1. What the domain model looks like (classes, attributes) and what it
does in terms of behaviour (domain logic, methods). In my use-cases this
would be typically done with SQLalchemy.
2. What the GUI shows of the domain model and how it does it - define
menus with entries, layout forms/dialog boxes with fields etc. This
should be done without having to permanently look up all the specific
details of the API of the GUI framework.
3. What attribute/method of the domain model a GUI element is
"connected to" (sorry for the quotes again). This should be possible in
an interactive way, so that you can test whether GUI and code work
together as required while defining the connections.
Anything else should be done by the framework without the necessity to
write a single line of code for the "straight forward" use cases:
- creating, retrieving, updating, deleting instances of domain model
- setting values of attributes instances of domain model classes
- calling methods of instances of domain model classes
|All times are GMT. The time now is 04:30 PM.|
Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.