Re: [Libreoffice-ux-advise] embedding palettes etc. ... #2 ...

Hi guys,

        First - thank you for your feedback, most helpful. Secondly,
sorry for the slow response - this whole code area is quite a serious
mess of vile cut/paste coding (amongst other things).

        So, here are some responses:

On Wed, 2011-09-14 at 22:11 +0200, Regina Henschel wrote:
>       I've recently been working on enabling embedding palettes / bitmaps /
> > gradients / etc. into ODF documents - and I've implemented import/export
> > for all of that [ only for impress currently ].
>
> Why only in impress?

        Well currently it is only impress+draw that allows saving
these settings anyway :-) that is a bug IMHO, and I'd love to fix it -
hopefully having re-factored the load/save code for this - it should
be easy to implement for all components.

>       I just pushed a change adding a check-box to allow the user to
> > configure this embedding to master (cf. attached screenshot "[X]
> > Embed").
>
> Will the user find the new feature?

        Probably not :-) but then - would they find it anyway ? 


> How does the user get the name of the embedded palette?

        It is unclear that a palette having a 'name' is a useful
concept, that is there in the code (interestingly) but I don't see it
in the UI. Of course, we have lots of (un-translated) names for colors
in the code, and in the palette but ... this is a different issue.

> Is the palette embedded in document templates too?

        Certainly - any ODF serialization from impress.

> Can the palette be transfered from one document to another?

        As you load and save the document it is transferred, otherwise
you need to save and re-load it in the other doc using the unpleasant
load/save buttons in each of those tabs :-)

> I like to see the dialogs for changing/loading/saving palettes
> completely separated from the property dialog of a single object.

        Agreed.

> >     * embedded palette, fill bitmap, hatch, line-dash etc.
..
> Having another information tab in the properties is OK for me.
> Seamonkey has such an information dialog for HTML-pages and I
> like it there.

        Fine.

> Embedding color or line palettes will not increase the file
> size too much, but embedding a bitmap palette will increase
> the file size quickly  with some MB

        That depends how large the palette is - the default one
is 152k, and presumably people won't want dozens of bitmaps to
fill areas with (at least, I hope not).

> So the question is, what default has the checkbox.

        The default would be to off; this is primarily a tool for
corporate template construction where they want to restrict the
palette people choose.

On Tue, 2011-09-13 at 21:54 +0200, Christoph Noack wrote:
> That brings up the question how many palettes (other objects)
> could be embedded. The checkbox seems to say "one".

        Right, so far the code has a simple list of colors, and doing
more is some work that I'd prefer to spend elsewhere :-) Indeed - it
seems (at first sniff) that the 'document theming' idea is done by
just having a well-known set of color names and using those uniformly
in templates - so potentially theming is possible if we get this
right.

> Just being curious: What happens if the user has a different palette
> on the system having a different set of colors?

        No problem, the colors of shapes are stored as real 'colors',
not as indexes into a palette (currently), so nothing particularly bad
happens - they would get the colors to choose from embedded in the
file, or from the system depending on that setting.

> Sure, but here each solution will sub-optimal, since we miss an easy
> way to separate "document" and "meta data". One thing that's really
> cool in Office 2010 is the backstage view doing that nicely ... at
> the moment, the File Properties dialog seems to fit best ...

        Great - this seems to be the consensus.

> ... although there is some relationship with "Links" in the Edit
> menu.  Resolving links magically "moves" the graphic files into the
> file.

        Oh - hmm, interesting. Of course, by default (these days) we
try to ensure that the default is to embed all the content that is
pasted / inserted into documents: since the alternative is just too
awful: of missing / lost data.

        Indeed - perhaps because of this - I can't seem to make
Edit->Links sensitive and/or useful - and it's function seems broken
to me. Should / could we remove that and/or whack it into the File ->
Properties dialog ?

> Maybe we should think about some kind of Object Inspector which would be
> helpful here, and would also be helpful for all kind of objects (even
> text formatting, if people try to understand strange behavior).

        Urk - sounds a bit advanced ;-) I'm just working towards
people being able to embed themes nice & easily ;-)

> Could be part of the colors work we've started (and postponed) a few
> weeks ago

        I missed that, pointers appreciated.

> Okay, could you please (if there is no quick solution) rename the
> checkbox to "Embed into document" (or something like that) and move it
> to the lower right?

        Can do, will take more vertical space, and some calculation (I
hate VCL's layout) but do-able.

On Wed, 2011-09-14 at 21:49 +0200, Astron wrote:
> Before making a suggestion, her are three questions:
> 1. What's the file size penalty for embedded palettes ?

        For palettes - almost nothing - perhaps 5k, clearly there are
lines, hatching etc.

> 2. Are there possible privacy concerns when embedding, e.g., patterns?

        Of course, you can encode whatever you like in whatever you like.

> 3. Does your addition embed the entire palette or does it make a diff
> against the default palette?

        The entire palette.

> If the answers go something like "typically 2 KB or less (depending on
> what the user adds)," "not really" and "a diff," then this would be my
> suggestion: embed it and don't add anything to the UI.

        Hmm - so I think a 'diff' for the case where people want to
replace the palette and enforce their set of colors (the use-case of
my corporate PR team) is likely to cause grief.

> We should aim for maximum document fidelity and if a document has the
> wrong colours on a different LibO installation, that doesn't really
> help.

        Oh ! so, this is not the colors in the document, it is only
the choice of colors that the user is presented with to choose
from. Now - of course, when we come to theming the answers may change,
and we'll need to embed any referenced colors unconditionally (as you
say).

> > >       * embedded media files [ I'll try to dig into this next ;-]
>
> Shouldn't that work already? (The last time I tried there was a bug
> where video clips would only play if they weren't embedded into the
> document, nevertheless you could embed them.)

        What does the UI look like for that, at least I couldn't see
how to do this.

> As a makeshift measure, maybe you could add a checkbox ("Embed
> palette into current document") to "Options > LibreOffice > Colors."

        The problem with that is that this is as Christoph says:

On Sat, 2011-09-24 at 16:05 +0200, Christoph Noack wrote:
>       * Options > LibreOffice > Colors doesn't allow loading / saving of
>         palettes, so embedding it from here might make less sense.
>       * This options page is only available for colors - Michael talked
>         about gradients / hatches / ...
..
> Still, no easy solution, only:
>       * extending the Document Preferences dialog
>       * extending the Edit - Links... dialog
>       * create something new

        So - thanks for the input.

        For now, I'm just going to follow the consensus of:

        + rename the setting "Embed into document"

        And, noting the consensus for a future direction of:

        + File properties - the best place for this stuff ...
        + add the "Resolve Links" functionality there

        I'd like to drop "Resolve Links" from the Edit menu as/when
that is done.

        How does that sound ?

        Thanks,

                Michael.

-- 
michael.meeks@suse.com  <><, Pseudo Engineer, itinerant idiot