ability to scroll inside the filter/stroke & fill docks

[insaner]

sometimes (actually pretty often) some of those filters can contain long chains of filter effects, or even the filter names, which cause the filter editor dock to be quite wide.. if docked and unhidden it covers too large a portion of the editing area which makes it near impossible to be productive while both editing the image and its applied filter.. adding a scroll bar to the effects window (or the just the filter editor dock itself) inside the filter editor would be a great way to take care of this

[su_v (suv-lp)]

Could you please clarify: this is a request to lock the width of the filter editor dialog to a fixed size, and add a _horizontal_ scrollbar if the content exceeds this hard-coded maximal width?

[su_v (suv-lp)]

Correction:
- lock the width of the filter editor dialog to a fixed size
+ lock the width of the filter editor dialog to a fixed maximal size

[su_v (suv-lp)]

Related to or duplicate of:
Bug #180302 “Smaller size / better resizing of docked panels”
<https://bugs.launchpad.net/inkscape/+bug/180302>

[su_v (suv-lp)]

Possible solution for Filter Editor:
- set a default (minimal) width for the list of filter primitives
- add a horizontal scrollbar if the content (linked filter primitives) exceeds this width
- expand the filter primitive list when manually increasing the width of the main dock (keep list on the left with named filters at fixed width, or increase it proportionally too (current))

[insaner (insaner)]

sorry all, since i discussed this over the jabber channel, i didnt remember to update the bug here.

yes, a horizontal scroll bar that appears when you resize the filter (or fill and stroke) dialog, so that there is no (huge) minimum size required for the dialog. that way a sensible minimum can be picked, and still have a good amount of wokring area real estate

in other words, if the dialog is so big that it is covering 4/5ths of my visible area in inkscape, then i want to be able to just resize it to whatever size i want (no minimum or maximum), and a horizontal scroll bar appears inside so the content is still accessible without needing to resize again.

possible candidates for scrollbars:
*filter name list
*effect list of the filter (either the list box itselft, or the "connections" part only.. )
*entire filter dialog

personally i think the first two should have the scrollbars (also since they already have vertical scrollbars too) but not the entire filter..

the behavior is seen in all sorts of apps first example i have in front of me is the kate editor in kde, where if you have multiple files open in the document sidebar, when you resize it such that the filenames dont fit, a horizontal bar appears so you can keep it at your resized size and be able to scroll to read the whole file..

i believe this small fix could improve usability (at least in my case for sure) by a very significant amount. thanks in advance

[insaner (insaner)]

decided to plunge headfirst into the code and give patch creation a try. so heres my first attempt, i hope that if anything at all it will get the ball rolling for this fix.. its not the best solution i know, and the scrollbars would best be placed into the "connections" column in the filters dock. but i dont know how to do that at this point.

[insaner (insaner)]

ok, following the directions i was given, heres another attempt at this, with a couple more fixes.. let me know what you think

thanks to su_v and john-smithi

[ScislaC (scislac)]

This does not apply cleanly against trunk... is this a patch against another patched file?

[insaner (insaner)]

hmm.. its a patch on r11889, not sure if that makes a difference.

i dont think i will be able to make a patch against newer builds since the gtk 2.24 support was removed, and i will probably need to upgrade my whole system to be able to compile..

[insaner (insaner)]

err oops, su_v just pointed out that its not 2.24 that was dropped, but 2.22.. which is what my system is (and which we had already discussed but i got confused..), so in any case the fact remains that i wont be able to test on the newer builds..

[su_v (suv-lp)]

Would it be possibly to add horizontal auto-scrolling when dragging a filter primitive connector? It already does auto-scroll vertically, but not horizontally (tested with GTK+/Quartz 2.24.14 on OS X 10.7.4).

[jazzynico (jazzynico)]

Patch updated (revision 12010).

[su_v (suv-lp)]

@JazzyNico - that patch seems to be against an older version of trunk: Hunk #2 doesn't apply here (AFAICT due changes in r11996). Attaching a diff against r12011 - please verify.

