[scribus-dev] Who is going to kill the style dialog ?

[Christoph Schäfer]

On Sunday 31 October 2010 18:06:51 Louis Desjardins wrote:
> 2010/10/30 Craig Bradney <cbradney at scribus.info>
> 
> >  On 10/30/10 8:08 PM, Louis Desjardins wrote:
> > 2010/10/30 Jean Ghali <jghali at libertysurf.fr>
> > 
> >> Louis Desjardins a écrit :
> >>  > Hi guys,
> >> > 
> >> > Currently trying to get something out of 1.3.8 on a Mac.
> >> > 
> >> > Are we really going to get out of the mud of this text engine ? out of
> >> > the mud of this style dialog ?
> >> > 
> >> > Hey ?!?!
> >> > 
> >> > Set type.
> >> > 
> >> > Three basic settings...
> >> > 
> >> > 1. Type.
> >> > 
> >> > 2. Typsesize.
> >> > 
> >> > 3. Leading.
> >> > 
> >> > Now, where are they ?
> >> > 
> >> > Type and typesize on the next tab...
> >> > 
> >> > Leading on the first tab...
> >> > 
> >> > No compliments. It does not work. It does not make any sense.
> >> > 
> >> > Yes, I know. I should know how to code.
> >> > 
> >> > Louis, get out of your comfort zone and start coding.
> >> > 
> >> > Can we simply get rid of this dialog and have the style created at
> >> > right hand click ? Bug 300 or so by Lyam, back in 2004 or something.
> >> > 
> >> > Please do us a favor and kill this dialog.
> >>  
> >>  I think everyone agrees there is much to say about current style
> >>  dialog.
> >> 
> >> Unfortunately the
> >> complaint cited here shows a lack of functionnality analysis. Why
> >> leading is a character
> >> property in Indesign/QuarkXPress? Because they have the capability to
> >> control that setting
> >> at line level. Scribus has currently no such capability. Consequently
> >> placing leading
> >> control in character style dialog would misrepresent Scribus
> >> functionnalities and makes
> >> currently no sense.
> > 
> > Does that explain why there is currently a tab split in the paragraph
> > style to put in different tabs the typesize and the linespacing? I don’t
> > think that they should be splitted, first. There are characters
> > attributes to a paragraph style. But maybe this is not how it’s
> > programmed. But from the user’s perspective, there is a need not to have
> > to run in circles into a dialog to set something, look elsewhere, try to
> > find settings that work together and that are related. It makes no real
> > sense to set type and typesize without a linespacing value. So why put
> > those on separate tabs?
> > 
> > 
> > Louis, that interface has been like that for a few years now.
> > 
> > Given those that can probably change this are working on the OIF project,
> > I don't understand why you are complaining about this now.
> 
> The reason is I don’t work really with Scribus on a daily basis — as you
> all know and for the simple reason that it is not usable in my production
> tasks and deadlines — although I do make some tests from time to time. I
> gave it a go last week and found out (again) that this dialog was so badly
> implemented. I have documented lots of things about this dialog over time
> and how users work. So, this last comment of mine is not helpful in the way
> that I haven’t repeated here all the things I wrote previously. But we
> really need to get the discussion going and to know what’s going on. And we
> really need a change as the actual approach is a dead-end in my opinion.
> 
> Just about tabs, I have to say I find incredible we have a tab only to set
> the keyboard shortcut of a style.
> 
> And as of now, I have also to say that we simply have *no clue* of what’s
> going on in the OIF project and plus, this dialog doesn’t seem to be on the
> radar as well. We have Text Engine rewrite and redesign of the PP. Nothing
> seems directly related to the Style Manager.
> 
> Maybe I forgot something or maybe I missed something?
> 
> > Still, I 100% agree with Jean.. functionality and usability analysis
> > needs doing properly before we will change anything.
> 
> I believe we do have had that analysis made over the years. But again, this
> might have just been words and not properly done bearing the actual code in
> mind. For this last part, I cannot help as you know. But about
> functionnalities and needs for the pro users, I can certainly give some
> interesting input.
> 
> And at some point, you guys might end up to the conclusion this needs a
> total re-write and re-design. The actual dialog is a mess and we also all
> know this.
> 
> I am 100% ready to share more and help with this as long as I know what’s
> going to be helpful.
> 
> Cheers!

Hi all,

Just my 2 Cents:

First, I want to reiterate that the Style Manager in its current incarnation 
needs a rewrite. It's too big, the UI is unintuitive, and worst of all, it's 
full of bugs.

One thing I like about the concept, though, is the separation of Paragraph and 
Character Styles, because this allows for some quite sophisticated use of 
styles and style hierarchies. On the other hand, Louis's remark that font size 
and line spacing are connected is without a doubt valid. We will have to see 
how to solve this, once the OIF work on the text engine has been finished.

That brings me to the next point. Louis wrote: "We have Text Engine rewrite 
and redesign of the PP. Nothing seems directly related to the Style Manager." 
Unfortunately, both are as closely related as it gets. Rewrite of the text 
engine means, among other things, support for complex scripts and OTF advanced 
features like automatic ligatures. The Style Manager must reflect those new 
capabilities and will also have to provide style features for users of complex 
scripts. It simply makes no sense to start a redesign of the SM without 
knowing exactly what features these users need.

As for the PP, the current handling of styles via the Text tab is a bit 
clumsy, as we all know. Also, one of the features that many users asked for is 
a better connection between PP and SM, e.g. launching the SM from the PP or 
adding direct formatting as applied via the PP as a style to the SM. Moreover, 
the PP, too, will have to reflect the new typographic features, and the amount 
of those features will likely affect the redesign and the modularisation of 
the PP tabs.

One thing is for sure, though: An extra tab just to set a shortcut is 
ridiculous, 100 % agreed, but it would nevertheless be a relief the feature 
would actually work, which it doesn't at the moment (there's a bug report for 
this).

Cheers,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20101101/2b125e26/attachment-0001.htm>