Scribus Forums

I did an analyse of current scribus interface and user experience with latest version 1.5. At first I'm an InDesign user since 2006 and work for a while with Scribus. How to say I'm not new in Scribus but I'm missing some nice features for a good intuitive workflow. My first steps with Scribus take a while to understand the logic and relations behind some functionalities.

I've collect all my improvements and ideas in a Google Slide.https://docs.google.com/presentation/d/19TL-UUOFfrtya983eO1USOB9Cc9uqzOC51RtWMclIkA/edit#slide=id.p

Check it out and give me feedback for your point of view and your optinion. It's a living document!

Hint: This document is a rough collection of ideas and will be update time by time. Ignore spelling mistakes and have fun :D

greetsMartin

_______________________________________________________

Update:

If you don't want to read all the posts, take a look to the "last state" of the concept here: https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.p

I created this presentation to keep the concept up to date on one place. If there are new stuff based on discussions here I will update the concept as well.

I've been muttering about this kind of thing for years but my crazy random outbursts are scattered around various posts and not in any kind of order like this.

I really like some of the ideas about changes to the Properties Palette (Window Properties in the presentation). This palette has way too much empty/unused space and even before 1.5 it was becoming unwieldy to use. With the extra functions in 1.5 - I especially notice it on OSX - there are so many sub-sub-scroll-lists/areas that it's very difficult to know exactly where you are without a good deal of thought. (See the attached screenshot for one example of the confusion. Notice the two scrollbars together on the right.) I do realise that 1.5 is still in development and things will get moved around, but this is the perfect time to see what can be done.

I particularly like the suggestion to convert the Properties tabs to side-icons (or even top-icons like GIMP). The existing tabs take up way too much space at the moment, so moving them to the side (or top) will free up a lot of extra "real estate".

Also, the different icons look great. Some kind of collaboration between Martin and otx (see the link from Kunda above) would do good things in my opinion.

Using an extra context-sensitive toolbar to offer some of the adjustments - like Inkscape, as mentioned in the presentation - Window Main (Tools) - instead of elsewhere looks very nice too. Anything to make the interface clearer and easier to use.

If I could add one extra thing, the Shape and Group tabs of the Properties Palette have much the same effects but on different things (with a couple of exceptions). Could they not be combined and made context sensitive? I.e. If you've got a group selected it offers group-related effects, or shape-related effects when the object selected isn't a group. It's just a thought.

I'll need to have a look at the presentation again but this could be a very good and much-needed step in the right direction.

now need to get it to the next step, where we produce specifications and files people can work with!

for the last year i've been collecting ideas in a github repository. one idea per project:

https://github.com/aoloe/scribus-project

most are just in draft status, some even just a placeholder.

the idea is to fill it with details until somebody picks it up and can implement it.

you're welcome to fork it and making pull requests to it!if possible with projects that are small enough, that there is a chance that somebody picks it up!(meta projects like "redoing the UI" are also ok... but i prefer a project "vertical selector in the PP" with icons attached)

i understand !my return about uxit fill have strange behavior we need to change something in 2 tabs to setup ...(fill and color) i think it was better to insert fill color in fill tabs it was more userfriendlyscribus is realy great !!!i love it

I'm glad this is being talked about!! I just downloaded to take a peak at what is new in 1.5 and right away I was blown away that the Properties window is a step BACKWARDS. At least in 1.4.x whatever category you were on was all you saw, so it was easy for my eyes to place buttons and what I was doing.

Now is 1.5 it's just one long scrolling list of EVERYTHING, which makes it very difficult to quickly see things and know exactly where I am in my work flow.

I really hope either the improvement suggested in the first post is seriously considered as it's beautiful, streamlined and is a nicer way of how 1.4.x worked OR the devs just go back to the 1.4.x model of things.

I have no clue why anyone would want a loooooong scrolling list of everything. It's MUCH easier to click on a category and see the options then to have to scroll to find a category first or always remembering to close one after you are done with it. It's now extra work. Seems backwards!

1.5 is a dev release. 1.5.1 is where the changes are being made with new icon set and such. I think the devs are planning to update the PP before 1.6Scribus definitely has a developer shortage. Looking at the codebase, it's an enormous undertaking to keep this DTP going and staying relevant. If you have any skills or know anyone that would like to volunteer...Scribus is open to proofs of concepts and patches.

after a long time I have made a rework of my initial concept for the property window. The new layout is based on the same tab logic as you can see in the first post. Currently not all tabs are done, but I think the finished parts are a good impression for design strategy.

I'm still working on a new UI concept for Scribus, but I want to share some new stuff with you. ;)

Short background story:The foundation for the new concept is a deeper analyze of Indesign CC 2014, Quark XPress 2015 and Scribus 1.5.1. and the most often used tasks for DPT's.The new Interface is more space optimized and gives the user more freedoms to create a custom workspace.Feedback or improvements are welcome.

If someone could convert this kind of thing into a usable UI it would help Scribus a whole lot.

My only - possibly - worthwhile comment would be to maybe not put too much faith in an analysis of how existing software works.

For a lot of applications, they do things the way they do because that's just the way someone originally programmed them to - a lot of the time the programmers aren't the users - and since then everyone has got used to it. Things often get put where they are because it was convenient for the programmer to put them there while writing the code.

On the other hand, asking the users what they want can be a nightmare. Ask two users what they want and you'll usually get at least three answers!

Please keep working on it though. If something like it can be implemented, that would be brilliant.

@Kunda,I've seen it yesterday on the google+ account of Scribus. Thanks for sharing, maybe we can improve it together with a bigger range of the community. So far no one has contacted me.

@Garry,the analysis helps me to understand the logic behind things. Maybe I found some weak spots in other DPT's and we can make it better :DMy goal is it to create an intuitive UI. The user should not think: "Meh! where can I find this function?" The user should think: "Ah, there is it! As I supposed." It's a hard goal but let's try!I think in good and simple user interfaces contains plenty of brain power. And I also think that about the user interface of InDesign and XPress. So why not benefit from it. ;)

I've completed the basic concept and I've defined some general design standards/rules for a consistent UI for Scribus. Have a look to the new screens.Further you can find the UI-Mockup presentation here in this Google Slide:https://docs.google.com/presentation/d/1M6R4ggFbgU1EXbWiL8hwppyQJhsNnUlw7_7rOA3Im1Q/edit#slide=id.ge4506b4e5_1_16

It's containing a short comparison between Indesign, Quark Xpress and Scribus and additional descriptions to the mockup screens and features.

- there is an idea floating around about separating the content part of the properties panel (which would be context sensitive) and the frame panel (which would contain the maniputations for the frame) - what do you think about it? - would it fit in your thoughts?

- how can we get to a specification (with no reference to non free software, if possible!) for the new UI?

I'd like to add a few comments (some of which I might be repeating from other posts).

1. Scrolling

I think the amount of "stuff" in any panel - for example, "Properties" - is important and can greatly affect how software is perceived and used. More specifically, the more scrolling the user has to do to find things in a panel the less professional it feels to the user.

To someone looking at the software for the first time it might look like there's loads of options for them to play with but in actual use it becomes tiresome to have to keep scrolling up and down to get where you want.

For example, in the Properties/Text tab, if you have a few of the sub-tabs open - unless you have a very large monitor - you have to scroll up and down to find the thing you want, e.g. Colour, Style, Columns, Advanced, etc. (See the image I posted earlier in this thread.) This can also have the effect of the user inadvertently making changes with a scroll wheel if the pointer happens to be over a control that accepts scroll wheel input. (Also, this sort of inadvertent change can be difficult to track down if you weren't watching.)

It is better to keep scrolling within panels to a minimum. By way of two examples, if you look at GIMP and Blender you will see that their controls are arranged in such a way that the user - even on smaller screens - has very little scrolling to do no matter where they are in the control panels. There are more panels to click between but they are each small enough to fit on the screen without scrolling. This can give the user a much better experience.

2. Content/Frame Split

I would be generally in favour of splitting content properties from frame properties as long as it was done well. (Even now, after using Scribus for a few years, I still find myself - every now and again - going to the Colours tab to change the colour of text. Stupid I know but my brain thinks "colour" and automatically moves my hand to point to the "colour" tab which is always visible.)

My main concern with this would be implementation. For instance, "XYZ, Shape, Group, Line and Colours" are all frame properties while "Text and Image" are content properties. So how would the two things be split? How would putting them in separate tabs in the same panel affect the UI? Would there be two separate panels instead? How would that affect screen space if they were side-by-side? If they were one-above-the-other that might cause major scrolling issues. Would a context-sensitive toolbar - as in Inkscape - be a good option instead? This would need a lot of trial and error which - I'm guessing - the developers won't have time for.

On a related note: How easy would it be for someone to put some kind of non-functional properties UI together that people could mess around with in Qt? I've no idea how much time this would take but it could help more people be involved and might allow for a quicker solution in the end.

3. Compression

I think the road Martin is going down is correct with a "compression" of the controls within the panels. At the moment, Scribus is quite "newbie-friendly" with lots of space and long control names/descriptions but it makes for a lot of unused screen real estate (and tool-tips are usually available to give more explanation).

For example, in the "Shape" tab, the "Disabled, Use Frame Shape, Use Bounding Box, Use Contour Line, Use Image Clip Path" options could all be compressed into the space of just the first two by putting them in two columns and omitting the un-necessary wording, e.g. "Disabled, Frame, Bounds, Contour, Clip Path".

For an example of a good lean UI I always point to the GIMP Toolbox. The toolbox and toolbox options give the user a whole lot of control but manage to fit all of that into two panels which can sit unobtrusively to the side of the main window. I haven't counted but I'm fairly sure that GIMP puts way more tools and options into one small double-panel - which seldom needs to scroll even on smaller screens - than Scribus puts in one panel that needs a lot of scrolling.

I realise that a toolbox isn't the same as a properties panel but the same sort of layout design could be used.

Getting a nice UI that is both streamlined and easy to use is difficult but any improvement would be good.

I like the idea about a splitted Property windows. If we separate the content Property from frame properties we have some options:

create a second Property window that contains text and image settings (might be grouped in tabs as seen in my mockup)

create two single windows

But I think in every case it should be context sensitive.For Text:

by double click on text frame show Text Property window (probably the user want to edit the text)

get focus by press F3

For Image:

by double click on image frame show Insert Image Dialog if image not set

by double click on image frame show Image Property window (probably the user want to edit the image) if image already set

get focus by press F4

@GarryI have caught myself as I wanted to set the text colour in the colour window. I think it's a good idea to merge both colour settings. See in the attachment the new version of colour tab. It should be also context sensitive. That means if a text frame is active the text colour widget is shown additionally. In other cases it's hidden.

In general, the Property window will be reduced by two tabs (text and image).

@a.l.eDid I understand you right, you are searching for instant libs? I made a short research about it, but I doesn't found useful stuff. Further I checked the Qt board widgets, I think it's necessary to create a custom widget.I think for tabs in Property window it can be used the Qt TabBar. The tab bar allows to reorder single tabs and supports icon only labels. Contra: the icons are rotated by 90° for vertical tabs.However in my opinion the important part is to clean up the single windows (panels) at first, like Property window. After that it can be implement the new docking widget (or we have to find a better solution).The DockingWidget supports vertical tabs but only with text labels. Also it's not possible to move a stack of grouped panels to another place. I found in Libre Office Writer a good solution for grouped panels in an icon bar but it's only one window and the user can't split the single panels from parent window.

I was glad to see the comparisons with work-alike programs. UI is one place where Scribus could use some help. Just remembering which panels were left open would be a welcome change (I'm looking at you, text panel- Stop closing every time I click on something else, then return back to my text area!)

While I know Scribus is not a text editor, text formatting (specifically applying styles, bolding, and italicizing) is a big part of my usage and I'd love to see it streamlined.

Great to see these designs, and the study behind it! :) however, to me there is still a lot of 'gray-space' between some elements, and the panels especially - some panels could be combined, or perhaps made 'semi panels' so they don't stretch across the whole side if they're not populated completely with icons/controls? it's just I don't like a panel taking the whole screen-side with only a few icons on it and a lot of empty gray space.. also, all the borders could be like max 1pix wide ;) keep up the good work! and please implement asap.

I just registered to say how great this is :D Excellent work! I'm dying to switch from Adobe completely at some stage. I just hope these features make it through. How likely is it that this will be adopted for 1.6.x?

I finished first version of the Property panel designs. See the whole set in attachement. I named the new UI Indigo UI. Becasue, it's a blue color like the main color of Scribus and it contains the word "Indi" the abbreviation for "independent".

While my spring-cleaning I removed the group tab. I think it's not needed all settings already available in Shape and Transparency tabs. Furthermore I separated the Text and Image tabs of Property panel in to single panels (content editing). These reduction of tabs in the property panel (frame editing) save more space in smaller tab views, like Shape Tab.

What else? I've created a Full HD view of the new UI to see unused space... some elements needs an optimization. Perhaps should the Property Panel completely split in to single panels. What are you think about that idea?

@cloudbustingI think if we can finish the UI details and someone of the dev's grab these ideas it's possible to implement this in Scribus 1.6.The other question is if the majority of the community vote for this new interface. But I think yes if I read the current feedback ;)

Otherwise Scribus 1.5 got already a new panel docking extension. And it's to much to rework these again. But Panel clean up should be possible (and is neccessary).

I agree that the properties panel should be split for each section. It would make more sense; some users/designers may never need to use a particular property, so it would allow more space to view the doc if split up.

And yes, it's much needed. I'm new to Scribus, so perhaps users that are unfamiliar with other software don't see some of the hindrances. But a clean UI like this with minimal fuss and mazes of menus to get through would be much more useable. Especially when working on a large project where the same tools are used again, and again.

I'm currently working on the new IndigoDock Widget. It's not done but I have some progress ;)

Features:- the whole dock is dockable on left or right side of main window- the dock contains a tabbar with sortable tabs- within the single tabs you can add/remove/arrange single panels (more than one)

Issues:- redocking of panels in another tab is a little bit tricky (but I'm on the fix)

ToDo's:- fixing of redocking in other tabs- automatic tab orientation switch by docking on left site- automatic tab creation by drag a panel on it- styling of the features

Code base:- DockWidget is a normal QDockWidget- IndigoTabWidget is a custom QTabWidget- IndigoDockWidget is a custom QMainWindow (tab body)- IndigoPanel is a custom QDockWidget

Hints:If I have a stable version I will share the code. But you can check the test program in attachment. It's an Ubuntu programm and written in QT 5.5.

Here is how you run it:1) Download QtCreator based on you OS and install via http://www.qt.io/download-open-source/2) Clone the indigoDock (https://github.com/nitramr/indigoDock) repository to your local machine 3) Find and click on the TestLayout.pro which should invoke QtCreator4) Build TestLayout by clicking on Build > Build Project "TestLayout"

there are some news about the IndigoDock codeing. As I guessed the standard Docking Widgets are not really useable for IndigoDock concept. I couldn't solve the issue for redocking in another parent. In the current GitHub Version its possible to dock a panel in another tab, but not back :(

What I did?I have rewritten the whole thing based on normal QWidgets. And it works! It's not done but there is a good foundation.

Check it out on GitHub:https://github.com/nitramr/indigoDock

The old Version is still included, but I will remove these if the version 2 works much better.

About the Version 2 Features:- left or right docking position of the whole panel stack in main window- moveable Tabs in TabWidget- undock single panels to Toplevel windows- possibility to dock single panels in tabs- grouping of more than one panel within a tab (only vertical splitter)

Widget Changes:- QMainWindow within single tabs was replaced by an own DropZone Widget- QDockWidget as Panels was replaced by extend QFrame

Known issues:- flickering by moving a panel after first undocking- toplevel windows wont close together with parent- toplevel window is visible in taskbar as separate window

Great UI improvement for Scribus. This is what scribus needs. It's showtime. Can't help it sometime I get last in the UI of Scribus. To much clicking for the seem action.

Maybe my best Idea is that when you are entering a txt frame to type some txt the UI is automatically on txt window to perform and speedup your work. If you deal with images for instance the UI is opening the right image settings window for you. At this moment that is a pain in my ..... to click every tine on those windows to open it if I create or deal with those frames. Must be some simple programmer who can deal with this ;)

Other strong missing feature is a function or a button to copy your text settings straight to a new paragraph style. Now I need to face all the settings and put it by hand in my new ceated style. Just an idea not more :P

1/ that's the main reason why i'm suggesting to split the properties palette into - one palette specific to the content of the frame ("the content palette") which would automatically adapt to the type of the current frame (showing image settings when you select an image frame and so on...) - and a palette for the formatting of the frame itself, which would stay as the user sets it.

most of the time you need only one of them on screen at the same time. sometimes both.

