Re: Re: Re: Re: [pygame] Pygame-UI: UI Component Framework for python and pygame

[info@xxxxxxxxxxxxxxxx]

Hi there,

You are making some really good points/suggestions. I would definitely take those in consideration. 

About the naming convention: I would most probably change this to be fit with the python convention. Currently it follows a .NET convention which as you point out is not very intuitive for python users. 
About the whitespaces: I use notepad++ with default settings to develop my code and those tabs are very readable when you open the code under that editor. 
About the BaseUIComponent: I am currently touching very little of it as it is really stable. Any major change to the BaseUIComponent I make has to have a really good reasoning for me to do it, but this doesn't mean I would not consider what you said about the rendering logic. I am not making the _parentSurface global because there are components which have another component's surface as their parent surface: an example would be the MessageBox which has a header and a TextLabel, all of the components in the header, as well as the TextLabel have their parent surface to be the component that owns them. This reduces overhead when propagating events down to subcomponents as it is done only if the event is already determined to be affecting the parent component.
About the UIComponentCollection: You should consider that a lot of the code inside this class is currently being developed. I would merge a lot of changes I have done to this class to trunk at the end of this week. The disposal logic is dirty at this point, I was just notifying the ComponentCollection that current component has been disposed this way and was removing the last reference to it (I had it put there to handle the MessageBox being disposed). I know that it's dirty but I have pretty much fixes all the logic there at this point, so you would soon be able to see a lot cleaner code there.
About components Visible property: This is a whole lot other property which I am implementing, and while this property is set to false, then the component would just be excluded from the rendering loop. You would not be able to see this code in trunk now because I haven't merged it yet.
About background/foreground: I am not exactly sure what you mean here. My idea is to have templatable content inside each component, meaning you would still have the background but in the foreground you would have anything you like to have. Is this something similar to what you have in mind or is your idea different?

Here is my question to you though: I see what you didn't like about the framework so far, but is there anything that you liked and because of which you would consider using it?
Please feel free to also contact me in person with any questions/suggestions/clarifications you may have. My skype: sauron_bg (write some meaningful content when requesting to be added though, because otherwise I would just ignore the request).

Best regards,
Konstantin Dinev

