scl wrote:

today a contributor addressed the problem of the missing possibility for scrollbars in Script-Fu dialogs, see [bug 725432].
He (or she) thankfully offers a patch.

From my point of view the problem lies deeper: if a dialog needs such a scrollbar it is very probably overloaded and not enough user friendly.

yes, in general dialogs do not scroll (unless it is good for usability, hh); content can scroll in dialogs.

I'm thinking of these solutions:
A) Reduce the number of elements in these dialogs. B) Use tabbed dialogs to organize these elements better.
Perhaps better solutions can still be found.

How do you think can we solve this?

well, as I understand it the big picture is that the script writer puts together the dialog, i.e. is a third party developer.

at that point GIMP can offer:

1) building blocks to reduce what needs to be shown at once (tabs, expander sections) or vertically (multi-column) 2) tutorials and style guides for script writers how to use less fields in dialogs, and how to use the things from 1)

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Hi,

today a contributor addressed the problem of the missing possibility for scrollbars in Script-Fu dialogs, see [bug 725432].
He (or she) thankfully offers a patch.

From my point of view the problem lies deeper: if a dialog needs such a scrollbar it is very probably overloaded and not enough user friendly.

Well, it depends on the resolution of your screen and the theme you are using. For those of us who use large font themes, a script doesn't have to to be one that's considered "overloaded" to need scrollbars. What one person considers "overloaded", someone else might consider to be perfect for the task.

As it stands now, I feel extremely constrained by the limitations of the script-fu dialog. It's almost like I'm literally trapped inside a little box. ;)

I'm thinking of these solutions:
A) Reduce the number of elements in these dialogs.

As a Script-Fu developer, this is not really an option. There are times when I can't get rid of any input fields and still provide the functionality and flexibility needed to create a great script.

B) Use tabbed dialogs to organize these elements better.

This would be a nice option to have. However, at times, scrollbars is actually a better solution, say for those last two checkboxes that run off the screen. Adding the option to display scrollbars, only when needed, requires very little extra code in the interface, while maintaining existing features like drag & drop, without introducing undo complexity in the SF-Interface.

Perhaps better solutions can still be found.

How do you think can we solve this?

Kind regards,

Sven

[bug 725432] https://bugzilla.gnome.org/show_bug.cgi?id=725432 _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

On Sat, 2014-03-01 at 15:16 +0100, scl wrote:

Hi,

today a contributor addressed the problem of the missing possibility for scrollbars in Script-Fu dialogs, see [bug 725432].
He (or she) thankfully offers a patch.

From my point of view the problem lies deeper: if a dialog needs such a scrollbar it is very probably overloaded and not enough user friendly.

I'm thinking of these solutions: A) Reduce the number of elements in these dialogs. B) Use tabbed dialogs to organize these elements better.
Perhaps better solutions can still be found.

How do you think can we solve this?

Not at all.

If a 3rd party script writer decides to have 50 parameters, the Script-Fu UI must still handle that gracefully :)

Of course I generally agree, it's bad habit, but what can we do...

Regards,
--Mitch

On Sat, 2014-03-01 at 10:03 -0500, gtux@gimpchat.com wrote:

[...]

. There are times
when I can't get rid of any input fields and still provide the functionality and flexibility needed to create a great script.

Sometimes a secondary dialogue box is used, and sometimes an expandable area within an existing dialogue box; both of these could conceivably be implemented for script-fu.

[...] at times, scrollbars is
actually a better solution, say for those last two checkboxes that run off the screen.

It always frustrates me that some of the built-in docks do this - e.g. I can't see whether Dodge is working on shadows, midtones or highlights without scrolling the tool options dialogue.

In that particular case, splitting between the common settings of opacity, paint mode, brush, and the size / aspects ratio / angle duplicated from the brush editor, the paint dynamics "Pressure Opacity" and the cryptic "Use GimpApplicator" all push down the options specific to this tool. So "Paint Options" and "Tool Options", and maybe giving Paint options a "collapse when not in use" so I don't have to look at Brush Size when I'm using the rectangle selection tool, would be a big improvement.

But in general dialogues have to be able to scroll, yes, because sometimes the screen is small, or the dock is narrow, or you are entering a 45 x 45 matrix of numbers for convolution...

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Sat, 2014-03-01 at 15:46 +0100, peter sikking wrote:

well, as I understand it the big picture is that the script writer puts together the dialog, i.e. is a third party developer.

The problem is that the developer only specifies abstract parameters with no GUI whatsoever, it's a flat list and script-fu generates the GUI automatically.

at that point GIMP can offer:

1) building blocks to reduce what needs to be shown at once (tabs, expander sections) or vertically (multi-column) 2) tutorials and style guides for script writers how to use less fields in dialogs, and how to use the things from 1)

That would be really nice if there was a way to add meta information for GUI building attached to the script, the exactly same problem exists with GEGL ops and we have a solution in mind where each parameter/property can have arbitrary name/value pairs attached. The system is in place, we just need to define names/values for GIMP to parse and make a GUI from.

For Script-Fu, there is no such system, and until there is, I think there is not much else we can do but let the contents scroll if there are too many parameters, in order to make the dialog usable at all.

Regards, --Mitch

While GnuTux was working on his patch, I was investigating the possibility of a tabbed approached. Here are some of my thoughts on the matter.

A tabbed approach could either be implemented automatically or specified within the script. The first problem posed by an automatic approach is how the table of widgets should be split into multiple tabs. If it is hardcoded as a fixed number of widgets per page then users with large screen displays would be penalized by choosing too small a number, whereas too large a number invites the same problem we're attempting to solve. Splitting the tabs based upon a calculation of the available screen real estate seems to me as running counter to the philosophy of letting GTK and the window manager handle such things. Whether hard-coded or derived, there are also the problems of whether the widgets should be divided evenly amongst the tabs (we probably wouldn't want to add a new tab for just one or two widgets) and how to label the tabs.