2/ yep, we need that! for styles, colors and all other resources. there should always be a "+" button at the place where you can choose a resource!

I tried to talk about this problem on SCRIBUS BUG-TRACKER PLATFORM, but obviously it wasn't the right place for it. I've made simple MOCK-UP how to improve PROPERTIES PANEL. I've worked in PageMaker, Quark, and InDesign from version 1.0 to current one... In my personal opinion at this stage of development SCRIBUS is as good as say InDesign or Quark, however... with this PROPERTIES PANEL and the way it works it's very time-consuming to do anything.... Changing a font and it's size takes forever, not to mention more advanced options. I have a feeling like everything is "hidden" :) Every user uses different toolboxes on daily basis. Why don't we allow users to turn on and off toolboxes they need? Would it be much of a hassle to change it as attached? Some of you will share my opinion and some of you probably won't. How about an option to let users decide that kind of user interface they use? I can't work with SCRIBUS at all for right now - just because of this PROPERTIES PANEL.... In my opinion it's a great DTP software, but telling the truth - it just takes two long to work with (especially with commercial projects where time is always crucial). Beside PP... as far as COLOR SWATCHES are concerned - why are they added in different place and than used from another? That's how Quark worked back in the 90-ties... :) Same for CHARACTER/PARAGRAPH STYLES - you create them in one place and than you use them from another toolbox... No reason for that! :) Finally, SHORTCUTS for CHARACTER/PARAGRAPH STYLES - there's no way to create them.... I like Martin's project - INDIGO DOCK. In my opinion creating small icons on right side that activate just one TOOLBOX is not really efficient. Each time someone wants to change a font you have to click on it, than do it, changing object's color - select it, than do it and so on... Again... waste of time:) From what I understand about INDIGO DOCK - it would be possible to activate more that one toolbox one below another, right? If that's so - I strongly support this idea.

yes I agree the current UI of Scribus is more like a maze - long ways of navigation, much scrolling and so on. My first idea was to stack single panels (separate or as group) in an icon bar. That means every panel has the full screen height (no more scrolling). But the Property Panel is another stack and you have to search again for features.

While I'm was working on a more detailed UI proposal I received many user feedback on different channels and the common points are:

- split PP in smaller pieces- let the user decide the arrangement of single panels and most often features- design the panels more space optimized (the other parts of ui too :D).

The current state of my concept is not exactly brilliant. But can be upgraded after new insights ;)

I see two extreme layout cases for the UI:1. show most of the features on one screen (beginner and user they need quick access)2. hide most of the features (professionels with full focus on document and shortcut user)

So we need:- flexible panels and docking mechanic- more shortcuts of important features

Furthermore I think clean up of panels, space optimization, new control elements are working perfect in both cases above and is necessary for a great user interface.

Your feedback support these new direction and I have to think about changes in the Indigo UI. Currently my focus is on the panel clean up and building new control elements... That's the first part of the Indigo Project.

Quote

it would be possible to activate more that one toolboxes one below another, right?

About your question, you can group more than one single panel in a panel group. Based on the single panel size you can see all panels in these group in one screen without switching to another icon tab. Every Panel group is stacked in the icon bar.

I've made another mock-up. In my opinion all those toolboxes should be "more compact" as far as their height is concerned since they go one at the top, next one beneath, next one beneath... Current GEOMETRY toolbox is about 10 cm in height (exactly half of my 24 inch monitor :-X).

The way I see it - there should also be some scrolling down possibility in Martin's project (this section on a right) - both with mouse-wheel and scrolling bar... Forgot to add it on my mock-up.

I suggest to provide some arrows next to "X" in those TEXT, COLOR, PAGES etc toolboxes so that this toolboxes could be expanded or rolled up - weather someone needs extra features or not. Example: TEXT, and TEXT ADVANCED PARAMETERS.

I strongly advice to enable creating COLOR SWATCHES, PAGES, MASTER PAGES, TEXT STYLES directly from those toolboxes....Why do we add them in one place and then as we want to apply them - we go to another toolbox... Makes no sense to me :)

Martin, I would place all those toolboxes only on the right side - like in Your first project :) You like them on both sides - fine. I mean... everybody likes something else.... Why don't we provide both options so that a user could decide weather he/she likes to have it on one or both sides? In InDesign there'are several possibilities how toolboxes are located. My toolboxes in InDesign look different than those at my colleague's...

I see two extreme layout cases for the UI:1. show most of the features on one screen (beginner and user they need quick access)2. hide most of the features (professionels with full focus on document and shortcut user)

Exactly... My idea in this matter is to create small arrows for certain toolboxes in order to expand/collapse them. I've made this example in my mock-up. Say we activate TEXT toolbox, in someone needs more advanced options for a text he/she presses on this arrow and then have more sophisticated parameters... With this step there will be 10 maybe 15 buttons on a right side instead of 50...

PS. why ARRANGE PAGES instead of PAGES? If a new user opens SCRIBUS for the first times there's a probability of 99% that if he/she would more likely look for PAGES instead of ARRANGE PAGES... :) At least I looked under P, not A + had to check it in Internet in order to find it ;)

I like your concept it's much simplier than my proposal. It reminds me a bit of the UI of Inkscape - a user can create a scrollable area with all single panels inside. So, I would like to extend your proposal with a collapse/expand function. Because in Inkscape a big area of the screen is blocked by the toolboxes. See image below for my proposal.

My idea: a user can collapse the scroll panel area to a single icon bar. Also the user can expand the icon bar by drag out the scroll panel area and all toolboxes are available on one screen. If scroll panel area expanded and a user click on an icon it scroll to right toolbox location. If the scroll panel area collapsed the icon bar switch in single toolbox mode and only one toolbox will pop up by click on an icon.

Quote

Martin, I would place all those toolboxes only on the right side - like in Your first project

Don't understand me wrong. It's possible to place the dock only on right side... ;) In my Demo Application it is possible to move the whole stack outside of the Main Window. You can redock it on left or right side or on both sides at the same time.

I think for a right to left application layout (for arabic languages) it's better to offer boths sides. It would be also possible for your proposal.

Sth new came across my mind... Check out my new mock-up ;D. Yellow color - what do you think about it? You activate all these toolboxes with icons on the very right. Than if you want to expand/collapse them you click on top section (GEOMETRY / COLOR / PAGES etc.). If you want to close certain toolbox - you do so with an "X" - brilliant, ha? :) At the end... if you want to have say GEOMETRY at the top, you drag and drop this toolbox so that it "jumps" higher or lower. Are you able to make this UI project a reality? How could I hack current user interface in order to start using SCRIBUS? :D

at first a question to understand you right. You have on right side an icon bar with all available windows/toolboxes. By click on a certain icon the related toolbox will show in the scroll container on left side and the "X" button hide it from scroll container, right? I like the idea.

So, that means we have some main features:1. Icon bar to activate the wanted toolbox (show in scroll container or scroll the container to right panel if already shown)2. foldable toolboxes with close button to remove toolbox from scroll container3. basic/advanced mode for toolbox content

The scroll container looks at the first view like the current property panel of Scribus :D On a second view there are some main changes. The icon bar for quick access and a scrollable container with all (or not) expanded toolboxes.

How could be the layout for working with multiple screens? Is the whole Dock Widget moveable out of the main window? Maybe some users want to fill one screen with all panels as a wall to see all features... For the current scroll container in your concept it's not possible... If the single toolboxes can move out of the scroll container it could work for such users.

at first a question to understand you right. You have on right side an icon bar with all available windows/toolboxes. By click on a certain icon the related toolbox will show in the scroll container on left side and the "X" button hide it from scroll container, right? I like the idea.

That's right + these toolboxes appear within scroll container in "basic" mode. If someone needs more advances stuff he/she clicks on very top of each container to expand/collapse them. We could add arrows next to "X" for toolboxes with such advanced possibilities (for those who haven't grasped this idea ;))

How could be the layout for working with multiple screens? Is the whole Dock Widget moveable out of the main window? Maybe some users want to fill one screen with all panels as a wall to see all features... For the current scroll container in your concept it's not possible... If the single toolboxes can move out of the scroll container it could work for such users.

Good question... Well, check out my first mock-up :) You pull these toolboxes out from our right scrolling area and there you have them :) (as alone standing toolboxes - you can place them where you wish). In my opinion another way to activate our toolboxes should be like in almost every software - by going WINDOWS (very top menu) => GEOMETRY / COLORS / PAGES / TABLES / ALIGN & DISTRIBUTE and so on). If someone accidentally closes a toolbox - there's usually a confusion "how do I turn in on now?". In case someone uses multiple monitor there should be some button to show/hide our right scroll container. How about right/bottom corner? Simple button with TOOLBOXES sign on it - you click on it and make our right scrolling area appear/disappear.

is the collapsed state (for full focus on document and shortcut users)

show the expand mode- the first toolbox is in advanced mode- second one is in collapsed mode

show the expanded state with two toolboxes- the icon will add or remove from iconbar

show all expanded toolboxes

Features- expandable/collapseable mode of the whole Widget- Toolbox modes: collapsed/expanded/advanced- Foldable Araes within a toolbox- arranging of toolboxes by drag and drop or by icon moving (also drag)- toolboxes can be docked or undocked in the stack- whole toolbox container is scrollable (overflow scrolling)- click on icon scrolls the related toolbox on top

Perhaps for multiple screens we can make the stack moveable, like in Libre Office.https://blogs.shu.ac.uk/shutech/files/2015/07/1.pngThe right area can be undock from main window.

Very nice. One question: is there an option to hide our right scrolling field for people who want to have separate toolboxes only (for example for those with multiple monitors)?

Do you know by any chance which file from SCRIBUS TRUNK should be opened by QT-DESIGNER in order to edit this interface? :) I tried to follow this tutorial, but no clue where to begin; http://wiki.scribus.net/canvas/Tutorial_Hacking_Scribus_User_Interface

Are you capable of applying your project into SCRIBUS? :) Are there some software developers to manage this? I have no C++ knowledge, I'm just a graphic designer :)

as Kunda wrote we have a test bucket for the new UI Elements. It's a small project but we can easily test new stuff outside of the regular Scribus project. If the community and the core developers like the new UI I think it will implement in next versions.

The Indigo UI Project is more like a showcase for possibilities and not a commitment for the next Scribus release. However, I will try to realize our newest concept within these project, but would be nice if more developer join to the project. For me it looks simplier to finish the new concept as the old one... because the half code is already done for the new stuff :D

greetsMartin

PS: about your question to hide the right scrollfield (I think you mean the icon bar).- If no toolbox is inside of the scroll container anymore the icon bar could be hide automaticly.- If a user drag and drop a single toolbar to the border of main window the iconbar can be visible again with the toolbar inside of the scrollbar.

Whatever the changes will be in this topic - anything would improve this panel :) In my personal opinion in current PP the most problematic is TEXT section with COLOROS AND FILLS, FIRST LINE OFFSET, ORPHANS AND WIDOWS packed together within small container, roughly 6 cm in height + this section as a part of bigger scroll area... :)

Martin, I meant how do I switch of the right scroll-field, not a left one... :) I attach in this post which one I mean. Remember, you've asked how do users switch the toolboxes off if they use multiple monitors... Left scroll-field - I understand it hides automatically. How about this one - the right one? I think if someone uses toolboxes as alone standing, floating ones - he/she won't need this one... Any option to switch this one off under WINDOWS => TOOLBAR etc?

I have understood your question right. ;) As I described, if there is no toolbox inside of the left scroll area the icon bar (right scroll field) will hide. If you want to bring back the icon bar you have to drag a single toolbox next to the right egde of the main window. By releasing the mouse button the icon bar will shown and the dropped toolbox is inside of the left scroll area. Also the related icon of these toolbox in the icon bar.

Long story short: if no toolbox is inside of the left scrollfield, the whole thing will hide (left and right areas).

Otherwise if I think more about it... it feels bad. Maybe the user is suprised if the whole thing is hiding by close/drop out the last toolbox... In worst case he/she doesn't know how to bring it back.

Other idea:- there is a close button next to the arrow icon on top- you can hide the whole stack (also if there more than on toolbox inside) by click these close button- it should be possible to show it again via (Window -> Show the cool thing) <-- or similar wording :D

- it should be possible to show it again via (Window -> Show the cool thing) <-- or similar wording :D

Yes, I'm for it :) This hiding-thing may not be recognized/noticed by everybody. Say I accidentally close this menu... I think first thing I do is to go to WINDOW => PROPERTIES PANEL in order to switch it on again :) Let's enable both ways so that if somebody won't find one way one of them - there will be always another solution for the problem.

My other "ideas" as far as UI is concerned: - clicking on a guide should cause opening some toolbox where you can write precise guide position, agree with me? - Shortcuts options for CHARACTER STYLES? (say CTRL + 1, 2, 3, etc...)- Shortcuts options for basic text operations like increase/decrease font size, increase/decrease distance between lines/letters in selected words... This small things speed up creation/designing process/entire workflow a lot.- I think I've mentioned that before - when it comes to ARRANGE PAGES... I can't make it any smaller in height (attachment) Hope this could get better with our new UI? :)- Need to simply how pages/master-pages are created... Simple + / - icons for the pages and + / - icons for master-pages could do... (in order to create/delete them - I lack an option to CREATE NEW PAGE from this toolbox in v 1.5... Duplicate page option would be also a nice one...

Today I've updated the Indigo project on GitHub. The new features are based on the last discussions here in the forum.

What's new?- now we have a single scroll container that contains all panels- tab bar allow resorting of the single panels- I tested some styles - now it's dark + simple image inversion (I don't know how looks on Windows or Mac, it's based on the Fusion Style)- tab icon will only show if panel is inside of the scroll container

Looking great, Martin! Really excited with your progress. I think the change to dark colours is great too. I find it much easier on the eyes when working at night, and for long projects. By the way, will this work on 1.6.0, or will it need to be altered for it?

- i'd prefer to have both a dark and a light theme...- we should avoid collapsable sections...- text and image tabs should probably be on the same pane (and automatically switching depending on the current content type: that's the idea behind the content pane).

One thing though: are TEXT, ALIGMENT, PARAGRAPH, CHARACTER, COLUMNS are to be again within single toolbox? I thought the main idea of the entire enterprise is to split up somehow current PP in sections such as TEXT, ALIGMENT, PARAGRAPH STYLES etc. in order to ease access to all those tools... In my personal opinion - if they stay like this (as single toolbox with one "X" in upper right corner) - it's not gonna make much difference in comparison to current PP state... ;)

One more thing regarding UI interface: it's really hard in v1.5 to manage pages around. There's ARRANGE PAGES toolbox as such, but in order to move them around, we need to go to very top menu => PAGES, MOVE PAGES, than some box show-up and we point out what is to be done... There should be some RIGHT-CLICK option within PAGES toolbox with MOVE, CREATE NEW and DELETE functions...

Kunda, good article, though this example with hard access to text properties is slightly exaggerated :)The author obviously hasn't found PP in order to do so :) I find this part very to the point:

"My biggest criticism of Scribus is the user interface – it takes more steps than necessary to make changes. Something we’ve have taken for granted as both Word & InDesign users is that there would be a simple top bar which allows you to make changes directly to the text and see a real-time change. In order to do this in Scribus, you need to select the text frame, right click and select ‘preferences’ then make the changes in the preference panel. There isn’t a shortcut for this process, so it can feel unnecessarily tedious – taxing working memory."

Guys, Scribus is a great software, no doubt about it. The weakest link is the UI :) Martin, how about the last UI prototype you've presented... are you planning add more "X"s between those toolboxes I wrote about in previous post? :)

Yeah, the author of these article bring it to the right point. The UI needs more love!

Guys, good ideas in the last posts. I think we are now much more flexable with the current UI state. In my eyes it's more like a framework, we have single panels in one big stack.We can freely decide what the content should be!

@Pablo:Is there a good reason why we should splitting the text panel in smaller pieces? I think for space saving we have the collapse feature of every panel. Furthermore I like a.l.e's idea to create a new panel type (CONTENT). It's a context specific panel. That means, if you want to edit a text frame you have only text related settings inside these panel. If you want to edit an image frame you have only image related settings inside.

The PP can be split in to single panels GEOMETRY, COLOUR, TABLE, CONTOUR, GROUP, SHAPE, etc.Furthermore we have other single panels like: LAYER, PAGES, ALIGNMENT, whatever....

In example my personal panel order would be:- GEOMETRY- CONTENT (text and image)- ALIGNMENT- COLOUR- then the other panels, because I do not use as often as the others above

