pygameui-users — Place to discuss development of Pygame.UI or with Pygame.UI

[Pygame.UI] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Pygame.UI] Test 2

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

Sorry for this...

Qark

[Pygame.UI] Simple test

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

It looks like it's not working...

Q.

[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

[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