How to show Recently Used Documents on JWM's Start Menu

How to do things, solutions, recipes, tutorials
Message
Author
B.K. Johnson
Posts: 807
Joined: Mon 12 Oct 2009, 17:11

#21 Post by B.K. Johnson »

MochiMoppel wrote:
...which would be very easy, but you also told me that even the basenames of your files may be very long (e.g.web page article titles).
Misinterpretation Mochi. Yes, titles of some web pages may be long, but I wasn't suggesting that they would be so long as to be problematic. What would be a problem is the path to a 6/7/8 level directory plus the long web page title.
So here your idea wouldn't help, right?
No, wrong!
And if the number of characters should be limited, what would this maximum number be and how should the name be truncated if it exceeds the limit
Here is a list of files with long titles I recently downloaded.
Backyard Woodfire Pizza Oven 10 Steps (with Pictures)-1.mp4
EaseUS-How to Create a Portable Windows 10_8_7 USB Drive.html
Is it Safe to Share My Internet Connection with My Neighbor_ - Ask Leo! (2019-07-31 10_52_13 PM).html
Is it Safe to Share My Internet Connection with My Neighbor_ - Ask Leo!.html

The first "Is it Safe ...", I renamed to the shorter title below it. It still is the longest at 74 characters. If you insist on a number, the old 80 col card length will suffice. Even such a length is unnecessary. The user has a good idea what he/she is looking for and should recognize it in 40 characters, I would think. The ideal would be:

Code: Select all

if file_length < 40, display all.
else make name consisting of a substring of the first 40 chars +"..."+ extension.
and should full path names be shown if they fit within the limit?
No! Why complicate matters. Why mix apples and oranges (paths and filenames)? But if you really want work, make the path to the directory a tooltip. :idea:
Lots of questions remain...
I don't think so. Unless you have more to pose. :wink:
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]

B.K. Johnson
Posts: 807
Joined: Mon 12 Oct 2009, 17:11

#22 Post by B.K. Johnson »

Duplicate deleted
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#23 Post by MochiMoppel »

This is a slightly improved (?) version of my initial script. It will display only existing files and only the basenames, not the full paths. While this keeps the menu items short it can pose problems after opening/editing files with same name from different directories. This will result in a menu with multiple identical labels ... not good! The script tries to solve this problem by adding tooltips, containing the full paths. JWM allegedly supports tooltips since version 2.3.3.
I tested with 2.3.7., but I see no tooltips. Does anybody have an idea how to make them work?

Code: Select all

#!/bin/bash
XBEL_PATH=$HOME/.local/share/recently-used.xbel
if [[ -e $XBEL_PATH ]];then 
    MAX_ITEMS=20 
    IFS=$'\n'
    ITEMS=$(awk -F'"' '/file:\/\//  { sub("file://","",$2); print $2}' $XBEL_PATH)
    printf -v ITEMS "${ITEMS//%/\\x}"               #convert UTF-8
    ITEMS=$(find $ITEMS   | tail -n $MAX_ITEMS)     #remove non-existent files, cut list off at MAX_ITEMS
    ITEMS=$(echo "$ITEMS" | sed  -r 's_(.*/)(.*)_<Program label="\2" tooltip="\1\2">rox -s "\1\2"</Program>_')
else 
    ITEMS="<Program label=\"File ${XBEL_PATH##*/} not found!\"></Program>"
fi
echo  "<JWM>
$ITEMS
</JWM>"
Some technical notes: According to the freedesktop specification the location of the xbel file should be $XDG_USER_DATA/recently-used.xbel, however at least in my system the $XDG_USER_DATA variable is not defined. The spec also sheds a little light on the confusing fact that recently-used.xbel does not contain data according to the Recent File Storage Specification, instead apparently uses this spec.

[EDIT] Changed code. Made more consistent with initial demo. Tested with JWM version vgit-1553. Still no tooltips.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#24 Post by BarryK »

