gtkdialog chooser

[trio]

Hi,

Does anybody know what action signal for gtkdialog <chooser> as in Nathan's wallpaper setter, that can do action when scrolling with up/down arrow? it's kind of annoying having to click for the preview to change

Regards

[MochiMoppel]

update-preview and selection-changed

[trio]

update-preview and selection-changed

Thanks but they dont work. I tried,. or you can give working example?

[MochiMoppel]

They work, though syntax is not what you might expect.

In /usr/local/apps/Wallpaper/AppRun add 2 lines to the chooser dialog:

<action signal=\"button-release-event\" type=\"refresh\">PIXMAP</action>
<action when=\"update-preview\">swapimagefunc</action>
<action when=\"update-preview\">refresh:PIXMAP</action>
</chooser>

[trio]

Thanks mochi. The changing from type= "refresh" to refresh:PIXMAP did the trick. Wonder why

[step]

Thanks mochi. The changing from type= "refresh" to refresh:PIXMAP did the trick. Wonder why

"refresh:" including the colon is the function name.
PIXMAP is the target of the function, what it acts on.
You name targets in the script. It means this particular script defines PIXMAP.

[trio]

Hshaha.. maybe i was not clear

What puzzles me is the difference of
type= "refresh" >PIXMAP< to >refresh:PIXMAP<

as the first does not work

[zigbert]

They work, though syntax is not what you might expect.

In /usr/local/apps/Wallpaper/AppRun add 2 lines to the chooser dialog:

<action signal="button-release-event" type="refresh">PIXMAP</action>
<action when="update-preview">swapimagefunc</action>
<action when="update-preview">refresh:PIXMAP</action>
</chooser>

Wow, this works?
What does actually when="update-preview" do?
Does there exist any documentation?
What else is it capable of?

MochiMoppel
Are you willing to request this change to Woof-CE?
https://github.com/puppylinux-woof-CE/w ... per/AppRun

[MochiMoppel]

What does actually when="update-preview" do?

It signals that a preview widget should be updated, typically when file selection has changed. Basically a preview widget can be added to a chooser dialog (see screenshot), but this is not supported in gtkdialog. The good news is that the update-preview signal is emitted anyway - and it works much better than the selection-changed signal. The selection-changed signal is emitted even before anything is selected at startup and it may generate errors when the user clicks in the left Places panel. The update-preview signal is fired only once for each selection change. Much more reliable.

Does there exist any documentation?

For the Chooser widget? Apparently not (see remarks by Thunor in this example). Judging from other remarks in the source code Thunor wasn't very convinced of the Chooser widget:

case WIDGET_CHOOSER:
/* Thunor: This widget is incredibly lacking in comparison to
* the fileselect action function and really needs a newer
* alternative (is anyone actually using this?) */

Fortunately not all remarks are correct. Chooser *does* support modes other than the default GTK_FILE_CHOOSER_ACTION_OPEN and there *is* access to a directory creation button. There is even an option to hide this button. File filters are not supported though.

What else is it capable of?

Again not sure what you mean by "it". If you mean the Chooser widget itself: Compared to the fileselect action function it is simpler, doesn't need another widget to work and thanks to its update-preview signal it allows to arbitrarily select files or folders without the need to limit the choice to one of these two. It allows to hook different actions to click and double-click.

Interestingly it is capable of multiple selection. The tag attribute select-multiple="true" turns on multiple selection, BUT this has no practical use since the variable will return only 1 item.

Here the two tag attributes that I found do work:

Code: Select all

Name                Description                             Possible values
-------------------------------------------------------------------------------
create-folders      show/hide "Create Folder" button        true (=default) or false
action              set action mode                         0 (GTK_FILE_CHOOSER_ACTION_OPEN=default)    
                                                            1 (GTK_FILE_CHOOSER_ACTION_SAVE)
                                                            2 (GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER)
                                                            3 (GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER)

Are you willing to request this change to Woof-CE?

No, thanks. My experience with Woof-CE was rather unpleasant. I deleted my account. Let's keep it this way.
  
  
  

[zigbert]

MochiMoppel
A great explanation. - I am learning!

Sorry to hear that you won't apply to Woof-CE.
I've updated the wallpaper script with your code

Thanks a lot

[MochiMoppel]

I've updated the wallpaper script with your code

