|
|
i'm not sure that an horizontal toolbar by default is a good idea. i normally work on vertical documents on an horizontal monitor (and i don't think i'm the only one...) and vertical space is scarce. imo: - first get a good vertical layout, - then implement an horizontal ribbon. there are few details that i'm not sure that are correct in the sections above... but, i think that such discussions probably first need a concept for the palettes being written and published. |
|
|
ale, there are reasons for InDesign and XPress using a horizontal layout. As you wrote, you are working on documents on a horizontal screen, which means there's more horizontal space than vertical (which is one of the major usability issues in Scribus with its vertically oriented PP). Also, a user interface is not the same as the general document orientation! Feel free to list the details you think aren't correct. I'll gladly incorporate them into a UI mockup file. |
|
|
I think it is not an easy challenge to tackle vertical and horizontal layouts in one move. Basicly the IndigoDock support currently vertical and horizontal panel directions, unfortunaly the panel content itself not yet. The difference to InDesign is that they have a fixed layout for all (panel sizes, allowed panel directions, fixed position/size of control elements). That makes it a lot easier to create a working UI in all cases. Furthermore they have only one UI-theme in different shadings for all operating systems. But Scribus have to support different operating system themes (Windows, Mac, KDE, Gnome, etc.). Every OS theme has different sizes, spaces, etc. In some cases it makes no sense to have Scribus's panels in horizontal layout, e.g. if there is a long list view. To achieve vertical and horizontal directions we can try to group all elements in smaller "blocks" which can float. But we have to remove the lists from user interface. See my screenshot for a proposal. Short facts: the UI will show only an access control element, like "choose color" and than you have a "floating overlay" or a "popup window" to modify the values. That could work for vertical and horizontal UI-layouts. But you have one step more to edit. Floating_Controls.png (77,849 bytes) |
|
|
Here is an example as a web application (Lucidpress) which comes without horizontal panels. https://youtu.be/-CCYr_VKP8A?t=2m23s Cool thing here, they found a way to optimize all the stuff for one screen because of usage in a browser. |
|
|
+1 for floating overlay |
|
|
This issue relates to a previous discussion about Typographic Colour and I believe we should connect the two. Here’s the reference. The discussion is worth reading, I think. https://bugs.scribus.net/view.php?id=9848 This dialog will allow more space. It’s a very specific task that don’t need to be delt in the main dialog and it implies many settings that work together to achieve one specific result. Once it’s set, there is no real need to get back to it so often. This will ensure very decent results (if not perfect) on the typographic front. Not a small victory! A general thought about a working UI is gather the settings where it really makes sense, according to the complete process. The idea is not to have tiny portions of settings in distincts palettes or tabs, as many as there are options (this is the à la InDesign way and it is underproductive). Opening and closing tabs in the PP palettes doesn’t make things more efficient only because they are gathered in main palette. Yes, the settings are organised from a listing perspective, but they are not organised to make people’s work efficient. Basically, what I think we need is a deep understanding of the full formatting and layouting processses, as a whole. It’s more complicated than simply putting things in order. However I agree that making the list is part no. 1 of that more complicated task. This needs more thoughts than just gather "text" or other settings together. The Typographic Colour set is part of what I envision here. * * * In paragraph, we need a couple options to manage what needs to be kept with next/previous paragraph. One good case example for this is you need a way to keep a subtitle with the next paragraph. In no way you want a subtitle to be left alone at the bottom of a page. This is not a widow/orphan case. They are disctinct paragraphs, not part of a paragraph. * * * There is a need for a "create style" dialog from the current settings. The user has only to determine whether it is a character or a paragraph style. * * * If someone feels I should create (or revisit) specific bugs/feature request for some of the items proposed here, just let me know. |
- Anonymous