This will display only existing files, including if have space characters, and will truncate lines exceeding 70 characters (actually, 70 bytes) by pre-pending "...":

Code: Select all

#!/bin/sh
echo  "<JWM>"
while read aFILE
do
 if [ -e "$aFILE" ];then
  if [ ${#aFILE} -gt 70 ];then
   echo "<Program label=\"...${aFILE:(-70):70}\">rox -s \"${aFILE}\"</Program>"
  else
   echo "<Program label=\"${aFILE}\">rox -s \"${aFILE}\"</Program>"
  fi
 fi
done <<EOF
$(tac ~/.local/share/recently-used.xbel | grep -m 20 -o '"file://[^"]*' | cut -c 9-)
EOF
echo  "</JWM>"
However, I won't use it, as the is a very noticeable delay when click the Menu button, before the menu pops up.
Last edited by BarryK on Sat 03 Aug 2019, 15:06, edited 1 time in total.
[url]https://bkhome.org/news/[/url]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#25 Post by MochiMoppel »

BarryK wrote:This will display only existing files, including if have space characters
Are you sure? recently-used.xbel uses UTF-8 encoding, e.g. %20 for space characters. In order to display spaces or accented characters or Japanese kanji you first must convert them
, and will truncate lines exceeding 90 characters (actually, 90 bytes) by pre-pending "...":
no, not bytes, it's really characters
However, I won't use it, as the is a very noticeable delay when click the Menu button, before the menu pops up.
Hmm, not here. Menu pops up without any noticeable delay, but this may well depend on the size of recently-used.xbel . Mine is relatively small but if your's is huge then I can imagine that it becomes unusable.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#26 Post by BarryK »

MochiMoppel wrote:
BarryK wrote:This will display only existing files, including if have space characters
Are you sure? recently-used.xbel uses UTF-8 encoding, e.g. %20 for space characters. In order to display spaces or accented characters or Japanese kanji you first must convert them
, and will truncate lines exceeding 90 characters (actually, 90 bytes) by pre-pending "...":
no, not bytes, it's really characters
However, I won't use it, as the is a very noticeable delay when click the Menu button, before the menu pops up.
Hmm, not here. Menu pops up without any noticeable delay, but this may well depend on the size of recently-used.xbel . Mine is relatively small but if your's is huge then I can imagine that it becomes unusable.
I did test with a text file that had spaces, it was stored in recently-used.xbel as-is, with the space characters.

I thought that I read that online somewhere, that ${VAR:(-70):70} is offsets in bytes, not characters. OK, good if it is characters.

I'm running a different computer right now, so don't know how big that recently-used.xbel was. Is there any way to limit it's size? If so, that would solve my problem. I suppose there must be a size limit, it surely can't just keep growing.
[url]https://bkhome.org/news/[/url]

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#27 Post by disciple »

Hi Barry, if menu delay is a problem, why not just include a separate utility like mochimoppel's speed dials, which also gives access to bookmarks?
Although maybe a faster implementation is possible - lxpanelx had a feature for this and I thought it didn't have a big delay.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#28 Post by MochiMoppel »

BarryK wrote:I did test with a text file that had spaces, it was stored in recently-used.xbel as-is, with the space characters.
:shock: How did you do this? This is hard to believe. I've never experienced this in any distro. Typical content would look like this: Likewise a file /mnt/home/Málaga.txt would be coded as href="file:///mnt/home/M%C3%A1laga.txt". Will not appear in menu unless decoded.
Is there any way to limit it's size? If so, that would solve my problem. I suppose there must be a size limit, it surely can't just keep growing.
Answered here. You can't really limit the size, but you can limit the lifetime of items. They will get deleted from the file when they are older than the threshold.

But frankly I don't believe that size is the cause of your delay. I tested with 1000+ items, which increased filesize to 500K, and still no delay. Your code is extremely fast (0.04sec) - because you are cutting corners :wink: . Your code greps the last 20 items and stops scanning the file once it has found those 20 items, so it is irrelevant how big the rest of the file is. You then process only these 20 items and check if they still exist. Not quite correct since after the existence check only some or none might make it into the menu. IMO you need to select the last 20 existing files. Compared with your's my code took 0.2sec, still not annoying.

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#29 Post by BarryK »

MochiMoppel wrote:
BarryK wrote:I did test with a text file that had spaces, it was stored in recently-used.xbel as-is, with the space characters.
:shock: How did you do this? This is hard to believe. I've never experienced this in any distro.
Yes, my bad. Just tested again, and the file with spaces is now stored with "%20".

Hmmm, don't know how I got the idea it was otherwise.
[url]https://bkhome.org/news/[/url]

radky
Posts: 977
Joined: Mon 03 May 2010, 03:13

#30 Post by radky »

Another iteration of the 'Recently Used' script for JWM.

Code: Select all

#!/bin/bash
#this script is started from $HOME/.jwmrc

XBEL_PATH=$HOME/.local/share/recently-used.xbel
PARSED_ITEMS=40
MAX_ITEMS=20

if [[ -e $XBEL_PATH ]];then
   LANG=C
   ITEMS=$(grep -a file:/// "$XBEL_PATH" | tail -n $PARSED_ITEMS | cut -d '"' -f2 | sed 's%file://%%g')
   printf -v ITEMS "${ITEMS//%/\\x}" #convert UTF-8
   echo -n > /tmp/jwmdocs
   for i in $ITEMS
     do
       [ -f ${i} ] && echo -e "<Program label=\"• ${i}\">xdg-open \"${i}\"</Program>" >> /tmp/jwmdocs
     done
   ITEMS=$(tail -n $MAX_ITEMS /tmp/jwmdocs)
else
   ITEMS="<Program label=\"${XBEL_PATH##*/} not found!\"></Program>"
fi
echo '<JWM>'
echo -e "${ITEMS}"
echo '</JWM>'
EDIT 19 Aug 2019: add line #11 for UTF-8 conversion (thanks MochiMoppel)
[color=blue][b][url=http://www.smokey01.com/radky/PupMates.html]PupMates[/url][/b][/color]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#31 Post by MochiMoppel »

Thanks radky for joining the party. You brought some potent stuff .... potentially lethal :lol:

3 concerns:
1) You added UTF-8 conversion, but the "LANG=C" renders it useless. You should remove it
2) You need an IFS=$'\n' in order to support filespecs with spaces (essential for your " for i in $ITEMS" loop)
3) You send clicked items to xdg-open while my script sends them to rox -s. The command rox -s can never do harm. It just opens a ROX-Filer window. What xdg-open does depends on its configuration, but unless you have configured it differently it will run rox (without -s option) and therefore may execute scripts that were merely opened or edited in an editor and may not be suitable to be executed (not finished, interactive CLI script etc.). An item in the .xbel file always contains the name of the application that registered it, e.g

Code: Select all

<bookmark:application name="Leafpad" exec="&apos;leafpad %u&apos;" modified="2019-08-20T05:55:35Z" count="1"/>
Sending a file to the originator, here leafpad, would be safe, sending it to bash would not. Parsing .xbel for the originating application is possible but may be too time consuming for the time critical <dynamic> menu.

User avatar
nic007
Posts: 3408
Joined: Sun 13 Nov 2011, 12:31
Location: Cradle of Humankind

#32 Post by nic007 »

Haven't checked if it works because I'm using Tahr 605 but could be useful if can be accessed via an open JWM window, perhaps as an item in the menu accessed from the favourite's button.

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#33 Post by MochiMoppel »

While trying to open files with xdg-open can be dangerous, opening them with the same application that placed them into the .xbel files is not a good idea either. Consider all the files that are downloaded by the browser. The RU menu might then contain .pet files, but who wants to open .pet files with Firefox?

Limiting the displayed files to a reasonable number is essential, but tailing the last items of the .xbel file, hoping that they are the most recently used, turns out to be wrong. It may work only for files that have been newly added to .xbel, but the order of the .xbel file does not change. When the user reads or changes a file that is already listed, and when this file happens to appear at position 10 of an .xbel file with 100 entries, tailing the last 20 items will never put this file into the menu. This means that often used files have little chance to appear in the menu.

IMO a much better approach is to sort .xbel items by their "modified" date and then display the 20 items with the newest "modified" date. This "modified" date is the date the .xbel item was modified and should not be confused with "modified" timestamp of the listed files. Unfortunately there seems to be no clear rule what "modified" means. For newly created .xbel items it is set to the date the item was entered into .xbel. After that e.g. Geany updates this date when it reads or changes the item again. Some conditions apply, but in general the "modified" date is a good indicator for "recently used" files.

I modified my script accordingly. It parses modified date and filepath, sorts by date, removes the date and displays the 20 newest items.

Code: Select all

#!/bin/sh
XBEL_PATH=/root/.local/share/recently-used.xbel
if [[ -e $XBEL_PATH ]];then 
	MAX_ITEMS=20 
	IFS=$'\n'
	printf -v ALL "$(sed -rn 's/%/\\x/g
	s_^.*file://([^ "]*).*modified="([^"]*).*$_\2@\1_p
	' "$XBEL_PATH" | sort -r | sed 's/.*@//')"
	echo '<JWM>'
	for file in $ALL ;do
		[[ -e $file ]] && CNT=$((CNT+1)) && echo "<Program label=\"$file\">rox -s \"$file\"</Program>" 
		((CNT==MAX_ITEMS)) && break
	done
	echo '</JWM>'
else 
    echo  "<JWM><Program label=\"File ${XBEL_PATH##*/} not found!\"></Program></JWM>"
fi

User avatar
recobayu
Posts: 387
Joined: Wed 15 Sep 2010, 22:48
Location: indonesia

#34 Post by recobayu »

Thank you, Mochi. I use your code in my gtkdialog program now. I put the list of recently used into a <tree>. it's now very normal and it can walk without problem. I change your last code a little, like this:

Code: Select all

recently_used(){
	rm $muksdir/recent
	rm $muksdir/recent_all
	
	#from mochimoppel
	XBEL_PATH=/root/.local/share/recently-used.xbel
	if [[ -e $XBEL_PATH ]];then
	   MAX_ITEMS=20
	   IFS=$'\n'
	   printf -v ALL "$(sed -rn 's/%/\\x/g
	   s_^.*file://([^ "]*).*modified="([^"]*).*$_\2@\1_p
	   ' "$XBEL_PATH" | sort -r | sed 's/.*@//')"
	   for file in $ALL ;do
		  [[ -e $file ]] && CNT=$((CNT+1)) && echo "$file" >> $muksdir/recent_all 
		  ((CNT==MAX_ITEMS)) && break
	   done	   
	else
		echo  "no recent activity" > $muksdir/recent
	fi
	sed 's/.*\///' $muksdir/recent_all >$muksdir/recent
}

export -f recently_used
recent_all is the long path. the recent is only the filename.
I think it is very nice if my <tree> have an icon based on the file in recent (<input file icon-column="0">). I look at /root/.local/share/recently-used.xbel and it has a line:
<mime:mime-type type="application/x-shellscript"/>
how to convert that become an icon in tree? Thank you.

Edit:
I add <tree icon-name="folder" >. It fixed.

B.K. Johnson
Posts: 807
Joined: Mon 12 Oct 2009, 17:11

#35 Post by B.K. Johnson »

MM's MRUD running on tahr-6.0.6
For the record, jwm is 2.3.6


Using the first two versions of MochiMoppell's script always gave me pathnames displayed from the left. This is depicted in screenshot, smalloriginal MRUD on tahr-6.0.6.png. I didn't know why until later when Mochi identified that when a pathname length exceeded the panel size the display switched to the left.

I then changed to the third version of dynamicmenu_recent.sh which displays the shorter file names and not the longer paths. It seems to work but here are some random observations:

Initially, MRUD showed 1 item - a Composer saved file done before the shutdown (??).
Several items from a previous session(s) are mysteriously added to the list. (twice)
Deleted files are not recorded.
A newly created directory is not recorded.
Moving a file to another directory is not recorded.
When right-click->Recently used is done with the cursor near the right edge, the file-list is correctly displayed on the left.
The display panel seems to change to accommodate the longest filename.
'Touch'ing a file does not add it to the list.
A file saved to /root/Downloads using a Firefox add-on was added to the filelist (html).
A file that was included in the file-list is dropped when the name is modified or removed from its original location.
A previously recorded file, was not added to the list after being edited and re-saved.



I was monitoring the MRUD correctly switching from right to left depending on where I placed the cursor on the desktop when suddenly 12 items previously on the list re-appeared and the panel list was on the lrft, no matter where my cursor was.
Screenshot smallMRUD_tahr_hang_left.png shows the surprise left hanging list.

I quickly realized that the length of at least one filename (ending with Vanity Fair.html) was a problem. I re-positioned my cursor further left and on retrying, the display returned to the right as shown in screenshot:
smallMRUD_tahr_hang_right.png.



This substantiates Mochi's comments on the expected behaviour depending on available space.

In the next session, immediately after booting, MRUD showed a single file (same as the solitary file before). I did not monitor the outcomes of specific actions, but when I next looked, there were 20 items in the list. I recognized several files saved via Composer. I also noticed that for a web page saved using Seamonkey's Save As/Save: (a) the .html was recorded, as expected (b) I did not see the *_files, although it could have been listed and subsequently dropped and (c) some/all component files of the *_files (.html, js, css, jpg) were recorded.
Aug 22
I will not be doing extensive tests of individual file types as done before. MM has already written what is to be expected.

Tooltip
MM has effectively limited the display to FILES ONLY as I suggested. My other suggestion was to show the path to file as a tooltip. He has not been successful so far. @Mochi, correct me if I am wrong, but a cursory search suggests that the approach you are taking for tooltips is not likely to work because:

Code: Select all

tooltips need to have associated widgets.  Widgets that do not receive events (widgets that do not have their own window) will not work with tooltips.[code]
and
[code]See examples/action-tooltips.pl in the Gtk2-Ex-WidgetBits sources for a sample program setting tooltips on menu items.

...

There's other ways to show what a menu item might do of course. For instance the Gtk manual under the GtkActionGroup connect-proxy signal describes showing action tooltips in a statusbar.
Tooltips fall into the 'nice to have' category; it is not a necessity. I therefore now suggest that the "how to" search and implementation be dropped. Here's why. The paths are unnecessary. The user, I submit, is interested primarily in the file: to take some action on it, and probably the containing directory. When he/she clicks the filename in the file-list, s/he can get both. The path is immaterial and furthermore it is available from ROX anyway.

I am quite happy with MRUD as it now exists except that I am perplexed by the appearance of files date-stamped Aug 15 and 20.

radky's implementation
I had planned on installing it on my tahr-6.0.6, and reporting results. But as radky has not responded to MochiMoppels comments about it, and I respect MochiMoppel's knowledge in the area, I have decided that doing so would not be a productive use of my time.

upupbb
The screenshot, smallupupbb-2_menu_only.png shows the menu when "Places" is clicked.


MochiMoppell contended that a file-list will ordinarily be listed on the right, provided sufficient space exists, but will otherwise switch to the left. This explains why my long path-names (original script) and long filenames (current script) would cause the switch and remain so until the offending item drops off. Screenshot, smallupupbb-1_menu_plus_RU_deployed.png
shows file-list at right when cursor is moved over "Recently used".


However, when at least one pathname exceeds the available right space, the list forms to the left when the cursor is moved over "Recently used". This is shown in the screenshot, smallupupbb-2_menu_plus_RU_deployed.png.]/b] You can see that a single pathname ending with ...ecent.sh is responsible.

