phatch-dev team mailing list archive

[Stani <spe.stani.be@xxxxxxxxx>]

On Sun, Jun 14, 2009 at 9:48 PM, Robin Mills<robin@xxxxxxxxxxxxx> wrote:
> On Jun 14, 2009, at 11:33 AM, Juho Vepsäläinen wrote:

>>>> I have used "get_relevant_field_labels" for conditional fields (ie.
>>>> fields depending on state of others). The system works, yes. But I
>>>> find it a bit suboptimal.
>>>
>>> Suboptimal in which way? Can you clarify?
>>
>> As stated below it felt as if "get_relevant_field_labels" was a bit
>> too elaborate whereas more compact representation might have sufficed.
>> I can see the justifications of the system better now.
I would propose for Phatch 0.2 we stick to the current system. For the
end user it won't make any difference and as such is not a reason to
postpone the Phatch release. (I would even rather try to merge the
multiprocessing branch before this feature.) When I started Phatch I
was inspired by the adminstrative interface of Django (the field names
are almost identical), which combines validation and automatic UI
generation, and because I prefered the simplicity and comfort of one
action = one file. Django obviously also not chose to use XML, json or
YAML to reduce the number of dialects.

For Phatch 0.3 we can open this discussion. Juho, the best way to
proceed would be to have a separate branch exclusively for the YAML
approach, which can be merged if we feel this will be the way to go.
Don't mix different features in one branch. Have a separate branch for
each (major) feature. (Just like Ido is doing for multiprocessing.)
But let's first concentrate our time and energy for Phatch 0.2. People
are not expecting Phatch 1.0 yet ;-) It would be nice if we could
still release it this month. Before you came this was not feasible, if
you continue like this it might be.

>> I think it's quite possible to embed Python within YAML definition.
>> Even better would be to have names ran through translator function
>> separately. It has been a while since I had to work with gettext but I
>> don't believe it will become too big a problem (it's my problem anyway
>> :) ).
Haha, you realize ;-)

>>> Until now I have no regrets. I really like that actions are one file
>>> as it makes it easy to handle. From the moment you start with multiple
>>> files (like an xml/yaml for user interface, pil function in py file
>>> and icon seperately), you need to manage. Do you put each action in a
>>> separate folder or zip or ...? So I took the KISS approach.
>>
>> Note that the UI definition can be included in the .py file itself.
>> Basically it would be just a string assigned to a class attribute. I
>> don't see much sense in separating it from the .py file. Note that
>> YAML is more about communicating structure whereas XML is more fitting
>> for purposes where you need to use a schema (ie. metadata to describe
>> structure of data). I rather would not use XML in this case.
>>
>> In the case of icons I might be inclined to favor separate files and
>> then refer to them just by using a name. Perhaps the arch should
>> support user defined icons even? One interesting aspect of open source
>> development is that if you provide the users affordance (ie. empower
>> them!), they might contribute something back in the form of enhanced
>> icons/whatnot. By the way I'm not saying that the current icons are
>> bad. On the contrary. :)
Or it is one file (with its easyness) or if you split, you have to
split all. For example the YAML and the icon belong to the view part.
So if the icon is separate, the yaml should maybe be as well. There
would be another good reason for that. Right now all actions are
imported at the start of Phatch. Probably Phatch could boot faster if
it would just take the YAML and the icons, as that is only necessary
for the UI. The code need only to be imported by the workers of the
multiprocessing pool. With multiprocessing there is no need for the
GUI process to import the PIL code. If the code of the action is
separated from the UI (yaml+icon), there is no need for the lazy
import structure within the init method of the action. This would make
the code clearer as well. But splitting up in files creates more
adminstrative work, every file and a folder has to be named. Therefore
Phatch should provide a 'create action' script just like django and
sphinx have a 'create project' script. So it would be good if you
could profile Phatch and try to give the YAML approach a selling point
which I can't refuse: further separating the view from the model and
speed increase. But also think of how actions are represented: as
folders or as zip files. With zip files you should measure the
overhead of unzipping by each worker process. (I'd love to see phatch
actions becoming as popular as firefox extensions, which are zipped
files AFAIK.) If there would be a website structure for that, it would
be probably wiser not to ship all actions but do like firefox.

>>> So I am open for new systems if it can do everything as the current
>>> system and better. In fact there are some parts where I consciously
>>> had to take a shortcut and I know there are better solutions. For
>>> example in action lists the english label fields are used as an ID.
>>> This is really bad as this means that if for example you correct a
>>> spelling mistake in a label it breaks a previous saved action list. So
>>> there is still a lot of place for improvement.
>>
>> Yeah. I fought with the name/ID issue as well. :)
Probably it is better to do this before a YAML transition.