---- OriginalMessage ----
>From: "inigo.delgado@xxxxxxxxx" <inigo.delgado@xxxxxxxxx>
>To: pygame-users@xxxxxxxx
>Sent: Thu, Jul 14, 2011, 12:36 AM
>Subject: Re: Re: Re: [pygame] Pygame-UI: UI Component Framework for python and pygame
>
>Another two cents (so you have 4!!! :P)
>
>I would make a object "background" and an object "foreground" instead
>of backgroundimage in the component style, so you can have animations
>in background an foreground (which is cool).
>
>
>2011/7/14 inigo.delgado@xxxxxxxxx <inigo.delgado@xxxxxxxxx>:
>> I have just take the code and I dont like -or have to argue because
>> dont think that is the best way to do- some things...
>>
>> As always I would like to be wrong and correct my opinions after this
>> dicussion because my objetive is to learn and to improve my
>> programming skills.
>>
>> Coding:
>> ÂÂÂ -8 whitespaces are a lot of whitespaces, i think 4 are more readable.
>> ÂÂÂ -I think that the first character in methods/functions shold be
>> lowercase and in classes upper case.
>>
>> At last these are 2 conventions but I think that are commonly used in
>> python... anyhow are only a convention and this is only a petition,
>> like you wish.
>>
>>
>> BaseUIComponent:
>>
>> You have _parentSurface and _controlSurface that I think that are unnecesary:
>>
>> I think that the component should have "how" to draw the component and
>> not "where" the where is common for all of them (always in a game that
>> only have one window). I'll put the 'where' -the surface- in a
>> parameter in the render() or, being more radical and thinking in this
>> UI like a simple game UI, put it as global because you'll only use one
>> surface per game.
>>
>> For the collisions (to know if the mouse cursor is inside the
>> component) I'll do this:
>>
>> def isPointInside(self, cx,cy):
>> ÂÂÂ if self._absY > cy > self._absY - self._heigth and self._absX < cx
>> < self._asbX + self._widht:
>> ÂÂÂÂÂÂÂ return True
>> ÂÂÂ else return False
>>
>> Which can be 'reintention of the wheel' but: they're only from 1
>> comparation to 4 comparations and 2 sums (the alternative are always 2
>> sums and the creation of 2 objects) ad it's not a complicated code...
>> For collitions between rectangles I wouldn't do this... but to know if
>> a point is in/outside a rectangle...
>>
>> This way you can avoid having the surfaces pointed in all objects.
>>
>>
>> UIComponentColection:
>>
>> I think that this should be a BaseUIComponent (implement it) that
>> contains a list of another objects that implement BaseUIComponent for
>> structural coherence, so p.e. it can be decorated (from the pattern
>> decorator of the GoF) in the future easily.
>>
>> Another think. In the render() method in UIComponentCollection have:
>>
>> for component in self._uiComponentCollection:
>> ÂÂÂÂÂ if not component._disposed:
>> ÂÂÂÂÂÂÂÂÂÂ component.render()
>> ÂÂÂÂÂ else:
>> ÂÂÂÂÂÂÂÂÂ # dispose logic
>>
>> So, to be honest, the method should be called "renderOrDisposeComponents()"
>>
>> I'll do something like this, in the collection:
>>
>> def render(self, display):
>> ÂÂÂ for comp in self._uiComponentCollection:
>> ÂÂÂÂÂÂÂ comp.render(display)
>>
>> And change the 'dispose' for a 'visible'Â property so in the
>> BaseUIComponent you can do:
>>
>> def render(self, display):
>> ÂÂÂ if self._visible:
>> ÂÂÂÂÂÂÂ #render stuff (blit)
>>
>> Because generaly you dont want to dispose elements, only set them
>> visible or invisible... And the visible and invisible properties are
>> of the object and the object draws himself.
>>
>> And also you can do a dispose method in the Collection to search and
>> dispose a component if you want....
>>
>> Well these are my ideas, my 2 cents.
>>
>>
>>
>>
>>
>>
>>
>> 2011/7/4 <info@xxxxxxxxxxxxxxxx>
>>>
>>> Hi Jake,
>>>
>>> To answer your questions:
>>>
>>> 1. For rendering I'm currently doing blit.
>>>
>>> 2. CSS parser is a great idea but initially I would like to implement a configuration manager using XML because this provides me with the opportunity of implementing a designer later on when I have enough quality components to build it with.
>>>
>>> Question:
>>>
>>> Why do you consider having CSS properties as attributes in the XML node wrong? The XML you have provided has width and height properties as attributes and font-size as a node content, shouldn't they all be nodes or attributes to be consistent? I'm not saying yours is wrong just wanted to know the reasoning behind it.
>>>
>>> Currently in my branch code I am implementing the configuration manager as a separate class that is being instantiated inside the base component and that finds the XML node by ID attribute where the ID is the ID of the control. To have all components instantiated from the existing XML I am using the component collection constructor with the config (XML) path provided to it. It goes through the nodes and instantiates each component by getting the component type, be it an ImageBox or a Button, from the XML and instantiating the component with the XML node attribute. Let me know what you think! I would soon have this code committed and once I make sure it works as expected, I would have it merged to trunk.
>>>
>>> ---- OriginalMessage ----
>>> From: "Jake b" <ninmonkeys@xxxxxxxxx>
>>> To: pygame-users@xxxxxxxx
>>> Sent: Sun, Jul 03, 2011, 04:28 AM
>>> Subject: Re: Re: [pygame] Pygame-UI: UI Component Framework for python and pygame
>>>
>>> For rendering, what do you plan on doing? ( blit, opengl, svg_blit, pygame.draw )
>>>
>>> My main request for reusability is loading a .css file.
>>> If for XML, I tried this. [ Using attributes for sll style info seemed wrong. ]
>>>
>>> <configuration>
>>> ÂÂÂÂÂÂÂ <component name="inventory left" width="200px" height="150px">
>>> ÂÂÂÂÂÂÂÂÂÂÂ <parent>inventory root</parent>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <type>window frame</type>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <!-- load base, except set font size -->
>>> ÂÂÂÂÂÂÂÂÂÂÂ <basestyle>inventory.css</basestyle>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <style>font-size: 20px;</style>
>>> ÂÂÂÂÂÂÂ </component>
>>> ÂÂÂÂÂÂÂ <component name="inventory right" width="100px" height="150px">
>>> ÂÂÂÂÂÂÂÂÂÂÂ <parent>inventory root</parent>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <type>window frame</type>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <basestyle>inventory.css</basestyle>
>>> ÂÂÂÂÂÂÂÂÂÂÂ <style>font-size: 12px;</style>
>>> ÂÂÂÂÂÂÂ </component>
>>> </configuration>
>>>
>>> Or, you could define that in xml:
>>>
>>> <configuration>
>>> ÂÂÂ <stylelist>
>>> ÂÂÂÂÂÂÂ <style id="inventory base">font-size: 1em; color:gray; font-family: sans-serif;</style>
>>> ÂÂÂ </stylelist>
>>>
>>> ÂÂÂ <component name="inventory left pane" basestyle="inventory base" width="200px" height="150px">
>>> ÂÂÂÂÂÂÂ <parent>inventory root</parent>
>>> ÂÂÂÂÂÂÂ <type>window frame</type>
>>> ÂÂÂÂÂÂÂ <style>font-size: 20px;</style>
>>> ÂÂÂ </component>
>>>
>>> ÂÂÂ <component name="inventory right pane" basestyle="inventory base" width="100px" height="150px">
>>> ÂÂÂÂÂÂÂ <parent>inventory root</parent>
>>> ÂÂÂÂÂÂÂ <type>window frame</type>
>>> ÂÂÂÂÂÂÂ <style>font-size: 12px;</style>
>>> ÂÂÂ </component>
>>> </configuration>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Jake
>>
>>
>>
>> --
>> Nota: Tildes omitidas para evitar incompatibilidades.
>>
>> :wq
>>
>
>
>
>-- 
>Nota: Tildes omitidas para evitar incompatibilidades.
>
>:wq
>