Now that MochiMoppell has modified his code to display only files (not the path), the likelihood of having all files displayed from the right is significantly increased. Ziggy, who is responsible for the code in Woof-CE that peebee used needs to implement at least that change. Although long names will then be unlikely, the possibility exists, and when that happens, the display will be stuck on the left until later additions push the errant file off. Or one manually removes it from the xbel file. Ah ha. I just saved a long pathname which left me stuck with an indecipherable panel on the left. My solution with Mochi's version would have been to rename the file, thereby removing it from the list. Alas, that doesn't work with the upupbb version. So, I manually removed the entry in the xbel file to get a visible RU displaying at the right.

Screenshots
smalloriginal MRUD on tahr-6.0.6.png
smallMRUD_tahr_hang_left.png
smallMRUD_tahr_hang_right.png
smallupupbb-2_menu_only.png
smallupupbb-1_menu_plus_RU_deployed.png
smallupupbb-2_menu_plus_RU_deployed.png
Attachments
smalloriginal MRUD on tahr-6.0.6.png
(130.13 KiB) Downloaded 320 times
smallMRUD_tahr_hang_left.png
(46.33 KiB) Downloaded 321 times
smallMRUD_tahr_hang_right.png
(106.23 KiB) Downloaded 319 times
smallupupbb-2_menu_only.png
(27.07 KiB) Downloaded 317 times
smallupupbb-1_menu_plus_RU_deployed.png
(79.28 KiB) Downloaded 313 times
smallupupbb-2_menu_plus_RU_deployed.png
(36.86 KiB) Downloaded 317 times
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#36 Post by MochiMoppel »

