Slashdot Mirror


User: ewestra

ewestra's activity in the archive.

Stories
0
Comments
3
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 3

  1. RAD tools are okay for mockups, NOT for real apps on Are GUI Dev Tools More Advanced than CLI Counterparts? · · Score: 4, Insightful
    I've been an application developer for over ten years, writing some very GUI-intensive apps, and I've yet to find a single RAD tool (which is really what this topic is about, not things like syntax highlighting, automatic project management, etc) which can do the job properly. The problem is that they all seem to (a) make it very hard, if not downright impossible, to include dynamic layouts, and (b) rely on hardwired pixel positions to lay out widgets.

    In the work I do, less than half of the GUI windows I develop are simple fixed input forms where all the elements are known beforehand. A RAD tool is fine if your window is a simple dialog box with nothing but fixed elements, but as soon as you need a dynamically laid out window you're sunk. Even something as simple as an input form with a variable number of rows of data is beyond all the RAD tools I've found (unless you use an ugly-looking table widget which in most cases means that the end product looks amateurish) -- and if you're talking about something like having a database schema driving the layout of your input forms, you can forget about RAD tools completely. As soon as you need this type of dynamic layout, the RAD tools become your enemy rather than your friend -- and the last thing I want to do is fight the development tools I use, or have to add contortions to my source code just so that the RAD tools will accept them.

    But the lack of support for dynamic layouts isn't the main reason I avoid RAD tools -- the fact is, almost all RAD tools I've seen rely on absolutely x,y coordinate placement (and sizing) for each widget. This is a terrible way to lay out your windows, because as soon as your program runs on a different platform, or even on a machine with, for example, a different set of installed fonts, or a different video resolution, suddenly all your nice-looking GUIs turns to custard. At best, your GUI windows look cramped or have widgets that don't line up -- at worst, your widgets overlap or are cropped. Talk about amateurish-looking GUIs! And if your GUI looks messy, your users will assume the code lying behind the GUI is a mess as well -- which is why I'm so fanatical about creating professional-looking GUIs.

    Anyway, that's why I've abandoned RAD tools, and hand-code everything. Sure, it sometimes takes a little longer to create a simple dialog box, but I more than make up for that by saving time when creating dynamic layouts and not having to redo everything when I want to run my app on a different machine or platform...

    Mind you, it has been years since I've looked at RAD tools -- it may be that some of them now do support dynamic layouts better, and maybe even use logical positioning (eg, sizers and other layout tools) rather than rely on absolute positioning and sizing. If there was such a tool (preferably for wxPython, which is what I'm coding in now), I'd love to hear about it!

    - Erik.

  2. Why have only one "official" GUI toolkit? on Ask Guido van Rossum · · Score: 1
    Hi. Let me start by saying that Python is amazing. I've been working with it for about a year now, and every project I've used it for has been outrageously successful. I'm constantly amazed at how easy and quick it is to program in Python...

    Now, one thing that has been bugging me for a while is that Python only has one "official" GUI toolkit (Tkinter), even though there are a variety of toolkits available. Each toolkit has its own strengths and weaknesses -- so why has Guido chosen to only mention one of these toolkits on the Python Language Website ? It seems to me that by having a single "de facto" standard toolkit gives the impression that no workable alternatives exist, which will lead many people to conclude (as I initially did) that Python is unsuitable for GUI programming -- simply because the "de facto" standard toolkit appears to be the only one available, and was unsuitable for the particular project at hand.

    Isn't this doing Python a dis-service? It seems to me that this idea of a single "standard" tookit smacks of a Microsoft-like attitude that there's only one OS/Word Processor/GUI toolkit you can use. With Python GUI programming, as with most things, there are many alternatives available -- each with its own advantages and disadvantages. So why not have a variety of supported toolkits, rather than supporting one to the exclusion of all the others?

    Thanks,

    - Erik.

  3. Re:Python GUI on Ask Guido van Rossum · · Score: 1

    Have you tried wxPython?