Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > anygui,anydb, any opinions?

Reply
Thread Tools

anygui,anydb, any opinions?

 
 
Rocco Moretti
Guest
Posts: n/a
 
      06-01-2005
Skip Montanaro wrote:
> Thomas> The Python world lacks the phenomenally successful development
> Thomas> models enjoyed by the now ancient Turbo Pascal, Delphi and
> Thomas> <gasp> Visual Basic.
> Thomas> AND
> Thomas> If the likes of Visual Basic can have it, then it becomes
> Thomas> really, *really* hard to convince the world that Python is a
> Thomas> serious, professional system.
>
> Remember, in the open source community we all pretty much just scratch our
> itches.


It's worth mentioning that although we all scratch our own itches, not
everyone can make their own benzocaine lotion. I.e. we all have wants
and desires, but for most people the time/expertise available to them is
insufficient to satisfy those needs. So answering "You know what would
be great ..." with "Scratch your own itch!" is presumptuous, bordering
on rude.

That said, you're right:

> Given that for the most part nobody in the Python community has a
> handle on any other Python person's paycheck, it's unlikely that enough of
> the community ...


Given that we're all volunteers here (or at least volunteers w/r/t
random usenet posters) anyone *demanding* something out of the Python
community is vastly overstepping their position. But that doesn't mean
they can't wish for it politely.

Random usenet posters willing to throw money at the problem, though,
are another thing all together ...
 
Reply With Quote
 
 
 
 
Skip Montanaro
Guest
Posts: n/a
 
      06-02-2005

>> Apparently, most Python people feel productive enough without such a
>> tool.


Thomas> As did many with Fortran. Or Cobol. Are we now so productive
Thomas> that there is no longer an unmet need for new/better software?
Thomas> Do we stop here? Is Python a comfortable place for the Luddites
Thomas> hang out.

