Disable GTK "recently used files"

[musher0]

Yes, but if B.K. Johnson's guess could be verified then there would be no need to reprogram anything, right?

Fine! Where's the code? BKJ?

[8Geee]

Running Slacko5.7 for 4 years, I can tell that mplayer must be using this file as a recent-viewed file-list (history). In fact playing anything audio/video through mplayer gets logged in the xbel file. So, IMHO, the file is necessary for at least mplayer, and may be tapped by other programs. I think Geany also taps into this file for updated/changed files/coding when using Geany to do so. This includes downloads, symlinks, etc. that other programs use.

WARNING: if you have done an OS download (including security update to OS or browser), or modified any OS file including symlink, DO NOT erase the xbel file until a full shutdown or reboot occurs. In fact its customary to do at least a reboot when doing OS or browser changes. AFTER the reboot, the xbel file can be erased. There seems to be flags involved.

Thats why I recommend erasure of contents over elimination of file. Your opinions may vary.

For those who woulld like to experiment:
1.) open Geany
2.) open recently-used.xbel using Geany
3.) find and open the CUPS error_log (might be /var/log/cups) using Geany
4. Delete the contents of both files (select-all then backspace) and save.
5.) DO NOT CLOSE THE TABS, close Geany instead.

Regards
8Geee

[B.K. Johnson]

I was away and although I did drop in and read the threads, any comments would have been incomplete and not verifiable. I am back and will address MM's last post and hopefully also answer some other questions.

Mochi wrote:

Sure, but as far as I understand B.K.Johnson upupbb displays a menu based on this file, and this menu contains only files that were recently saved but not those which were merely opened.
AFAIK the timestamps recorded in the recently-used.xbel file are not sufficient to make this distinction.

Let me clarify some points.
I have neither. looked for nor seen the code in upupbb. I assume it is based on MM's code because of its similarity in name and operation. However, I have posited to peebee via PM that MM's post is the source of his implementation and he has neither denied nor confirmed if it is so.
I have stated in the upupbb thread that I had eventfully got a working Recently Used (RU) in upupbb. Working in the sense that the display hung from the right and had sufficient space to easily accommodate pathnames exceeding 100 characters. Subsequently, the display unexpectedly reverted to hanging from the left and I could no longer see the files listed. It seems there is a conflict with an application I use or some action I take that results in the switch. I inadvertently saved a session when the display was bad and now RU is useless on that flash drive.
I can't/won't argue with MM whether or not it is possible for the files displayed in upupbb's RU are "opened" and/or "saved". What I can say is that while I was able to see upupbb's RU, I do not remember opening a file and seeing it added to the RU list, but I most certainly saw the addition when I saved a file. Note that 90% of my files are html so Firefox, SeaMonkey and Composer would be the tools I would have likely used.

Later
As explained, I can no longer see the filelist in upupbb. I booted an installation of an earlier version of upupbb specifically to (a) check the orientation (right or left hanging) and (b) verify if both "opened" and "saved" files were shown in the display. On checking PupSysinfo just now, it shows System Uptime: 0d 5h 5m. RU has been rock solid during the period. This early version of upupbb running on a Kingston flash has not once switched to a left-hand display.

The table below shows how certain file types running in particular applications are recorded/shown or not in the display. This is a random selection of file types and applications determined by what resided on the system. For example, I was unable to test whether the opening of .doc and .docx files would be recorded because I did not have LibreOffice installed on this system.
Condition Recordrd Y/N
-----------------------------------------------------------------------------------------
html file opened with firefox..................................No
html file opened with seamonkey...........................No
html file opened with composer.............................No
html file saved with composer...............................Yes
html file opened with leafpad................................No
txt, script file opened with leafpad........................No
txt, script file opened with geany...........................Yes
graphics files opened with Viewnoir, mtpaint........No
mp3 file opened and played in mhWaveEdit.........No
pdf file opened in evince.......................................Yes
mp3 file opened and played in Gnome MPlayer....Yes
mp4 file opened and played in Gnome MPlayer....Yes

I am guessing that the intermittent switching could be a result of the flash drive used. The stable version of upupbb is running on a Kingston flash drive while the problematic upupbb is running on a cheaper flash drive. The problem could be related to the quality of the flash drive.

[musher0]

Hi BKJ.

