|
|
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. |
|
|
I can reproduce, see screenshot edit: I kind of like the fonts being bolded in the menu though. |
|
|
bolded-styles-menu.png (104,609 bytes) |
|
|
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. |
|
|
Oh, I see. I wonder if there is a more explicit way the user can understand this intention ? |
|
|
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). |
|
|
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. |
|
|
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 |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
As for me, bold is ok too... |
|
|
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 |
- Anonymous
