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

[MochiMoppel]

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

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.

[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.

[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

[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]

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

[MochiMoppel]

@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]

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

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?