ubiquity-slideshow team mailing list archive

[Evan Dandrea <evand@xxxxxxxxxx>]

On Tue, Sep 15, 2009 at 6:05 AM, Dylan McCall <dylanmccall@xxxxxxxxx> wrote:
> I'm concerned about this, too, staring at the branch again. It's
> definitely a useful effort, but I think, right now, it feels like a
> jumble in places. (And don't take that the wrong way; most of the
> jumbliness is my own doing). On the one hand I can see the benefit of
> having a shared source package, but on the other it's stretching in a
> way that may be really tough to maintain.
>
> By refactoring it, we would probably kill the ability to preview a slide
> without building anything, (so a "make test" command would be nice).
> "slides/link" can go up a level, then a different slides directory can
> exist for each variation and that can be duplicated without messing up
> anything else. The build script could pick through them automatically,
> instead of having a duplicate target for each one.

make; sensible-browser build/slides/index.html; make clean, no?

> We could bump into issues with different look & feel being pursued for
> each distribution. If each variation of the slideshow shares resources
> such as the icon decorating gimp-fu script, we'll end up with either one
> script that has multiple options within (and a general.css with 4
> different versions of "#container") or each variation containing its own
> slightly (but not quite) duplicate variety of each script, for example
> to sharpen the reflections on icons.
> However, if look & feel isn't going to be a concern and all that will
> change ever is content, then this can be pretty easy.
>
> ...Which, to be honest, lands me back at a thought: /why not/ just
> maintain a distinct branch / project for the kubuntu / xubuntu / etc.
> versions? I suspect there is some history here that I am missing which
> explains away this doubt of mine, though. I often put too much trust in
> fancy gadgets :)

My concern is that we'll forget to copy fixes from one branch to the
other.  I take this from my experience with ubiquity and oem-config
(as mentioned), which used to be separate source packages that shared
a lot of common code and a lot of bugs that tended to get fixed in one
or the other.

Now, assuming that the slides end up diverging completely -- Kubuntu
mentions KOffice instead of OpenOffice, the Kubuntu translation team
instead of the Ubuntu one, and so on -- we're left with a duplicate
build infrastructure that's arguably more complicated than it needs to
be to support two projects building from the same tree, and the
javascript and navigation libraries, both of which I would hope are
fairly static (but again, any small change could bite us).

Ultimately, I'm not overly concerned with which approach we take,
provided that the communities that will be working on these packages
are happy with it.  So I suppose I defer to Roman to see if he'd
prefer to keep this in ubiquity-slideshow-ubuntu trunk, and Dylan to
approve it, given that he has concerns about how well this will
integrate.  Of course, I'd also like to give it one more further
review before we upload.

If we do go the route of separate packages, I apologize profusely for
previously pushing for the Kubuntu slides to be integrated into the
existing tree unnecessarily.

>> Also, I would argue that we shouldn't keep the UI files in this
>> package.  It should simply be content viewable in a browser, not a
>> special widget.  Leave the task of creating a UI to ubiquity.
> Those are for the preview script, I think. In my own branch of the
> branch I moved them to a "test" directory to get things better
> organized.

Ah, my mistake.