[scribus] some user interface issues

[Gregory Pittman]

On 04/23/2012 04:50 PM, Manuel wrote:
> Dear Scribus developers and users,
>
> Some days ago, I started my first "serious" book layouting project in
> Scribus. Being a passionate bug reporter, I took note of every user
> interface issue that I came across. So here is that list.
>
> My work environment is OSX 10.6.8, with Scribus 1.4.0 (stable version
> of January 12 2012).
>
> ***
>
> 1) Selection of paragraphs and wrong style information
>
> Generally, when selecting a piece of content of a given paragraph, the
> Properties window shows the Text Styles (font, size) that apply to
> this paragraph. This works fine when:
> - The cursor is placed at some point *inside* the paragraph.
> - The whole paragraph is selected with Cmd-double-click.
>
> But the behavior is different for the following cases:
> - When the cursor is placed at the end of the paragraph.
> - When a selection is drawn from bottom-right to top-left (with the
> mouse / trackpad, or using the arrow keys) in such a way that the
> cursor is positioned at the beginning of the paragraph.
> In this case, some properties (font, size) show the default document
> style, while others (linespacing) show the actual style of the
> paragraph.

This issue comes up in various ways. Another is when someone has 
consistently applied some font other than the default, then notes that 
on PDF export, the default font shows up even though it's never actually 
been applied to any text. So in a sense the frame outside of the text 
still has that default style.
>
> ***
>
> 2) Details that make it hard to draw selections with the mouse / trackpad:
>
> a) Clicking on an empty line: does *not* place the cursor on that
> line, but rather places it on the next line that does contain text.
> The only way to get the cursor on an empty line is to use the arrow
> keys.

Yes, I see this, but is this a major problem?

>
> b) Extending a selection by moving the mouse outside the current text
> box (with shift key): as soon as the mouse leaves the text frame,
> movements are not taken into account. For instance, extending a
> selection to the left border of the frame requires extreme precision,
> since as soon as the mouse leaves the frame, it has no influence
> anymore.
>
Whenever I want to extend to the left border, I use the Home key.
> ***
>
>
> 4) Closing a document requires mouse usage.
>
> A typical sequence of keystrokes when closing a document: Cmd-S for
> saving the project, then Cmd-W for closing.
>
> The issue: when the cursor is placed inside a text frame, simply
> pressing the Cmd key seems to produce an invisible modificiation in
> the document (the title bar gets a * appended, indicating a not-saved
> state).
> This means that every use of Cmd-W for closing a project triggers a
> modal window that asks for "Dont' Save/Cancel/Save" (the highlighted
> option being "Cancel"). The use of the mouse/trackpad is therefore
> necessary to "Save".
>
> If the highlighted option was "Save", (the default behavior in OSX
> applications), the user could hit the return key, not requiring the
> usage of mouse/trackpad.
>
I am guessing that others would not want Save as the default. I think 
Cancel is a safer option. All you have to do is tab your way to 
whichever choice you like, no mouse required. I notice that all sorts of 
non-character keys will activate a "change" in the document: Shift, Alt, 
Esc, Home, PgUp, End, arrow keys, for examples. This is, of course, only 
in Edit Contents mode. I guess one thing I would wonder in your case is 
why you wish to close a document while in Edit Contents mode...

Greg