[scribus-dev] Who is going to kill the style dialog ? Urban renewal
christoph-schaefer at gmx.de
Thu Nov 11 00:43:52 CET 2010
On Wednesday 10 November 2010 18:06:12 Gregory Pittman wrote:
> On 11/10/2010 09:55 AM, dbolack at electricmulch.com wrote:
> >>> The values are always visible and accessible. They are in the
> >>> Properties Palette. The one issue to solve here is to put in the PP
> >>> all the settings that are only available into the actual Style
> >>> Manager.
> > I'm that wacky class of user who finds those side palettes distracting
> > and wasteful of screen real estate.
> GUI DESIGN AS URBAN PLANNING
> The PP has already become an overcrowded ghetto of functions that may
> have seemed like a good idea at the time, but have created a succession
> of cramming of information and choices into a dialog which would
> realistically need to crowd out the document display to easily show
> everything in it.
> The answer is to find the philosophical approach that can serve as some
> sort of urban renewal, finding a new home for squatters on this precious
> real estate. At this point, if you're going to live in the PP, you have
> to justify your existence, either in terms of importance or kind of task
> you perform. I would propose that anything which is a simple toggle, a
> yes/no, check/uncheck, is a prime candidate for eviction to some other
> place, maybe a Context menu. (this brings up an interesting possibility
> of a Context Menu coming out of right-clicking the PP)
> Only after some ground has been cleared, the remaining bits reorganized,
> are we in a position to putting more things in there, but even they
> would have to abide by the new paradigm.
> The weakest argument for keeping something in the PP is that "it's been
> there since version 0.x". In software development, the only constant is
The comparison to urban planning is probably appropriate, and urban renewal
can sometimes be achieved by adopting what works elsewhere.
Since the original posting was about the Style Manager and the future of this
beast, I'd like to focus on this one, while the PP is currently being
When it comes to styles, there are probably three major aspects that have to
be dealt with: editing, managing and applying them. In the future we may also
have to consider whether a style can be a "shared resource" (Jon Cruz is also
tinkering with this aspect in his work on Viaduct, and RagTime 6.5 recently
introduced something like that: http://www.ragtime.de/img/art_tmb/308_1.jpg),
but let's focus on the three obvious challenges.
To see how styles have been implemented elsewhere, I looked at several DTP
programs and word/document processors: AbiWord, KWord, OpenOffice.org Writer,
LyX, RagTime, QuarkXPress, and InDesign.
As it seems, there isn't much variety in style implementation (at least from
the perspective of user interaction), and the details are only minor. The
major differences can be found in style management. AbiWord, XPress and
InDesign (and currently Scribus) use a free-floating dialog that lists all
available styles and also enables access to style editing. Except for Scribus,
all open a new dialog for style editing, whereas Scribus expands the Style
Manager (sigh!). The fact that Scribus also allows for applying a style is,
unfortunately, no advantage, as it is opaque and clumsy. As already mentioned,
RagTime lists styles in a resource window, from which they can be accessed.
LyX works similar to LaTeX, so the word "style" has a semantic definition and
is dependent (among other things) on a document class -- nothing we could or
should consider in a genuine DTP program. KWord and OO.o use a dialog that's
dockable or docked to the right of the application window. This is an
approach, which is familiar to users of programs like CorelDraw, sK1 or
(partially) Inkscape, and its biggest advantage, at least in my opinion, that
styles and other relevant resources or options are readily available without
interfering with the view of the document, while free floating dialogs always
hide parts of the layout, so, personally, I think that's the path to follow.
Both KWord and OO.o can also display style hierarchies, and OO.o has even more
viewing options, although its mix of viewing options and sorting doesn't
convince me. Both are also lacking a filter that allows to search for styles
In general, I consider the OO.o style management to be the sanest (disclaimer:
I always preferred StarOffice over MS Office even back in the days when it was
proprietary software because of its transparent and superb style management).
For those who are unfamiliar with the use of styles in OO.o, here's a short
description: The dockable style manager ("Stylist") consists of 3 parts: an
icon bar at the top, a list field that lists all available styles and drop-
down list at the bottom that offers sorting/viewing options.
The icon bar is split into 2 parts: five icons for each supported kind of
style (paragraph, character, frame, page and lists). To the right there are
two icons for "quick actions": the infamous "bucket" icon that allows for
quick formatting of text, a feature that regularly drives users of word
processors mad, and another one that provides a feature, which has been
(rightfully) asked for by Louis: creating a style from direct formatting.
While it should be obvious that the details (e.g. the kinds of styles
available for selection) would have to be different in Scribus, the general
approach is transparent and clearly arranged.
The same is true for the style list: Double-clicking on a style will apply it.
A right click on a style offers two or three options, depending on the kind of
style: Default styles that are part of OO.o can be modified, and it's also
possible to create a new style based on the default style. Custom styles can
be deleted (the third option). Again, it's obvious that the concept can't be
copied 1:1 for Scribus. E.g., there's no reason to have a long list of default
styles, and the only styles protected from inadvertent deletion should be the
ones created during document creation. On the other hand, it should be
possible to easily assign a shortcut, something also requested by Louis
(assigning keyboard shortcuts should be part of the "management" aspect of
styles, in my opinion).
As for the sort/view choices, I already mentioned some of its shortcomings
above. Let me add that many of OO.o's sorting options are probably superfluous
in a DTP program, as they are based on typical automated word processing
functions that remove the flexibility required in DTP.
What about editing styles? Now, if the 3 tabs we have in Scribus now are
considered to be too much, there's even more to hate in OO.o. Here's a list of
tabs available in OO.o Writer:
1. Paragraph Styles:
- Organizer (style name, next style, parent style, category -- all very
- Indents and spacing
- Text flow
- Font effects
- Position (i.e. subscript/superscript settings, rotation, scaling and
- Outline and numbering
- Drop caps
- Condition (options for condtional styles)
2. Character Styles (provides a subset of paragraph styles):
Organizer, Font, Font effects, Position, Background
- Type (i.e. dimensions, the other settings are or should be irrelevant for a
- Options (editable: yes/no, printable: yes/no, text direction)
- Flow (i.e. types of text flow around the frame)
- Numbering style
(the three options listed above are actually three different ways to apply
different bullet/numbering options)
As is obvious, not all of these options are applicable to Scribus. Some have
been on the wish list for a long time, others may be appropriate in a word
processor, but should be avoided in a DTP program. There are also other
desirable options that would be wonderful to have in Scribus, e.g. kerning
pairs as in XPress or nested styles as in InDesign. What's also obvious (at
least to me) is that not all options require a separate tab.
While the number of options and the number of tabs will depend on the features
available in Scribus, as well as the space required for the design, including
consideration of Qt limitations or portability across platforms, one thing
that all dialogs listed above have in common is the "Organizer" tab. Since the
options in this tab are directly related to style management, it should be
considered to implement something similar in Scribus.
As for the layout of the style dialogs in OO.o, I think it shouldn't be
considered an example at all. There are so many tabs that they don't even fit
into one row and need to be stacked. As a consequence, the order of tabs
changes depending on the selected tab. This more than confusing. An
application that probably did it right is InDesign, as it uses a layout
similar to our current Document Setup/Preferences, i.e. a dialog with two
distinct parts, namely a column with categories to the left (but implemented
as buttons, not icons, which saves space) and the content of the selected
category to the right. This approach would also allow for easy expandibility
in future versions with new features.
Another shortcoming of the style editing dialogs in OO.o (and other programs)
is their modality. At least in this regard the current Scribus Style Manager
is behaving a bit saner.
OK, this has been a rather long posting, but I thought it might be helpful to
discuss existing implementations, especially since re-inventing the wheel is
Perhaps we can start from here and reach a reasonable and flexible solution,
even if the result will be something completely different. What we need,
though, is a solution, because the Style Manager has to change, which, I
think, nobody will dispute.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the scribus-dev