In article <pan.2009.09.11.12.02.03.656...@nowhere.com>, Nobody <nob...@nowhere.com> wrote: >On Mon, 07 Sep 2009 23:56:17 +0000, Albert van der Horst wrote:
<SNIP> >> >> In view of the above this is not quite the correct way to put it. >> >> What I resent is that it leads to a non-professional attitude >> of the graphical part. Programming is over, lets now kludge >> some screens together. No. The graphics part has to be carefully >> designed, carefully tested, and carefully "written", even if it >> is using a graphical tool. So, yes please, *do* create a GUI >> "programmatically". > >My view is that the program should provide functionality without >unnecessarily dictating the way in which that functionality is used. >Essentially, it's an issue of "loose coupling". > >The interface really should be configurable by the user according to their >needs. The code doesn't need to *know* the position or dimensions of >a widget, or its label or colour or spacing, let alone dictate them. > >In most cases, the code shouldn't even get to dictate that specific >widgets even exist. Rather, it should provide actions which can >be bound to buttons, menu items and/or accelerators as the user chooses. I don't necessarily disagree. But how does this work in practice? I have a totally programmable editor (I do, I'm using it right no.) I'm able to redefine commands to the point that I have no longer a command to quit the program, and even have no longer a possibility to define a new key-combination to quit the program. The hacker who wrote it would say: "don't do that". Combined with my habit to switch the Caps lock and control keys and use the editor full-screen, someone else really gets nowhere. What if I prefer to have the gaz throttle and the clutch pedal of my car switched. Is that a good idea? Bottomline, "let the user choose" must not be an excuse for us, where we are not able to propose a good choice. (You may read the subject note-eater on my website.) Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. alb...@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
