[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] New GUI



On, Tue Jan 22, 2008, Kamilche wrote:

> Marcus von Appen wrote:

[...] 
>> Kamilche, as I am the OcempGUI head, I'd like to hear where exactly your
>> problems and expectation were (and still are) regarding an user interface
>> system for your applications and games.
>> 
>> Regards
>> Marcus
> 
> Sure. I've attached a more thorough critique of some of the features in 
> Ocemp GUI, since you're interested.

Answering this will become a bit off topic, but as there are some more
people reading this list, I guess answering some general things here is
okay. The others will be answered off list.
 
> General and UI Observations
> ----------------------------
> In mnemonics, '#' is used to denote the accelerator key, instead of '&' - 
> nonstandard. The mnemonics don't work with the right alt key, just the left 
> alt key.

Basically the mnemonic solution is bad at all, not only in OcempGUI, but
in any (major) toolkit I know: not fail-safe, unintuitive to use
(doubled mnemonic character for the real character) and using the same
mnemonic by accident on one form (due to a translation or an improper
test) causes usability problems. I am however sure, that there is no
standard, that declares '&' as mnemonic - just because other toolkits
use it, do I have to?

[....]

> The borders and window styles are non standard, and unattractive.
> The font has hinting problems - a different font would be better.

What's the standard for window and border styles and where it is
defined? The default theme is in fact and without discussion far away
from what one would consider 'nice looking' and already on the TODO list
(for quite some time now...).

[...]
 
> By the end, you realize it requires 88 lines of code to create a simple 
> screen that doesn't DO anything. Ideally, a GUI builder should build it for 
> you and save the results to a file. In your code, you should just have to 
> say 'load thatscreen' and put in code to actually do program stuff.

Show me a GUI builder that in fact produces clean, non-overloaded code,
that does not break, if I manually change, add or remove stuff and so
effectively eases development. I am not aware of any. If they do not
match these criteria, but I am instead forced to stick with them (like
e.g. VS.NET), they are useless.
 
> I don't like having to execute a 'connect' for every button I want to 
> click. For standard controls and most situations, it's likely that the 
> parent of the button (the frame or the window) wants to handle the button's 
> click. Why do I have to code a connect for every little bit of 

So the Frame in which the Button resides handles its click. Clicking on
the frame will then be handled by its parent and so forth? What about
the topmost container then? To me that sounds like a weird
implementation, but feel free to provide me a handy example for such an
event handling..

> functionality? It would be better to have the 'obvious' cases automatically 
> handled, and reserve 'connect' and its ilk for global events that multiple 
> controls might want to handle.

So the button gets clicked and how should it know (or the Frame) what to
do? I still have to implement the callback. If I do it in the Button or
Frame, does not matter here as it's the same effort and does not lower
the work.
 
> There's more, but I don't have time to review it further. I hope you find 
> this partial list of limitations useful.

Sure. The feedback is highly appreciated.

Regards
Marcus

Attachment: pgpbL9OlZEpxJ.pgp
Description: PGP signature