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

[Louis Desjardins]

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!

Louis

>
> Craig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20101031/b818630e/attachment.htm>