4:22 PM <Kunda> MrB, why'd you skip 1.5.2 (jumped to 1.5.3) ?4:32 PM <jghali> Kunda, we won't skip 1.5.2, but we will not focus on bugs in 1.5.24:33 PM <Kunda> jghali, ah! i see4:34 PM <Kunda> jghali, 1.5.2 == ScribusCTL ?4:35 PM <jghali> no, rather resource management4:36 PM <jghali> for 1.5.3 the current plan is to look at indigoDock or ScribusCTL depending where they are

Kunda are right. Contributors are really welcome to these project, because in the last month I haven't enough time to bring it forward. If you plan to develop the code you can clone the code and make a pull request. Have a look on the roadmap as Kunda said. For a general UI discussion we can talk here. Every proposal is welcome.

sorry for the long silence. Today, I have good news for you, I could fix a major bug for panels arranging via drag 'n' drop within the drop zone. Yet, there is only missing one main feature for version 1 - auto scroll feature if the user clicks on an icon. And finally there are some smaller fixes, performance optimisations and refactor work necessary.

I see two ways to integrate the IndigoDock in Scribus.1. directly in main source code2. as a third party plugin

I think in both cases I have to "convert" these project in a library.

greetsMartin

PS: I'm on providing more informations about milestones, details of planned features / todo's, graphical material and so on.

just one (imo rather important thing): somehow, one of the bigger concerns was to separate the settings relating to the content from the ones that affect the frame.

the idea was, to have a content palette, whose content would automatically change depending on the type of the frame currently selected.afaict, it does not make any sense to have the setting for the image shown, while you're editing a text frame.

on the other hand we could have one (or more) "frame" palette, that should be displayed at the same time as the content one.

I haven't forgot it ;) You can find a fully filled dock in attached screenshot. From top to bottom prioritized to importance for my opinion. On top, the geometry panel which contains the xyz stuff, shape and drop shadow settings, below the content panel. In these case shows it settings for text editing. In case of image it will show other settings.I think the content of "Content" and "Geometry" panel will be really huge. It is hard to say if both fit in one screen (depend on inch size :D). But a user has some options:

1. drags out one panel and put it next to the other one2. uses icon on right side for auto scroll to the wanted panel3. collapses the features for every panel (currently there are 3 states; 1 collapsed; 2 normal; 3 advanced)

I like it so far.. really impressive work. We're considering merging it in as the work for Scribus 1.5.3. Some comments for now:- the "group box" for the palettes has quite thick borders and feels a little unwieldy. Maybe it could be thinner?- do we need the "group box"? Can we just push palettes together to get them to stick?- or can we get multiple of them?

I'll play around, and see what else I can find for improvements. However, again, its really cool, keep up the great work.

I have not yet looked at the linking to main code.. to be done once we get 1.5.2 out the door.

i've quickly tested the latest updates and like the responsiveness very much. big thanks to the developer, i think you're making some people very happy, including me :)

- indeed the 'group box' borders could be much thinner (but i'm assuming you're leaving the design and polishing part for a later stage)- the top panel(s) now takes priority and spreads across the whole width, with the dock/side panels underneath. is there a way to make the dock/side panel take up full window height and keep the top panel to the left of it? not sure if that makes sense, i might be totally wrong, but from experience i know the top panels rarely have enough icons/items to fill them up up to the right border, which results in an unoccupied gray area in the top right. would be great if the gray-area would be rather occupied by the always-busy dock/side panel.

- the vertical toolbar with one icon per docked palette- how it slides to an open palette when clicking on the icon- shuffling around the buttons and the palettes

what i did not like:

- expanding/collapsing dialogs. i might be suffering too long under the corrent PP, but really don't see a reason why somebody would be more effective by collapsing and expanding them. the solution in inkscape -- very similar to your icons, but with longish vertical buttons -- is better.(- imo, expanding of parts of palettes should also be avoided... but can sometimes be useful...)

i think that we should create widgets that optimally use the available space and refrain from hiding the bad work by collapsing it...

my whishes:

- i'd love to have a docking area on both sides of the screen (in the future also top/bottom... if we can have horizontal widgets for the palettes...)... but you might be already planning it...

As I've said before, this is looking great, but whatever solution is finally decided upon I hope it will not follow the current way Scribus works where, for example:* You select a text frame (for example)* You make changes in the PP Text tab* You de-select the frame to see how it looks unslected (or for whatever reason)* The Text tab is now "hidden" and the PP goes back to "X,Y,Z"* You re-select the frame to make more changes* You now need to re-select the Text tab

I find myself in this kind of situation very frequently and it's a tedious way of working having to keep re-selecting the same tab over and over again just because I want to see what something looks like when it's not selected.

Automatically going back to the last user-selected tab - if it's valid for the object(s) selected - would be much better.

Also, and I think I'm mirroring one of a.l.e's comments: Can the amount of scrollable areas in the PP be kept to a minimum? The last time I used 1.5.0 I was in the situation where I had three scroll boxes inside each other which was really confusing.

These small issues aside, I'm looking forward to seeing where this overhaul of the interface takes the software. A confusing UI is often the thing that puts new people off more than bugs or lack of features.

@MrB: It is not possible (and not planned) to group panels, like it is in Scribus 1.5.2. The idea behind is really simple, you has only one place where you can activate the panel which you want - by click on icon bar. In the current QDockWidget you can stack single panels but you have to find the right icons (tabs) to activate the panel.

The current IndigoDock doesn't support multiple Docks, but I have planed that for v1.2

@a.l.e: I'm not what do you mean with collapsing/expanding dialogs. Do you mean the panel itself or the single collapsable content within the panel? If do you mean the content I agree, it is not progressiv but we haven't to use these control element ;)I prefer to keep the collapse/expand function of panels, because every panel can be really huge and not all features of these panels are permanently in use. That's the reason for the advanced mode of every panel.

@All: I'm currently working on control elements for the panels. I could finish the graphical AnglePicker and the LabelWidget. The LabelWidget allows easily to add a icon and a widget. Furthermore you can set a string or another widget instead of the icon.

Take a look to the latest version on the attached screenshot or in GitHub repository.

At the end if I will fully support a horizontal dock I have to think about how will the panels fit in. But thats stuff for v1.2

BTW: I've created a simple click dummy to simulate the behaviour of edit geometry and content of a text frame. By click or double click on it it will show the linked panel and scroll to it if it is in the dock.

Martin, Heads up, that this week April. 15 is when Libre Graphics Meeting is starting in London. Perhaps, if you were planning to hack on indigoDock that it would be strategically done while LGM (http://libregraphicsmeeting.org/) is happening. I believe Scribus project will receive some good traffic during that time from FLOSS developers and enthusiasts.

I've also been tagging issues on the bugtracker with 'indigodock' showing what the project might address if/when implemented in to the scribus code base.

In file included from ../indigoDock/main.cpp:1:In file included from ../indigoDock/mainwindow.h:12:../indigoDock/indigoiconwidget.h:1:9: warning: 'INDIGOICONWIDGET_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]#ifndef INDIGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~../indigoDock/indigoiconwidget.h:2:9: note: 'INDOGOICONWIDGET_H' is defined here; did you mean 'INDIGOICONWIDGET_H'?#define INDOGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~ INDIGOICONWIDGET_H1 warning generated.

In file included from ../indigoDock/mainwindow.cpp:1:In file included from ../indigoDock/mainwindow.h:12:../indigoDock/indigoiconwidget.h:1:9: warning: 'INDIGOICONWIDGET_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]#ifndef INDIGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~../indigoDock/indigoiconwidget.h:2:9: note: 'INDOGOICONWIDGET_H' is defined here; did you mean 'INDIGOICONWIDGET_H'?#define INDOGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~ INDIGOICONWIDGET_H1 warning generated.

In file included from ../indigoDock/indigoiconwidget.cpp:1:../indigoDock/indigoiconwidget.h:1:9: warning: 'INDIGOICONWIDGET_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]#ifndef INDIGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~../indigoDock/indigoiconwidget.h:2:9: note: 'INDOGOICONWIDGET_H' is defined here; did you mean 'INDIGOICONWIDGET_H'?#define INDOGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~ INDIGOICONWIDGET_H1 warning generated.

In file included from ../indigoDock/build/debug/moc_mainwindow.cpp:9:In file included from ../indigoDock/build/debug/../../mainwindow.h:12:../indigoDock/indigoiconwidget.h:1:9: warning: 'INDIGOICONWIDGET_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]#ifndef INDIGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~../indigoDock/indigoiconwidget.h:2:9: note: 'INDOGOICONWIDGET_H' is defined here; did you mean 'INDIGOICONWIDGET_H'?#define INDOGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~ INDIGOICONWIDGET_H1 warning generated.

In file included from ../indigoDock/build/debug/moc_indigoiconwidget.cpp:9:../indigoDock/build/debug/../../indigoiconwidget.h:1:9: warning: 'INDIGOICONWIDGET_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]#ifndef INDIGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~../indigoDock/build/debug/../../indigoiconwidget.h:2:9: note: 'INDOGOICONWIDGET_H' is defined here; did you mean 'INDIGOICONWIDGET_H'?#define INDOGOICONWIDGET_H ^~~~~~~~~~~~~~~~~~ INDIGOICONWIDGET_H1 warning generated.

I think it is better to post errors in GitHub repo. Otherwise we grow up the thread here. ;)

BTW: I could finish the first alpha version of save and load workspace files to restore UI layout. But it supports currently only panels, like:- order in dock- expander state (normal, advanced, collapsed)- dock state (docked, floating, hidden docked, hidden floating)- position on screen for floating panels

I've made changes for panel expander state. Now it isn't anymore possible to collapse panels. I agree with a.l.e. that is senseless to have a collapsed state, because it takes only space and have no benefit.

So, I reduced the states to 'Normal' and 'Advanced' only. The advanced widget container doesn't exists anymore too. Now, all advanced features can be controlled only by a signal which will send from panel. That means now it is possible to switch on / off single widgets in main panel content and not only in a container below the main content as before. See attachement for an example of the new 'Normal' / 'Advanced' states.

Martin, Very cool! some feedback: in order to get the extended view one has to click on the small arrow which is a very small target...for ease of workflow, can we extend the area of the un/collapsing function along the whole head of the panel instead ?

Hello all especially TIM_OCC,these ALL layout designs looks GREAT!!! I must say that Scribus needs UI redesign MOST OF ALL features planed because original UI is TOTALY COUNTERINTUITIVE!!! I wonder how such a UI DISSASTER could be created in this century :o :(

well, if you have seen the scribus code and have an idea about how UI decision are taken, i think it's not that hard to guess why the scribus UI is not as good as it could be (ehm ehm ehm).

- as a programmer you create a feature as a prototype. and the hardest part is to get all the edge cases right. a basic UI is enough: we can improve it later. and later is... well... later

- when the programmer does not use the product (much), he will have a hard time doing the right UI decisions. imo, the worst offenders in scribus are the choices done by completeness (there are a few features that are completely useless, but they have been added because theoretically it's the same as other features that are useful).

- in the same spirit, if you create something, which is in a similar part of code as something else, you will put it next to that one in the UI. exposed in a similar way. there is nothing that could possibly go wrong. or not?

- finally, when many people have complained about how ugly the interaction is, the programmers somehow gets it, that it's time to do some changes. but there are already so many wires behind the scene that would have to be changed, that we will do that when we do that planned feature (which needs a new UI). of course, the planned feature will take much longer to get out of the planning stage...

ah, then you will have all those user complaining because you have changed something and now they cannot keep thy crazy habits (that were needed because the UI was terrible... but now they are used to it and produced workarounds they can live with).

so: it takes much effort to create a good UI. and, sadly, we have too few people, who care about a good UI and -- at the same time -- have the patience to stay on it for a couple of years and make things change.

but one such person is here and with a bit of luck (after many months of efforts!) we will see a big improvement soon!

p.s.: the considerations above are not specific to scribus but apply to many projects where UI is a second class citizen... and there are many such projects, not only in the open source world.

When I started to learn to use Scribus I believed Scribus had a larger and faster moving development team than I now see. I could see no good reason for the large number of UI errors I kept falling over, many rather basic.

But, now that I know the team is small relative to the task at hand, several responses seem appropriate and I have adjusted my expectations from "smooth sailing" to "I can probably sort out a workaround".

After reading here and elsewhere that many substantial UI issues persist for a very long time, and seeing them remain, I think the Scribus website greatly over-promises, and then Scribus under delivers. That is not to say Scribus is not very capable, but that by setting user expectations far too high, the real Scribus can only deliver disappointment. That is a bad outcome in several ways. It must drive potential users and contributors off so soon that they give nothing back. No money, no feedback, no code...

Over-promising is easy if you already have discovered the workarounds and the features to avoid. Easy if you are familiar and know the neighborhoods to avoid. How many potential users have left when utility just wasn't there or difficult to find, and badmouthed open everything?

I wonder if it would be good to disable - just grey out - weak functions that have better implementations elsewhere in Scribus. Things like styles are a mess to create and use. (Yes, I have figured them out, but only because I fell across the answers by mistake) Can we just kill off thestyle drop downs in the story editor since they seem not to do the job? Much more experienced users than I seem to say that the story editor is a chancy tool and that if you can avoid it, it is usually best. Since the documentation seems to laud the story editor, it took me a while to start avoiding it.

Darn it, Scribus IS a worthwhile project. I find myself getting fluent and choosing it for more and more tasks. It deserves better PR, better documentation, and a more unified UI. The issues I am running into are probably driving away money and public support. Adjusting user expectations lower might help.

I think we don't have to talk about that Scribus needs a new UI, and many reworks for usable workflows. But there is to mention that the Scribus project is not developing by a high paid developing team which can work more than 8 hours per day on it. It is made by free developers which can work only in their free time. It is not like Blender or Ubuntu which have a company behind to pay for developers to work on it.I started these UI project in early 2015 - more than 1,5 years ago and it is not done yet. The reason why I did it is really simple. I wanted to work efficient with Scribus and was more busy to handle the UI than work on my projects. So, Scribus has great features but mostly unusable in daily professional work. However thats not new, but we are working on it. Not fast as could be but we do our job.

I think Scribus is in a vicious circle. Less people are interested in because of bad usability, but without a bigger community it is hard to find developers / designer which will/can work on it. You can have the best product, but with bad ads or a bad packaging nobody want it (I think only Amazon have success with bad user interface :D). Ok, I believe if Scribus would have a great UI the community will grow fast and will pull more contributors in the project.

However, at the end some good news. I could implement the whole IndigoDock in Scribus but I'm currently fighting with some compiling issues. If I have more progress I will let you know it ;)

can i suggest you to recreate the repository as a copy of the current github code and make your changes a "public" commit?currently, i have the feeling that some of your changes are already in the initial commit...

the idea is that each commit has meaningful title and introduces a "single" change. in that way one can have a look at the commits and understand what you have changed and you don't need to write down everything in the readme.

a summary of the changes in the readme is of course useful, but you can keep them shorter and reference to the relevant commits.

you can have a look at the CTL branch on github

https://github.com/HOST-Oman/scribus/commits/ctl

to see how HOST is managing it :-)

once it's setup i can help you with keeping it in sync with the scribus development...

thanks for the hints. I have updated the repository. Now, there is only one inital commit with origin Scribus files which can be compiled and there is a second commit with IndigoDock integration which can't compiled.

Yes, thats why I have troubbles with debugging... But without my code it works. Maybe something will wrong initialized or get wrong datatypes. While compiling I got sometimes internal memory errors too.For now I have to find a way for a better dedugging option with cmake.

short update. I decided to stop developing of IndigoDock as single project as seen on https://github.com/nitramr/indigoDock. My code doesn't fit well in current Scribus code base.

Now, I'm full focused on integration of IndigoDock in Scribus and all necessary optimizations and upgrades. In short words: I'm developing a special version of IndigoDock which fits perfectly in Scribus code base directly in the Scribus code. Later I will put back the improvements and useful upgrades to the original separate project that others can use it for their application.

Working Scribus Version which uses IndigoDock you can find here: https://github.com/nitramr/scribus-indigo

Work in progressCurrently I'm on restoring the panel and dock settings for workspace saving. And I'm on fixing some UX issues. But basic integration was successfully and the dock is usable. ;)

Working Scribus Version which uses IndigoDock you can find here: https://github.com/nitramr/scribus-indigo

I happened on this topic using 'show unread posts since last visit', and read some of the earlier posts to try to discover what it is all about - which I think I understand, but not fully as I am only a recent user of Scribus. In earlier posts you appeared to ask people to try out your work, and I wonder if that still applies, and to noobs like me, or just more expert users. If the former applies, could you provide instructions that lead a novice like myself by the hand to install Scribus with Indigo, as the list of files that appears on selecting the above link is daunting to say the least.Thanks, Don

thanks for request to check it out. Currently there is only the source code available, because the version is not ready for a stable release. It is in alpha state only, but usable with some issues.