[jazzynico (jazzynico)]

> that patch seems to be against an older version of trunk

More or less with a modified version of and older version of the trunk ;)
I confirm your patch works, thanks!

[insaner (insaner)]

a few more fixes in this patch.. this should free up a bit more screen real estate in the filters dock.

 still missing though is something to automatically trigger a repaint of the infobox when the primitive is changed.

this patch also includes a "reorder filters" feature (couldnt find a bug for this.. so i will file it later -- but at least we can test the fix now), where you can drag and reorder the filters. it must be a non-selected filter, otherwise it will just activated the rename feature. the ordering is not yet persistent, as it must be attached to the list that stores the data somehow.. but at least the first part of this is done in case anyone else wants to undertake this task (i dont think i will be for a while).

[jazzynico (jazzynico)]

Patch from comment #15 tested on Windows XP, trunk revision 12149.

Would it be difficult to implement horizontal auto-scrolling as suggested by ~suv comment #11?

[insaner (insaner)]

ive been looking into it a bit.. but i think the best thing would be to file a separate bug for it.. its significantly unrelated to the portion of code ive been looking at, and i wont be able to get to it any time soon. i think i might have an idea where the fix could be done. if you guys want, file a bug and assign to me.. ill try to get to it eventually

[su_v (suv-lp)]

The patch introduces a selection regression: it automatically reselects the top-most filter primitive in the list whenever an output/input connection is modified - this does not happen without the patch.

To me the major drawback of the patch is that the lack of horizontal autoscrolling makes it more cumbersome for advanced filter editing beyond adjusting effect parameters at the bottom of the dialog, and one has to watch out to not loose data accidentally because of easily failed drag&drop actions when connecting output and input to other filter primitives and/or sources, when the targeted drop point is outside the visible vertical slice of the filter primitive list.

For a quick test, apply e.g. 'Bevels > Bloom', and reconnect the second input of the bottom-most filter primitive (Composite) to 'Source Alpha' (instead of 'Source Graphic'), using a touch device (e.g. laptop trackpad) - you cannot drag the grabbed connection and swipe (scroll the list horizontally) with one gesture.

Note: I did not test usage with tablet & pen at all.

[insaner (insaner)]

hmm i see what you mean.. will look into it then. also, you will see the problem this bug is referring to quite vividly illustrated if you add (merge) 3 more filters to the bloom that you first added. it is now impossible to move the primitive connectors at all to the right most column without resizing the window past the size of the screen

[insaner (insaner)]

ok.. its a bit hacky, but i got the horizontal auto scrolling to work.. so if this patch gets accepted, we are ready to roll..

test it and let me know.. this grants me about 25% extra screen real estate, hope its useful to others too

[su_v (suv-lp)]

1) Basic tests with Inkscape 0.48+devel r12191+bzrdiff-1062134-scrollies-x2.diff on OS X 10.7 look ok with
- GTK+/X11 2.24.13, GTK+/Quartz 2.24.17
- GTK+/X11 3.4.4, GTK+/Quartz 3.6.2
(yes, it works with experimental GTK3 builds, too - despite the redraw issues as documented in bug #1066808)

2) The selection issue (comment #18: reverting to top-most filter primitive whenever a connection is modified) is fixed, too.

3) Not tested at all:
> (…) also includes a "reorder filters" feature
(Personally, I'm not sure whether this should be part of this patch - AFAIU it's not related at all to the changes for the filter primitive list to allow a smaller minimal width of the (docked) dialog)

[insaner (insaner)]

for 3) i can remove that part of the code if you want

i will be checking this in hopefully by friday. let me know if there are any (other) issues

[jazzynico (jazzynico)]

Also tested successfully on Windows XP, trunk revision 12224.

As for 3), I confirm it should be attached to its own report so that we can test and comment separately.

[insaner (insaner)]

done! the line of code for 3) was not included in the push..