deficiencies of Scribus text edit routine

[jack_cat]

Hi All!
This is a complaint about the Scribus GUI, specifically about text editing.
My main complaint is that the Properties Window is a cludge. 
I am still using 1.4.6, so it is possible that this is already being addressed in 1.5.x.

Yesterday I took a chunk of work and put it back into Open Office to revise, where not only are the footnotes far easier to work with, but all text operation having to do with font and style manipulation is also easier, because the icons are generally accessible with only one click. And I have been using Open Office for text preparation as advised, as one part of my workflow, but not for everything. I am working on the work-flow issues of using Scribus. While forum poster Dragonfly has been criticized for trying to integrate Scribus into other work-flows as a component, it remains so that for my purposes I will always need auxiliary programs like Gimp and Open Office.

Editing text in Scribus could be as easy as in Open Office, couldn't it?

No matter what I want to do to a passage of text in Scribus, I have to open another window: either the Story Editor or the Properties Window.

In OO, the icons for text manipulation are present on the desktop in a menu at the top of the screen or in a sidebar window, and can be kept handy or not. This really doesn't waste much screen real estate, and to italicize a single word requires only selecting the word followed by ONE mouse click; the Text Properties sidebar does not obstruct one's view of the work as does Scribus's larger Properties window.

When I leave the Properties Window open, I have to keep moving it all around the screen trying to get it out of the way of seeing what I'm working on. I am not running out to buy a bigger monitor. I have the best and fanciest computer that I have ever owned in my life, albeit a little less than state of the art.

Scribus's Properties Window has too many functions to be handy, and is takes up too much screen space. Because it has too many functions in it, it takes more mouse clicks to drill down into the text properties. Sometimes it will come up again with the text properties open, but if I leave the particular text box and go work on some other detail, the next time I bring it up I have to open the text properties again.

In Scribus:
Select the word.
F2 to summon the Properties Window
Click on "text".
Click again, when necessary, to open the colors and effects.
Click the change.
Or, two clicks to change apply bold or italic: first open the drop-down, then click.
F2 to close the Properties window. Minimum five operations instead of two. And hunting with the mouse to drill down into the menus.

And the Story Editor has one major problem: it's not WYSIWYG, and so it is very difficult to tell what text
markup has already been applied when the text is open in Story Editor. IMO there is no reason not to make
the Story Editor WYSIWYG at least with regard to font and style markup, it would be a lot handier that way. (A non-programmer talking here.)

My suggestion: either put a menu bar with the common text manipulation icons across the top of the main screen as with most word processors, or make a SMALL text properties pop-up window or floating sidebar which does not obscure the workspace, so that it may more conveniently be left open than the present large Properties window, and which does not also contain all of the other properties which are stashed in the current Properties window along with the text properties, which could be accessed separately when needed just as easily as being bundled in with the text properties.

Thanks,
jack

[jack_cat]

Actually I see that this line of thought has also been suggested by the guy who posted
Scribus UI/UX improvements
« on: February 10, 2015, 10:56:54 pm »

who wants to redo the user interface. Sorry I didn't read further
before making a redundant post.

The proposed UI as shown for instance in this pic,
http://forums.scribus.net/index.php?action=dlattach;topic=1617.0;attach=1358

would, if I read the guy's proposal right, include the changes that I would like to see.

therefore my post above should probably have been appended to that thread w/ the 300 other posts.
thanks
jack

[a.l.e]

i have programmed many of the changes proposed in that thread...

... some have been accepted in the development branch, some are blocked in the bug tracker, some are pending because the latest ones have not being accepted yet.

i'm willing to continue my work as soon as it's clear what will be accepted and what not... but it's not easy to get that information.

[a.l.e]

a few thoughts about your first post in this thread.

- the story editor is not WYSIWYG by design! if you want to see how your text looks like you edit it in the frame. if you don't care, you open the story editor.

- scribus is about all the advanced features you find in the text properties! if you don't need them, you might be better served by libreoffice! (but, of course, the properties and text windows should be much more compact and the indigo project you're linking makes many good suggestions!)

scribus is not a word processor tool, it might be used as such, but it will always be different.
as an example, the reason why there is no italic or bold buttons, is because scribus does not slant or thicken your text to make them italic or bold.
scribus asks you to use the italic and bold variant of your fonts (of course, if we can find a good way for scribus to detect italics and fonts styles in a font, then we could also add a button that makes the task easier... but many professional fonts have multiple bolds and a couple of italics!).

if you want to get deeper into these issues, i can help you to formulate your wishes in a way that is more likely to help the programmers implement your ideas. but it probably want be a simple journey... even if you don't need to do any programming : - )

ciao
a.l.e

[dragonfly]

I remember floating an idea about two years ago in this forum. It was to use a higher level macro language to "autodrive" the Scribus UI.  It does not require deep knowledge of programming although an understanding of defining javascript variables will be useful. The utility is found here. https://jmgr.net/
When I find time I will write a "proof of concept" such as the workflow summarised by @jack_cat above as one example. I use this approach to drive multiple applications on my desktop.  Think of yourself as the conductor of an orchestra of tools.  Scribus, OpenOffice, Gimp, Inkscape and so on in any workflow. Do not be discouraged by the unsupported feeling of Actiona. The author is one person and he suffered a loss of discussion threads in his server so recent discussions were lost.

An alternative for Windows is autohotkey but Actiona is cross platform.

[jack_cat]

@A.L.E
You make it clear that you have a low opinion of the Story Editor.
I understand that from one point of view one should be able to do everything
in a text frame in the main window, using the properties window on the side.
I am doing considerably more of that as I become more familiar with the
Properties Window, which I found difficult to work with at first. 

All the same I use the Story Editor quite a bit. It is mis-named, for a start: it is not convenient for editing large files, and much easier to use with short texts. The word "Story" is misleading. "Editor" would be fine.

I am pleased with the improvement to the SE found in Scribus 1.5.2 over 1.4.6. The display font can be set, and this improves the look and feel a whole lot. So, somebody has worked on it.
I would merely like to express my hope that there will be further work on it.

[a.l.e]

yes, i hate the way the story editor currently works.
it has been created at a time when editing in the frame did not work well enough and now is a mixed tool , one that is not really good for any use.

but i love the idea of a *-editor.
in my eyes it should have a way to show the formatting as markup. for most or the whole formatting. no wysiwyg at all.

sadly, we cannot get there by improving the current editor: a new editor with a clear -- modern -- concept should imo be built from the ground up.


nowadays, i gave up trying to get people to specify and build a new *-editor and just ignore it (and use it in the very few cases when editing in the frame is not practical).

ciao
a.l.e

p.s.:  it's called story editor because it lets you edit the content of a story and not the content of a frame. i guess that it's a concept that comes from quark express times.
i don't like the name but i don't think that Editor is better (it's not the default way to edit the content).