kubuntu slideshow

Roman Shtylman shtylman at gmail.com
Tue Sep 15 11:34:35 BST 2009


I did indeed forget to push :) But have done that now.

So what should I aim to fix before the package can be merged? Or are
we really a bit late in the cycle? Can the merge happen and then
re-org afterwards? or should the re-org happen before the merge?

~Roman

On Tue, Sep 15, 2009 at 1:05 AM, Dylan McCall <dylanmccall at gmail.com> wrote:
>> Thanks for making those changes.
>>
>> I am not keen on the approach of maintaining copies under kubuntu/ of
>> only a slightly modified part of the javascript library, the rest of
>> it completely unmodified, and some of the slides.  If we make the
>> smallest of changes, we have to make them in two places, and my
>> experience with oem-config and ubiquity leads me to believe that we'll
>> often forget.  Can you not refactor this so the modification is
>> layered on top of the common code, and that shared pages are generated
>> in both build directories at build time?
>
> 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.
>
> 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 :)
>
>>
>> You're missing a copyright notice for the Kubuntu logo.
> Roman, did you forget to push that? I only see the two revisions from
> the merge request that was made a while ago.
>
>>
>> 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.
>
>
>
> Thanks,
> Dylan
>



More information about the Ubuntu-installer mailing list