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.

So under each page would be the actual procedures such as...


Something like that?

This would also apply to someone who considers usable of a piece of software with over 16 settings (*) that you cannot test interactively, and for which you cannot even set context-sensitive default values?

(*) What seems to fit in a 768-pixels-high dialog, some of them being higher that the standard (PF_TEXT,PF_RADIO) on the dialog I used to test (DemoGUI).

This would be absolutely marvelous.
But what page (if any), would SF-IMAGE and SF_DRAWABLE fall under?

Yeah, most of the desktop apps that I use don't make use of a lot of input forms but normally, when you resize a window (or have a smaller resolution display) and there are forms/dialogs, scroll bars appear to allow you to get to those entry fields. Even in GIMP, we see this kind of thing. For example, with the paint brush (and other dialogs). When there isn't enough room on the screen, scroll bars appear.



Of course, scrolling forms and dialogs are a way of life in the web browser and on smart phone & tablets. Certainly, most flavors of C have the ability to create scrollable forms but as you say, there are varying schools of thought on whether it's best to present a scrolling form or multiple screens/tabs.

I guess I can understand why the Script-fu dialog was designed as it was, back in the day, but it does seem like there could be room for improvement now. I'm not sure what the best approach would be. My initial thought was that a scrolling form might be a good option, but I do like the idea of tabs. Truthfully, I'd be happy with any way to get a few more items on the Script-Fu UI.

Well, I was mainly speaking to the idea that we are given default scripts in GIMP that can't be used unless we have a display with a high enough resolution. There are certainly limitations as to what Script-Fu currently provides, but that doesn't mean it can't, or shouldn't, be improved, nor does it mean that it should be summarily abandoned in favor of somethings else.

I will concede that there does come a point to where one would need to abandon Script-Fu for a more robust development environment, but that doesn't necessarily mean Python would be the better alternative.

Me too Tux.
Mainly though i would be happy to be able to adjust the scripts written by other folks that my res can't see. Just by adding the procedure for SF-PAGE would do it.

Saulgoode is this procedure already available and can it be turned/switched on?

In this regard, I am reminded of G'MIC, where you can see that, when the selected filter is from among those provided with a large amount of settings, the right dialog box becomes scrollable if necessary.

When you use the above method or below method to move a dialog box, does using the tab key (rather than the mouse), to select options make any difference?

1. Right click the Menu bar -> select Move.
2. Use the arrow keys to move the window.
3. Left click the Menu bar to release.

I make a noticing 2 proposed , and already functional improvement for the python script interface
Not only that but was that to cause my

now here we are talking of script fu not of python so i only give the link
viewtopic.php?f=9&t=9378&start=0

Anyway if the python module may be modified maybe are possible modification also for script fu..at least to fix the scroll bug , or allow double columns when space is insufficient

SF-IMAGE and SF-DRAWABLE are treated specially when they are the first arguments passed to a script, so they should appear at the beginning (typically). There would be an advantage to having them appear before the first SF-PAGE (as you show), but it might be a little tedious to explain the reason.


No, it is not available. It would need to be written.