[Pygame.UI] Re: Pygame.UI - Notes

[Ludek S. <qa...@se...>]

Tim Ansell wrote:
>>>>1) Application is class responsible for managing windows (so, it's not 
>>>>visible)
>>>
>>>Why should Widgets be classed as "visible". Plenty of "widgets" are not
>>>visible. For Example Layouts - Grids. The more we separate out special
>>>widgets the more likely we are to make a mess.
>>
>>Widget is a visible componet. Layout manager is not a widget -- it's a 
>>components that lays out the widgets in some metawidget.
> I can think of Layouts which might need visible components. (IE Handles
> so they can be resized and such.) How does this scheme handle those
> situations? 
In most GUI I know is layout separated from metawidgets. The reason is
simple -- you can have multiple layout mechanisms to select to layout
subcomponents in metawidget. The handle to resize metawidget you've
mentioned is not part of layout manager -- it's part of (meta)widget.

>>>>3) I've changed completely drawing (some magic included -- look at 
>>>>Widget.draw)
>>>
>>>
>>>The reason I didn't do this is I've named styles in the following way. 
>>>
>>>draw<Class><Style>
>>
>>That's what I want to prevent. Why not use "smart draw function" for 
>>several widget types? Let the theme designer decide.
>>
> How would the theme designer decide? Look at widget.style? It makes
> little difference to me how this is done. 
> 
> However draw<Class><Style> does help to split up the documentation a
> bit. (IE Where different styles require different stuff.)

When class is included in the draw procedure name, it prevents you to
use the same method for drawing similar widgets (or forces you to write
empty method and call it from it).

>>>>4) I think that even CoreTheme must be useable (let's make it black and 
>>>>white theme), so Each *Theme class must be able to draw the widget (just 
>>>>empty box or box with text is OK)
>>>
>>>CoreTheme == Theme used when no theme is specified?
>>>
>>> When you draw something by default people tend to think it's the
>>>best/correct way to draw it. It also makes people more lazy :). 
>>>
>>>However it does make themes easier to produce and gives more instant
>>>results.
>>>
>>>I would prefer to just provide some good complete themes with the
>>>package.
>>
>>Remember one of the requirements? We must support partialy defined 
>>themes. Withouth default theme definition, this requirement will not be 
>>fullfiled.
>>
> 
> 
> Partially defined themes can still work, they just only work with the
> Widgets they are defined on. Plus if you inherit from BlackAndWhite
> theme you'll work with all widgets. 
> 
> I think this seems to be the better as if you are implementing a full
> theme and you make a typo with the name it dies instead of working with
> different graphics (which could cause some confusion). However if you
> wanted it to it's very easy.
> 
OK, we can settle this discussion with decision to implement very simple
default theme and provide abstract and "working" themes. I think that
it's quite good solution.

>>>>5) Let's move general theme methods to the BaseTheme class 
>>>>(drawTextAndIcons)
>>>
>>>
>>>Well I would like WidgetTheme == BaseTheme.
>>>
>>>Widget should also be the base for almost everything.
>>
>>This will make WidgetTheme quite fat.
>>
> 
> 
> Why would there be a lot in BaseTheme/WidgetTheme?
> 
> I can seen about 5 or 6 possible methods am I missing something?
Yes, you are -- we will provide more high level drawing methods in
future (like gradient box, 3dBox, several border types, ...) and all of
this should go into BaseTheme, so every theme can use it. More, if you
want to support OpenGL in the future, this will be the correct place for
all the related methods.

>>>>7) Think about *using* the class before designing anything. For example:
>>>>   your text attribute was tuple, so if user wants to change text
>>>>   he must type this:
>>>>   widget.text = ("NEW TEXT", ALIGN_W)
>>>
>>>This should also work if you don't use tuples but a list instead.
>>>
>>>widget.text[0] = "NEW TEXT" 
>>>widget.text[1] = ALIGN_W
>>>
>>>Or we could define a new constant and have it
>>>
>>>widget.text[TEXT] = "NEW TEXT"
>>>widget.text[ALIGN] = ALIGN_W
>>>
>>>It also allows us to add new attributes to the text/icons without
>>>needing a bunch of new attributes.
>>
>>But there are two issues with your solution:
>>1) we cannot automaticaly detect change in the list
>>2) it's ugly (sorry), the font, aligment, etc. are not changed often 
>>while text is.
>>
> 
> 
> My problem is consistency. Why does the same argument no apply to Icons?
> Wouldn't there picture change a lot more then there alignment or font? I
> suppose it doesn't make a huge difference.
It does. It will break a lot of existing code and is also less intuitive
  to use. I think that we can refactor icons handling not text handling.
What about this:

widget.icons[0].img = <some image>
widget.icons[0].align = ALING_NE

>>>>8) Why do you check that theme set for widget has been derived from the 
>>>>default theme? There is not strict type checking (when we speak about 
>>>>classes) in Python, so why to enforce it? Everything is about protocol 
>>>>(method signature) and there is nothing which prevent user to access 
>>>>wrong widget attributes in the draw method.
>>>
>>>
>>>Because people should be reading the classes. If they didn't read the
>>>class they shouldn't be implementing the method. Plus it gives you the
>>>error at creation time instead of when you go and try and draw the thing
>>>making life a lot easier when it comes to debugging.
>>
>>When they do not read the documentation they are in trouble anyway. 
>>Don't limit people. Offer them a lot of possibilites.
>>
> 
> 
> I prefer errors to occur as soon as possible. It allows me to find
> problems before it gets to the 100th button click. Problems at creation
> cause me less headache. If the person wants to ignore everything they
> just inherit from the class and do nothing. Then we get a NotImplimented
> error instead of a AttributeError.

When we support multiple styles per widget, you can still get
AttributeError when using incorrect style.

> I'm happy to offer freedom. The main reason I can't use pyUI is because
> it's way to restrictive. I also like to be fault tolerant, consistent
> and informative. 
So let's not build another pyUI :-))

> The other issue is that it's your project, so your the leader. If you
> don't like something I do just override me. :)
Well, life teached me to respect opinions of my coworkers. I prefer
agreement instead of enforcement.

Qark