If you want to check out the current Scribus version with indigoDock you have to complie it from source code. You can use this introduction from Scribus Wiki to compile it from source code. https://wiki.scribus.net/canvas/Building_SVN_versions_with_CMake#Build_from_Source

I think this intro is only helpful if you are using linux. I'm not sure how to compile on Windows or Mac.

Note: My version is an inoffical branch from Scribus.

greets,Martin

PS: if there is a stable version I will provide an easy installable version for linux (Ubuntu). For other operation systems someone with other OS than me has to compile it.

Thanks for the prompt reply, Martin - which tells me that I'm not really able to be involved at the moment. I recall trying linux some years ago, when my brain was younger and more able to cope with new concepts. I'm now rather an old dog unable to learn many new tricks, so I guess I'll have to wait until you guys make it simple to use with Windows 10.

From what I did read, it seems that you have put a lot of thought and work into the project, for which one day I'm sure many people will be grateful.

short update from my side. I could improve the new dock and could fix some bugs (only 1 known is left).In the last GitHub Version Scribus got a startup layout, which means all panels are visibile on startup and can be arranged later by user.

If I can fix the last bug I will take a look to the panel layout and make some improvements there.

BTW: I got some help for auto generation of an end user version of Scribus. But there are some troubles in the binaries, so if we can solve it we will have a deployable application for massive testing on linux ;)

BTW: I got some help for auto generation of an end user version of Scribus. But there are some troubles in the binaries, so if we can solve it we will have a deployable application for massive testing on linux ;)

Yo Martin, Exciting. Once it works lets prominently display it for people to test. Also perhaps you want to offer some insight for devs that may be interested in submitting patches ? Like how you'd appreciate the patches to be submitted etc...?

today I want to present a test version of the Scribus Indigo branch. https://transfer.sh/14TFxp/scribus-git43554ee-glibc2.14-x86-64.appimage

This version contains:

new dock + panel layout

dark and light icon set

dark and light theme

I have replaced the old theme switcher in settings where you could switch between styles, like Windows, Breeze, GTK+ and Fusion. Now the new theme picker based on Fusion style plus addition CSS definitions.Default is the dark theme, but you can switch it in settings.

If you want to use Scribus Indigo, please make a backup of your ".scribus" folder in home directory and delete the folder. It is a hidden folder. The old settings generate conflicts with the new themes.

greets,Martin

PS: In some tests with AppImage file we had issues on some linux distributions with missing Python libs.

I have created a wiki page which contains some more infos about the Scribus Indigo project itself. Here you can find a download link to latest appimage file and a roadmap. In next time I will extend this page / pages step by step.

Check it out and make a bookmark if you want any time the latest version ;)https://github.com/nitramr/scribus-indigo/wiki

The screenshot below shows my current standard UI-setup for scribus 1.5.3svn applied to the Indigo-AppImage.The orange coloured text is added by hand, since the latest AppImage (Ubuntu) doesn't show any text there. I also changed the terms "Properties" and "Text Properties" to "Frame" and "Content".

My wish: I would like to see all the sub-menu/sub-panels (Drop Shadow, Shape, ...) in "Properties" and "Text Properties"moved to the "icon"-panel on the left side.

The other panels like "Align and Distribute", "Scrapbook", "Layers" and so on, I would rather arrange the way it's already possible with the latest scribus-svn. So e.g. I can have the layers panel in a fixed position and always visuable .

I don't know, if that's the way the ui-changes are planed to be anyway ...

currently there is no finished design concept. So, it is still open for more input. If I get you right you need only an icon bar in the Frame panel or do you need only a split Frame (Properties) panel into single panels?

For the overall design concept I found some nice User Interfaces and there is a new common trend. It is a quick access/tool bar. It is similar to my old proposal as described here:https://docs.google.com/presentation/d/1M6R4ggFbgU1EXbWiL8hwppyQJhsNnUlw7_7rOA3Im1Q/edit#slide=id.gcb561e9b3_0_9

I think such tool bar will be really useful.

Check out the application screenshots in attachement. I like the way that the apps are simple but have all advanced features.Focus is on most often used features and basic settings. Features which are not often used are in a "second navigation layer". These advanced stuff is accessible on same places where the basic settings are.

In the end you have all important stuff on one screen and if you need more detailed settings you can show it by one click. I think it is also a good idea for Scribus to put the advanced features in a second layer:1. to have a clear interface2. to make it intuitive

I'll give my vote for having a quick-access toolbar. They can be very useful.

For instance, it would be much easier to change the outline colour of a shape by just selecting from a drop-down on a toolbar rather than navigating to the Colour tab of PP, making sure you have Outline selected and then changing the colour. It's this sort of long-winded navigation that makes Scribus a bit of a pain to use sometimes.

Selecting which tools to show on the toolbar at any given time might cause a bit of an argument but I think it would be well worth the effort.

Forgive me for asking, but isn't that what the IndigoDock is all about?

My impression of the project was that it was going to make the PP more flexible while also removing clutter with the ability to collapse dialogs/palettes into icons.

If dialogs can also be docked/undocked then that's pretty much like the LibreOffice palette isn't it? Or am I missing something? (That's entirely possible as I've not used the IndigoDock myself and don't often use the LibreOffice palettes as the toolbar is usually good enough for what I need.)

yes, this what indigodock is about.that's why i'm talking about the pp in here : - )

for now, i see indigodock as a testbed for the dock, with a sample implementation. and with a bunch of screenshots as its bases.now we know what is possible and we have a code base that we can eventually use for mocking ideas.

my point: i'd like to sit down and have a chat about how the new PP should work. and produce a document that states a bunch of recommendations for the PP.

we can start with the current state of indigo dock (which is the result of multiple experimentations) or from libreoffice (which is a product that is not thought for DTP, but has the advantage of being a finished product... (and being free software so we can freely "copy"/borrow from it)). or from both.

Ah, I see. I thought you were proposing to start another "rival" project. Got myself a bit confused there. Sorry.

I can't really comment on IndigoDock as I've not used it and, as I said above, I don't have much experience with the LibreOffice palettes. (My use of LO is so basic I only need the toolbars but the palettes look nice.)

I don't know those other applications well enough to sort out how exactly they relate to the points at hand, but the idea of having the most used tools and properties closer to the surface while eliminating the visual traffic jam feels good to me. I'm in favor of things that hew to GarryP's description, "My impression of the project was that it was going to make the PP more flexible while also removing clutter with the ability to collapse dialogs/palettes into icons".

I find myself wishing I had faster access to several items. If I am off topic here - please ignore or let me know an I can re-post when and where more appropriate.

The tools that I wish were right at the surface are - at least as I can recall this moment:

Thinking about interface and the icons that line the edges of the app, I would love to be able to customize by putting most of them away. I try to use keyboard shortcuts. Somehow remembering what some icons do is not a strong point for me, and trying to pick out the one I want out of a mass of little minimal graphics slows me down. In LibreOffice, the first thing I do when installing is get rid of almost all icons and save only the few I actually use. Every once in a while. I add another icon as needed.

Again please let me know if this is relevant or off topic. Everyone has plenty on their plates and I'm not trying to suggest we re-invent too many wheels at one time. So, is this pertinent to the IndigoDock?

I agree with a.l.e about the property panel (if you are talking about libreoffice 5). It is similar to the layout what Scribus currently have and also what big player uses (like Sketch).

In attachment you can see what I have in mind for Scribus. The property panel have a main section for necessary settings and addional sections for optional settings.Optional settings are not "enabled" by default, so the input fields are not visable and Scribus have to use some default values, like contour color = none and width = 0.

For every object we can define a preset of settings in the property panel.Example: Rectangle -> Geometry and Fill color have some pre-filled values.Example: Line -> Geometry and Contour have some pre-filled values.Example: Text Box -> Geometry and Basic Text Options have default values.

Furthermore we can put some quick actions (icons) on right side of the section header. Like: enable/disable feature, show/hide advanced settings, show style editors, etc.

Just put some thoughts together. Perhaps this has already been discussed. Please ignore me if it has! ;DI guess the main idea is condensing the interface a bit and re-evaluating the existing divisions in properties. Currently settings for various typography features are spread amongst too many tabs as an example. I think this is hindering the full potential of Martin's awesome scrolling feature. There are secondary sections within the "text" section for example that need to be navigated through for some opentype stuff, etc.

I haven't been able to test the integrated indigo app version as I'm on windows so I may have missed stuff.

It might be interesting to look at the interface from a photo editing program called Darktable. It has potentially valuable ideas.

There are none of the usual drop down menus. Instead almost all actions are driven from panels on one side of the screen. See PanelClosed.jpg

The panels each drive a single kind of action. The panels expand fully so that the controls for a given action are completely available. See PanelOpen.jpg

The selection of what panels one wants to be visible and available can be customized with a couple of clicks. One can "put away" unwanted panels or re-introduce them, to allow fast and least cluttered access to the ones one wants. And that is the notion I hope I am explaining here, that the ability to quickly adjust one's interface gives a fluid and uncluttered workplace.

Btw I see the Scribus bug tracker roadmap for 1.5.3 is at 95% currently, which is exciting :)

@Martin,Are there any issues/ideas in particular you'd like to discuss for clarity/community feedback?Are the existing panel sections in the non-indigo Scribus app set in stone, or can you recategorizesettings as you see fit?

I want to show something. Based on the last propsals and posts I reworked the Property Panel.

My proposal below show only the "frame" panel. The image section as well table section will be located in "content" panel together with text settings. Only group settings still missing in my propsal. It needs more brain, because most of the group settings are copies of shape and transparency section.

The idea behind such UI is to have minimal basic settings of most often used settings. Every setting, e.g. color represent only an "access point" which you can edit in a separat dialog / popover. That save a lot of space if we put the setting details in a second level. Furthermore we can reuse all level two dialogs / popovers on different places.

I think at this point we can discuss which features / settings have to be in level one and level two.

BTW: the power on/off icon will expand or collapse the section body + enable or disable the settings for the selected object.

I think a simple post is not enough to show all details. If you want to see more details take a look to my presentation. There you can make comments to specific elements too.https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.p

Have in mind that the layout is not written in stone. It is just a proposal and can be refine, change or rework in any direction. It should keep a community project. ;)

Step by step I will extend these presentation with more UI propsals for other panels, dialoges and other places. I hope I will find a good way to merge all of your ideas into one useful concept.

Is it fair to toss out a group of ideas and responses? A couple of responses - positive - as I look at your beautiful work: I immediately like the idea of putting level in the shapes panel. Knowing a level numerically would assist navigation.

I really like your emphasis on a compact presentation of the components of each panel. Since I am often working on a laptop, not an ideal tool for DTP, well fitted information and data input will make life easier. I suspect that the original format was developed with desktop size monitors in mind, an entirely reasonable assumption, and the increasing usage of smaller devices is an unforeseen limitation on viewing space. Your design seems to present excellent visibility without losing clarity.

I also appreciate the inclusion of shape, borders, and drop shadow into the frames panel - less jumping around to access related activities.

I may be missing something right in front of me but I'm not seeing a text properties panel or dialog in your presentation. Do you see that as a panel? I suspect so. And do you see it remaining much the same or changing significantly? Might a button connect text properties dialog or panel to opening the style manager?

Also, what do you have in mind for text and paragraph styles?

Usually I argue for very compact dialogs for space economy, but whatever happens with the dialog to create new colors - Edit>Colors and Fills> Add - color creation dialog might want to be a bit more generous in size. It can be fussy to do precise color picking in the existing dialog. The little window that shows the whole spectrum and gradations of saturation is quite small. There appears to be opportunity to rearrange as well as enlarge the whole thing were it to me.

The old vs new windows should be larger and touch seamlessly. Fine gradations of color are more difficult to see when separated by any visual barrier. The resulting interface would be less visually appealing but better for actual color work.

I have mocked up a rough sketch of a color picker dialog with more area given to the color picker window, and adjacent before and after color windows.

A question for everyone. How much do you use "Align and Distribute"? Does it make any sense to incorporate a button to invoke "Align and Distribute" from frames / shapes panels? I don't know for myself. I can see either answer.

Layers - Do Layers deserve a place in panels? I'm not sure if this is part of your "panels philosophy". The availability of a shortcut (F6) makes it a less urgent question, but it still pops into my head that the panels and properties may be a logical launching point for things like this - just a button or a panel?

thanks for your quick feedback. You are right, the text properties are not in my presentation. I will do some stuff later on it. ;) I'm not sure if you know it already, the developers have extracted the text properties from common property panel. There is a floating idea which split all properties into 2 diffent panels. One panel hold all "frame" properties the other one all "content" properties. So, frame size, drop shadow, border and fill color will be "frame" related. Text, image and table are content related and will be in the second panel.

My proposal show only the "frame" panel. Later I will take a look to the "content" panel, because the restructure of the text section will be a bigger effort for me.

For the Text properties I can image to do it the same way as I show in my proposal. You have some combo boxes to choose your paragraph or character style and your can open the edit dialog on text property section. But lets see.

If I'm thinking about the color sets and color mixer it is a lot of work to unify and simplify that colossus.Personally I never used much different color sets. It is enough for me to have a local one which I fill easily step by step with colors while I'm working and not in the beginning before I make anything on the document. I can imagine to have one common dialog on all necessary places to edit the local color set. If a user click on a color field it opens the common dialog where the user can edit the palette, select a pre-defined color from color set or mix a new color. I think can be simple and clean without much clutter. See attachement.

For layouts I use really often "Align and Distribute" functions, but I think a good auto snaping feature can reduce such usage. (But only if the snaping tool show distances between objects).I think for scribus it can be in a separate panel, because there are a lot of options and possibilies to use it. Some other layout applications have only few buttons which they can group with other features.

About the layers, I think it should be a separate panel. It is your only possibility to sort objects in Z-level on one place. For complexer layouts it is essentiell. Why not keep it in it's own panel?

The attachement show different color picker from other applications, but in general I think to merge the scribus "Manage Color and Fills" dialoge and the "edit color" dialog into one for all places.

Are the mockup graphics you're using available for download by any chance? Would be nice to play around with ideas if I can find some time :)

My thoughts:I would prefer if layers was left as a panel; I think it's essential for complex layered typography+illustration projects. Judging by the animation gif on page 9 of this thread though, it looks like you can close the panel if you wish to save space @CGood? Maybe I'm wrong on this (?)

Do you think Align and distribute buttons could fit into the XYZ panel beside the flip buttons in your mockup @Martin? Not sure how everyone else feels about this though... I tend to be distrustful of snapping but perhaps others feel differently :P I do think displayed distances would be needed, as you say, in the absence of these buttons.

Yes, you can have the mockup file. https://mega.nz/#!XN0iwSiL!Y6gJa9Kh3196PkdGNU85eGscP0FoaQ4odWMNPEXNhp8 (443KB)

But you will need Gravit.io to edit this file. http://designer.io/ (it's free)You can use it in your browser or as desktop application. But it is a bit slow. At this point if someone knows a better tool let me know. Unfortunately Inkscape is not much better.

Yes, you are right, as long we will have the layers in a separate panel you can close it to save space... but I know someone will need layers, he/she can show the panel. If we would merge such features into the property panel you can't hide the section easily. The same for alignment and distribution panel.

I think for alignment and distribution it makes no sense to have it in property panel because it is not a property function. And for the alignment-snapping tool... yeah it is another topic which we can discuss later. :D

Martin: I'm not sure if you know it already, the developers have extracted the text properties from common property panel.

That sounds like an excellent jumping off point.

Martin: split all properties into 2 diffent panels. One panel hold all "frame" properties the other one all "content" properties. So, frame size, drop shadow, border and fill color will be "frame" related.

I like that, gathering connected tools closely!

Martin: Text, image and table are content related and will be in the second panel.

I like that too. I suspect that with a lot of topics to control from the Content Panel, there might be pop ups or flyouts to drill down to the many moving parts?

Martin: My proposal show only the "frame" panel. Later I will take a look to the "content" panel.

I really like the thinking on everything so far.

Martin: If I'm thinking about the color sets and color mixer it is a lot of work to unify and simplify that colossus.Personally I never used much different color sets. It is enough for me to have a local one which I fill easily step by step with colors while I'm working and not in the beginning before I make anything on the document. I can imagine to have one common dialog on all necessary places to edit the local color set. If a user click on a color field it opens the common dialog where the user can edit the palette, select a pre-defined color from color set or mix a new color. I think can be simple and clean without much clutter. See attachement.

I like the idea of gathering related functions together so that one's instinct is to more naturally go to the right place. Use of the current interface involves remembering the different places various functions can be accessed and some hopping back and forth.

The GIMP and Indesign images you attached show the before and after color patches touching - one thing that greatly helps with more precise color thinking.

