Preferences and tree layout
lilmatt
jminta asked me to post my thoughts about sharing preference UI between
Lightning and Sunbird to the newsgroup to gather more feedback. This
also brings up a question regarding where these files should live in
the tree.
First, here's my "grand plan" for preferences:
For sanity, I'm suggesting we reuse Sunbird's preference UI wherever
possible and practical in Lightning. Doing so leverages the work
already done on those preferences, and gives a user moving between
Sunbird and Lightning familiarity. We could initially use Categories,
Alarms, Views, and Timezones as they are. Rather than adding a bunch
more prefwindows to Thunderbird's preferences, I suggest we limit
ourselves to one inserted prefwindow, labeled "Calendar". We then use
tabs (like the Advanced pane currently does) and place each shared
prefwindow from Sunbird in a tab in Lightning.
To implement this, we would pull most of the XUL out of each shared
.xul file, and put it in an .inc file. The .js could likely be used as
is. Then lightning-preferences.xul would #include all those .inc files,
and Sunbird's .xul files would each #include the appropriate.inc file
as well.
Now we get to the fun part about tree layout. Note that /m/c/ is
shorthand for /mozilla/calendar
Currently, ALL of Sunbird's preferences (including those that won't be
shared by Lightning because Thunderbird already has them [ex:
about:config]) live in /m/c/base/content/preferences. The fact that
some Sunbird-only prefs made it inside /m/c/base is my fault. I opened
a bug to move the Sunbird-only stuff inside
/m/c/sunbird/base/content/preferences and made a patch, but jminta
wanted to truly figure out where the Sunbird-only stuff should live
before moving them yet again.
There are two camps:
1. Keep stuff in /m/c/base/content/preferences and package it
appropriately using jar.mn. Sunbird-only stuff goes into sunbird.jar so
Lightning's download size doesn't balloon. Everything's in one place,
but you need to look at (and understand) jar.mn to see what files are
packaged with which front-end.
2. Keep /m/c/base pristine and move the Sunbird-only stuff to
/m/c/sunbird/base/content/preferences. This means we'll have .xul files
in /m/c/sunbird/base/content/preferences that #include files in
/m/c/base/content/preferences. Do we care? I'm not sure.
Perhaps there's a third that I haven't even thought of.
Please submit your opinions on both the preference sharing strategy,
and which tree layout option you prefer (and why).
I like the pref sharing (which is good, 'cause I thought of it), and I
prefer tree layout #1. I think using jar.mn to package stuff into
separate jars (and only if necessary) is easy enough to deal with. A
similar scenario could be applied to the themes directories in the
future. If people _really_ wanted to keep /m/c/base pristine, we could
also move preferences out to be a top level directory, like
import-export.
Note that I'd like to make a decision on this fairly soon, perhaps as
early as this week's phone meeting if enough people have weighed in, as
improving Lightning's preferences by using Sunbird's would be a big win
for 0.3.
Let the opinions flow...
-lilmatt
Justin Wood (Callek)
[[...]]
> -lilmatt
>
Having touched and thought about nearly no current calendar code; I'd be
much more apt to comprehend Tree Layout #1 if I was to try and delve
into developing for calendar.
I do like the basic concept with .inc files; though I'm not sure if
overlays (and using chrome.manifest for where you should overlay in
what) would be better. I tend to dislike .inc's, mainly because it
makes line-comparisons very hard if the error console starts spewing
stuff, ever.
~Justin Wood (Callek)
Michiel van Leeuwen
> Note that I'd like to make a decision on this fairly soon, perhaps as
> early as this week's phone meeting if enough people have weighed in, as
> improving Lightning's preferences by using Sunbird's would be a big win
> for 0.3.
I don't think that this should be a reason to target something for 0.3.
I can think of a lot of things that would be a big win for 0.3, but we
can't get it all...
Michiel
lilmatt
> To implement this, we would pull most of the XUL out of each shared
> .xul file, and put it in an .inc file. The .js could likely be used as
> is. Then lightning-preferences.xul would #include all those .inc files,
> and Sunbird's .xul files would each #include the appropriate.inc file
> as well.
Per the phone status meeting, substitute "XUL Overlay" for include
files in the above.
Same idea, but better implementation.
Stefan Sitter
About the tree layout: I'd prefer to keep everything together,
especially if it is shared between Sunbird and Lightning. This makes
it easier to find stuff if your are working on it. If preference
related code is spread about three different subfolders of mozilla/
it's hard to find your way through it.
/Stefan