There's a difference. When I began programming, the only tools I had were
the IBM card punch machine (basically a typewriter to enter my program) and
the printout I got from the operator via my drop box (to show me compilation
or run-time errors or my program's output on those rare instances when the
PL/1 compiler didn't barf on my deck). In that situation, switching to a
better set of tools (an ed(1)-like editor displayed on a CRT hooked up to
our school's CDC timesharing system) was a no-brainer. It wasn't all that
big a jump to switch to PR1ME computer's full-screen editor (probably
something like vi, though it's been so long I can't remember anymore).
After leaving school and moving on to VAX/VMS I looked around for another
full-screen editor, farted around with EDT for a bit, but eventually
stumbled upon Gosling's Emacs (on a DECUS tape I think), then GNU Emacs
awhile later, then in the past three or four years settled on XEmacs. (I no
longer remember how I edited BASIC code on the IMSAI 8080.)

About 25 years have elapsed since my first exposure to Gosmacs. As you
might imagine, I now have a fair amount of cortical area devoted to
Emacs-fu. Based on my inability to help my son with his geometry homework
this year I suspect most of the neurons that had previously been devoted to
Euclidean geometry have been taken over by Emacs. Here's a quick summary of
(some of) the functionality available to me from within Emacs that relates
more-or-less directly to programming Python:

* I do all my basic text editing and software development in Emacs, both
local and remote files, but I also read mail there, including this mailing
list. If I had more of a Usenet mindset I could read it in Emacs as well.

* Python mode (thanks Tim & Barry) gives me access to inline help for
attributes of many builtin objects, it does a good job of colorizing my
code, supporting block moves and block comments and alerts me to runaway
strings.

* With pycomplete hooked up to Pymacs, it can do a pretty decent job
completing partial expressions.

* Using Emacs' builtin compilation facility I run pychecker over my code and
step through the messages it emits. (I suppose with a little thought I
could modify the compilation facility to define pychecker suppressions
on-the-fly as I pick through pychecker's output.)

* Emacs' tags facility lets me effortlessly jump to class and function
definitions in my code.

* I can get Python tracebacks when sitting at a gdb prompt using a little
snippet of gdb's command language. If I wanted to I could use pdb to set
breakpoints and execute my code under control of the pdb debugger but I
generally just insert print statements.

* I've also messed around a little with Bicycle Repair Man, a refactoring
editor written in Python that integrates into Emacs via Pymacs.

* I can also edit C and C++ code in the same editing/compilation/debugging
environment when the need arises.

* I can transparently use CVS or SCCS (and I suspect Clearcase and
Subversion) from within Emacs, without being aware of the different
packages' syntaxes.

* If I need to work from home I can ssh into my desktop computer at work and
using gnuclient, connect up to a running Emacs session that's got all the
state I built up while at work.

The learning curve for me to switch to something other than Emacs for
software development at this point just isn't worth it. I'm sure the same
would be true of long-term vi users or people accustomed to other
full-featured editors. (Both Emacs and vi have the advantage that they are
available on all major computing platforms.)

Maybe I'm arguing for a tight integration between an IDE and an external
editor and just don't realize it. I suppose it can be done, but I suspect
it would be a major challenge. If not, it would have been done well already
by other tools. Instead, my limited experience in this area suggests that
most development environments just punt and use whatever feeble editing
widget is available in the author's chosen widget set. They all seem feeble
and slow to me, mostly because they aren't optimized for editing fixed width
text.

OTOH, maybe I'm arguing for a better integration of other tools/packages
with Emacs and more complete documentation of what's already available.
Should anyone be interested in helping out, a good place to tackle that
would be in the python-mode project on SF
<http://sourceforge.net/projects/python-mode/>. I do know from past
experience with other tools that "providing basic Emacs keybindings" just
doesn't cut it. Where are the rectangle and register commands? What about
macros? (How would I live without macros?) At this point it's not just
basic typing skills I would have to transfer to another tool to be able to
switch and be as productive as I am with Emacs today. Sure, you can laugh
at the kitchen sink that Emacs has become over the years, but it supports a
lot of functionality. Think of it as an IDE framework & tool chest if you
like. I'm sure I've only scratched the surface.

In short, just because I still program in Emacs, don't assume I write my
code on stone with hammer and chisel.

Skip
 
Reply With Quote
 
 
 
 
Skip Montanaro
Guest
Posts: n/a
 
      06-02-2005

>> Are we talking about a drag-and-drop GUI builder?

Thomas> I am!

>> What about Glade?

Thomas> Dying to try that. Ask me again in a week.

I use Glade at work on a regular basis. Took me a few days to get
proficient, and it has some warts, but it sure beats the heck out of
manually creating all those widgets in my Python code.

Skip
 
Reply With Quote
 
Thomas Bartkus
Guest
Posts: n/a
 
      06-02-2005
"Skip Montanaro" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> >> Are we talking about a drag-and-drop GUI builder?

> Thomas> I am!
>
> >> What about Glade?

> Thomas> Dying to try that. Ask me again in a week.
>
> I use Glade at work on a regular basis. Took me a few days to get
> proficient, and it has some warts, but it sure beats the heck out of
> manually creating all those widgets in my Python code.
>
> Skip


Yes. Anything that automates/assists the creation of the user interface is
a phenomenal time saver. The task of getting data from and delivering it to
a human operator is still the most difficult and time consuming part of
creating software. It is so onerous that it tempts one to abandon writing
software for organic beings altogether.

My reference to Visual Basic was meant to be a poke in the eye. The
language itself stinks. BUT - having a robust IDE with keyword tooltip
prompts, built in language documentation, robust built in debugging, and
most of all - a stable GUI , a standard suite of widgets for interacting
with those pesky, error prone humans, the ability to draw these on a form
with a mouse and have all that running in minutes! It no longer matters that
the language itself smells like 4 day old fish! No amount of linguistic or
structural elegance can have as much impact on productivity as the IDE/GUI.

It drives me crazy when someone suggests that it might amount to no more
than a bit of fluff hardly worth bothering with because when it comes to
programming -

An excellent IDE/GUI just trumps everything.
Thomas Bartkus




 
Reply With Quote
 
Skip Montanaro
Guest
Posts: n/a
 
      06-02-2005

Thomas> My reference to Visual Basic was meant to be a poke in the eye.
Thomas> The language itself stinks. BUT - having a robust IDE with
Thomas> keyword tooltip prompts, built in language documentation, robust
Thomas> built in debugging, and most of all - a stable GUI , a standard
Thomas> suite of widgets for interacting with those pesky, error prone
Thomas> humans, the ability to draw these on a form with a mouse and
Thomas> have all that running in minutes! It no longer matters that the
Thomas> language itself smells like 4 day old fish! No amount of
Thomas> linguistic or structural elegance can have as much impact on
Thomas> productivity as the IDE/GUI.

Thomas> It drives me crazy when someone suggests that it might amount to
Thomas> no more than a bit of fluff hardly worth bothering with because
Thomas> when it comes to programming -

Thomas> An excellent IDE/GUI just trumps everything.

Glade is fine for building Gtk user interfaces. I have no idea if there are
similar tools for other widget sets, though I wouldn't be surprised if such
tools existed. Once the GUI is fairly stable, most of the development after
that occurs in the underlying functional part of the code (at least in my
recent experience). For that, no amount of Glade slinging will help.

Skip

 
Reply With Quote
 
Magnus Lycka
Guest
Posts: n/a
 
      06-03-2005
Skip Montanaro wrote:
> Glade is fine for building Gtk user interfaces. I have no idea if there are
> similar tools for other widget sets, though I wouldn't be surprised if such
> tools existed. Once the GUI is fairly stable, most of the development after
> that occurs in the underlying functional part of the code (at least in my
> recent experience). For that, no amount of Glade slinging will help.


Here are a few...

http://wxglade.sourceforge.net/
http://boa-constructor.sourceforge.net/
http://spe.pycs.net/
http://www.roebling.de/

http://thekompany.com/products/blackadder/

There's also something inspired by Visual FoxPro...
http://www.dabodev.com/
 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      06-05-2005
"Thomas Bartkus" <(E-Mail Removed)> writes:
> "Paul Rubin" <http://(E-Mail Removed)> wrote in message
>> Are we talking about a drag-and-drop GUI builder?

> I am!

[...]
> I happen to be one - and I *know* I'm not alone - who thinks that building
> user interfaces is way too difficult and way too important. It is
> particularly frustrating in that we do seem to be moving backwards in this
> department.


"What GUI builder should I use", or similar, is a common question on
c.l.python. I'm a curmudgeon, and don't like GUI builders - so I avoid
them. While normally that wouldn't cause me to encourage others to
avoid GUI builders, I think they have a worse problem: they encourage
the delivery of applications without flexible, robust user
interfaces. In short, the help produce inferior applications. While
this isn't strictly a python issue, c.l.python is where I run into it
- so I'm bringing it up here.

Now, I'm not an expert on GUIs, GUI toolkits, or GUI builders. I've
used some of each, and draw my conclusions from that admittedly small
sampling. Possibly there are other samples that don't have the
problems I describe. Part of the point of posting this is to expose
these thoughts to others, and find out what I've overlooked. I'll
return to these points where appropriate.

What the user deserves.

I'm going to take a side trip into what constitutes a robust, flexible
user interface - which is what I believe the user deserves. Please
bear with me. By robust, I mean the user interface should adopt to the
environment it's being run in. Windows that don't fit on the screen
are simply unacceptable - but all to common if you use a very small
screen resolution. By flexible, I man the user should be able to
adjust the UI to suit their viewing conditions - the DPI on the
screen, the viewing distance, and their possibly aging eyesight.

I use two systems with graphical interfaces, and both are a bit out of
the ordinary. You might even call them extreme. One is a 1600x1200
desktop on a 21" monitor viewed from about 18" away. The other is a
640x480 desktop on a 53" monitor viewed from about 10' away. Even
those these are on opposite sides of "normal" users systems, they both
suffer from the same problem - out of the box applications have UI
elements that are unreadably small.

The obvious solution would be for the system to detect all these
environmental factors, and scale the applications
accordingly. However, things like viewing distance and the quality of
my eyesight are hard to detect automatically, and it would be a pain
to have to enter all those things manually. Since the end result of
all these is a single factor - a UI scale factor - a system wide knob
to scale applications would seem to be the solution.

Note that this is *not* an easy thing to do. Anyone who's tried
scaling bit-mapped fonts will tell you you can't simply scale something
and expect it to look good. Scalable fonts have "hints" and other
goodies in them so they look good as you scale the fonts up/down. This
may be why, but most windowing systems don't seem to do provide a
global UI scale knob. X certainly doesn't. Windows has a limited
capability to scale fonts system-wide, but it doesn't work very
well. OSX seems to have a system-wide display DPI setting one can play
with, but it's not clear how well that works. NeWS and NeXT could
probably do this, but would seem to have a negligible to nonexistent
user bases. rio seems capable, but the typical rio UI is ugly even by
my admittedly low standards.

Failing the single system-wide knob, a flexible application should
have allow the user to scale the application with a single knob. This
is hard to do with modern GUI toolkits. I do it by using text for
imagery in the UI, and having a scaling factor that is applied to the
font sizes. While I prefer text to graphics for UI elements, that's a
rant for a different time. I'll concede that such an interface is
probably unacceptable on a modern commercial application - users now
expect graphics. But how many GUI toolkits let you use a scalable
graphics format (SVG, PS, etc) for images in the UI? My predilections
have kept me from looking closely, but I certainly don't recall seeing
any in the GUI toolkits I've looked at.

I claim it's obvious from this what's wrong with GUI builders. But I
want to look at what I, as a developer, want from GUI development
tools before going into details.

What the developer wants.

Ok, what I mean is what *I* want. But I don't think I'm that unusual,
so I'm going to generalize to other developers as well. I'll point out
what has to be different for this generalization to fail.

First, I'm not a graphics designer. While I've studied page layout and
typographical design, and read Tufte's books on design, I'm a *long*
way from being a good graphics designer. I know even less about the
field of human-computer interactions. Hopefully, a good GUI library
will have had people on the development team who do know something
about these fields. In this - the desirable - case, the library should
have more knowledge about good UI design than I happen to posses.

Given that, the more I can depend on the library to do for me - the
less I have to specify - the more likely I am to produce a good UI
with that library. Conversely, the more I have to specify in the GUI
development process, the more likely I am to screw things up. I claim
this statement should hold for most developers, unless they happen to
be experts in the fields of graphics design or human-computer
interactions.

What's wrong with GUI builders.

Ok, *now* we're ready to deal with GUI builders.

The first, and most obvious, thing that GUI builders do is force the
developer to specify an exact position - if not size - for the
graphical elements of the UI. Better GUI libraries don't do
that. Instead they let the developer specify the position as part of
the overall structure, say as "the third button in the second toolbar
from the top", or "one of two buttons in a toolbar running across the
bottom of the window". This latter allows the knowledge of the library
designers to dominate the design, hopefully producing a better UI than
the you get from your typical software developer.

The GUI builder might provide an advantage if it allowed the GUI
design to be cleanly separated from the underlying code, so that a
specialist in UI design could do the graphics design, and then the
developer could come and add the underlying code. However, the GUI
builders I've dealt with require specifying names for the various
elements of the UI, which names should make sense in both
environments. This would seem to defeat such a split design, but I've
never tried it, so I can't say for sure.

Further, look at the kind of interface the GUI builder gives you. The
position of all the elements are nailed down. This makes it hard for
the GUI to adopt to the extremes of display environments that you find
in the wild. The GUI builders I've used made it hard, if not
impossible, to build an application that can scale the GUI to meet the
users needs. In other words, the GUI builder helps build applications
without flexible, robust user interfaces that are inferior to what can
be built using a GUI library.

Typically, I don't find a GUI builder that much faster than a good GUI
library. If I have to specify pixel positing for elements, the builder
will be a win, but if not, then not. So I haven't examined all the GUI
builders in depth. Maybe there's one out there that will let the
application developer scale the GUI when the application is invoked,
and will re-arrange elements of the GUI so they fit on the screen
properly. If so, I'd love to hear about it.

Thank you,
<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
Jeff Epler
Guest
Posts: n/a
 
      06-05-2005
On Sun, Jun 05, 2005 at 02:38:16PM -0500, Mike Meyer wrote:
[...]
> The first, and most obvious, thing that GUI builders do is force the
> developer to specify an exact position - if not size - for the
> graphical elements of the UI.

[...]

Certainly some---or even most---builders work like this. But there's no
reason that a GUI GUI builder can't work in terms of the more
sophisticated layout algorithms that are available in most modern GUI
toolkits.

I've written a GUI builder for Tcl/Tk (some old versions live at
http://unpy.net/~jepler/nf/ but they're very out of date). The core of
the application is the part that can write Tcl source code to regenerate
the screen as it's currently displayed.

The user can either use graphical tools like "insert widget", "show
properties", "pack earlier/later", "automatically add accelerator keys",
or script the thing by typing in Tcl. Want to use the grid manager?
Fine, go ahead. The graphical interface to the grid command may be
poor, but the commandline interface works great. When things are as you
want them, just "save", and you can trivially "source" the resulting Tcl
code from your Tcl/Tk app.

I'm not trying to evangelize Tcl/Tk above any other language/toolkit,
but I am saying that by pairing an interpreted language with a GUI
toolkit, you can get a powerful GUI builder that instantly has top-notch
scrptability and also the guarantee that you can use the powerful
features of the GUI toolkit.

I didn't do a survey of existing software before writing mine, but I
don't know of another builder that takes this kind of approach. I
wonder why not.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCo2FYJd01MZaTXX0RAvB1AJwM/6+06j5HkvNtoOUZ1JEr1SWbnwCeL1es
hfTLOJDwL9+/fbgjdgUgBhs=
=R2Cz
-----END PGP SIGNATURE-----

 
Reply With Quote
 
Bruce Stephens
Guest
Posts: n/a
 
      06-05-2005
Mike Meyer <(E-Mail Removed)> writes:

[...]

> The first, and most obvious, thing that GUI builders do is force the
> developer to specify an exact position - if not size - for the
> graphical elements of the UI.


They do? I don't remember them doing that. I just downloaded SpecTcl
(a oldish example) just to check, and that doesn't. I presume more
recent ones work no less well?

I seem to remember that the GUI builder in Visual Studio didn't seem
to be particularly sane (I couldn't seem to work out how to get a
dialog to resize appropriately to accommodate different font sizes,
for example), but I assumed that was just me failing to understand
something.

[...]


 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      06-06-2005
Bruce Stephens <(E-Mail Removed)> writes:

> Mike Meyer <(E-Mail Removed)> writes:
>
> [...]
>
>> The first, and most obvious, thing that GUI builders do is force the
>> developer to specify an exact position - if not size - for the
>> graphical elements of the UI.

>
> They do? I don't remember them doing that. I just downloaded SpecTcl
> (a oldish example) just to check, and that doesn't. I presume more
> recent ones work no less well?
>
> I seem to remember that the GUI builder in Visual Studio didn't seem
> to be particularly sane (I couldn't seem to work out how to get a
> dialog to resize appropriately to accommodate different font sizes,
> for example), but I assumed that was just me failing to understand
> something.


In my experience, they do. But as noted, my experience is limited.

<mike
--
Mike Meyer <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
icmp weirdness - PIX 501 (does any really mean any??) news8080@yahoo.com Cisco 2 09-23-2005 04:04 PM
Anyone interested in getting any Certificationz from Microsoft, CISCO or any other IT CertificationzzzZ...?? get.certified@gmail.com Cisco 0 03-07-2005 03:09 PM
so what does IE or any of the IE shells have over firefox ? (any anti firefox ppl bother looking at recent plugins available?) *ProteanThread* Firefox 12 10-20-2004 08:31 AM
Does any one have any material for 70-015 Srinivas Iragavarapu MCSD 0 10-08-2003 05:48 AM



Advertisments