GNOME Bugzilla – Bug 725432
Enhance The Script-Fu Interface To Support Scrolling
Last modified: 2018-05-24 14:20:45 UTC
Created attachment 270618 [details] [review] Patch To Add Support For Scrolling To: script-fu-interface.c I would like to propose an Script-Fu Interface enhancement to enable support for scrolling. There are several reasons this would be a useful enhancement to GIMP. As it now stands, if a script's dialog is too large to fit on the screen, it simply disappears off the edge. In Linux, users can alt-click and drag the dialog around to get to the needed input items, which is not really an optimal solution. Windows users are out of luck, as they have no way to get to the input fields that are off screen. In the case of Windows 7/8 users, there is no provision to gain access to these fields. A scrolling Script-Fu dialog resolves this problem. Even in Linux, scrolling a preferable option to alt-click and drag. Another really good reason to implement this enhancement is to allow Script-Fu developers (like myself) the freedom to add all the needed input items to the dialog. For example, text effect & logo scripts can requires several input fields, just for the text, even before you begin processing the effects. Personally, I have always felt limited by the constraints of the Script-Fu dialog, which is why I'm asking you to consider the small patch I'm attaching to this request. The patch adds scrolling to the Script-Fu dialog, with minimal changes to the interface code. The modification has been tested, works well and users really seem to like it. Thank you for considering this enhancement request. GnuTux
If a Script-Fu dialog is larger than the screen, then this may be an indication that the script is doing a lot more than what this binding is intended for.
Whose to say how many input fields are appropriate or required for the task at hand? Script-fu/Scheme is certainly capable of handing many inputs. Adding artificial and arbitrary limitations doesn't make much sense to me. The only real limitation is the script-fu interface. Sometimes, you need more input fields that can fit on the screen, especially a lower resolution display or when the user configures their desktop with large font themes, due to their vision (which is the case for me). Even the logo script "Glossy", which is provided with GIMP, doesn't fit on my display. Not everyone has perfect vision or uses super high resolution displays with tiny fonts.
While I am not a fan of dialogs full of lots of input fields and widgets, this patch is well-designed in that the scrollbars are only introduced if needed. For Script-fu dialogs that fit on the screen (in other words, 99.9% of them), the presentation of the dialog will be exactly the same as currently presented. The additional code handles the ugly situation of having portions of dialogs hidden offscreen and, for such cases, provides a much more elegant interface than current behavior.
I agree, even though such scripts are evil, they do exist, and should be handled gracefully. Nice patch, but it lacks spaces before each '('. I'd also call it a bugfix not an enhancement.
Hi GnuTux, first of all thank you for picking up a problem and providing a solution that even is tested. Such contributions are always welcome. The issue what Michael was probably pointing out is that dialogs which need such a scrollbar contain too much elements to still be considered user friendly. The 'Glossy' dialog is an example. Users who are trying to get a job done *fastly* (that's our product vision) have to find their way through such dialogs and have to answer a plethora of questions silently in their minds: 'What is this thing?', 'What does it mean?', 'Which option should I choose?', 'Where do I find that thing to achieve this or that?'. We strive to make GIMP more user friendly. I personally think just adding a scrollbar heals symptoms, but doesn't solve the problem itself. It even makes the users think more especially about the last question. IMHO these dialogs should be reviewed and get an easier interface instead. To answer your objections: > Whose to say how many input fields are appropriate or required for the task at hand? This is depends on the intended user audience, their goals and the specific task. More generally this is a product of the rules of usability. We in the GNOME project follow the GNOME Human Interface Guidelines, for instance see https://developer.gnome.org/hig-book/stable/principles-simplicity.html.en. > Adding artificial and arbitrary limitations doesn't make much sense to me. These aforementioned limitations are neither artificial nor arbitrary, but lie in the human nature of cognition. So, to put things right: your work isn't useless. It points us to an issue that still needs to be solved. Let's discuss this topic on the GIMP developer mailing list. This is the usual way to deal with all enhancement requests (not only yours). I brought up the discussion here: https://mail.gnome.org/archives/gimp-developer-list/2014-March/msg00000.html. We can try to make the best out of your code there. Feel welcome to join us ;-)
(In reply to comment #4) > I agree, even though such scripts are evil, they do exist, and should > be handled gracefully. Nice patch, but it lacks spaces before each '('. > Sorry about the spaces. Should I submit an updated patch? > I'd also call it a bugfix not an enhancement. That being said, should I submit a patch for V2.8.x and perhaps it could make it into the next maintenance release?
> Let's discuss this topic on the GIMP developer mailing list. This is the usual > way to deal with all enhancement requests (not only yours). I brought up the > discussion here: > https://mail.gnome.org/archives/gimp-developer-list/2014-March/msg00000.html. > We can try to make the best out of your code there. Feel welcome to join us ;-) Ok, I responded on the list. :) Thanks!
Created attachment 274398 [details] [review] Cleaned up patch I cleaned it up a bit to match the coding style, but it can't go in like this because: - the magic numbers don't work because of themes - the table must not grow when the dialog is resized - there probably should be no scrolling at all if all widgets fit the screen
i think the patch is a good idea for now. (using GIMP 2.6.12, the "Color Exchange" dialog (not Script-Fu specific, found under Colors -> Map) also does not fit on my screen (1366x768). I'm using Linux, and didn't know about the Alt-click functionality, but that fortunately does immediately solve my specific problem.) Therefore, if such dialogs have not been simplified enough in the current development according to GNOME Guidelines, and still warrant the need for scrollbars, i would like to see this patch/functionality somehow applied to all dialog windows if it isn't already. I actually think it would be good to add this patch/functionality to all dialogs, because i don't believe it is possible to simplify using GNOME Guidelines every dialog to the lowest common denominator (that being the smallest screen (or screen resolution thereunder) that might be displaying GIMP) thank you
(In reply to comment #8) > > - the magic numbers don't work because of themes > - the table must not grow when the dialog is resized > - there probably should be no scrolling at all if all widgets fit the screen I had thought the last item had already been addressed (comment #3); the scrollbars should not be appearing if the contents fit the dialog. I agree with the second item and had discussed this with GNUtux earlier. While he expressed a personal preference for scaling enlarged dialogs, doing is inconsistent with the behavior of other plug-ins and would represent a change from previous expectations. Fixing this should just be a matter of setting the GTK+ flags correctly when building the dialog. I also agree with the first item. I only tested against the default theme and can see where other themes might cause problems. Thank you for looking into this.
Comment on attachment 274398 [details] [review] Cleaned up patch As per comment 8
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/540.