>> There are at least
>> two ways how to handle this issue:
>> 1. provide optional id parameter to Field (ie. fields[_t('Value')] =
>> self.CharField('Phatch', id='value'). Then you can do value   =
>> self.get_field(id='value',info). If possible I would try to eliminate
>> the info parameter too.
>> 2. provide optional id parameter as in 1. and get value from self like
>> this: self.fields.value . So basically the system generates the wanted
>> attributes based on ids.
This is dangerous as when you insert a field between the others, the
values of saved action lists get mixed up. The goal for IDs should be
that previous action lists should handle nicely inserting/removing
fields (this happens now) and that it is immune for renaming fields
(this is not the case). So if fields are not explicit, you just
substitute one problem with another.
>>
>> 2. feels more natural to me. Of course the problem is that it pretty
>> much forces you to invent id should you want to refer to a field later
>> but is that such a bad thing? Besides explicit ids it might be
>> possible to use some rule (ie. order of fields) but I yet have to
>> figure out a reliable and nice way to do this.
No explicit ids are a good thing, see my previous comment. Right now
the fields are ordered dictionaries.

>>>> Note that everything needed by interface and get_relevant_field_labels
>>>> methods can be generated based on this. So if wanted, this system can
>>>> fit on top of the current one instead of replacing it. I think the
>>>> system would pretty much pay off for itself in more complex cases (ie.
>>>> hierarchies going past two level). Furthermore it could be used to
>>>> bring cohesion and consistency to the system.
>>>
>>> I'm afraid we need more power for the relevancy. (Check out Xforms.
>>> Inkscape is going to use that.) For example for the varborder action,
>>> I wanted to implement the opacity is only shown if the values for
>>> left, top, bottom and right are negative. How would you do that with
>>> YAML? I like a relevance method as it is dynamic and very flexible,
>>> while YAML looks static. The current proposal looks 'suboptimal' to
>>> me, but prove me wrong ;-)
>>>
>>
>> Okay. That's a good question. :) For me YAML is just pure, initial
>> structure of the whole. Basically you get nice, ~visual~
>> representation of the structure.
Hmmm... but field structures are so small. Most action have not more
than three fields. So there should be other benefits (see my comments
above), otherwise it just looks overkill to me. What I like less about
it, that it introduces another syntax, with its own syntax errors, and
thus more complexity. So for me the visual presentation is not so much
a selling point for me. If we would have actions with twenty or
hundreds of fields, I would agree with you. I never calculated the
average fields in action but it will be pretty low.

>> To determine extra logic you would have to attach a handler to element
>> and then check logic there. So basically that would be one extra line
>> to YAML definition (handler: my_awesome_opacity_toggler) and
>> implementation of the func in action. Obviously each of these handlers
>> would have to be invoked every time a value is altered (more
>> sophisticated system would be able to minimize the amount of calls but
>> even this would do the trick for time being).
When doing the get_relevant method, I first started with separate
relevant methods, but it just seemed overkill. In the corner cases
where we can't define the relevancy through YAML, I would stick to one
method, which means one call and which avoids other side effects like
circular references. Also the get_relevant method has the advantages
as you can alter values, which is nice for an action which uses the
presets (as is the purpose for the perspective action.) For now the
name was get_relevant but in fact in my mind it could be used for more
purposes, so maybe I should rename it to 'on_change' or
'on_interaction'.
Another very nice approach and out of the box solution is Traits:
http://code.enthought.com/projects/traits/, which has wxpython and
pyqt bindings: http://code.enthought.com/projects/traits_gui/ I was
doubting to use it, but as it is not a pure python depedency I
refrained from it. It basically does validation and interaction
between fields out of the box. Juho, if you don't know this module, I
think you would be very interested to explore it.

>>
>> So just to make it clear, YAML is just a starting point. You can do
>> all kind of fancy stuff with handlers hooked up with it. It should
>> scale more than well to the basic cases (most of actions are pretty
>> simple) and then some.
>>
>>>>
>>>> I suppose many actions have some sort of background color and opacity
>>>> defined in them. It would be possible to refer to generic properties
>>>> such as this in the structure itself. In this case you would subclass
>>>> ColorField and SliderField and end up with something like this:
>>>> BackgroundColor
>>>> BackgroundOpacity
>>>>
>>>> Of course sometimes you might want to this partially (ie. Opacity):
>>>> Opacity: # subclass of SliderField
>>>>   -name: just some opacity
>>>>   -value: 55 # i'm not happy with the default so let's set it to 55 :)
>>>>
>>>> Anyway those were some initial thoughts after two days of development.
>>>> It has been pretty easy to work with phatch so far. :)
>>>
>>> Well many features are implemented in a few hours or less, so you see:
>>> two days of development is already plenty enough to give feedback.
>>> Just take in account that besides features, the transition from Phatch
>>> 0.1 to 0.2 is also from an one person project to a multiple persons
>>> project. I feel still too much load on my shoulders, but with so much
>>> energy I hope that can diminish ;-)
>>>
>>> Probably for these kind discussions IRC is a better medium (#phatch on
>>> freenode). I'll be there monday.
>>>
>>
>> Okay. From my point of view as a scientist it would be interesting to
>> understand how the transition from one to many (cathedral to bazaar)
>> happens. More specifically what triggers it. Perhaps you can share
>> your experiences later. :)
The secret is: scout wonderful people for interesting posts on their
sites or blogs and attract them to your project.

The last lines of your post were very important and I'll give a separate answer.

Stani