Martin: For layouts I use really often "Align and Distribute" functions, but I think a good auto snaping feature can reduce such usage. (But only if the snaping tool show distances between objects). I think for scribus it can be in a separate panel, because there are a lot of options and possibilies to use it. Some other layout applications have only few buttons which they can group with other features.

I'm not sure I understand "But only if the snaping tool show distances between objects". Do you mean that the snapping radius might be a visible line around an object?

I don't tend to use snapping much. I might use it more if there was a handy way to turn it on and off quickly, but that is very low in my shopping list.

Martin: The attachement show different color picker from other applications, but in general I think to merge the scribus "Manage Color and Fills" dialoge and the "edit color" dialog into one for all places.

I notice that an eyedropper color selecting tool is in the other program's dialogs - I think that is appropriate in a color picker panel or dialog.

Cloudbusting: Do you think Align and distribute buttons could fit into the XYZ panel beside the flip buttons in your mockup

If it is feasible, that sounds like another instance of putting related things together and making overall navagation and productivity faster and easier.

Martin: as long we will have the layers in a separate panel you can close it to save space... but I know someone will need layers, he/she can show the panel. If we would merge such features into the property panel you can't hide the section easily. The same for alignment and distribution panel.

I think for alignment and distribution it makes no sense to have it in property panel because it is not a property function. And for the alignment-snapping tool.>>

I'm unsure what you mean in "property panel" and "not a property function". By "property panel", do you mean the XYZ panel?

Are you thinking Layers and A&D should each have their own separate panels? I am not objecting, but merely trying to understand your thoughts.

<rant>There is a lot of great work and discussion going on here so I won't try and get in the way, but I think I need to add my two-penneth about colour editing (as it has already been brought up).

I've said this elsewhere but, for my purposes at least, the current tools for colour editing/maintenance are archaic and require way too much work to use easily. Having to go into a modal dialog and then into another, then change the values, then OK out of the two dialogs just to change a colour is, to me, a very long-winded and, frankly, silly process.

Adjusting a colour until it's right can be a very long process consisting of many dialog-openings and button-clicks that really shouldn't be necessary, especially not in 2017. Colour manipulation is a core DTP function so why does Scribus make it so damn awkward to do?

If any changes are to be made about how Scribus lets users use colours then I think the whole area needs to be looked at from a root level to make it as easy as possible.

It would be a great pity for the UI to have all of these really nice improvements while also keeping such an old-fashioned and long-winded process in place. A little bit like giving a house a complete make-over with new doors, windows and furniture, but leaving the stained and tattered old carpets in place. It just doesn't make sense to me.</rant>

P.S. The "Before and After" colour swatches in any colour editing dialog/window/area need to be abutted against each other. Having a gap - as is currently - makes the whole thing pointless when you're making subtle changes as your eye "recalibrates" on the colour in between. (In other words, in the time your eye has moved from one to the other it's already seen a different colour so you can't see the difference properly.)

I'm not sure I understand "But only if the snaping tool show distances between objects". Do you mean that the snapping radius might be a visible line around an object?

Yes, I mean it should show the radius. Maybe snapping is the wrong description for that. I have something in mind like Google Slides do it (see attachment).

@a.l.e.: In that past I tried out Pencil 3 but it doesn't allow custom shapes and also it is hard to import custom icons. But all over it is a nice tool, yes.

I thought about the color picker. And now I have an all-in-one thing. :D It can be used on all places where colors, gradients or patterns can be set.I'm not sure if it is to complex at the moment. But you can manage your color palettes, gradient sets and patterns.

@Garry: unfortunately it is not a root level element yet. But if you will click on such small "color preview" in property panel it will open this new dialog. Important is that all changes which you make in the color picker should instantly apply to the object in the document. Otherwise is it a guess how does it look at the end. That is why there is no apply button.

regards,

Martin

PS: the empty buttons in left down corner of the color picker can be uses to import colors/gradients from other sets or to filter the list or to save/load the set.

Making the actual HSV "rainbow" color picking window larger would mean that manual dexterity is less taxed to get any desired degree of precision of color selection. This may not the place to be saving interface real estate. The current size feels too small to me. Any given movement of the mouse makes too big a change in color. I cannot make movements fine enough to make subtle changes. I am a painter and color relationships matter to me. I feel like I am unable to control color. I feel like I make big sloppy changes even when I put 100% concentration into controlling my movements.

Another possibility - would arrow keyboard input be usable to nudge the control point within the rainbow? I see that I can influence the sliders below, but would it make sense to retain the focus on the rainbow window, and allow very fine movements via arrow keys? Just an idea. If any good, I imagine this could get added now or later.

GarryP, as usual, cuts directly to the heart of the problem in the color dialogs. At an absolute minumum, it takes eight clicks to set a new color. I am sure that could be reduced.

There are other places where intermediary dialogs have to get clicked through with no benefit. Adding glyphs off the keyboard is the same. First it takes two clicks to get to something called the "Character Palette". Then, since that is just a conduit to Glyphs, another click, and then I have arrived at the "Enhanced Character Palette". And then, rather than using the logical process where a single click would only highlight a glyph, and a double click would enter it in text, a doubleclick merely puts that glyph in an intermediate state. Then it takes yet another click to enter the glyph into one's text. Then I need two more clicks to back out of two dialogs. In sum, it takes eight clicks or more to invoke the dialogs, insert a glyph, and back out of the dialogs.

I see no benefit from those intermediary dialogs. I would be very pleased if the number of functions that tale one through useless screens were reduced.

Beyond that, enabling a different and more emphatic action from a double click than from a single click makes for efficiencies with little downside. I don't know if there are other places differentiating between single click and double click actions could be useful?

<rant>I feel the same about the text editor. I do remember reading somewhere that it does have some value, but for the life of me, it feels like one more wall, one more set of avoidable clicks, one more interference, between me and doing design. Why should I work in an interface where imoprtant modifications are invisible when I can just work inside my document where I can see what I am doing?</rant>

There are two things I want to speak to here. One is that the list of wanted features may at some point be just too much for Martin. For me, if we can make real progress, even if not perfect, I am in favor. Perfection may not be a valid goal. Martin please speak up if you reach a limit?

The other is that the scope of things that are being talked about might veer into layers of software I suspect no longer are "interface" features. I suspect that both the color dialog and the glyphs could each be unified much as a matter of a new interface and reconnecting interface controls to existing underlying functionality. But, I want to encourage Martin and the devs to speak up if my or anyone's requests start heading into the under-the-hood code. I don't see that here, but please feel free to direct me to the new features wanted list if I'm off topic on any commennts here. I'm not a developer so my view of what connects to what and how is just guesswork.

The effort is not to much for me. All the feedback here is very helpful to understand how Scribus will use and where are the biggest painpoints / frictions in UI. I think to get valuable user feedback is the hardest part in UI-Design. If you have specified problems you can solve it. :D

I think it is not posible to replace only one "feature" with a new one without updating another one, because all is releated - more or less.

About the scope I think we can focus at first for property panels (content and frame) and connected features. That includes:- color mixing and handling- styles (gradients, color sets, paragraph styles, character styles, table styles)- remove clutter in text editing section (focus on most important settings, all other stuff are advanced settings for a second level)

That will be a big rock, but it is dueable.BTW: this UI updates can be make independently of the IndigoDock integration, because it will work in the current Scribus user interface too.

I think I was not very clear in my description using the term rainbow window. I have included a rough sketch to show what I mean by rainbow window. All else in my sketch is merely context and I don't mean for the rest to be a suggestion. I trust you are on a very good path towards a cleaner, faster, less "click heavy" interface.

In the interests of simplicity - and to avoid the alienation of existing users - I would suggest that, at first, the UI isn't changed too radically when it comes to colour selection/editing. A lot could be done to improve colour selection/editing but I think some basic changes would make a big difference.

I don't have any real problem with how colours are selected via the PP. Things could be moved around a bit but the method of selecting a colour is relatively easy to understand for beginners and not a huge problem for experienced users. It could be improved but I think any changes in this area would make for a far larger change that is necessary and might have too many existing users complaining.

It's the colour editing functions that I have a problem with and my main problem is with the modality of the dialogs. Having to open a modal dialog and then another within that to edit a colour and to OK them both before seeing what a colour change actually does is a real pain, and can add many more clicks than is necessary.

If the two dialogs could be combined and that combined dialog was made non-modal - I.e. the same as the Layers palette - then editing colours would be made so much more simple. If I could leave this "Colours Palette" open and make adjustments on-the-fly it would make Scribus so much more easy to use and could even help to bring new users in as it's more what they are used to in other applications.

If this new Colours Palette was a wide window - as in some of the examples supplied - it would take up too much screen space if it was constantly open. I would suggest making it a thin vertical strip which could be docked to the side of the main window without getting in the way of what the user is doing. (See the very crudely-made attached mock-up.)

Basically, combine the two dialogs, make the combined dialog non-modal and change its orientation to vertical. That would do me fine and dandy, for now anyway.

NOTE: If the Colour Palette was non-modal - and therefore all adjustments were made "live" - there would be no need for an "Old/New" display. Imagine you move a slider and change a value to get the new colour. There's no way for the software to know which was the "real" old colour - the colour before the slider change, or the colour after the slider change but before the value change - so the "old" colour doesn't have any real meaning. So why keep it?

I agree with the vertical layout for the colour panel, I think it would be more economical as far as space goes. I think this is where the beauty of having a left and right panel area comes in. I can see myself having more "permanent" panels of user's preference on the left of Martin's UI, while making full use of the scrolling feature with the panels to the right.

GarryP, I'm not sure I am reading your post correctly. Are you referring at all to the Add Color function? I understand that you want to "Edit" live, and in a smaller panel than I might want, but are you also saying the panel space to add a totally new color should be similarly size constrained?

In your github post you ask,"Should the list of open palettes be linked to the document or to the Scribus instance?"

I don't know if I am answering your question or muddying the waters if I say 99% of the time I want the text properties to be want is open first. I use the XYZ far less than text properties. To me having the XYZ open by default is one more place where I have more clicking that gets me to the workspace I wanted all along.

I am a creature of habit and would prefer Scribus to open either to a default place I choose - Text Properties - or to where I left off last time. Does that make any sense?

a.l.e. I like the idea of an onboarding screen, where the user can choose options what he wants to do. The concept remembers me to photoshop, as seen here:http://pe-images.s3.amazonaws.com/basics/cc/2017/interface/recent-files-panel/photoshop-cc-start-screen.jpg

Some other applications include directly some tutorial videos there too. What is also nice for beginners.

About your open questions in the Git repository:

Quote

"Should the list of open palettes be linked to the document or to the Scribus instance?"

If I get you right, you are asking of storing the workspace layout (palettes layout etc.) into the document file, like blender do it?I think it should be linked to the Scribus instance and load from user profile. Lets say someone create a file with his own workspace layout and give it to someone else - it could break his workflow because of arranging the layout that fits to him.

What do you mean with "resource Window"? Is it the symbols/scrapbook palette in Scribus? I thought it is not document related, and I think it should be part of the user profile workspace. Or do you mean the ressource manager?

You can extent the dialog if you want to use the color palette or you can change the color picker mode. I agree with Garry, if there is a live manipulation you don't need much big color preview or old/new color.

We're very close to releasing 1.5.3 and once its out, we want to concentrate on 1.5.4 with integration of IndigoDock and palette redesign. We need to sync up on design and proposals etc. Maybe email me mrb@scribus.info and CC jghali@scribus.info

What I am proposing is that the "Colours" dialog - currently shown by menu "Edit -> Colours" - and the "Edit Colour" dialog - currently shown by pressing either the "New" or "Edit" buttons on the "Colours" dialog - are combined into one single non-modal dialog (or palette, depending on how you want to call it).

If the dialog (palette) is designed correctly then it could be resized as the user wants. My recommendation was that it should be able to be sized to fit into a vertical strip that can - if the user wants it to - be docked or simply placed to one side of the main canvas. If the user wants to make the dialog as short as possible then that would be up to them. Conversely, if the user wants to make the sliders as long as possible then they should be able to extend the height of the dialog to accommodate that.

CGood / a.l.e / Martin:

I'm not sure what "Should the list of open palettes be linked to the document or to the Scribus instance?" means. What "palettes" are being talked about - colour palettes or UI palettes (e.g. dialogs), or something else - and what constitutes an "open" one?

If palettes refers to UI palettes (dialogs) then I would agree with Martin that their constitution - open/closed, position, etc. - should not be linked to a document. There are many reasons for this, and Martin has already given one, but one specific case would be if someone using a very hi-res screen (e.g. 4K) passed a document onto someone else with a much lower resolution screen. The main window and the dialogs could have positions/sizes that are outside the lo-res screen area which could render Scribus unusable.

If, on the other hand, palettes refers to colour palettes then I think it would be nice if Scribus could handle multiple palettes within the same document. For example, if someone has a newsletter where the colour scheme changes by season - e.g. orange in summer and blue in winter - then it would be good if the user could easily switch between different variants of the same palette. In this way, the colour "Primary" could be orange in the "Summer" variant and blue in the "Winter" variant. Having this kind of functionality would also mean that the user could test lots of variations of colours while being able to revert back to a particular saved scheme without having to write down the colour values.

Martin:

I don't know how your "Colour Picker" dialog is supposed to work but I think the inclusion of gradients and patterns may have some problems. Gradients and patterns can only be given to fills and not outlines, therefore the user should not be able to choose either a gradient or pattern for outlines. How would you achieve this? Would the dialog "know" that you were picking a colour for an outline and not a fill?

I like the idea of keeping all of the colour stuff together, I just don't know how you intend it to be implemented. Maybe I have just not properly understood what you are doing.

General:

I think some confusion might be starting to creep in here about different dialogs for different things.

The change in functionality that I was suggesting for the "Colours" and "Edit Colour" dialogs - combine and make non-modal - are, in my mind, not to be confused with any kind of "colour picking/choosing/selecting" dialogs/panels/panes/windows.

To me, for DTP purposes, the act of defining/editing colours should be a different function to choosing/picking/selecting colours. The user should define the palette that they want to use and then choose from that palette as needed. A little like going to the DIY store to get the paints you want (defining the colours), then putting your brush in the right paint pot (choosing the colour).

Maybe there is a way of combining the two functions but I don't know how that could be achieved or how effective it would be. I think it would be better to keep the two functions separate. This forces the user to think about how they apply colour to their documents rather than just using whatever they want. I realise this way of working is a bit of a throwback to the old mechanical printing processes but I think it's important that Scribus keeps to this tradition even if most people don't get their documents printed the "old fashioned" way.

correct me if I'm wrong but you can set gradients for borders. (tested in nightly build 1.5.3.).

So, let my try to explain what are my thoughts about the color picker. My basic idea is to replace all color picker / mixer in Scribus with a common one. You are right patterns and gradients are not available for all objects - the color picker have to be context specific.Here is a showcase how the color picker looks like in different contexts:https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1b2d6150d9_0_19(Slide 9 and 10 show the color picker, slide 15 - 17 show the contexts)

The color picker itself contains a color mixer and one local color set (color palette) for the document.

You can access these color picker on different places:1. global as it is via menu bar: Edit -> Colors and Fills...2. in property panel if you set a color for: Fills, Border, Text

1) If you open the color picker via menu bar you can only edit your local color set by mixing new color, remove colors or import colors from other sets, becasue there is no context object. Further more you can edit gradient palettes or your patterns. This mode is for all users which want to have a global management.

2) If you open the color picker via property panel you will have a context object which tell the color picker which options have to be hide/disable. In this case you can also edit you local color set, but you can edit the object color too. In such case you will have a realtime color preview in your object. You can use a custom color by mixing the color directly in the mixer or you choose a color from your predefined local color set.

I have no idea what's going on in the 1.5.x versions so I can't comment on gradients for borders. I'm not sure what constitutes a "border" and why it's different to a line (as currently exists), or are they the same thing just under different names?

I think I can understand where you're coming from now but it might take a while for it to properly sink in. It goes against what I said in my previous post but if it's a better way of doing things then I'm all for that.

In what comes below I've used the term "brush" instead of "colour or gradient or pattern" as it seems to be a reasonably prevalent term and it's more concise.

So, if I've got it right so far:1. The "Edit -> Colours & Fills" dialog allows the user to create a standard palette of named brushes that can be used globally throughout the document.2. The "Colours & Fills" dialog allows the user to create, edit, delete and import named brushes.3. Any changes to the named brushes in this "Colours & Fills" dialog automatically affect any objects using those brushes.4. Essentially the "Colours & Fills" dialog is an extension of the "Document Setup" dialog but in a different place.5. A separate dialog - the "Colour Picker" - will be available.6. This "Colour Picker" will be available when an object is selected.7. It will look like the "Colours & Fills" dialog but will act differently, as below:8. The user will be able to select from the standard document brushes or create a new custom brush.9. The new custom brush will have no name and cannot be used elsewhere in the document (except if the user gives the same values or uses the eyedropper, of course).10. The standard document brushes cannot be altered in this "Colour Picker" dialog, they can only be selected.

