View Issue Details

IDProjectCategoryView StatusLast Update
0013634ScribusUser Interfacepublic2016-01-13 23:34
Reporterchristoph_s Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx86_64OSOpenSUSE 64 BitOS Version13.1
Product Version1.5.1svn 
Summary0013634: Bold fonts in the Style Manager
DescriptionThe SM displays some options in bold by default, and even more when a document with styles has been imported.
Steps To Reproduce1) Create a new doc.

2) Open SM; line spacing is in bold.

Now import any text document that uses styles (e.g. from 0009080) and open the SM. There are even more options displayed in bold.
TagsNo tags attached.
PatchNo

Activities

jghali

2016-01-08 13:09

administrator   ~0038033

Unable to reproduce 2). The rest is expected. In SM, the bold font indicates attributes which are explicitly set while normal font indicates an attribute which is inherited either from a custom style or from default style.

Kunda

2016-01-08 14:36

updater   ~0038038

Last edited: 2016-01-08 14:38

I can reproduce, see screenshot

edit:
I kind of like the fonts being bolded in the menu though.

Kunda

2016-01-08 14:37

updater  

bolded-styles-menu.png (104,609 bytes)   
bolded-styles-menu.png (104,609 bytes)   

jghali

2016-01-08 15:29

administrator   ~0038040

Last edited: 2016-01-08 15:34

The screenshot shows only expected behavior. As mentionned the bold font indicates attributes which are explicitly set and not herited from parent or default style.

Kunda

2016-01-08 17:09

updater   ~0038043

Oh, I see. I wonder if there is a more explicit way the user can understand this intention ?

christoph_s

2016-01-09 07:22

administrator   ~0038050

Jean, this seems to me a typical developer attitude, i.e., the attitude of someone who likes to see the inner workings of a programme reflected in the UI.

There are so many options in the SM by now that it's impossible for a regular user to discern which options have been imported (apart from the fact that users may be completely unaware of any options selected by the creator of a particular file, as well as the programme's default settings).

Moreover, the SM is already incredibly crowded, and the use of a bold font requires further enlargement of the dialogue, especially in Finnish, German and Hungarian with their notoriously long words.

Next, it is totally incongruent with *any* other UI element. A newly created colour isn't listed in bold in a colour selector, and neither are imported colours or fills from vector files, so it's, again, only expected from a developer perspective, not from a general user's perspective.

Finally, at least on Linux it looks like shit (sorry).

jghali

2016-01-09 12:55

administrator   ~0038051

Sorry Christoph_s, but style inheritance is certainly not a developer thing. What you propose is removing a functionality which make it easier to work with those. So unless what you propose allow to replace effectively the current functionality, there is not chance that we will implement the proposed change.

>> Next, it is totally incongruent with *any* other UI element.

Not an acceptable argument unless what you propose effectively replace the existing functionality.

Kunda

2016-01-13 18:59

updater   ~0038126

Well then, lets invite conversation around a different creative way to discern which styles have been imported and the styles that already existed. Please add your ideas to this thread

jghali

2016-01-13 19:12

administrator   ~0038133

The problem here is not to to discern which styles have been imported and which the styles already existed. The problem is to make differentiate which style *attributes* have been explicitly set in a style and which attributes are inherited from parent style.

JLuc

2016-01-13 21:16

developer   ~0038134

BTW there is another way to discern inputs : the *

This * way is the way some other apps do.
Scribus also does sometime : when a document has been edited, its filename appears with a * in the menu bar, meaning it has been localy changed and it's different of the recorded named file.

BTW : Some way should be used in the property palette so as to show which styling attributes have been localy overloaded and differ of the named style used. * seems a better candidate for this than bold.

jghali

2016-01-13 22:19

administrator   ~0038137

The * is not a solution *at all*:
- will need bigger widgets when we need smaller ones
- will add visual clutter to the interface whereas we need less.

JLuc

2016-01-13 22:43

developer   ~0038138

As for me, bold is ok too...

Kunda

2016-01-13 23:34

updater   ~0038139

idea: how about changing the font color (red?) instead of bolding the text. I'm reminded what christoph said about how bolded text "further enlargement of the dialogue, especially in Finnish, German and Hungarian with their notoriously long words."
We can make a notation at the bottom of the preference window explaining what the colored text is

Issue History

Date Modified Username Field Change
2016-01-08 06:49 christoph_s New Issue
2016-01-08 06:49 christoph_s Status new => assigned
2016-01-08 06:49 christoph_s Assigned To => fschmid
2016-01-08 08:50 fschmid Assigned To fschmid =>
2016-01-08 08:51 fschmid Status assigned => new
2016-01-08 10:57 Kunda Steps to Reproduce Updated
2016-01-08 13:09 jghali Note Added: 0038033
2016-01-08 14:36 Kunda Note Added: 0038038
2016-01-08 14:37 Kunda File Added: bolded-styles-menu.png
2016-01-08 14:38 Kunda Note Edited: 0038038
2016-01-08 15:29 jghali Note Added: 0038040
2016-01-08 15:30 jghali Note Edited: 0038040
2016-01-08 15:34 jghali Note Edited: 0038040
2016-01-08 17:09 Kunda Note Added: 0038043
2016-01-09 07:22 christoph_s Note Added: 0038050
2016-01-09 12:55 jghali Note Added: 0038051
2016-01-13 18:59 Kunda Note Added: 0038126
2016-01-13 19:12 jghali Note Added: 0038133
2016-01-13 21:16 JLuc Note Added: 0038134
2016-01-13 22:19 jghali Note Added: 0038137
2016-01-13 22:43 JLuc Note Added: 0038138
2016-01-13 23:34 Kunda Note Added: 0038139