Pythonic cross-platform GUI desingers à la Interface Builder (Re: what gui designer is everyone using)

[Wolfgang Keller]

> > What "GUI designer" would come the closest to the way that Cocoa's
> > Interface Builder works? I.e. is there any one (cross-platform) that
> > allows to actually "connect" the GUI created directly to the code
> > and make it available "live" in an IDE?
> 
> If you're developing on the Mac, PyObjC allows you to use Interface 
> Builder for developing Python apps.

I know that. And no, I haven't used Interface Builder yet myself, just
because I would need those GUIs also to run elsewhere than on my
private Mac.

> However, there are those of us who are deeply uncomfortable with IB
> and related tools, such as RealBasic and LiveCode/Runtime Revolution.

I haven't used any of these either, just because I don't like those
languages. Their syntax is ugly, static type declarations are imho
perfectly redundant for interpreted languages and besides they don't
offer me an interactive interpreter, which is an absolute must-have for
my day-to-day use of Python - "office automation", ad-hoc "information
logistics" etc. (errr, sorry for those quotation marks again... ;-).

> These tools make code organization very hard by reducing the amount
> of code written to the point of the UI working by "magic," 

Any modern GUI framework has quite a lot of "magic" going on
"behind the curtains" without that the user needs to know or understand
how it works. And this is the way it _should_ be. As long as it is well
documented how to use that "magic".

The current GUI frameworks which are available for Python require way
too much "glue code" that needs to be written by hand, imho simply
because they are primitive wrappers around frameworks for C++
developers who are used to such bulkloads of slave labour. Python as a
language is way ahead of C++, Java, C# etc. in terms of functionality
that you can implement per coding effort required , but it simply lacks
GUI frameworks and corresponding development tools that are equally
efficient.

> and/or by breaking up your code into little snippets that you can
> only view by clicking on the widget in the UI tool.

I remember reading about RAD IDEs/frameworks out there that managed to
integrate/seperate their generated code with/from user-written code
quite well. And which could even use external revision control systems
etc.. Back in the good old days of software diversity, before MS/Java
took over the whole world...

> A related issue is that using a tool such as this makes you heavily 
> dependent on that particular tool, and subject to its developers' 
> priorities, release schedule, and bugs.

This is true with _any_ language, library, framework or software. Heck,
it's even true with hardware! If this was such a show-stopper, we would
still write computer programs like this: 0100011100101010101....
Well, certainly not me, in that case.

> The pace of Xcode development--with Apple making frequent changes to
> project formats in a backwards-incompatible way--is an example of
> this.

Wxwidgets/python has a reputation for frequent incompatible API changes,
too...

And Apple's "product politics", oh, well, errr, uhm, don't get me into
that... *sigh*. If only all those third-party applications for MacOS X
were available on Linux, I would happily forget about Apple's very
existence.

> One reason I prefer to code UI's by hand is because a) in Tkinter
> it's very easy to do, 

Tkinter is imho honestly the very best "argument" if you want to make
potential new users turn their backs away from Python for good. Just
show them one GUI implemented with it and, hey, wait, where are you
running to...

> I think these issues are a reason that the slick "drag-and-drop" UI 
> builders tend to be developed by commercial software shops to support 
> their language and/or IDE, but find little traction among open-source 
> developers and languages.

The point is that loads of potential "developers"(*) simply don't
ever get to use Python due to the very lack of such tools (and
corresponding frameworks).

* Domain experts in fact who would need to implement loads of
software to help them get their work done but can't. And since there's
no budget for external developers, nothing get's ever done about this.

Sincerely,

Wolfgang