The code was a quick shot
To make the code more efficient and avoid calling the same functions twice the 2 lines I proposed should replace the 2 button-release-event actions instead of being added to them.

[zigbert]

Sorry
Fixed

[zigbert]

Looking into the <chooser> widget trying to actually use it...

With the knowledge of the action="1", I am getting really close to a useful save-dialog. The final issue is that I can't get it to accept a <default> file - only a <default> folder.

Code: Select all

echo '
<window>
<vbox>
	<chooser action="1">
		<default>/root/.jwmrc</default>
		<width>600</width>
		<height>400</height>
	</chooser>
	<checkbox>
		<label>My options</label>
	</checkbox>
	<hbox>
		<button ok></button>
		<button cancel></button>
	</hbox>
</vbox>
</window>
' | gtkdialog -s

Change /root/.jwmrc to /root, and it all works fine, but I find it user-unfriendly to not give the user the default filename. If the user first opens a file - that should be the default saved filename as well. Do anyone know something I don't.

Thanks for any help

[MochiMoppel]

I find it user-unfriendly to not give the user the default filename

Not implemented in chooser - and not implemented in the fileselect function either, which Laszlo Pere developed 2 years later. I assume that there were always more important issues on the to-do list.

Leaving the field blank does not necessarily mean that the dialog is user-unfriendly. GTK_FILE_CHOOSER_ACTION_SAVE is also - and probably most often - used as the "Save" dialog for yet unsaved documents, in which case the field remains blank (Leafpad) or contains a dummy name like "untitled" (Geany).