Thanks for the additional information.

I know for a fact the recently-used.xbel file does not monitor the html files opened with
browsers. In particular, the mozilla family browsers have their own history file, which is
very complete. E.g. : places.sqlite.

xbel will however list a file or archive downloaded by a browser.

As to leafpad and mhWaveEdit, I don't really know why they are not monitored by the
xbel process. Why list a musical piece played through mplayer and not through
mhWaveEdit? Perhaps these apps are considered as not important enough by the
xbel process?

IHTH

[MochiMoppel]

I am back and will address MM's last post and hopefully also answer some other questions..

Welcome back. You raised new questions and I sent you a PM, so we hopefully can sort out the confusion and mysteries and come back here with a solution. I realize that we have successfully derailed this thread but maybe we can provide some hints why not to disable GTK "recently used files"

I know for a fact the recently-used.xbel file does not monitor the html files opened with browsers

Don't confuse opening a website with opening a local HTML file. The latter apparently is what BKJ is talking about, and in this case browsers do register the opened file in xbel. However in my experience this works only 100% when the HTML file is opened via the browser's File-Open menu. Drag/dropping a HTML file into a browser window or double clicking a HTML file in ROX may not work.

In particular, the mozilla family browsers have their own history file

History of visited sites. Completely different subject.

As to leafpad and mhWaveEdit, I don't really know why they are not monitored by the
xbel process

Leafpad does write to xbel, and so does mhWaveEdit , but only when file is opened via File-Open. Additional conditions apply.
mhWaveEdit also writes when saving file.

[peebee]

see:
http://www.murga-linux.com/puppy/viewto ... 12#1034412

[MochiMoppel]

@peebee: Thanks. After rereading BK's post on your upupbb thread I'm sure that BK's issue is not related to your distro or to my script.

@B.K.Johnson: I think what you experience is normal behavior of JWM (maybe of any other file manager) and I can reproduce it even with older JWM versions.
1) In principle submenus open to the right (of course since this is where the litte arrow points)
2) If there is not enough space on the right, they open at the left instead.
3) If neither on the right nor on the left of the screen is enough space to display the menu item, i.e. if even only one single menu label is wider than your screen width, JWM will always open the submenu at the left, displaying as much of the ending part of a label as fits into the left screen space. Depending of your screen resolution this can easily happen with your extremely long file names.
Just normal, but a bit difficult to fix when it happens. Easiest way is to delete the .xbel file

[B.K. Johnson]

MochiMoppel wrote:

@peebee: Thanks. After rereading BK's post on your upupbb thread I'm sure that BK's issue is not related to your distro or to my script.

I have long contended that I suspected a 'conflict', especially since the ealier upupbb is rock solid and the later version always worked after reboot.
MochiMoppel wrote:

1) In principle submenus open to the right (of course since this is where the litte arrow points)
2) If there is not enough space on the right, they open at the left instead.
3) If neither on the right nor on the left of the screen is enough space to display the menu item, i.e. if even only one single menu label is wider than your screen width, JWM will always open the submenu at the left, displaying as much of the ending part of a label as fits into the left screen space. Depending of your screen resolution this can easily happen with your extremely long file names.

Points 1 & 2 I knew - standard. #3, I never thought about, but makes sense. My screen resolution (1366) wasn't a problem; the problem was the constriction caused by the placement of 'Places' and immobility. peebee never expected insufficient space on the right (and rightly so). It's the long pathnames that we return to. Let's deal with that in the other thread. Any solution developed there can be adopted by peebee.

Just normal, but a bit difficult to fix when it happens. Easiest way is to delete the .xbel file

Thanks.

[s243a]

I'm not sure if it has been mentioned or not but one way to disable this is to delete the folder that contains the file (I.e. ~/.local). If one does this though it will produce a lot of errors in /tmp/xerrs.log

[MochiMoppel]

I'm not sure if it has been mentioned or not but one way to disable this is to delete the folder that contains the file (I.e. ~/.local).

Maybe hasn't been mentioned because it doesn't work ?

[s243a]

I'm not sure if it has been mentioned or not but one way to disable this is to delete the folder that contains the file (I.e. ~/.local).

Maybe hasn't been mentioned because it doesn't work ?

