I was wondering if anyone has any insight as to why the Script-Fu user entry screen doesn't present scroll-bars when the input window is too large for the display.

This is basic functionality in QT and GTK and I'm just wondering if there is any reason why this ability is not already included in Script-Fu.

That is a good question. And it could very well be the answer to our one column dilemma. You see user/value added areas in the dialogs in GIMPs interface so why not scripts also?

In Linux (MATE), I can hold Alt-m and drag the input screen with the mouse to get to the entry fields that are off screen.

Is there a similar feature in Windows and/or MAC?

The answer is in this thread..

viewtopic.php?f=9&t=2850#p36798

Basically, it's because you don't actually call a Script-Fu script directly, like a plug-in, you call the Script-Fu plugin, which runs the script interpretatively. The Script-Fu script can't then call another Script-Fu script interactively because the Script-Fu plug-in is already running your script interpretatively and there is no mechinism to spawn another instance, while passing the proper parameters/arguments to the new instance.

Well, it's not just any old plug-in. It's a scheme interpreter and the problem arises when attempting to call another instance from a script already running inside.

The interface to the interactive dialog can't be called from a script running in the scheme interpreter, because the interface code exists outside the interpreter.

Yeah, I guess since we can't call a Script-Fu script interactively from another Script-Fu script, a workaround might be to modify interface to allow scrolling.

Can you drag the menu around to see the off screen fields in Windows, as I can in Linux with the Ctrl-m + mouse? I can't remember if there are Window's keystroke to do that or not.

Found this for Windows..
http://lib.umhs-sk.net/keybshortc.pdf

ALT+ SPACEBAR + M = Move current windows with arrow keys
ALT+ SPACEBAR + M + any arrow key once, then move the mouse to position the window where you like.

I think the answer to that question is that Script-Fu has been kept as simple as possible and adding optional scroll bars is extra complication.

If you really want to add all those extra inputs to a user-interface, then it's time to move to Python and creating a custom UI using pygtk or TkInter, then you can expand to more than one column, tabbed interface etc. (Of course you'll also learn about the extra complications in building a flexible UI )

Kevin

Well, if that is true, it's laughably misguided that scroll bars have been omitted because Script-Fu's UI has been intentionally "kept simple". I actually doubt that is the case. Heck, I can't even get some of GIMP's Built-in Logo scripts, like Glossy, to fit on the screen and I have decent resolution. This issue is exacerbated when one is working with even lower resolution displays, such as 1024x768. Why would some Script-fu scripts, that many users can't even see on the screen, be included in GIMP? It just doesn't make sense. It's not like we need 100's of inputs, anyway. How about 15-20, which would cover very basic functionality?

If it is true, whoever made that decision should be severely beaten around the face and head, so as to have some common sense slapped into them.

+1 to that.

I wonder if it would really be that difficult to add auto scrolling for all op systems to script-fu dialogs via the script-fu.exe plug-in src.

Found this
http://www.codeproject.com/Articles/109 ... -a-C-Helpe

And GTK.
http://hackage.haskell.org/package/gtk- ... indow.html

Can Java scripts be ran in GIMP yet? I thought they were going to implement that in GIMP-2.8.

Scrolling of the controls within a dialog is not consistent with traditional human interface guidelines. Does anybody have an example of this being done? F-Spot has a scrolling toolbox, which in itself is ugly enough; but I have never seen a scrolling dialog.

The preferred method for handling more controls than fit on a page is either tabbed dialogs:



or list controls:



It would be entirely feasible for Script-fu dialogs to resort to a tabbed dialog if the number of widgets is too large. The main reason it hasn't been done before is probably that any decent window manager provides a ready means of accessing parts of a window that display off-screen (e.g., ALT+CLICK).

You can right click and move a dialog with the arrow keys in Windows XP but as soon as you try to enter data (clicking mouse), the window position resets itself.
You can however use the "TAB" key to get to value input areas , type in the value and TAB on to the next value area. Pain though.
Tabs in dialogs would be an excellent idea i think. How would you categorize them though so that they would be fluent in all written scripts?

I would just add an SF-PAGE option to the script-fu-register procedure.

For example (using the Lighting Effects tabs):

If not the reason i believe that was a perfect excuse , but you should consider WHEN was written the script fu interpreter , in that period was rare for script and plugin have more the 3 or 4 controls, with even people complaining that unsharpmak was too complex because have too much sliders :3 !

And "kept simple" was a suggestion repeated as a mantra ,and respected almost a religious point

would be no possible allow to toggle the not used options ?

i.e. suppose a script has a option for... let say use gimpressionist, and after the "use" gimpressionist" box there are all related commands

now toggle off that part, when that plugin is not used, would not only shrink the dialogue so hopefully would fit in the screen size but maybe even more important will "kept simple" for the users, avoiding to confound them with inactive dialogue.