Scribus UI/UX improvements

Previous topic - Next topic

Kunda


tim_occ

Hi guys,

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 code
2. as a third party plugin

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

greets
Martin

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

tim_occ

Update:

Auto-scroll feature is full implemented. Check out the latest showreel on Google Drive:
https://drive.google.com/open?id=0B6L-QFyXo0RRQ1pSeWdYLVNDUTA

greets
Martin

Kunda

Hey Martin!
I tested your 2 commits.. they work great!
Thanks so much.
Very exciting

GarryP

This just keeps getting better and better. Fantastic stuff.

a.l.e

i like what i see :-)

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.

what are your plans on this matter?

ciao && thanks for your precious work
a.l.e

tim_occ

Hi a.l.e,

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 one
2. uses icon on right side for auto scroll to the wanted panel
3. collapses the features for every panel (currently there are 3 states; 1 collapsed; 2 normal; 3 advanced)

greets
Martin

[attachment deleted by admin]

MrB

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.

corebots

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.

looking forward to future updates,
cheers

a.l.e

i love:

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

GarryP

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.

corebots

thanks for the latest update; the thinner borders do look better now ;)

tim_occ

Hi Guys,

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

best,
Martin

[attachment deleted by admin]

MrB

I didn't mean to group panels like in 1.5.x, I mean to make the panels sticky, so when you bring them together, they stay together, edge to edge. This would possibly avoid needing the dock.

tim_occ

Hi MrB,

that is an interesting idea, sound like a simple solution. But If I'm thinking deeper about it some important question will popup.


  • without a common dock is there no option to save space -> wall of panels (might be a user needs a second screen)
  • if the panels are floating over the main window they will cover the workspace

I can imagine that the current dock solution could be go in these direction as seen in some posts before.




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.

greets,
Martin

[attachment deleted by admin]