It worked for me but it might depend on which programs are using it. Also prior to using any program which writes to this folder one could drop the permissions of said program (e.g. runasspot) so that said program can't write to the folder. However, don't run as spot. Run as a user without a home folder .

[MochiMoppel]

recently-used.xbel is created in whatever directory the environment variable XDG_DATA_HOME is assigned to.
In my Puppy XDG_DATA_HOME is set to /root/.local/share, so the file location becomes ${XDG_DATA_HOME}/recently-used.xbel.

Removing /root/.local/share can prevent the saving of recently-used.xbel , but only as long as no other program recreates it. Parcellite is such a program. Parcellite doesn't care about XDG_DATA_HOME, it has this directory hard coded and creates it when it doesn't exist.

[s243a]

recently-used.xbel is created in whatever directory the environment variable XDG_DATA_HOME is assigned to.
In my Puppy XDG_DATA_HOME is set to /root/.local/share, so the file location becomes ${XDG_DATA_HOME}/recently-used.xbel.

Removing /root/.local/share can prevent the saving of recently-used.xbel , but only as long as no other program recreates it. Parcellite is such a program. Parcellite doesn't care about XDG_DATA_HOME, it has this directory hard coded and creates it when it doesn't exist.

What if you set XDG_DATA_HOME=/dev/null

[MochiMoppel]

What if you set XDG_DATA_HOME=/dev/null

Brutal, but works.
However symlinking /root/.local/share/recently-used.xbel to /dev/null would not work

If you only want to prevent certain applications to access the .xbel file you can redefine XDG_DATA_HOME before executing the application, e.g this will start geany with a disabled .xbel file:

Code: Select all

XDG_DATA_HOME=/dev/null geany

Not surprisingly a barrage of error messages will follow:

Code: Select all

(geany:6698): Gtk-WARNING **: Attempting to read the recently used resources file at `/dev/null/recently-used.xbel', but the parser failed: Failed to open file '/dev/null/recently-used.xbel': Not a directory.

(geany:6698): Gtk-WARNING **: Attempting to store changes into `/dev/null/recently-used.xbel', but failed: Failed to create file '/dev/null/recently-used.xbel.VCML6Z': Not a directory

(geany:6698): Gtk-WARNING **: Attempting to set the permissions of `/dev/null/recently-used.xbel', but failed: Not a directory

[s243a]

What if you set XDG_DATA_HOME=/dev/null

Brutal, but works.
However symlinking /root/.local/share/recently-used.xbel to /dev/null would not work

If you only want to prevent certain applications to access the .xbel file you can redefine XDG_DATA_HOME before executing the application, e.g this will start geany with a disabled .xbel file:

Code: Select all

XDG_DATA_HOME=/dev/null geany

Not surprisingly a barrage of error messages will follow:

Code: Select all

(geany:6698): Gtk-WARNING **: Attempting to read the recently used resources file at `/dev/null/recently-used.xbel', but the parser failed: Failed to open file '/dev/null/recently-used.xbel': Not a directory.

(geany:6698): Gtk-WARNING **: Attempting to store changes into `/dev/null/recently-used.xbel', but failed: Failed to create file '/dev/null/recently-used.xbel.VCML6Z': Not a directory

(geany:6698): Gtk-WARNING **: Attempting to set the permissions of `/dev/null/recently-used.xbel', but failed: Not a directory

Maybe redirect standard error to some kind of error filter function. For instance such a function could remove the offending lines with a statement like:

Code: Select all

 grep -v recently-used.xbel

[MochiMoppel]

Maybe redirect standard error to some kind of error filter function.

???
These warnings are good!. They can tell you if and how applications try to use the .xbel file. This is valuable information, don't redirect it. At least not yet.

[perdido]

recently-used.xbel is created in whatever directory the environment variable XDG_DATA_HOME is assigned to.
In my Puppy XDG_DATA_HOME is set to /root/.local/share, so the file location becomes ${XDG_DATA_HOME}/recently-used.xbel.

Removing /root/.local/share can prevent the saving of recently-used.xbel , but only as long as no other program recreates it. Parcellite is such a program. Parcellite doesn't care about XDG_DATA_HOME, it has this directory hard coded and creates it when it doesn't exist.

What if you set XDG_DATA_HOME=/dev/null

Or this

Code: Select all

export XDG_DATA_HOME=/tmp/

Interesting discussion.