Scribus UI/UX improvements

Previous topic - Next topic


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 ?


Hi together,

today I could achieve a new milestone. The planned Workspace support for IndigoDock is implemented in beta state.

Whats new?

  • panel direction fits in dock orientation (vertical / horizontal)
  • panels are extendable/collapsable by double clicking on panel title bar -> Kunda this is for you ;)
  • docks support vertical title bar to save space in horizontal orientation
  • restoring workspace supports additionally dock state + floating panel size
  • workspace will save in single file (currently there is no save/load functionality for multiple files, but would be possible yet)

Whats still broken?

  • an empty dock occur some resizing issues
  • current layout will be cleared if there is no valid workspace file

Let me know if you found other issues.


PS: all updated files are available on GitHub ->

[attachment deleted by admin]


Looking forward to seeing this!

Thank you Martin.


thanks for the update looks nice!


Very late to read this, but your project looks wonderful!!!!!


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  :(

BTW I'm InDesign user since 2005


hi bkf1

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.


I need to rant.

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.


Hey together,

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




You said it most eloquently - a vicious circle.

Even though I get frustrated, the underlying functions of Scribus are very worthwhile. The work you are doing is really impressive. I am looking forward to the day your work is ready.



I have uploaded a new repository to GitHub which includes the IndigoDock integration.

Currently there are still compiling issues which I could not fix. Maybe someone can take a look to support me. I have described the places which I changed in the original Scribus code on GitHub.



hi martin,


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

to see how HOST is managing it :-)

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


Hi a.l.e.

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.




just one hint for the future: you should try to make commit that are as small as possible, with commit titles that say what has changed in the code.

but you don't need to change your first commit now!

i'll compile it, and try to figure out what happened by reading the diff!

thanks for your work!


i get a very strange rror with qtextedit.h... it's the same one you're getting?

i will try to have a look at it later this evening... but now it's time for a grill party at the river!