Do I have a basic understanding of what's going on or have I missed something? If I have it right then it sounds like a good way to do things. Neat and understandable.

One thing I can add at this point is that I think it might be good to have an extra "Send to Standard Palette" button on the "Colour Picker" to allow a custom brush to be used globally. The user would give the brush a name, the brush would be inserted into the standard document palette, and the local custom brush would be changed to use the new standard brush. A big time saver.

I also have another suggestion: Would it be possible for these dialogs, when displaying a colour (not gradient or pattern), to have an extra rectangle to each side of the current colour? These rectangles could each display a user-selected colour (from the existing list) - defaulted to black and white - which would help the user to choose a colour in relation to colours already created. It's not a high-priority item or anything like that but I think it would be useful (if the whole thing is going to change then why not take things further?).

All in all, from what I've seen, this looks like it could be a massive leap forward for Scribus. It's "basic" things like this that make all the difference to using an application. If the basic stuff is difficult or time-consuming then it puts people off. Making something like colours much easier to use will make such a big difference.

In the color picker there is a "plus" button next to the color palette to send custom brushes to the list for a global usage. You can edit colors in palette by double click. The only thing what I have to think about is how can a user cancel the editing of a color in palatte to create a custom new one.

About the Line and Border wording... it is the same. In Scribus 1.5.3 you can use gradients for Lines as well for Fills. In my mockup I renamed "lines" to "border" because it is an often used wording in other applications for such settings. But I can rename it back to "lines". We can also use "contour". But wording can be a part of refinements afterwards if we have the basic concept done.

"Lines" properties such as thickness, dashes, corner profile, flat cap... currently apply to individual lines as well as borders of frames, so it applies to objects with line like behaviour. I assume that whatever the name for that panel, it would assign appropriate properties to single lines and to frame borders.

I want to be able to name colors when I create a new color - and - to be able rename them when my edit changes essential nature of a color. It sounds - GarryP that you are saying this too: "One thing I can add at this point is that I think it might be good to have an extra "Send to Standard Palette" button on the "Colour Picker" to allow a custom brush to be used globally. The user would give the brush a name, the brush would be inserted into the standard document palette, and the local custom brush would be changed to use the new standard brush."

I really like the idea that color edit changes be immediately reflected in the Scribus document. Several less steps.

Martin said: "The only thing what I have to think about is how can a user cancel the editing of a color in palatte to create a custom new one." A simple revert or cancel button to undo changes in mid process might suffice. I suspect no issue as long as the numeric color definition of the original color was to be held in memory to be reverted to.

GarryP - I am very fuzzy on the implications of the word "Brush" with respect to color in Scribus. Is "Brush" synonymous with "a tool to assign color" with respect to Scribus?

Outside the scope - I think - of the discussion so far is the idea that I'd like to be able to add colors to my default or persistent palette even if I have a current document loaded into Scribus. I suspect that may be outside of the scope of this current project but not knowing the code involved, I mention it. Perhaps in some future iteration - Scribus 3.0...?

On GarryP's assesment of the modal / non-modal behaviour of the color selection/ editing dialogs or panels.. "What I am proposing is that the "Colours" dialog - currently shown by menu "Edit -> Colours" - and the "Edit Colour" dialog - currently shown by pressing either the "New" or "Edit" buttons on the "Colours" dialog - are combined into one single non-modal dialog (or palette, depending on how you want to call it)", it would be wonderful if color picker/edit panels would not prevent interaction with the Scribus document while the dialog is visible. I understand that is called non-modal behaviour? I like GarryP's ideas for that very much.

I also like GarryP's concept that color edit / pick dialogs be resizable.

I believe it makes sense to have to select whether one is modifying color/pattern.. properties for fill or for line.

Martin: " My basic idea is to replace all color picker / mixer in Scribus with a common one. You are right patterns and gradients are not available for all objects - the color picker have to be context specific." Agreed on all points.

Again - this all feels like dramatic progress in making a happier interface.

"Lines" properties such as thickness, dashes, corner profile, flat cap... currently apply to individual lines as well as borders of frames, so it applies to objects with line like behaviour. I assume that whatever the name for that panel, it would assign appropriate properties to single lines and to frame borders.

Yes, exactly.

Maybe we should define some more wording terms to be on the same side.

Document Color Set (local color sets)It is your individual color set what you use in your document. If you make changes there it will affected only your local document.

Local ColorIs a color which is not contained in a color set. It is just local in a single document object, like a rectangle frame.

Global ColorIs a color which is contained in a color set. By changing the gobal color all linked objects will update the color.

Modal DialogA modal dialog is a single window which lock all other windows / UI elements of an application until a "confirmation" action in the modal was made.

If you agree we can use these wordings to explain things.----

So, the color picker have a color mixer to mix new colors by set color values or by picking a color from color map / color slider. Below the mixer there is a local color set which will only used in your active document. Next to the local color set there are buttons to load full external color sets or just single colors from such external color set into your local set.Further more you can save your local color set as an external one to use it later in other documents.

You can have local colors and color sets which you can extend by importing external ones or you can "convert" local colors and color sets to global ones.