B.K. Johnson wrote:@Mochi, correct me if I am wrong, but a cursory search suggests that the approach you are taking for tooltips is not likely to work because:

Code: Select all

tooltips need to have associated widgets.  Widgets that do not receive events (widgets that do not have their own window) will not work with tooltips.[code][/quote]You are wrong :wink: 
The approach I am taking is the approach described in the JWM manual. Making sure that the method described in the manual works and that tooltips are associated with a widget, e.g. a menu, is the job of the author of JWM, not me. Tooltips  work for static menus but strangely don't work for dynamic menus.

[quote]The paths are unnecessary.  The user, I submit, is interested [u]primarily in the file:[/u] to take some action on it, and probably the containing directory. [/quote]May be unnecessary [u]for you[/u].
I'm sure that a user, once he finds half a dozen scripts in his menu, all named AppRun,  appreciates to see the full path and not just the basename.

[quote="recobayu"]I look at /root/.local/share/recently-used.xbel and it has a line:
<mime:mime-type type="application/x-shellscript"/>
how to convert that become an icon in tree?[/quote]Gtkdialog stuff is OT here, so I proposed a solution in recobayu's own thread [url=http://www.murga-linux.com/puppy/viewtopic.php?p=1035838#1035838]here[/url]. It could be adapted to add appropriate icons  to JWM menu items. Not that anyone in his right mind would ever want do this, but possible it is  :wink:

disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

#37 Post by disciple »

MochiMoppel wrote:Thanks radky for joining the party. You brought some potent stuff .... potentially lethal :lol:

3 concerns:
...
3) You send clicked items to xdg-open while my script sends them to rox -s. The command rox -s can never do harm. It just opens a ROX-Filer window. What xdg-open does depends on its configuration, but unless you have configured it differently it will run rox (without -s option) and therefore may execute scripts that were merely opened or edited in an editor and may not be suitable to be executed (not finished, interactive CLI script etc.).
Off topic, but does the normal xdg-open from freedesktop run scripts? If not, is it really acceptable for Puppy to have a substitute xdg-open that does?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

Post Reply