The values are kept between calls to the same filter in the same Gimp session. So Gimp keeps a set of values somewhere which is not the one used in the registration. In fact when one thinks about it the registration is only useful for the menu location, the type of images on which the filter can act, and the PDB declaration. Dialog contents (types of widgets, ranges, defaults values, and labels) being declared at the same time may simplify the code a bit and ease the work of the script developer (this insures some consistency between the dialog and parameters declared to the PDB) but it is not technically necessary and could be done much later.

A possible solution is to keep everything as it is now, and just add a callback function to the registration data. Before displaying the dialog, Gimp passes the dialog description (from the registration or the last use, with values set to the registration defaults or the last ones used) to the callback, which returns a new structure to be used to create the dialog. A default callback just returns the same structure, and advanced call back can change the default values, ranges, labels, available selections... (a PF_HIDDEN widget type could be useful)

I've taken the first step and setup a development environment in Fedora 20 (running in a VM) and was able to get a clean compile of GIMP 2.9.1 devel from GIT.



Turns out I can compile the Script-Fu plug-in, without doing a full GIMP compile. All I have to do run make in the script-fu folder, making changes to the interface easy to test.

Well, I've made good progress updating the Script-Fu interface routines to support scrolling.



I still have a few issues to work out, such as auto-sizing, but it works well.

This is actually a pretty good solution, due to the fact that existing scripts (ones with lots of input dialogs that don't fit on the screen) won't need to be updated. With the popularity of smaller screen resolution pads and tables, this feature should come in handy, going forward..

I wonder if the GIMP developers would consider adding this code to the next release?

When I've tied up the loose ends, I'll release the finished code for those who like to roll their own GIMP.

Nice GT. I liked messing around with the 2.9 version.

Well, the development version is pretty dang buggy, at this point. I guess whether any given feature works, depends on when you happen to clone it from GIT and compile. It works well enough for development, though.

When I'm satisfied the new scrolling code is bug free, I'll release a patch for GIMP's latest stable source code, so we can have scrolling on GIMP V2.8.x (after a compile). Who knows how long before V2.10 is released. My guess is that it won't be soon.

Looking good Tux!
This is great news for me as i have a 15.6 monitor but it is also very short I'm gonna guess about 9 inches tall maybe ten so the dialog's are off the screen still for me until this is implemented. So this is just a recompiled src code change for the script-fu.exe file then?

Yep. The only thing I've had to modify so far is script-fu-interface.c, which is compiles to the script-fu executable (plug-in).

Earlier in this thread I had proposed using a tabbed dialog as opposed to a scrolling one. While I still think the tabbed approach would present a more elegant interface and be more consistent with the dialogs of other filters, I concede that the scrolling approach implemented by GNUtux would be the more practical implementation.

One of the biggest challenges to creating a tabbed interface would be support for drag-n-drop operations (of brushes, colors, patterns, gradients, etc). By my reckoning, support for this feature would almost double the size of script-fu-interface code, whereas support for drag-n-drop in GNUtux's scrolled dialog should require no specialized processing. Increasing the complexity of the interface code for little, if any, gain in actual functionality can not, in my opinion, be justified.

I look forward to endorsing this feature's incorporation into GIMP. However, I would suggest holding off on submitting an official enhancement request until the code has been tested and its operation can be readily demonstrated and its beneficial nature understood.

Thanks for the feedback and support for this project.

To be perfectly honest, it's been 15-20 years since I've engaged in any serious C coding and back then, the C language was a bit different than it is today. The basics are the same but I never had to deal with GUIs. The code I was developing back then was mostly hardware interfaces, so my expertise with the abstraction level of the GTK API is pretty much nil.

So, I'm trying to come up to speed. At this point, I'm still at the monkey see, monkey do, level. While my scrolling modifications do work, with the minimal changes I made to the original interface source, I really don't know if what I've done so far is the correct approach, or not. My guess is there are probably more elegant (or proper) ways to code this feature and I would welcome input or collaboration from anyone here. I suppose another resource I could take advantage of would be the GIMP developer list, which I do follow, but I have yet to subscribe to the list.

So far, I've only invested a few hours into this effort and I would like to get a little further along before presenting what I have. Even if I have to toss what I have and start again, the time I've spent has been a good learning experience. That being said, I would like to see this feature implemented in GIMP.

Who knows? The whole idea might be rejected by the GIMP Developers and I'll be the only one using it.

I'm not sure what you mean. The new scrolling interface would be used by all Scheme scripts.

Depending on how tabbed support was implemented, I suppose you could code the interface to split up various input fields into categories or simple columns, which should work on all the older scripts as well.

Thank you for adding new features.
I can not wait to start testing for Windows.

This implementation should cause all previously installed scripts to incorporate a scroll bar if the interface is too long or the monitor screen too short. I think because all previously installed scripts would not have to be re written to accept the code it is a beautiful step in the right direction. Tux i believe you will make it into the script fu history books. If you need a tester just holler.

Yeah, well, with my weak GTK skills, this project could go down in history ...as an epic fail.

The main problem is, I can place the list of Script-Fu input widgets in a resizeable, scrolling box, but it doesn't automatically size the box to initial height & width of the list of input widgets. By default, it sets the width to the size of the action buttons at the bottom and the height to (what appears to be) the minimum size of the vertical scroll bar. So, every time I run a script, I have to manually resize the box, which is a pain. I can manually set the initial size of the box, but since every script's input screen has different widths and heights, setting it manually doesn't really help much.

The behavior we need is as you describe above. I'm sure it can be done, but I can't find any examples and it's not obvious by reading through the docs.

Not sure i get you about re sizing each dialog box. Do you mean dragging out the corner of the dialog to make it wider? I don't think the width according to the buttons at the bottom will be an issue. And if i have to scroll in every dialog that is no big deal either. Maybe you could show a screenshot of the problem? Thanks Tux.

Yes, that what is happening. As it stands now, you have to grab the corner of each script's dialog and drag to expand it, because it always starts at the minimum size. Setting the height to 200px is an OK compromise, I suppose.



Surely, this is an issue than can be resolved and it's just that I haven't figured it out. If I could determine the size of a widget I might be able to just use that. Perhaps saulgoode or someone else here will be able to help out. I did subscribe to the GIMP devel list, so if all else fails, I guess can always ask there.

To me it sounds like you have packing problems

In PyGTK you get to specify if boxes can expand to fill the available space, or just use just enough space to contain their contents. http://www.pygtk.org/docs/pygtk/class-gtkbox.html

In TCL/TK you can specify the horizontal and vertical behaviour separately, so hopefully GTK will allow you something similar.

You do have a conundrum with the vertical size - are you going to create a dialog that is bigger than the user's display, then when they manually re-size it the scroll-bar appears? Or fix the dialog size from the outset? If so what happens to dialogs that are naturally smaller than your fixed size?

Kevin