Re: [Libreoffice-ux-advise] to duplicate an existing style

Hi everyone,

Needless to say, I didn't want to send the last mail the way I did.
Sorry. Sometimes I am not the master of my hands (or my keyboard), it
seems.

> > > > >  Could it be a good idea to just copy Scribus's behaviour [1]? It gives
> > > > >  you buttons for
> > > > >  [New]     [Clone]
> > > > >  [Import]  [Delete]
> > > > >  where "New" always creates a new empty style (that is, a copy of the
> > > > >  default style)  and "Clone" creates a copy of the currently selected
> > > > >  style (btw, I like "Duplicate", as initially proposed by Olivier, much
> > > > >  better as a name for the button). Inheritances can then be defined
> > > > >  later on.

From Regina's mail:
> > > You need inheritance from the beginning to fill the fields with the
> > > inherited values. That there is no visual distinction between inherited
> > > and set values is a different problem.
>
> I am not sure I get this completely, Regina.
> # I think it would be quite possible to just copy the entire default
> style when using [New]. Also, of course, every style created via [New]
> would then inherit from the default style I suppose, every style has
> to depend on something).
> # Every style created with [Duplicate] (or [Clone]) would inherit from
> the same style the original style inherited from.


From Rafael's mail (and my answer to it):
>  > I believe Astron's own proposal on the Paragraph Style window addresses this
> > in an elegant way
>
> Sure, it solves a few problems and extending the list box with eg grey
> text for inherited definitions might be an okay visualisation...

I am actually not so sure my idea with the grey text is realistic any
more, because in the case of a dependency on the default style that
would probably be a mass of definitions. Maybe expandable separators
between those areas would help.


> Yet, the problem for most people is that they have never extensively
> worked with styles and might not understand intricacies like
> inheritances. I think most people don't have any understanding of
> technologies like CSS etc.,

I am not sure knowledge of CSS basics is necessary but I am pretty
sure it helps.
Btw, I would be incredibly glad if any would want to work on my
Organiser tab redesign :) (and I am willing to assist of course).


Regina again:
> > > I would like to get the linking feature to the page style too, so that
> > > e.g. changing the margin in the parent style will also change the margin
> > > in the child style. Often there are only little differences between
> > > parent and child.

Agree.


> > > You can it see the other way round too. Cloning is first "new with
> > > inheritance" and then "breaking the link".
> > >
> > > For inexperienced users, both cloning and linking should be shown, so
> > > that he has the chance to learn, that there is a feature "linking".
> >
> > +1. I am up for easing the general comprehension of the way styles work.

I see what you mean and I think I agree. Both features should exist,
but they must be named clearly. But I think the emphasis should be put
on making "duplicating" easy/more visible.


> > > Those inexperienced users will not use styles, far less create own styles.

Yes, but it should be our aim to make it easy to create good-looking
documents with LibO and while you don't need styles for that, they
certainly help create consistency. This is why we should also target
inexperienced users.

> So we have the possible behaviors
> (1) Generate a totally new, independent style
>       The question is, from where it gets its settings. I see extreme ways
>       (a) Use only default settings, nothing in organizer
>       (z) Use an existing style and set all properties as own settings in the new style. Very 
> full organizer.
>       Perhaps something in between
>       (m) Copy those settings from an existing style, that are not equal to defaults.
> (2) Generate a child style, which has no own settings in the beginning

Okay, I'll try to specify this now:
[New]
# inherit from "default style" (user can change this later)
# no new definitions (empty organiser, except for, as proposed above,
the separators indicating inherited definitions)

[Duplicate]
# inherit from the same style the original style inherited from
# copy all definitions from the original style


Regards,

Astron.