No subject

>  > 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.