[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.

>>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.

>>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.

>>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.

>>6) Do not set explicitly theme for each widget -- it's hard to change it 
>>then.
> Yeah, I agree we need some way around this. If you think of one please
> tell me :) (And no we can't use a global variable ;) Plus each widget
> needs to be able to override the ones below it. Maybe have setTheme
> cycle through the sub-widgets.
And what about to get theme from parents if there is not theme 
specified? It's small performance penalty we can live with.

>>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.

>>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 think there is some problem with your and mine approach -- you tend to 
be very restrictive and I tend to offer a freedom. We have to settle 
this or we end with rewriting code again and again. Please -- do not put 
restrictions whete they don't have to be. Libraries shall offer as much 
freedom as possible for possible user.

Qark