On Oct 15, 12:27 am, greg <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