<default> and fs-folder accept only folder paths and I agree that they should handle erraneously entered file paths more gracefully. Your example would pose another problem: .jwmrc is a hidden file and hidden files are not displayed by default (you can change the default, but that's a different story). Now try <default> with /root/.jwm, a hidden folder. Switch to the parent folder /root and - tataaa!! - hidden files are now displayed and when you right click you see that "Show Hidden Files" is checked. GtkFileChooser is full of surprises.

Here a small summary of the startup behavior:

Chooser startup folder

Code: Select all

Tag                                     Chooser selects
-------------------------------------------------------------------------
none                                    Recently Used
<default>"/path/to/folder"</default>    If folder exists: folder
                                        If folder does not exist: parent folder of folder 
                                        If folder is hidden: folder ("Show hidden files" property will be turned on)
                                        If folder is a regular file: nothing
<default>""</default>                   current folder (=folder of script file or folder of symlink pointing to script file) 

For the fileselect function above behavior is the same when applied to the fs-folder attribute

[MochiMoppel]

Thunor's dislike for this widget ("I can't recommend using it") makes it even more appealing to me. Forbidden fruits taste sweet.
Tasting is now done here. I'm not sure where to put some of the nitty gritty stuff. Let's keep it here. I hope trio doesn't mind.

Some issues may still need clarification:

Signals
In order to use chooser effectively it is indispensible to understand its event handling.
Attaching actions to events can become challenging as chooser emits signals in a very bizarre fashion - or not at all.

Some examples:

• file-activated: emitted when user dbl-clicks a file, but this also emits almost all signals in the book. Complete bogus.
  confirm-overwrite: should be emitted for GTK_FILE_CHOOSER_ACTION_SAVE when user inputs existing file name. Does not seem to work.
  button-press-event: only recognized in the small bar in bottom left, containing + - buttons.
  focus and notify events: not recognized at all
  current-folder-changed: fires *before* the folder changes. <variable> returns folder before change
  key-press-event: Only recognized for modifier keys. Char keys will trigger search box. After opening search box corresponding key-release-event not recognized, not even for modifier keys.

Below script should help to better understand signals. It must be run from a console to see the output.

Code: Select all

echo '
<vbox>
    <chooser  action="0" create-folders="true" >
        <variable>vCHOOSER</variable>
        <width>600</width>
        <height>400</height>
        <action>                                echo -e "default\t\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action when="confirm-overwrite">       echo -e "confirm-overwrite\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action when="current-folder-changed">  echo -e "current-folder-changed\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action when="file-activated">          echo -e "file-activated\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action when="update-preview">          echo -e "update-preview\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action when="selection-changed">       echo -e "selection-changed\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="button-press-event">    echo -e "button-press-event\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="button-release-event">  echo -e "button-release-event\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="button-release-event">  echo -e "(button codes PTR_BTN:$PTR_BTN PTR_X PTR_Y:$PTR_X $PTR_Y PTR_X_ROOT PTR_Y_ROOT:$PTR_X_ROOT $PTR_Y_ROOT )"</action>
        <action signal="key-press-event">       echo -e "key-press-even\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="key-press-event">       echo -e "(key codes KEY_VAL:$KEY_VAL KEY_SYM:$KEY_SYM KEY_MOD:$KEY_MOD KEY_RAW:$KEY_RAW )"</action>
        <action signal="key-release-event">     echo -e "key-release-event\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="key-release-event">     echo -e "(key codes KEY_VAL:$KEY_VAL KEY_SYM:$KEY_SYM KEY_MOD:$KEY_MOD KEY_RAW:$KEY_RAW )"</action>
        <action signal="hide">                  echo -e "hide\t\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="show">                  echo -e "show\t\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="realize">               echo -e "realize\t\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="map-event">             echo -e "map-event\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="unmap-event">           echo -e "unmap-event\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="configure-event">       echo -e "configure-event\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="enter-notify-event">    echo -e "enter-notify-event\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="leave-notify-event">    echo -e "leave-notify-event\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="focus-in-event">        echo -e "focus-in-event\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
        <action signal="focus-out-event">       echo -e "focus-out-event\t\t$(basename $vCHOOSER 2>/dev/null)"</action>
    </chooser>
    <hbox>
        <button label="Enable">     <action>Enable:vCHOOSER</action></button>
        <button label="Disable">    <action>Disable:vCHOOSER</action></button>
        <button label="Show">       <action>Show:vCHOOSER</action></button>
        <button label="Hide">       <action>Hide:vCHOOSER</action></button>
    </hbox>
    <hbox>
        <button label="Clear console"><action>clear</action></button>
        <button ok></button>
        <button cancel></button>
    </hbox>
</vbox>
' |  gtkdialog -s

[MochiMoppel]

I find it user-unfriendly to not give the user the default filename

I have tried to find a solution for this old problem lately.

A couple of months ago user Leon also perceived it as a deficiency, so I offered an explanation and a solution for the MMview viewer here. It is now implemented and works more or less. but could be improved. Still finding the correct timing can be a problem: Starting xdotool too early will cause it to write to a not yet existing window, starting it late will annoy the user, so I wrote a little demo that allows to calibrate the timing.

When starting to type in chooser, the little searchbox at the bottom (see screenshot) will open. Typing the exact filename will result in the selection of the filename.
Instead of simulating the typing with xdotools's type option, which requires delays between each typed character, I figured that it would be faster and more reliable to paste the filename from the clipboard into the searchbox. Now the only delay that has to be taken care of is the time between the map-event and the time when the window is ready to take user input. Seems to depend on many factors. With my slow netbook and an old distro like slacko 5.6 0.8 sec seems sufficient, with modern distros I need more than a second. With a fast computer and a modern distro the time should be again less than a second. Also the directory size seems to matter. The directory /usr/bin is a good benchmark for testing (takes long to scan and therefore long time before xdotool can go to work)

Would be interesting to know which timing works for other users. I personally prefer 0.8 sec. In the demo script I use 1.5 sec. Feel free to experiment. The script requires xclip and xdotool.

Code: Select all

#!/bin/bash
#Purpose: Find suitable delay for xdotool. Make chooser (re)start with a specified file
#Usage:
#1) Select a file in the chooser widget
#2) Press Restart button. This should restart the script with the last file selected
#3) Repeat steps 1 and 2 with different file in different directory to see if this works reliably. 
#4) If selection fails repeatedly, increase JUMPTOFILE_DELAY value 

JUMPTOFILE_DELAY=1.5	#seconds

FILESPEC=$(</tmp/lastdir)
STARTDIR=${FILESPEC%/*}
FILENAME=${FILESPEC##*/}
[[ -d $STARTDIR ]] || STARTDIR=/ 
echo -n "$FILENAME" | xclip -loops 1 -sel c	#send basename to clipboard

printf '
<window>
<vbox>
	<chooser>
		<variable>vCHOOSER</variable>
		<width>500</width><height>400</height>
		<default>"'"$STARTDIR"'"</default>
	</chooser>
	<button label="Restart">
		<action>printf "$vCHOOSER" > /tmp/lastdir ; exec "$(realpath "'$0'")" &</action>
		<action>exit:</action>
	</button>
</vbox>
<action signal="map-event">xdotool sleep '$JUMPTOFILE_DELAY' key comma BackSpace Shift+Insert Escape &</action>
</window>'  | gtkdialog -s

[misko_2083]

I find it user-unfriendly to not give the user the default filename

I have tried to find a solution for this old problem lately

[s]
You can use the class to find the Xwindow ID.
Also --sync option and --onlyvisible options are required. I know that those are available years ago.
[/s]

This is without xclip:

Code: Select all

#!/bin/bash
#Purpose: Find suitable delay for xdotool. Make chooser (re)start with a specified file
#Usage:
#1) Select a file in the chooser widget
#2) Press Restart button. This should restart the script with the last file selected
#3) Repeat steps 1 and 2 with different file in different directory to see if this works reliably.


FILESPEC=$(</tmp/lastdir)
STARTDIR=${FILESPEC%/*}
FILENAME=${FILESPEC##*/}
[[ -d $STARTDIR ]] || STARTDIR=/
export CLASSNAME="MochikaMopelka_FileChoser"
export FILENAME

printf '
<window>
<vbox>
   <chooser>
      <variable>vCHOOSER</variable>
      <width>500</width><height>400</height>
      <default>"'"$STARTDIR"'"</default>
   </chooser>
   <button label="Restart">
      <action>printf "$vCHOOSER" > /tmp/lastdir ; exec "$(realpath "'$0'")" &</action>
      <action>exit:</action>
   </button>
</vbox>
<action signal="map-event">xdotool search --sync --onlyvisible --class "$CLASSNAME" type --delay=1 "$FILENAME" && xdotool key Escape & </action>
</window>'  | gtkdialog -s --class="$CLASSNAME"

Edit: scratch all of that, it still needs a 2 sec delay for /usr/bin
I will try to catch the load event with strace.

[MochiMoppel]

You can use the class to find the Xwindow ID.
Also --sync option and --onlyvisible options are required. I know that those are available years ago.

I don't think that class or any of the mentioned options are required since the new window is already active (though not yet visible). Basically your version is the same as mine explained to Leon and currently used in MMview. But thanks for looking into it.

[MochiMoppel]

Edit: scratch all of that, it still needs a 2 sec delay for /usr/bin .

I assume you mean sleep, not delay. Directory /usr/bin contains more than 1000 files and required sleep duration depends on the number of items in the displayed tree. I've tested a variable sleep time: 0.8 sec when the number of files is <100 and 2 sec. when above. Seems to work.

The real problem is the delay between characters.
1 is much too short, xdotool's default of 12 works OK for ASCII filenames. If you deal with filenames containing Unicode characters, the required delay is much longer. I tested with filenames like
Aθήνα city.txt
Greek city Θεσσαλονίκη.txt
You will see that characters are skipped when delay is too short. My reason for avoiding xdotool type.

[misko_2083]

Edit: scratch all of that, it still needs a 2 sec delay for /usr/bin .

I assume you mean sleep, not delay. Directory /usr/bin contains more than 1000 files and required sleep duration depends on the number of items in the displayed tree. I've tested a variable sleep time: 0.8 sec when the number of files is <100 and 2 sec. when above. Seems to work.

The real problem is the delay between characters.
1 is much too short, xdotool's default of 12 works OK for ASCII filenames. If you deal with filenames containing Unicode characters, the required delay is much longer. I tested with filenames like
Aθήνα city.txt
Greek city Θεσσαλονίκη.txt
You will see that characters are skipped when delay is too short. My reason for avoiding xdotool type.

Then I giess the filenames must be utf-8 encoded.
In UTF-8 Latin characters are 1byte sequences corresponding to ascii.
Greek, Cyrillic, and some other are 2byte, and Korean,Chinese,Japanese 3 byte, south asian 4byte. I guess the longer the sequence is, the longer it takes for xdotool to decode and type.
It also makes string manipulation difficult. Doesn't it?

Whenever the dialog searches for filenames it creates a short lived process but it creates other short lived processes and it's difficult to figire which one is the right one. My idea was to detect when that short lived pricess ends.
Sometimes system is too busy and the dialog would load the filenames much slower.
I guess the only way to do it right is to write a new gtk file selection dialog and do iselect the last filename internally.