gtkdialog chooser
gtkdialog chooser
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
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
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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>
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>
"refresh:" including the colon is the function name.trio wrote:Thanks mochi. The changing from type= "refresh" to refresh:PIXMAP did the trick. Wonder why
PIXMAP is the target of the function, what it acts on.
You name targets in the script. It means this particular script defines PIXMAP.
[url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Fatdog64-810[/url]|[url=http://goo.gl/hqZtiB]+Packages[/url]|[url=http://goo.gl/6dbEzT]Kodi[/url]|[url=http://goo.gl/JQC4Vz]gtkmenuplus[/url]
Wow, this works?MochiMoppel wrote: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>
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
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.zigbert wrote:What does actually when="update-preview" do?
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:zigbert wrote:Does there exist any documentation?
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.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?) */
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.zigbert wrote:What else is it capable of?
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)
No, thanks. My experience with Woof-CE was rather unpleasant. I deleted my account. Let's keep it this way.zigbert wrote:Are you willing to request this change to Woof-CE?
- Attachments
-
- chooser_with_integrated_preview.jpg
- Example of chooser dialog in Inkscape
- (46.51 KiB) Downloaded 1066 times
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.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
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
Thanks for any help
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.zigbert wrote:I find it user-unfriendly to not give the user the default filename
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)
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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:
Below script should help to better understand signals. It must be run from a console to see the output.
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
- Attachments
-
- mm_chooser_test.png
- (189.47 KiB) Downloaded 746 times
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
I have tried to find a solution for this old problem lately.zigbert wrote:I find it user-unfriendly to not give the user the default filename
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
- Attachments
-
- Screenshot.jpg
- (50.45 KiB) Downloaded 444 times
- misko_2083
- Posts: 114
- Joined: Tue 08 Nov 2016, 13:42
[s]MochiMoppel wrote:I have tried to find a solution for this old problem latelyzigbert wrote:I find it user-unfriendly to not give the user the default filename
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"
I will try to catch the load event with strace.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.misko_2083 wrote: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.
- MochiMoppel
- Posts: 2084
- Joined: Wed 26 Jan 2011, 09:06
- Location: Japan
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.misko_2083 wrote:Edit: scratch all of that, it still needs a 2 sec delay for /usr/bin .
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
- Posts: 114
- Joined: Tue 08 Nov 2016, 13:42
Then I giess the filenames must be utf-8 encoded.MochiMoppel wrote: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.misko_2083 wrote:Edit: scratch all of that, it still needs a 2 sec delay for /usr/bin .
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.
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.