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