Scribus UI/UX improvements

Previous topic - Next topic


Hi Martin,

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 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.


Hi Christoph,

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.
From 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.


[attachment deleted by admin]


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:
There's only one docking area on each side. Not sure how we could have multiple thin palettes below each other then.

[attachment deleted by admin]


Nice work!

the limitation of the QDockWidget / QMainWindow was my reason to start to develop a custom control which hold and manage single panels.

Is it a floating layout or static? With floating I mean if with width of the panel is not wide enough the blocks break into a new line.

Currently it would be possible to have multiple DockWidgets to each other in one row. But the width is limited to the MainWindow width.

[attachment deleted by admin]


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.


hello i am interesting for testing but i only have windows os did you have a beta for it ?


Hi Micker,

I have no Windows next to me. If you able to compile the source code you can do it. Otherwise someone with a Windows machine has to do the job.

Sorry for that.



if you can explain a little maybe i can do it


micker, do you know how to compile on windows with visual studio (or eventually with cygwin)?

if not, sadly windows is often the hardest platform for compiling many open source projects...


ok i understand ... if i can help with me little mind lol


micker, i don't want to turn your offer down!

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).

the starting point is here:

on the other side, the easiest way to test scribus with "indigodock" patches to run on a windows computer is:

- install the latest ubuntu in a virtualbox
- install the development scribus from a ppa
- fetch and run the indigo scribus appimage created by the continuous integration (travis)

i / we can help you a bit with both ways... but it's you who will have to do the hard work : - )

have a wonderful evening


So 1.5.3 is out, you should rebase to it.

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.