Automatically implemented tabs would most likely result in a dialog interface more objectionable than the scrolled dialog proposed by GnuTux's modification.

It would be possible to offer manual specification of the division of the tabs, for example by adding a SF-PAGE separator instruction in the registration block of the script. This would afford script writers better control over the dialog layout, being able to group related input fields in the same tab; as well as providing a means of specifying the label that is to appear on the tabs. Such an approach could readily be provided in a backwards-compatible manner -- should a page separator not be supplied, the script dialog would be presented as it always has.

Adding such a "SF-PAGE" facility to Script-fu may be worthwhile pursuing; however, it relies upon the script author taking advantage of it (or upon older scripts being updated to take advantage of it). It still does not address the possibility that the script author includes too many widgets on a single tab pane. N.B. Even if a tabbed interface is supported, it would still be prudent to support a scrolled interface within the tabs as a graceful way of handling an excessive number of input fields being requested.

With a tabbed approach, the implementation is at least an order of magnitude more complex than the code needed to implement scrolling. The tabbed dialog would need to support drag-n-drop; requiring either a "misuse" of the GimpDockbook widget or at least duplication of its D-N-D signal handling code in conjunction with a GtkNotebook container. (I say misuse since a script dialog is not dockable). Modifying the Script-fu registration code to support tabbed panes would require even more code.

By contrast, GnuTux's modification is straightforward, only about twenty lines of code, uses GTK in a standard, easily comprehended manner. It is much better suited for handling what is basically an edge case that is likely to only ever appear in just a handful of scripts.

-------

I would point out a couple of issues that still exist with GnuTux's modification in hopes of improving it further.

Firstly, Windows users have reported that the dialog created is obscured by the taskbar when that taskbar 1) runs along the bottom of the screen and 2) is not auto-hiding. If there are any Windows programmers who know how to rectify this, it would make the patch better behaved on those systems.

Secondly, with the patch applied, resizing of the Script-fu dialog results in the widgets within the scrollable window to be scaled. Normally such window resizing of a Script-fu dialog results in the widgets being scaled horizontally, but not vertically (additional empty space is inserted into the dialog). If possible, the patch should be amended to restore original behavior with regard to dialog window resizing.

I've actually seen "in the wild" a script-fu fork that would add options for explicitliy creating widget columns. AFAIK, author of that have never contacted the GIMP developers - let me google around to try and find it -

Ah, here - someone had actually hacked the Python-fu to allow greater control of the generated UI:

http://gimpchat.com/viewtopic.php?f=9&t=9378

And as for script-fu,a couple of days ago, someone made a scroolbar enabled version -
this is such a straightforward workaround for UI's getting larger than the screen that maybe it
could be considered a bug-fix and go into gimp-2.8:

http://gimpchat.com/viewtopic.php?f=9&t=9824

(disclaimer: I had not tried either, just saw the screenshots)

js -> wrote:

While GnuTux was working on his patch, I was investigating the possibility of a tabbed approached. Here are some of my thoughts on the matter.

A tabbed approach could either be implemented automatically or specified within the script. The first problem posed by an automatic approach is how the table of widgets should be split into multiple tabs. If it is hardcoded as a fixed number of widgets per page then users with large screen displays would be penalized by choosing too small a number, whereas too large a number invites the same problem we're attempting to solve. Splitting the tabs based upon a calculation of the available screen real estate seems to me as running counter to the philosophy of letting GTK and the window manager handle such things. Whether hard-coded or derived, there are also the problems of whether the widgets should be divided evenly amongst the tabs (we probably wouldn't want to add a new tab for just one or two widgets) and how to label the tabs.

I would point out a couple of issues that still exist with GnuTux's modification in hopes of improving it further.

Firstly, Windows users have reported that the dialog created is obscured by the taskbar when that taskbar 1) runs along the bottom of the screen and 2) is not auto-hiding. If there are any Windows programmers who know how to rectify this, it would make the patch better behaved on those systems.

I agree. If there was something I could do to compensate for this deficiency in Window's, it would be nice. In Linux, when the size of (sf_interface->table) is larger that the screen size and I set the dialog to that size, GTK keeps the dialog above/below panels/taskbars and displays scrollbars. In windows, the size of the taskbar is ignored and the full screensize is used, so the dialog falls behind the taskbar. The workarounds I've seen to compensate for this are pretty messy hacks. Perhaps this is an issue with Window's implementation of GTK and should be corrected there.

Even with this deficiency, Windows users are happy with this modification. In the event this does occur, they can easily resize the dialog to get to the input fields that were previously off screen and inaccessible.

Secondly, with the patch applied, resizing of the Script-fu dialog results in the widgets within the scrollable window to be scaled. Normally such window resizing of a Script-fu dialog results in the widgets being scaled horizontally, but not vertically (additional empty space is inserted into the dialog). If possible, the patch should be amended to restore original behavior with regard to dialog window resizing.

As you say, by default, vertically increasing the size of dialog results in some of the the widgets (with graphical elements) being scaled up. With the old behavior, vertically increasing the size of dialog would just add a bunch of white space between the input fields and the progress bar, which is not at all useful. While neither of these options are that useful, at least with scaling, you can make some of the items a little larger and easier to see. For that reason, I actually find the current behavior slightly preferable.

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

this is such a straightforward workaround for UI's getting larger than the screen that maybe it
could be considered a bug-fix and go into gimp-2.8:

Here, Here! That would be great. The patch has been tested on GIMP 2.8.x and works well.

http://gimpchat.com/viewtopic.php?f=9&t=9824

(disclaimer: I had not tried either, just saw the screenshots)

js ->