[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] New GUI
Marcus von Appen wrote:
On, Tue Jan 22, 2008, Kamilche wrote:
[Unhappiness about the existing GUIs]
It's interesting to see that a lot of people tell some public
list/forum/whatever how unhappy they are with existing solutions, but do
not dare to get into touch with any of the solution developers or even
describe the problem areas they see somewhere.
It explains, why there's so much lousy software on the market. People
just complaining, but not helping in any way.
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.
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.
In radio buttons, multiline text is centered by default. It really
should be left aligned.
There'e no 'pygame.quit' at the end, so after running, the examples hang
and you have to manually close the DOS box. This makes them hang in IDLE
as well.
The borders and window styles are non standard, and unattractive.
The font has hinting problems - a different font would be better.
There's no selection capability on the text edit boxes - you can't drag
your mouse to select text, have it highlight, and do standard text
editing on it.
Many examples are so simple as to be useless, such as the 'event.py'
example. An event showing a button actually executing code when clicked
would be good, instead of showing a 'picture of a button' in one example
and showing an 'event that's raised' in another example.
In the 'example.py' application, the 'box' entry shows 4 items placed on
top of each other. Clicking on the background items brings them to the
foreground, and they never go back. Was that intentional? Why are they
changing zorder? This is not obvious to me.
In the file dialog example, clicking '..' when at the top doesn't bring
you to the list of drives. You have to manually overtype drive C with
drive D using the limited editing capability allowed in the folder name box.
The image map example suffers from performance problems. Just moving the
mouse over the imagemap box causes events to queue up and get rendered
so slowly, you quickly wonder if the example is broken. A single swish
of the mouse from left to right, and you have to wait 3 seconds for the
display to catch up.
The sliders suffer a performance problem as well. Dragging the sliders
isn't instant, you have to wait for it to catch up to the mouse.
The 'hello world' examples have an unpainted area to the right of the
window, that is picking up whatever was underneath when the window was
created.
The main window is not resizable.
The status bar is not recognizable as such, it looks like a frame with
text in it. It needs to look like a status bar, and have multiple panels
you can set.
The toggle buttons don't look any different than depressed normal
buttons. Toggle buttons usually look significantly different than normal
buttons, by such hints as having a different shape, different shading,
or graphics on them as well.
There are no examples of an FPS indicator, a global event that several
controls might want to handle.
The tooltip makes no attempt to stay on screen - it gets cut off on the
right.
The window example is too small - it shows a single button that you can
click. I would like to see window examples throughout the examples, not
just this unrealistically simple example.
No fullscreen mode available.
No 3d option for the text.
No menus.
No way to enlarge/shrink controls when the window size changes.
Code Observations
-------------------------
I don't have time to critique all the example code, so I just ran
through the 'radio.py' example.
'from ocempgui.widgets import *' - pollutes namespace
After creating a table, you must set the alignment explicitly for each
row. Why not have the most common alignment, which is probably
align_top, the default?
table.set_row_align (0, ALIGN_TOP)
table.set_row_align (1, ALIGN_TOP)
When creating radio buttons in a loop, you must specify the group
manually with an if switch. Why not have all radio buttons that belong
to the same parent, automatically in the same group?
btn = RadioButton (s, group)
if i == 0:
group = btn
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.
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
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.
There's more, but I don't have time to review it further. I hope you
find this partial list of limitations useful.
--Kamilche