[Keine Änderung] what is the point? i want to see the values -> always!

[StefanGold]

Again such nonsense! Of course, I would ALWAYS like to see the values

[MikeTO]

If No Change was removed to make it work more like MS Word and some other apps, there would be no way to know if an attribute was defined for this style or inherited from another style.

But I agree with why you want this - sometimes you're editing a style inherited from another and you just can't remember what that other style's definition is. So you have to click OK, edit the other style, cancel, and edit this style again.

Perhaps the Style Settings summary's inherited style name (Heading 1 in this screenshot) could display a popup definition of its attributes if clicked or moused over. I'd find that very useful.

[StefanGold]

I changed the values a few hours ago and want to know what i have changes.... and the summarys did not show the word spaces

[walt.farrell]

8 minutes ago, StefanGold said:

I changed the values a few hours ago and want to know what i have changes.... and the summarys did not show the word spaces

If you changed the values in that text style, they should show when you edit that same text style again.

The "no change" usually applies to values inherited from some other text style, not the one you're looking at. 

So, what style did you change, and what one are you looking at?

[MikeTO]

11 minutes ago, StefanGold said:

I changed the values a few hours ago and want to know what i have changes.... and the summarys did not show the word spaces

Either I'm misunderstanding you or you're misunderstanding what "Keine Änderung" means. It doesn't mean that you haven't changed this field, it means this style has no changes from the style it is based on. If it's not based on a style, it means that the value has not been set.

I think that "No changes" might have been better named "Undefined".

[StefanGold]

Maybe that's what it means.

However, i want to see the values and there are many reasons for that.

I just do not know how you can get this idea not to display them. That makes no sense to me at all ... like many other "things" in V2

[walt.farrell]

11 minutes ago, StefanGold said:

like many other "things" in V2

V1 was the same in this area.

[walt.farrell]

12 minutes ago, StefanGold said:

However, i want to see the values and there are many reasons for that.

As I said, if you changed the values (as you said you did) then you would see the values there when you look again.

But you are not the only user to have expressed the wish to know the actual value when it is unchanged and inherited from a parent style. 

It's just already there for the first situation you described.

[Oufti]

36 minutes ago, MikeTO said:

"Keine Änderung" means […] this style has no changes from the style it is based on. If it's not based on a style, it means that the value has not been set.

24 minutes ago, StefanGold said:

Maybe that's what it means.

Certainly, it is. 

• "Where [no change] is shown, an attribute remains unchanged from the Based on style."
• "Wird [Keine Änderung] angezeigt, ist das Attribut unverändert aus dem in Basiert auffestgelegten Stil übernommen."

https://affinity.help/publisher2/de.lproj/index.html?page=pages/Text/textStyles_create.html?title=Erstellen und Verwalten von Textstilen

 

 

7 minutes ago, walt.farrell said:

24 minutes ago, StefanGold said:

However, i want to see the values and there are many reasons for that.

you are not the only user to have expressed the wish to know the actual value when it is unchanged and inherited from a parent style. 

What I would find very useful is a purely informative field aside the popup, appearing when a popup menu is set to [No change] and indicating the actual value (as set in the base style used) — probably presented between brackets, for clarity.

[Old Bruce]

We can see the "actual" values if we use the Character and Paragraph panels and select the desired Text Style.

Having said that I too would like some sort of indication of the values but I do also realize that for some things like Decorations or Drop Caps this could be perhaps confusing in implementation. Text colours could also be massively weird looking.

[Barry Newman]

This is not a great solution, @StefanGold is absolutely right. I have seen other programs do it the wrong way as well. Companies and developers display in some obscure way that inheritance may or may not be involved, and the actual information presented to the user is hard to understand.

I would like to look at some best practices from larger companies that have done it well and where you could say the method is close to a de facto standard, if not the standard.

After my morning coffee has seeped into my brain.

[Oufti]

1 hour ago, Old Bruce said:

[…] for some things like Decorations or Drop Caps this could be perhaps confusing in implementation. Text colours could also be massively weird looking.

In the recapitulative window at the bottom of the Edit style dialog or at the top of the Styles panel, a textual description is given.

It could be the same, parameter per parameter. 

E.g. (Drop caps in bold)

Police: Arial; Épaisseur de police: Normal; Italique: Désactivé; Largeur de police: Normal; Corps de police: 12 pt; […]
Lettrine: Actif; Hauteur de lettrine: 3; Caractères de lettrine: 1; Caractères auto de lettrine: Actif; Alignement gauche de lettrine: Inactif; Descendants de lettrine: Inactif; Distance de texte de lettrine: 0 pt; Style de lettrine: ""; Mots initiaux: Inactif; Nb de mots initiaux: 3; Caractère de fin des mots initiaux: .?!:; Style des mots initiaux: ""

But, yes, for Decorations, it is not very explicit… 

Taquets de tabulation: Aucun; Décorations de paragraphe; Liste: aucune

[MikeTO]

21 minutes ago, Barry Newman said:

I would like to look at some best practices from larger companies that have done it well and where you could say the method is close to a de facto standard, if not the standard.

No app does this perfectly because there is no perfect solution and the de facto standard is not to allow for 'undefined' (known as No Changes in Publisher). Most apps don't show you what a style inherited versus what you've defined separately in this style. If you change something in the parent style in an app without this concept it always changes the styles that inherit from it.

IIRC, if Style 1 is Bold and Style 2, which inherits from Style 1, is Bold, changing Style 1 to Regular will also change Style 2 to Regular in apps such as ID and Quark.

In Publisher, if Style 2 is No Change then changing Style 1 to Regular would have the same effect but if Style 2 was set to Bold then changing Style 1 would have no effect. IMO, the way ID and Quark do it is simpler but they don't give us the choices that Publisher does.

Some apps do it even worse. In MS Word, if Style 1 is Regular and Style 2 is Bold then change Style 1 from Regular to Bold will change Style 2 from Bold to Regular - Word just  inverts the setting.

At first glance the easy solution is to show both - show the value that has been inherited (Regular) vs. what has been set in the style (Bold). For controls such as lists it would be easy, square brackets could indicate that it's an inherited value [Regular] while no brackets, Regular, could indicate it has been set locally. This approach wouldn't work for simple controls such as checkboxes and colour wells. And it would be a mess for complex panes such as Decorations.

This is why I suggested adding a summary of the inherited style's attributes. This would at least let you see the combined effect of Style 1 and Style 2. I realize that there's a real-time preview, but if you can't remember if Style 1 has tracking set to 35 or 40% a summary would inform you.

[fde101]

I probably would have worded it "Inherited (value)" where value is the value that is currently being inherited.