(Here we go, it's another long post with a lot of different ideas stuffed into it...)

Martin:

Thanks for confirming that I'm thinking along the right lines. I was concerned that I might have got it all the wrong way round.

As for the naming of lines/borders, a "border" as the word is used in English has connotations of something that surrounds or divides things - which could be confusing - but a "line" is just a line, whatever it's used for. Continuing a similar logic, a "contour" could be confused with the "contour line" which is used for text flow. Might I suggest, following on from my use of the word "brush", using the word "pen" instead?

A "line" is something that is drawn through various points. (This could also be called a "path" but that would be confusing to users.) If we want to detach the concepts of points of a line from how the line is drawn then we could say that the user draws a line with a pen. The line stays as the collection of points but a concept of "pen" could be used to say how it is drawn.

Most graphics APIs use similar concepts and I think it's a good analogy for Scribus to use. People are used to drawing lines with a pen in the same way that they are comfortable with using a brush to paint an area.

Currently, Scribus uses "Line Styles" to say how a line is drawn and I think the concept of "pen" could be used in exactly the same way but it would also avoid the confusion of mixing it in with the other text styles. (I've always thought that line styles were defined in a confusing place.)

Basically, if the user knows that a "brush" - a solid colour, or a gradient, or a pattern - is something they can use to cover an area and a "pen" - a solid colour (or gradient as of 1.5.3) with a width, arrows, etc. - is something that is used to decorate a line, that would make things easier to think about. They could even be presented to the user using similar dialogs which would give a more consistent UI. (Maybe pens and brushes could also be applied to text in the future?)

Obviously, as you say, the wording can be argued about once things have progressed further. I just think it might be worth putting in a bit of time to get the overall concepts sorted out in case some optimisation can be achieved.

CGood:

I think I've tried to make it clear above how I think line/borders should be treated. Essentially, the stuff that is currently related to "fills" - solid colous, gradients, etc. - should be treated as a "brush" and the things that are currently related to "lines" - solid colours, width, dotted, etc. - should be treated as a "pen". If I've not explained it well enough or you think it's wrong in any way - especially if there is an exception or problem that hasn't been covered - then please say so. I am in no way saying that I think I'm right and that it's the only way to do things. I'm just saying that I think it would be sensible to look at things that way but I could be totally wrong.

Naming pens and brushes - what are currently called colours, gradients, patterns, line styles, etc. - is a very important function and should, as you say, be kept in Scribus. It would be very bad if users couldn't name things like that as there would otherwise be no way of keeping consistency between objects.

Immediately applying changes "live", especially for basic things like colour changes, has to be - in my opinion - the way forward for Scribus. In this modern world users want, and should expect, to see changes like that happen immediately. There are really only two reasons why this shouldn't happen: 1. The hardware being used can't handle the redraw fast enough, or 2. The developer doesn't know how to do it. I'll leave the people reading this to consider each situation for themselves. (There is a third reason, which is that the developer has their hands tied by the API or other bits of the software but that's really just another way of saying point 2.)

As for a "persistent palette", you might have a point there. There seems to be various types of "palette":1. The "saved palettes", the ones you can import from;2. The default palette (I can't remember where this is set as I've never bothered to change it);3. The saved document palettes (which can also be imported);4. The current document palette;5. The custom colours within the document.There might be a way of managing all of these more consistently - and maybe there should be - but I think you're right that it would probably be something for the future. It would be nice to be able to easily save palettes outside of a document so they can be reused. Or maybe what we've got is enough. (Edit: See below where I've answered pretty much the same question but in a slightly different way which could even look like I've done a U-turn!)

Martin (again):

I started writing this before your latest post came in so I'll just append my extra comments here.

I like the idea of having some definitions now that things are getting a bit more complicated. If I could just amend/expand your definitions a little:

Global Colour Sets* are a set of named Global Colours;* are self-contained files;* are supplied with Scribus as resources;* are not related to any specific document;* cannot be editable by the user.

Global Colours* are named colours;* are defined in Global Colour Sets;* can be imported from a Global Colour Set into a Document Colour Set as a Document Colour;* cannot be editable by the user.

Document Colour Sets* are a set of named Document Colours;* are defined in a Document;* are only available for use within that Document;* can be editable by the user.

Document Colours* are named colours;* are defined in Document Colour Sets;* can be imported into other Documents;* can be editable by the user.

Local Colours* are not named colours;* are defined in the object to which they are applied;* can be converted to a Document Colour;* can be editable by the user.

Documents* are SLA files containing a user document;* have only one Document Colour Set.

Document Windows* contain a visual representation of a user document including rulers.

Scribus Main Window* contains one or more Document Windows;* also contains the toolbars.

Dialogs* are single self-contained windows which Scribus can display separate from the Scribus Main Window and Document Windows.

Modal Dialogs* are Dialogs that do not change the document contents or appearance until the action has been either confirmed or cancelled by the user;* disappear upon confirmation or cancellation by the user.

Palettes* are Dialogs where the action of the user is immediately reflected in the document window;* are non-modal, meaning that they persist on screen until the user specifically closes them.

I hope that's made things a bit clearer. If not just tell me what I've got wrong.

Is there anywhere we can store this glossary so it can be easily amended? It would be nice to be able to point people to it where there is confusion. Maybe a "Glossary.MD" file could be added to the IndigoDock project?

I don't think that the user should be able to create their own Global Colour Sets as I would like to think of "Global" as meaning that they are the same throughout the world. Every Scribus installation has them and they are all the same so if someone says "Use Napier Green from the Classic Kit Global Colour Set" then everyone can do that and it's always the same thing.

Having said that, maybe there is a need to have an intermediary between Global Colour Set and Document Colour Set, "Persistent Colour Set" perhaps? I like the idea of the user being able to define their own colour sets that can be shared between different documents and it would also be nice if a change to a "Persistent Colour" would propagate to all of the documents that use that colour. I.e. You change a Persistent Colour in one document, then load another document that uses the same Persistent Colour and it has already been automatically changed.

The problem I have with Persistent Colours (and Sets) is that I think it would be difficult to manage them in a way that is easy for the beginner to understand them. Global Colours (and Sets) are fairly easy to understand; they are non-changeable but can be imported into anything. Document Colours (and Sets) are even easier to understand as they are the things most people use on a day-to-day basis. It's the concept of having a colour that can change between documents that will be difficult to get across to the user. I am imagining people getting in a real mess by using the "wrong" type of colour and not being able to figure out why another document has changed. Maybe I'm not giving people enough credit though.

Phew, I think that's probably where I should stop for now. My typing fingers are getting tired. If I've said anything that is wrong then please tell me.

Yeah I like the glossar idea and I have add it here too:https://github.com/nitramr/scribus-indigo/wiki/Glossar

Again about lines, contour and border, I agree with lines. I think if we talk about different styles for fills we can use "brush" as term as well "pen" for line drawing. Because if we would take a look into the Scribus source code it is already there. Qt provide some classes for drawing.: brushes for fills and pens to line drawing.

But I think in case of the UI we can split the "brush" into the more specific versions, like: solids, gradients and fill patterns (as it is).

Regardless of some minor quibbling on my part here, the majority of changes concocted so far are real improvement and I support them.

Naming of color properties imparting tools

Re Brushes and Pens VS Strokes and Fills. I find the "Strokes and Fills" terminology as workable as any other. I feel that "Brush" and "Pen" implies functions we are not talking about - like caligraphy and drawing, when in fact we are setting color properties for predetermined areas and line like objects. Clunky as heck but would "Area Color Properties" and "Linear Color Properties", or "Area Color" and "Line Color" be appropriate? A border or periphery is a line that wraps around an area.

I am not sure that we can count on Scribus users to have much vector app experience to draw upon to make the pan and brush naming seem intuitive.

Perhaps - if brush and pen are adopted - the resulting confusion could be limited by mouse pointer hover help by saying "fill area w/ color", or "color this line", regardless of the formal naming.

Defining Sets Of Colors And their Functions

Can we avoid definitional conundrum by adding a name for persistent groups of color added by an individual user - by calling them "User Defined Colors" or similar?

Global Color does sound like perhaps the extended default set of colors Scribus arrives with.

I'm willing to bet many users will understand that changing a user defined color would change it in all documents, but that some will get blindsided.

I have no idea if what is stored - currently - in a document is the numeric definition of a color or the name. I don't know if changing my colors currently will propagate into other documents. In the new scheme a pop up hint or hover help to tell the user of what happens to a changed color influencing other documents would / could prompt the user to define the edited color with a new name if the new color was really only needed in the current document. I think that could resolve user confusion with the new user.

No matter how it is done, all users have to commit naming and process to memory and there will be learning curves to surmount. We can at best make the process a bit more intuitive.

I do not want to have to re-make or import colors to get away from the raw default Scribus colors. The default colors are quite reasonably chosen very strong general purpose colors but they are not generally comfortable for me. I'm a painter so maybe I'm too picky about color. Perhaps if a really fast way of importing colors were there?

I would like:

Global Colors = default Scribus color setsUser Defined Color Set = persistent colors I have created and named that will be available to all my documents without an importing processCurrent Document Colors = colors that are not available to other documents without some import processMaybe for un-named colors an default color name could be auto generated? Color00001, Color00002 Color00003... even if these be only part of current document and would need to be imported to other documents.

Maybe a button to make a color - and it's changes - persistent and propagate across all documents?

But, reading in this forum has taught me the value of listening very carefully to GarryP's thoughts. So as I am not sure of the value of un-named colors, GarryP can you speak to the value of un-named colors and of not making all named user colors persistent?

I am 100% on board with GarryP's concept of faster acting color edits - regardless of naming etc. And hope we can eventually (or sooner) be rid of other modal dialogs etc in other processes.

Maybe the process of changing what colors are persistent etc is an issue for future updates? I suspect one may have to implement changes well below the level of interface to change a color database functionality?

<COLOR NAME="Cool Black" CMYK="#990000ff"/><COLOR NAME="Green" RGB="#00ff00"/><COLOR NAME="Registration" CMYK="#ffffffff" Register="1"/>I think it should be possible to create colors without give it a name. Sometime it is necessary to use colors in gradients which you have not definied in your color set, so you need local colors again. Would you give such color a name if you use it only one time in your gradient?

In my opinion color names making only sense in case of color brands, like "Blender Orange", "Coca Cola Red" or "Pantone 7740 UP". Colors without a name can just show the color values, like Indesign do it: C50 M48 Y20 K0 or R128 G0 B28.

I made a test to check if the new panel design is useable in the Scribus Workspace.

If you would use a Full HD screen (1920 x 1080 px) you can use the "content (text)" and "frame panel" in one column without scrolling. Check out the presentation to see more details about the content panel and give feedback here. ;)https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1b39926b0d_0_4

In my opinion the text settings are still take a lot of space. Any ideas how to reduce it?

This might be starting to get a bit more complicated than I thought it was going to be so can I try and put some points across that, hopefully, might help?

The first time I used the word "brush" in this thread it was only as a shorthand for saying "solid fill, or gradient fill, or pattern fill". I had to use the same phrase a lot so I thought it was a good way of being precise without being overly verbose. It seemed to be a reasonable word to describe these things as a group but it also seems to have added a bit of contention, so could I add these as glossary terms? (The glossary wasn't my idea by the way, but it was a good one.)

A FILL* is a visual decoration that can be applied to an object;* covers the entire AREA of an object;* may or may not be named.(Do we really need to define AREA? Maybe.)

A SOLID FILL* is a FILL that uses a single COLOUR.

A GRADIENT FILL* is a FILL that uses a GRADIENT.(Someone else can properly describe a GRADIENT if they want to but I think we all know what we mean.)

A PATTERN FILL* is a FILL that uses a PATTERN.(Again, if someone wants to define PATTERN further then please do so.)

I think these definitions are reasonable - to start off with - and everyone knows what is meant.

As for "pen", that was just a logical extension of using the word "brush" earlier. Maybe that was a mistake, so can I offer the following for addition to the glossary?

A LINE* is a set of POINTs;* has a starting POINT;* has an ending POINT;* may or may not be a closed construction.

A STROKE (replacement for Line Style?)* is a visual decoration that can be applied to an object;* is used to describe how a LINE looks (this needs to be defined much better);* may or may not be named.

A SOLID STROKE* is a STROKE that uses a single COLOUR.

A GRADIENT STROKE* is a STROKE that uses a GRADIENT.

A PATTERN STROKE* is a STROKE that uses a PATTERN (these were in 1.5.0, no idea if they're still in there).

Personally I have no preference between "brush and pen" and "fill and stroke" as long as whichever is chosen is used consistently across both the documentation and UI. (And even better still across the code too, but that ship probably sailed years ago.)

The naming of colour sets still needs some thought but I agree with CGood that the names should properly reflect/describe what they contain so that there is no confusion. For example "User Defined Color Set" could be mistaken for the colours that the user has defined in the document. It's tricky but I'm sure we can come up with something good. Once it's done properly then it doesn't need to be done again.

After more thought, I also agree with CGood about what I called "persistent colour sets" (the ones that are shared between documents). They're probably an extra complication that isn't necessary at this point (and may never be). Can we all agree to drop them so things don't get too far off track? No point adding extra complication if it's not needed.

As for un-named colours, they would be very useful. To add to the example given by Martin, I often just want to experiment with colours, temporarily adding them just to see how things look. Currently I have to specifically create a named colour before I can even start to do what I want to do. An un-named colour would allow me to create what I want and then play around with colours, rather than having to create the colours before I really know what I want to do with them. I can end up with a lot of junk colours that way and I would prefer not to have to delete stuff that I didn't want in the first place. Being forced to name every colour induces extra work for the user when it's not necessary. As long as a local colour can later be converted to a document colour for use elsewhere then that would be fine.

The same goes for un-named fills. In fact, that's how Scribus currently works. You can't currently use a fill in different places without using the eyedropper. Being able to name fills would give the user more control.

Martin: I don't have enough time to look at your latest offering but it looks great so I'll put some proper time in to have a think about it over the next few days.

Hi Garry - Perhaps I took your previous use of "brushes and pens" terminology too literally. I am in agreement with your newest glossary.

Martin. My own take on the space used by the Text Properties Panel or dialog is that I don't think it is too large.

I have cobbled togther a notion - attached - that might be able to reduce unwanted space useage by any given extended panel by enabling the quick and convenient opening or closing of secondary related topics.

Please do not take this as anything but an idea for quick opening and closing of primary and secondary level properties panels or dialogs. My general idea is based on designs like LibreOffice - a set of small buttons to open properties panels or dialogs.

I do not intend to be suggesting here actual levels of what constitutes a top level category or secondary... So I offer an idea of functionality - not taxonomy. If I have anything at all to offer here it is the idea that small buttons might be able to represent two levels of detail and do so without visual confusion. A way to reduce clutter.

The very thin vertical yellow bar denotes second level properties accessed to the right of it. And that the topic directly above is primary.

All that said, I have no idea whether my notion is a good match to the beautiful scheme that is coming into focus in these pages and in your work.

EDIT: I should note that no other portion of my illustration is intended to offer suggestions about interface - they are there only to provide context.

Do you think those secondary buttons for text properties are really necessary, though?My understanding was that we were trying to do away with those dialog-inside-of-dialog steps that the current Scribus ux suffers from. The text properties panel is probably the main improvement I'm looking forward to with Indigo as the current dialogs are already so fragmented... How can we come to an agreement on the most important or primary text features?

For example many designers will be interested in advanced typography features, but I know not every user will have use for these. I think finding a balance between one user's clutter and another user's primary features is vital for the type panel

EDIT****Sorry CGOOD, I didnt view your mockup closely enough!For a minute I thought all those secondary properties were separate panel buttons!I think this could be a good way of organising the advanced features

cloudbusting - Thank you - Notwithstanding your rereading and subsequent positive assessment - I think your initial questions, criticisms, and concerns are absolutely pertinent. I present my notion as just one possibility for a visually and spatially compact way for a user to be able to open or close panels or dialogs quickly. That ease of closing part is perhaps most important since it could be a key for the user to de-clutter.

It is something of a trial balloon. I am not sure it would fit anyone else, while I could work with it happily. I have lofted the notion as a way to see if others like it or not. Perhaps the one part that is truly novel is that yellow vertical stripe that connects a number of secondary topics within the primary topic directly above the yellow.

Just like in politics, it is the details of what-does-what that counts; the exact way the pieces interact. In fact, your excellent questions got me thinking outside the confines of my initial notion. Such a set of buttons could behave in various ways I had not given thought to.

In my initial conception, all secondary buttons are visible, and to open a second level dialog one clicks on the second level button. Clicking there again closes that same panel.

In another way to make things work - even the secondary level buttons are revealed only when the corresponding primary panel is opened. See my attached image. Less clutter - but secondary buttons must be discovered by the user. It would be a trade-off. The interface could stay very clean. But more clicks. But what do other people think?

There is one factor that has not received much attention - that simplifying where one goes, not just how one goes, makes an interface more usable since that step of remembering and deciding to go to this menu, or that icon, or another panel button is changed to just knowing I move the mouse pointer to a single zone.

I think I need more time to think about this new idea, but it looks very interesting.

As has already been mentioned, the way that the current PP UI behaves like a graphical Matryoshka doll can get very confusing. As I said on the first page of this thread, there can be scrolling sections within scrolling sections and that makes things look very ugly and difficult to navigate.

I would prefer that - on most people's screens - no scrolling was needed at all within the PP. Having used Inkscape for a while - with what can be a seemingly endless "scrolling tool window" (or whatever it's called) - I think scrolling is bad for this kind of thing. Just having "Arrange" and "Align and Distribute" and "Fill and Stroke" open on a 1080p screen means you have a scrolling area. To me, that's not right. (Yes you can "iconify" things but I think it's confusing. Maybe it's just me.)

If I have understood the proposal correctly it would mean that - for sections that have sub-sections, e.g. Text / Optical Margins - there would only be one sub-section displayed at any one time. This sounds okay but I have the feeling that there should be a "priority sub-section" that is always open when that section is open (e.g. for Text, you would always show font, size, justification, etc.) regardless of which other sub-section is open.

IMPORTANT: I think this would be a good point for us to get some kind of handle on what these things are called. If some people call them tabs and sub-tabs, or sections and sub-sections, or areas and sub-areas it will get very confusing. Is there a proper word for these "sections" / "sub-sections"? Can we agree on a naming convention? Do any other applications call them something nice that we can use? The names would have to be something short that would give people a good idea of what they do. For instance, calling them things like "priority functional area" or "secondary sub-functional panel" will be horrible. I have no ideas at the moment so I'm totally open to suggestions.

All in all though, this idea could have merit but I'll need to let it rattle about in my brain for a while to see if I can think of any situations where it could make things worse. (I can't think of any at the moment.)

…Personally I have no preference between "brush and pen" and "fill and stroke"…

…neither have i in general – but as almost any other software for graphics and dtp use 'brush' and 'fill' in a certain way, we shouldn't change this for scribus. (a 'fill' is what we're talking about – and a 'brush' is usually what you call 'pattern stroke' – if i understand your description right…)

just an idea. Let's say we remove the text and property panel completely as separate panels from layout and put them in a fixed place. I analyzed a bit more Indesign and Quark XPress. Both have object and context related main properties on a fix place on top. All panels on right side in Indesign or XPress are used for other categories, like pages, alignment, layers etc.

Let's say we would follow a similar concept to have all properties object and context related on a fixed place to organize other categories on the left or right side of Scribus workspace.

I made some thoughts about these concept. See attachment.

There will be an icon section which is visibile if an object is selected. In example a text frame.Now the section show only icons for properties which can be made for these object (our text frame).It show single icons for:- frame properties (xyz, fills and lines)- text properties (font, color, alignment, styles)- advanced character (character scaling, etc.)- advanced paragraph (hypenations, optical alignment etc.)- shape- etc.

The area where you can make settings for the properties will float over the document, but can't move. Just show and hide by clicking on linked icon.

In my proposal I show only two icons instead of X possible icons.

Further more there can be a section in these bar to add custom features as a shortcut to scripts or other stuff. A user can add such shortcuts by click on "add shortcut".What do you think about it?

I'd like to hear other responses. I am going to think more and hope to hear arguments and opinions before I say I'm fully against or in favor of this latest idea of text properties living separately at the top, but my initial reaction is that I am wary of any new space consuming items at top or bottom constraining the workspace vertically.

I tend to be unhappy with any image or document program limiting usable vertical workspace. With the shorter and wider screens available nowdays, any spare space seems to be to the left and the right. Vertical space is in very limited supply. This is most true when working with documents that are vertical or portrait mode. I seem to always want to clean out the top and bottom as much as I can. Could I get rid of all stuff at top and bottom, I would, and I'd put it at the sides.

Were it up to me, and for my use only, I'd go so far as to be rid of all of the menus, program ID, and close/minimize/etc buttons and all the wasted space at bottom. I'd put all that stuff to the sides. Were screens less extremely horizontal, I would feel absolutely differently. I should say clearly that I am not suggesting we now engage in extreme redesign of the ordinary workspace. I would like to just register that adding things at top, and especially things that drop over and obscure the working document feel like a regression to me away from user friendly design.

I hope not to discourage out of the box thinking since while I don't like the idea of crowding the vertical space by putting a text properties floating rectangle over the workspace, I do like the idea of having near instant access to text properties. I may use them more than all others combined. But a set of properties palettes at the sides would do the same.

Button Behavior

I did not mean, yesterday, to imply that opening one secondary panel would prevent others from opening - nor the opposite.

It is an open question, if my notions yesterday have any merit at all, of how exactly the buttons and panels might behave.

One way could be quite restricted in which only one primary panel and one of its secondary panels could be open at a time. Very clean, but maybe a bit restrictive?

The vague notion I had in my mind but not as a suggestion yesterday is that one could open as many or as few panels as one wants, and soon the total length would exceed the length of the vertical space for panels - and a scroll bar would magically appear. That would allow a user to scroll up and down through the panels if that user wanted. That same user could use buttons to close panels and restore order. I tend to opt for non-destructive freedoms if those freedoms don't mess up my interface. So, today I am suggesting that.

Another mode could be allowing one primary panel and as many of its secondary panels as the user wants, but no other primary or secondary panels.

I see no benefit to all such restrictions, but the geometry of my general scheme allows many ways of doing things.

I'm voting for unlimited open panels. User freedom!

Naming

GarryP's questions about naming are important.

One idea - "Parent Panels" and "Child Panels" - that makes the relationship between upper and lower level very clear.

My original terminology does not have the same clarity - "Primary Panel" and "Secondary Panel" - which Primary goes with which Secondary? Well, the geometry of the buttons would help, but the naming does not point one's intuitions quite as neatly.

I haven't used any other DTP software for a long time so I have no argument about what other applications call things. If "brush" (for how lines look) and "fill" (for how areas look) are the "industry standard" then I would be behind a decision to make that the way Scribus works. The less people have to re-learn when coming from other software the quicker they can get into it.

The icons in the Colours tab of the PP seem to already be that way but the rest of the UI doesn't really match up, e.g. the "brush" options are under the "Line" tab and they're also controlled by "Line Styles". It's confusing for beginners if there's both a line (tab) and a brush (icon) but they relate to the same thing. My point in trying to get a consensus on what they were called was to get consistency across the UI (and documentation). In other words, "brush" means the same thing everywhere and everyone knows what it means.

If everyone is happy with "brush" and "fill" then I'm happy too.

Martin:

Your context-sensitive floating toolbar idea sounds very nice in theory. (I can only say "in theory" as I've not used it, since it doesn't exist yet.) I think it would certainly help people who are coming over from other software, such as word processors, as it's something like what they are more used to. (Now and again we get questions from beginners who have trouble with the concept of the Properties Palette.)

I'm not sure if I'm 100% sure about splitting some functionality between the PP and a toolbar. It might be better to keep it all in the same place (for consistency) but, then again, it might not. Having to go to one place to do some stuff but then another place to do other stuff related to the same thing might be a bit confusing. I've thought about this sort of thing myself in the past but have never come up with anything that I was really happy with. Maybe an expansion of your idea would lead to something really great, I just don't know.

This is one of the big problem areas with UI design: everyone's different and wants things differently. While one person might love using toolbars (or something similar), someone else will hate them (for whatever reason).

If I was being forced to make a decision about this, right now, I would probably come down of the side of just making the PP more usable. It's less of a controversial option and it's what existing users are used to. That's not to say that the toolbar option is "wrong" or anything, but it's probably just a bit of a step too far at this point. I think its one of those things that you've got to actually use in practice to see what you prefer and that's probably not practical (there could be a whole lot of work that may have to be scrapped if people don't like it).

Having said all of that, I can see the benefit of having some of the most used options readily available via a toolbar (font, size, fill colour, etc.). The only problem with that is: "Who says what the most used options are?" What I use most might not be what other people use most. This is a very tricky area that has no perfect solution. All you can do is try and come up with something that the majority of people are okay with.

CGood:

I have the same issues as you when it comes to vertical space being used by the UI. Most displays now are wide screen, as you say, and I find that - especially when working on single-sided documents - I have a lot of unused space to the left and right. I normally fill these up with the Align and Layers palettes (because I use them a lot).

On the other hand, (there's always another hand) what about people who use their screen in a vertical orientation? A lot of DTP professionals - and others - use a vertically-oriented screen because that's the orientation of the pages they're working on. For these people, the horizontal space is more precious than vertical space. A big PP off to the side will fill up quite a bit of their display. I realise that most people are working on horizontal screens but it's worth keeping this in mind if Scribus is presenting itself as a product for professionals.

Basically what I'm saying is that what's right for some won't be right for others. If the UI can offer a solution that can be changed according to the user's individual requirements then that probably the best solution, but it's probably a lot more work.

As for primary and secondary panels, I agree that the user should be able to say which panels they want to be open. If they want everything open then that should be allowed. Conversely, if they only want "the basics" open then that should be allowed too. Let the user decide.

As for naming, I'm trying to get away from using "primary and secondary" and, probably, "parent and child" and, if possible, the words "panels" "sections" and others. It's difficult to describe but an analogy would be with cars. The driver has a "dashboard" which has most of the controls on it. Within the dashboard there is the "centre console" and the "instrument panel" and the "heater controls" and the "media centre", etc. These things all have different names and it would be nice to be able to give each of the things in the PP a specific name so we don't have to use sentences like "open the PP Text tab, then expand the Columns & Text Distances sub-panel and press the Tabulators button". We could just say "go to the <thingy>", whatever the <thingy> was called, and it would be obvious where that was.

This might be a very difficult thing to do, and it could be completely pointless in the end, but I think it's worth thinking about as it might give some insight as to a better configuration for the PP. Then again, it might not, but it's worth a try.

Maybe there is no perfect naming for the contents of controls for properties? While I'm uncomfortable with brushes and pens - if those have wide industry support in this context then that is worth considering. If only for the purposes of explanations, the wiki, and tutorials, we do I believe need to name the more central properties and those more subsidiary. Martin's original project and his analysis of what "contains" what, and the question of naming all have me thinking again of the "tree" of essential, central properties, and those that are subsidiary. Another way to look at that is to look at what properties are shared by many or few objects.

The "tree"

I have been thinking about what properties "belong" to what objects and which way one might imagine the parent vs child sorts of relations might be described or defined. I have put together and attached a rough notion to illustrate my initial conception. Working with databases has taught me the importance of identifying what belongs to what very clearly. I found that first my impressions can be less than accurate. So - what have I missed here and what needs a re-think?

I think this is important. Understanding what belongs to what might help naming and structuring properties palettes (and buttons if they be helpful), structuring what really belongs in what menu eventually - pretty much everything.

Where to put properties palettes

I was wondering if the assumption was that everyone is using really large screens horizontally. The thought of screens in portrait mode hadn't occurred to me. I wonder if it might be a good idea to consider folks with smaller than optimal horizontal screens. I'm not sure it can be assumed everyone has a big screen. For instance I use a laptop since I am on the road a lot, and the laptop has become my primary tool despite minimal screen.

Looking to the future...

Would it be possible to envision as a Version 2.0 of an enhanced interface, the ability to drag the properties palettes to any of the four sides or detach them and float into second monitors etc? That would give the user a high level of freedom to make the workspace their own. I assume this is a few steps too far for the current project - too much new code.

I suspect the post I made the other day left people scratching their heads.

I am trying to sort out what controls - panels, dialogs, menus, or buttons - should control what. The question appears obvious and trivial, but logical structure tends to be economical and useful in the long run. Bad structure drags one down.

I want to get a clear idea of hierarchy - what are the most primary objects and properties, and what would be secondary objects and properties. What object or property subsumes what? I think that is clarified by asking what is the irreducibly minimal set of properties intrinsic to a given object? What is not irreducible? That all sounds academic, but it feels important.

I think the UI should support both small and large screen sizes. Because you can have only large screen on a desktop, if you would travel by train you can't have a really big screen (if so it is unusual). If we want to give freedom to the designer to be work at his favorite place we should make the UI flexible.

I think such feature/tool hierarchy will help to clean the UI and to show only important things on small screens and more advanced stuff on large screens (if wanted).In my visuals I was trying to apply a new kind of hierchary in UI. This layout based on my personal often used features / tools and on that what InDesign/XPress show in the property panel. I believe these guys made already such list of important features. Why not benefit from them?

For the hierachry of features I prepared a document. If you want you can add your thought there (or anybody else).https://docs.google.com/document/d/17aFErWh8TnLeXW1q6U3KAzbKDODqnq7e0W8_T4_AvEo/edit#

I apologize for my digressions on the hierarchy of objects and properties. My goal was to understand the nested Russian dolls of nature of program objects and object properties. But after all that, I don't think it revealed anything to me that everyone else didn't already know. My understanding just felt fuzzy and unclear. And I didn't feel like I could stand behind any hierarchical scheme of controls until the big picture fell into place. I think Martin and GarryP probably everyone understood the big picture better than me.For what it's worth I post my scheme below. There will be no great revelations.

My perspective of the hierarchy of Scribus objects - from user level:

The objects one uses to build documents starts at the page level, and then below that are frames (and framelike objects - lines), and then below that live the contents.

In more detail:

1) Top level - Pages - which can contain frames (and lines) - i.e. there are particular Page properties even when no frames exist. Page properties would be Number + Size >>> Pages can contain frames or be blank

2) Second level - Frames - which can contain their kinds of contents - but there are frames properties even if there are no contents. All Frames have XYZ - Size - Location - Orientation - Layer - Level properties and while a frame with no contents is silly, it is possible and has frame properties.

3) Third level - Contents of frames - in the case of text contents the immediate contents are text and paragraphs. Frame contents are particular to the type of frame.

