On Wed, 2010-11-10 at 11:39 -0500, Matthew Barnes wrote: > Here's a few built-in top-level stub sources as trivial examples. They > don't do anything other than name a backend. They would appear as bold > group names in a source selector widget. > > 1. Filename/UID: "on-this-computer" > > [source] > name='On This Computer' > backend='local' > > .... > The built-in "system" (a.k.a. Personal) source is an interesting corner > case because it defines several different groups. (The comments below > are just my annotations, they would not appear in the key file.) > > Filename/UID: system > > [source] # org.gnome.Evolution.Source > name='Personal' > parent='on-this-computer' > > [extensions/address-book] # org.gnome.Evolution.Source.Selectable > color='#000000' # would not be used in the UI > enabled=true # would not be used in the UI > > [extensions/calendar] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=true > > [extensions/task-list] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=false > > [extensions/memo-list] # org.gnome.Evolution.Source.Selectable > color='#becedd' > enabled=false
Hi, it's pretty confusing to me. I understand from the above that there are two files, one for groups, which is stored in system directory, and "one" for real sources, which is stored in user's home. Will be there any kind of property inheritance? As in your example above, I would like to define the 'color' in the [source] key-file-group, thus all extensions will inherit it, but, if user changes color for one of them, then it'll create its own key and it will be used instead of the parent's. Maybe it's not the best example with the color, but imagine the Exchange account, I would like to define server address and credentials, connection setup and such, in the parent, and the children (mail/calendar/...) will inherit this. It seems to me that there is no difference between the file in system and home directory, both are using [source], but each for a different purpose. I do not think it may work well. Imagine the exchange account again. Right now you define an account name, and this name is used as a source group name in Calendar and such, same as in mailer. With that you wrote I do not see a way of achieve that just from the user's home. Or is this based on the existence of the parent/backend key in the [source] key-file-group? In that case the exchange account will have actually two files instead of one in the home directory, one for group definition and one for real sources? It's unnecessary, right? a) you would search for parents, in home and in system directory. b) you should be able to easily distinguish between group definitions and real sources definitions (all are named [source] in your proposal) and be able to _easily_ reconstruct them. Well, it's not straightforward, from my point of view. I would rather name groups [group], avoid confusion, and be able to define all this in one file, thus for usual user they will be able to distribute only one file with predefined account settings instead of many. Of course, the groups should either have the 'uid' defined in the file, or it should "inherit" uid from the file name itself. Filename: excha...@my-company [group] name='excha...@my-company' backend='exchange' server='my-company' username='me' [source] color='#FEFEEF' parent='excha...@my-company' [extensions/mail] enabled=true [extensions/addressbook] fragment='personal/Contacts' name='Contacts' [extensions/addressbook] fragment='personal/second-contacts' name='second-contacts' [extensions/calendar] fragment='personal/Calendar' name='Calendar' last-notified='2010-10-10T10:10:10' [extensions/calendar] fragment='personal/second-calendar' name='Second Calendar' color='#80FF80' ... Well, you cannot have two groups with the same name in the key file, thus you really meant to have one file per each ESource/EAccount + one file for the group definition, all these put into one folder in the home (+ system group definitions in system folder)? I do not like the idea much, but I agree it can work. Also, remember that users can name their accounts whatever they want, but not every latter is usable for the filename - so the files will be either meaningless strings or something descriptive? The last two questions (and I see I mostly answered above questions myself), how will be the group definition propagated to mailer, respectively how will be defined the POP account, which doesn't have a group in the folder tree, same as the mbox, which is hacked in and hidden in the background? Will these two kinds also require its own group file (for the 'backend' key) or not? Because you have [source] for groups and [source] for pseudo-sources (the real source is at the [extension/...]), then will I be able to define a child of the source, not of the group, and it'll be propagated to the UI? Just an idea, not that I think it would be usable. Bye, (slightly confused) Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers