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.

Saulgoode, do you think this is a project worth pursuing? I'd be happy to contribute with tracing, coding, documenting or whatever might be necessary to make it happen.

Yes. Now might be a good time to tackle this as the code will necessarily need updating for the GIMP version after 2.10 (because of the switch to GTK 3). By "now", I mean next year -- I've got some obligations that are going to tie me up until after the holidays.

That sounds great, Saul. Could you direct me toward some relevant bits of source code to peruse in the interim.

The first thing is to understand what Script-fu calls the "standard function arguments" (sometimes referred to as 'sfa' in the docs). Basically, if the first arguments in the registration are among SF-DISPLAY, SF-IMAGE, SF-DRAWABLE, SF-CHANNEL, SF-LAYER, or SF-VECTORS then there is no widget drawn for them and they get assigned their values from the corresponding active item. This is why you typically see the following code in the 'script-fu-register' call:
Note that these arguments will result in widgets if they appear later in the registration.

These standard arguments are "counted" in the function 'script_fu_script_collect_standard_args()' in the script-fu-scripts.c file.

In the same file, the function 'script_fu_script_proc()' then determines if a dialog box needs to be created based on the run-mode and whether there are any non-standard arguments.

The dialog box itself is created by the function 'script_fu_interface()' in the file script-fu-interface.c -- this is where all the GTK widgets are defined and callbacks get assigned to update the corresponding PDB argument value. This function would need to be modified to set up tabbed pages and to place the argument widgets appropriately on those pages.

If anyone is tweaking this code: the one thing these dialog miss IMHO is some way to set value defaults (and ranges, for sliders/spinners) that are adequate for the image...

I agree with Ofnuts. We also need to tweak the input for text to be able to stack it instead of one long text line. By stack it i mean sort of the way the tag <BR> works in HTML. Just to create a break. This could result in a smaller width for dialogs also. A few things could be fixed while it's being re vamped.

There are two text input widgets, PF_STRING and PF_TEXT. What you want is PF_TEXT.

@saulgoode - Thanks for the info. That will give me a place to start.

@ofnuts -I might be misunderstanding, but I believe what Rod is wanting is an enhanced SF-STRING, where you can add line breaks and still only take up a single line on the screen. Either that, or a modified SF-TEXT, where instead of a 3 line scrolling dialog, you have a single line scrolling dialog.

That would be a smaller SF_TEXT, plugins don't expect line breaks in SF_STRING.

That would not be an easy change. The expressions defining the widgets' values are evaluated when the script is loaded, i.e., either at startup or when a Script-fu Refresh is performed, so the image may not be known, let alone its dimensions.

It might be possible to store the expression itself as the argument, and then evaluate the argument when the dialog is constructed (i.e., when the script is executed), but then one needs to develop a means of specifying what the parameter is evaluating. A kludge would be to insert some pseudo-variables such as $image, $width, etc; but I generally dislike such approaches and would lean towards providing bindings only for the standard function arguments and letting the script author be responsible for retrieving the corresponding arguments (e.g., (car (gimp-image-get-width sf-image)) or somesuch). The code might be more complicated but it would not place any artificial limits on what parameters are available (one could, for example, derive the argument from the length of a path or the number of blue pixels in the selection).