Image Frames - Image Frame contents are image files and have particular image file rendering properties, i.e. scaling.Text Frames - Text Frame contents are constructed from text and paragraphs and have particular types of text and paragraph properties. Text frames seem to be the most complex objects in Scribus. here is where breaking up elementary and advanced properties make most sense.Shape Frames - Color/Fill/StrokeTable Frames - Tables have their particular table types of contents properties.Render Frames - Render Frames have their particular types of contents properties.Lines are frame like - Color/Fill/Stroke and have their particular Line properties.

this will be my first ever post. It took me so long to read through the thread that it actually logged me out.

I am neither a programmer nor a designer, but simply an end user. To be blunt, the current interface, particularly the properties tab is to put it politlely, dire. To make sure I was not deluding myself, I showed my twelve year old the current properties tab (1.5.2) with the video mock ups Martin has produced. I will let you guess what he preferred. His comments were that the 1.5.2 properties tab was simply to big, with too many words and way to much wasted space. He also had the opportunity of seeing the InDesign CS6 version that is on my windows machine and simply said, why can't it be like that... that is much easier to understand.

So on behalf of my son who has no axe to grind, I would like to ask, why can we not simply have two options to download, both the current (1.5.2) and the proposed Indigo style and let people decide for themselves which they prefer.

thanks for your feedback. It is great to hear that you have tested the UI mockup with someone which is really fresh in this topic.

About the Indesign UI, I'm sure that we are not allowed to clone the UI. It is like Microsoft's Ribbon UI which is used in their Office suite. It is copyrighted / patented. Furthermore Scribus has some different settings as Indesign which can not easily fit into the same UI. A good example here are gradient options for fills and lines. Indesign doesn't support so much possibilities. That is the reason why we will have much more settings.

I think to have two different UI's makes no sense. The developer have to maintain both and from UX perspective it will solve only symptoms. A solution would be to fix the problem and to find one UI which fits to most users.

I can imagine to have a beginner and an advanced mode.

Beginner mode could be like MS Word to create basic layouts without any specialized settings like, micro typography etc. Could be work for professionals too to create a rough basic layout, and after switching in advanced mode the user can make all the specialized things.

just an idea. Let's say we remove the text and property panel completely as separate panels from layout and put them in a fixed place. I analyzed a bit more Indesign and Quark XPress. Both have object and context related main properties on a fix place on top. All panels on right side in Indesign or XPress are used for other categories, like pages, alignment, layers etc.

As I remember, quark displays only part of settings on quick bar. To adjust more advanced settings you have to dig into options anyway. It will take lots of time and testing to select which options go there which don't. I like scribus approach where all controls are available so I see all my tools. Currently I only miss option to dock two columns of panels next to each other on the left or right side, so I have both text properties and properties open.What I mean, that I like to see all settings that are connected to element then only part of.

I've been reading through this very long thread, and I think you're the only who's not getting lost in details that can be figured out later but still focusses on the basics ;) That's not meant as an offence to anyone, since those details need to be considered later, and a discussion on them is absolutely necessary.

I've also seen that you already made a lot of progress at https://github.com/nitramr/scribus-indigo/wiki. Well done!

Now that Scribus 1.5.3 is ready for relase, maybe we can get back to the basics and see how we can continue from there.

In my opinion the top priority must be several issues before 1.5.4 can be released (or before your branch can be integrated into svn):

1) Rip both properties palettes apart and modularise them (and make them dockable for the time being).

2) Make the modularised palette elements content-dependent, which means, for example, that no image-frame-related element is visible when a text frame has been selected.

3) Enable access to the relevant settings dialogues via the modularised elements, i.e., to Styles for text frames, lines and tables, to Colours & Fills for general frame settings and shapes.

4) Introduce frame styles.

5) Introduce a feature to save the current workspace, both with a document and as an external file. These options aren't mutually exclusive.

Points 3 to 5 are among the most requested features I heard from professionals.

The rest will be sorted out and optimised via real world testing: trial and error :)

I absolutely adore your drafts for horizontally layouted palettes, and I'm convinced that this is the way to go, especially for text. I think, though, that for text a dialogue needs at least 3 tabs on top of the dialogue to provide access to all features. I also think that those horizontally designed dialogues need to be able to be moved around on canvas or docked at the top or bottom. Having them fixed at the top might cause unforeseen problems, so it's better to allow for some flexibility.

And here's another suggestion: InDesign provides access to advanced features like the OpenType ones via a menu. Perhaps it would make sense to add a new menu "Typography" or "Advanced"?

One nitpick: You should use Qt Designer to see what's realistically possible with Qt and how it will all look at the end on multiple platforms.

thanks for your feedback. I agree with you that some steps has to be done before an integrtation of the IndigoDock is possible - or meaningful.Currently I try to hold my branch up to date with the latest features from developer branch.

Most of your points are already considered in my UI concept as a proposal. https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/editFrom time to time a made updates, based on feedback here or on other channels.

Some minds about horizontal layouts. The IndigoDock already support horizontal panel layouts, but the panel content is not optimized yet. To allow a fluid horizontal layout we need "block" based elements which can float. That can be a problem in some panels which contain lists, like pages panel. Another option is to allow only specifc panels to be "horizontal", but it will be hard work to find a good solution.I think it is a good idea to check out the possiblities of the Qt Designer, but it should not be a constraint for the UI, because the IndigoDock is a full custom control. I try to say: if there is nothing which fits to our design let's build our own controls. ;)

In attachment you can see a screenshot of the IndigoDock branch on a full HD screen in vertical orientation. Looks really unuseable and need more love.

So I played around a bit in Designer and here are two versions of the same palette. One is a normal Widget and one is a DockWidget. Ignore the main title bar on both to a degree as that can be turned off. I have not fully styled the spinboxes etc. The only style applied is 10pt font.

One thing that is a limitation is the dock widget areas. See here: http://doc.qt.io/qt-5.8/qdockwidget.htmlThere's only one docking area on each side. Not sure how we could have multiple thin palettes below each other then.

So I think we can achieve relayout based on available space by simply telling the dockwidgets to rearrange themselves. Ie, if we use style sheets (or calculations) manually locating the layouts or widgets, we can just tell them to move when required.

just warn you, that getting scribus to compile on windows is hard work, since very few people have done it (for the scared one: one of the guys in the team does create the .exe! so it's that scribus can and will be compiled on windows!), the process to get all the pieces together is rather tedious and you have to know a bit visual studio to get there.

if you have those skills (or want to acquire them), you're very welcome to try it out (and improve the documentation on how to get Scribus to compile).

We need to decide how to move forward here. I've presented some sample palettes however we don't have a great docking solution for the number of palettes required, and we need to determine what widgets fit together on one palette. Is it as simple as the existing palettes broken up into individual ones or something more complicated?

... once upon a time, it was discussed to first do a split between a content and a container palettes.

that would imo already be a good start.

on top of that, what i would like to see: a way to always have the same controls at the same place (and docked)... this would probably mean that two (groups of) palettes can be docked and one should be able to switch inside of the group.(similar to what gimp does, but with the vertical "buttons bar" that martin is proposing.

I wanna stress one thing :- screens are horizontal- paper most often are verticaly orientated

When displaying a page, there is often more available room in the left or right part, and there is often missing room in the top or bottom area. It's not 100% true because it depends on the zoom factor, but its a massive trend.

Horizontal palettes take the free room where where it's more scarce.

Vertical palettes take the free room on the right or left side, right where it's more likely to be available. However not so newish, they really seem to be a better way of displaying tools rather than horizontal one !

JLuc, I feel it's very important to point out that screens are not always horizontal.

A lot of professional DTP set-ups use vertical screens because, as you say, paper is most often oriented that way.

Forcing the palettes to go the side of the screen will take up a lot of valuable screen space on vertical monitors.

Because of this, Scribus should not be optimised towards horizontal screens. Scribus should allow the user to put things where they want them instead of forcing certain layouts.

I understand that most people will have horizontal screens but not everyone will.

If Scribus wants to be seen as a professional tool then it shouldn't make life difficult for the professionals that might want to use it.

To add a little extra to this - because it's relevant - Scribus should also be solid when it comes to multi-screen use. If the user puts their main window on one screen and their palettes - PP, layers, etc. - on another screen then Scribus should remember this layout and cede to the user's wishes. I don't know how much testing has been done on this but I've seen quite a few issues where Scribus windows go missing and get moved around so it's worth keeping in mind.

I made an update of the Indigo branch. Now it is based on Scribus 1.5.3 master branch which includes all changes until today.https://github.com/nitramr/scribus-indigo

----

So, I want to share my minds with you about the horizontal panels. I agree with Garry, Scribus' workspace should fit to the user, for beginners and professionels. Why not support horizontal panels?It is possible if we put all panel ui elements in small blocks. See image in attachement. In this way we can have a "floating" layout. But this solution will break if not all elements can fit in such "static" blocks, like list views.

Here is an example for a vertical layout (elements can group into 2-row blocks):https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1b39926b0d_0_4

Here is an example for a horizontal layout (you can see the 2-row blocks better):https://docs.google.com/presentation/d/1JRs-9VUaZGjG3Dvyci2DCpwIpYQLR8IZv485hjujdEk/edit#slide=id.g1d20649765_0_14

If the elements are grouped into blocks/panels that are added to a flow layout (or whatever the Qt equivalent is) then the UI should be able to handle both without much extra coding. Let the user give the orientation and size of the area and let the UI/API figure it out. That's what all these layout manager classes are for.

I understand that some list views won't work well - e.g. colour selection (if it's kept as it is, and, really, should it not just be a simple drop-down?) - but there are some parts of the UI - e.g. "text flow around frame" - where a simple drop-down list would make the UI much cleaner and help to avoid that problem.

If there's a part of the UI that doesn't fit into a flow layout then maybe it's time to have another look at it and see if it can be done differently.

I think a basic point is that even if the user uses a landscape-oriented monitor and wants all of their palettes and things at the top and bottom of the screen leaving only a "letterbox" of space for the document then they should be allowed to do that. There's no right or wrong way, there's just the way the user wants to have it for whatever reason they want, and Scribus should allow for it.

So I agree, and it was my plan anyway to support vertical and horizontal layouts.So I could show both at the same time, its not in preview mode, but I think we can achieve both with the same raw .ui file. In fact, we might be able to just lump all widgets unordered onto a blank dialog ui and then use stylesheets to set the x/y locations. The problem then becomes scaling to UI DPI etc. Anyway, sample screenshot attached.

I just built the latest indigo.. - something's funny with the icons.. always very light, to the point of being unusable. - I don't like how the properties palette becomes empty when no item is selected, although I understand why in context.

Other than that its a good thing so far.

I haven't read the code much yet so I don't know if the base changes are what we would want with the newer "broken up" palette thoughts.The idea of splitting the palettes up more, eg so XYZ (with some others perhaps like rotation) would be more flexible and get around the issue of not having palettes making sense (ie like the PP being blank right now per the above)

What about the limited docking options in current Qt?Would we need our own docking container that docks into the current Qt areas and then our palettes dock within that? I guess thats not unlike what is done now in indigo but also would cover the horizontal option where multiple small palettes can fit together.

I only managed to build Scribus from source on OSX via some very patient hand-holding by another user.There was a lot of "try this, then this, oh it didn't work, try this instead, ah you're missing that, so do this, then that, what do you mean that's not what it says, okay then try this other thing" etc. etc.I would suggest using the #scribus IRC channel on freenode.net to get some real-time support, if it's available (always ask nicely). Doing this via the forum will probably be a bit like playing chess by post when you're not sure of the rules.

i just found another interesting approach on dtp programswith a imho very clean and intuitive user interface

done by https://www.belightsoft.com/products/printworks/

apparently it lacks on the options side it s also not open,but maybe its a interesting thing look at.

A mouse menu (like krita) fired by a shortcut to toggle between the tools could be an interesting idea how to save some precious space and get even more of the worked on document to be displayed somewhere in the future. Just to have something to think/dream about for the long terms :)

I hope this an interesting informationand i also want to take this opportunity to thank you for the amazing work you all have done so far.I know it's pretty damn hard to actually change something.

For me it's like a miracle, everytime i read through this feed and see how it evolved over the years. It makes me smile.It might seem like a small step sometimes, but if you look at it for them long term period it changes things pretty massive.

this is just for documentation purposes, I have no time right now, just money :(but I will be here for the next years if I can.

thanks for your warm words, it is a great motivation to keep on it. :DI checked out the webpage of this tool and it looks pretty nice. Could it be that this tool has been called "Swift Publisher" in the past? I have it already in my list of DTP's

Currently I have created some custom dynamic UI widgets which can handle pre-built layout files. So, easy to create UI's via Qt Designer instead of programing. ;)Nothing is integrated yet in Scribus so far but I plan to create all needed layout files at first and than try to connect the wires in Scribus.

Take a look to the first UI redesign in attachement. The UI is organized in floating blocks to suppport horizontal layouts.

BTW: the latest UI Widgets are on Github: https://github.com/nitramr/IndigoUIWidgets

I want to give an update to you about my progress. A big part of the text properties panel is shining in a new design. But at this moment a lot of small details have to be adjusted.

The "new" Scribus is available in a Scribus fork on GitHub for selfcompiling. But at this moment Scribus crashes after closing the document. If someone wants to figure out the reason why it would be great.

At this moment I have some more progress. I could fix the crash and finished the refactoring of the text palette. Furthermore I renamed the text palette into "content properties palette" because now this palette shows the related property settings of your selected object. For now it supports settings for text content and images. The image properties need some more adjustments.

I really appreciate your work. I don't know if the layout of the text panel you presented has it's final form. If so, I have one remark:The character section is quite... scattered. At first glance I had a problem with undestanding which form means what.

thanks for your post. I think there are some ways to supporting me. Since I changed the UI I changed a lot of code as well. At this moment I'm not sure if all features are working as expected. So testing would be one option. But for now there is just the source code, no binaries. But I'm able to create binaries for Linux. ;)

I never though about donations... but I remember that I have a paypal.me link. If someone wants to make donations here is the link: https://www.paypal.me/martinreiningerBUT: donations are not required that I continue my work!