PyGUI as a standard GUI API for Python?

[lkcl]

On Oct 15, 12:27 am, greg <g... at cosc.canterbury.ac.nz> wrote:
> Paul Boddie wrote:
> > there are a few things with
> > regard to layouts which are very difficult with Web technologies (and
> > aren't getting any easier, either) but which are almost trivial with
> > classic graphical user interface toolkits, and of course there are
> > cases where the roles are reversed.
>
> I've written quite a lot of desktop gui apps, and I
> don't think I've ever felt the need for free-flowing
> widget layouts.

 i have.  an image library.  placed in a scrollpanel, the images
automatically flow left-to-right then down the page.  the application
doesn't dictate what size of panel the user _must_ view the images
in.  if they want to use the whole screen width, they can.  if they
want to view the images in a single column, they can.


> To say that a desktop gui api is
> severely lacking without this feature is somewhat
> overstating the case.

 it's the _combination_ of the limitations that makes them severely
lacking.  each limitation on its own does not, of course.

 the key point is, really, that if you take away one particular layout
methodology from designers, they _will_ adapt - they _will_ cope, and
rejig the design of the app to fit the widget set.

 ... but that's cart-before-horse. that's "IT tail wagging the
business Dog".

 so, when it comes to moving the same application functionality to a
different platform, or to the web, people freak out.  you're locked
in.  the cost is too great.  the effort is too much.

 ... as you might be aware, i'm not really a big fan of restrictions
imposed by software design :)


> Also, I think that proportional resizing is overrated.

 proportional resizing is very difficult to do well, and so many
people don't even consider it.  many designers will say "this app is
to be used on a 1024x768 screen" (and now of course they're running
into difficulties with the netbook pcs with the 1024x600 screens, and
KDE's control panel "close" button is now off-screen for example!)

it took several months to design a 2d graph widget which was "useful"
when scaled down to 200x150, especially given that the axes could be
logarithmic (!)  starting with the axes themselves, we had to break
things down into small, medium and large graticules, where the
distance between each range of graticules would no longer be
displayed, below a certain number of pixels (5 or so).  likewise with
the axes numbering. then the axis description had to go, below a
certain size.

then, we had controls (sliders and dials) where, again, the graticules
automatically disappeared, and, also, if below a certain size, the
"readout" would also disappear.

so if you're doing _simple_ applications, then yes, proportional
resizing is entirely unnecessary.

but if you're doing applications where you have to display vast
amounts of interactive graphical data (the example above was a real-
time digital audio restoration GUI) then you really do have to think a
bit harder about what you're going to present the user with.

>  Proportional resizing is a
> compromise that just ends up annoying me.

 if it's done badly, then yeah, i agree.

 if you look, for example, at the source code of my web site,
http://lkcl.net/site_code, you'll see that the site is capable of
resizing to deal with anything down to about 300 pixels in width.  the
onResize function redoes the layout, placing the seven components in a
hexagon if there's space, a side-on "H" below 800 pixels, and a single
line below 640 pixels.

 it didn't take too much effort, and it means that anyone viewing my
web site even on a QVGA screen won't have to do horizontal scrolling.

not that i'm _expecting_ anyone to do that - i just wanted to prove a
point :)


l.