Trash Roxapp - Discussion Document

What features/apps/bugfixes needed in a future Puppy
Message
Author
disciple
Posts: 6984
Joined: Sun 21 May 2006, 01:46
Location: Auckland, New Zealand

Trash Roxapp - Discussion Document

#1 Post by disciple »

I am going to be updating the Trash roxapp soon (hopefully next week).
But I want to start a more general discussion about its future.
Please respond with either your opinion of how the Trash should work (in terms of what the user sees), and/or specific discussion of the details of implementing it.

------------------------

Personally, I would like to see a trash that places deleted items in a .trash folder in the top directory of the filesystem they come from - similar to the way the Windows recycle bin works. One specific benefit of this will be that you can trash a large item from some mounted partition, and it won't be copied into your small pup_save file, filling up space. It will also avoid potential problems caused when you trash an item but there ISN'T enough space, and when you try to restore a file that came from a filesystem that isn't currently mounted. On a multi-user system it would also allow you to restore things someone else has deleted.
Ideally I guess anything deleted from inside a user's home directory should be sent to ~/.trash rather than than /.trash as well.

I think the implementation of this might be a bit beyond me - in particular I have no idea how to determine where the top of the filesystem the deleted item came from is. Also, we would have to do away with any symlinks (e.g. for .DirIcon) in the appdirs of the trashed items, to allow for Windows filesystems. (or just be happy with not having an icon on windows filesystems).

And how would we centralise it? We could send anything trashed from inside ~ to ~/.trash, and also put symlinks there to anything else the user trashes. (We couldn't put the actual appdirs there, and just put the actual deleted items elsewhere, as the whole point in the appdirs is to cope with deleting files with the same name). But would this arrangement be too confusing on a multi-user system, because you would see everything you trashed in ~/.trash, but if you go to /mnt/hdb1/.trash, you will see things that don't show up in ~/.trash, because someone else deleted them?

Also, should we have some sort of check (if that is possible) for read-only filesystems, so you can't accidentally send something to the trash that doesn't actually get deleted after all? (Actually, this might not be a problem - I can't remember how the code works, and I haven't tested to see what happens at the moment).

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#2 Post by dvw86 »

Well when I wrote the trash application originally, I intentionally did not put the trashed item in the drive that it came from. Mac OSX does this and it makes invisible .trash files on all your external drives, even your USB thumb drives. I have always found this annoying. It could be done pretty easily though. Although you could leave it the way it is and just check if there is not enough room in your pup_save file. It would be easy to notify the user if the trashed item was too large or if it was on an external drive. Read only file systems could be an issue if you wanted the trashed items on the original drive, but I have an even greater concern. What if the drive is formated as NTFS? Some Puppys can write to NTFS drives, but if the NTFS drive isn't in the best of shape it could cause data loss. My vote would be to leave things the way they are but check to see if the trashed item is large or on an external drive. If it is, then offer to just delete the item and not put it in the trash bin. I should update the Trash app to check for NTFS drives anyways. I was planning on updating the looks of the trash soon. It was going to get a FLTK interface. I think that FLTK can look much nicer than xmessage.

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

#3 Post by disciple »

OK, if you are planning to update it, here are the facts to be aware of (you probably know most of it already though)
-I updated it a while ago to handle paths with spaces, and to add some enhancements.
-Someone else over at Rox also fixed the spaces issue (I wish I'd known that before!). They then fixed a number of other bugs apparently (there is a proper changelog), added some features, made it Freedesktop compliant and ported it to some GTK gui. One important result of their changes is that you can trash files/folders called .DirIcon and AppRun and whatever the other file is that appdirs need, without losing them forever. I was going to fix this, so I'm glad I found out.
-I started (but don't have time to finish until sometime after easter) backporting their version to work with xmessage and .trash rather than .Trash (so that it is backwards compatible with Puppy's trash), and adding my earlier feature enhancements in. I also intend to make clicking on a trashed item bring up the information window, which will have a button to open the file (I did have clicking open the file).
-Does Dingo have FLTK? There are so few FLTK apps around that if you use FLTK you should really keep the capability of using something else if necessary. Or will it be statically linked, and will that solve the problem? Also, Puppy has so much GTK that gtkdialog or something would fit in better. Maybe we could introduce to Puppy the gui that the guy over at ROX uses. But I think it was quite large by Puppy standards.

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#4 Post by dvw86 »

I worked with the guys over at Rox for a while, but I got busy changing jobs and what-not. I'll have to check back and see what they came up with. I would just use murgaLua for the FLTK interface. Just test for murgaLua at the begining of the script. If it is there than use it. Otherwise use xmessage or gtkdialog.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#5 Post by Pizzasgood »

I've never used the Trash Roxapp and probably never will unless I get really bored, so please excuse any ignorance on my part. Not that I have anything against it. I've just learned the hard way since leaving 'doze that once I delete something it's gone, and do not want to unlearn that and get sloppy and also have to worry about emptying trash and such...
Also, we would have to do away with any symlinks (e.g. for .DirIcon) in the appdirs of the trashed items, to allow for Windows filesystems. (or just be happy with not having an icon on windows filesystems).
Why give up the icon? Just name the image itself .DirIcon and not have any symlinks in the first place. :wink:

As far as determining the root of the filesystem a file comes from, that shouldn't be too hard. Running mount returns a list of all mounted filesystems and where they're at. Assuming you know the file's full path, you can do some string processing to figure out where its root is.
And how would we centralise it?
I'm not familiar with how it works. I do know that you can use mount to see all the mount points, then do a check to see which of them have .trash directories. Then you could symlink the trash directories or their contents or do whatever else you feel inclined to do. I think something like "trash_from_hda1/", "trash_from_hda2", etc. would make sense, though it's a little long winded.


The idea of placing the trash on the drive it came from has the advantage of being pretty fast (moving files within a partition doesn't really need any actual data transfer, unlike across partitions).
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#6 Post by dvw86 »

Okay I have been thinking about this and playing with some of my USB flash drives that have trash directories from Mac OSX. Here is what I'm thinking. When a user sends something to the trash, first check for any issues such as read only partitions/drives or NTFS formated partitions/drives. If it is such a drive, show the user a message letting them know the issue and exit. This is something that should be done anyways. When something is sent to the trash from inside the pup_save file then put it in $HOME/.Trash. If the user was root (such as in Puppy) then it would be /root/.Trash. If the user was Bob then the path would be /Bob/.Trash. If the trashed item is from another area, put it in the top of the partition for that drive. For instance /mnt/sda1/.Trash. Here's the catch, on boot and anytime a new partition is mounted or un-mounted, the trash icon would have to be updated to see if there was anything in the hidden trash folders. This would be easy to add to the new auto-mount script that I am writing. One thing that really bugs me about the Mac OSX trash is the emptying of the trash with other drives mounted. If you have a drive mounted with things in it's hidden trash folder, emptying the trash deletes all the files in all the hidden trash folders on all the drives. Maybe a separate menu option to empty the trash for each partition would be good? One fun feature would be to use and show the trash folders that may already be created by Mac OSX. If done right, Mac OSX would use the trash folders created by Puppy.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#7 Post by Lobster »

8) seems to just work

:)

Not quite sure why you are improving what works?
Are there any security issues?
Could you shred the data? (overwrite with 0 & 1 several times)

Do you intend animating the icon?
Maybe a record of how much is in the trash?
Store trash as gmail option?
Last edited by Lobster on Thu 04 Sep 2008, 06:35, edited 1 time in total.
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#8 Post by amigo »

You can use the stat command to find out what physical drive a file or folder ison.

Not too long ago I wrote a Rox AppDir called RecycleBin which lets you throw itmes away and still be able to put them back where they were originally. I also had thought about implementing separate trash cans for each drive at least as an option. Other pressing matters stopped the work on it for awhile.

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

#9 Post by disciple »

Why give up the icon? Just name the image itself .DirIcon and not have any symlinks in the first place. Wink
Yes, but if we are ultra keen on saving space, then a symlink is better, and it's not like there's any real need for the icon. Also, then the icon could be changed with themes :)
Although I think Nathan was talking about rewriting the trash to actually use an icon that matches the mime type of the file... which would be cool, but sounds horrendously difficult.
I've just learned the hard way since leaving 'doze that once I delete something it's gone,
I just avoided the trash until I sat down to figure out why it didn't work, and realised that the reason was simply that I usually had spaces in the paths. So I fixed that, and now Lobster says
Cool seems to just work
Well, somebody who didn't use spaces would have said that before, but they would have been wrong - for me it certainly did not work.
At the moment if you unwittingly trash something called .DirIcon or AppRun or AppInfo.xml or whatever the other thing is, then it is GONE FOREVER.
So we will get the fix for that. And apparently the guy at ROX has fixed other bugs - I didn't notice any others, but hey, if they're fixed, that's great.
Then it will almost "just work". Except for the very real issue of trashing something big from elsewhere, and filling up your pupsave. So I think we should at least do a check to prevent that...

No - I don't really know or care about security issues. And shredding data is a completely different task from what the Trash does, so if you want an app for that, I think it should be separate (I guess it could be on the item's right-click menu - but how many people would ever use it? Is there a utility in Puppy for shredding things?).
No - I don't care for animated icons.
Maybe a record of how much is in the trash?
That is a good idea - do you want the icon do indicate this? That would be meaningless if we do what I want and have .trash directories on every partition. But if we do it the way Dan suggests, detecting Trash directories, (which is compulsory if we want to be Freedesktop compliant) then I think we could put an option on the right click menu to show us a table for this.
One fun feature would be to use and show the trash folders that may already be created by Mac OSX.
And what about Gnome and KDE etc? I ended up with things in trash on my flash drive in Ubuntu, but I'm not sure whether it was Gnome or KDE that did it. I wonder if the Mac trash is anything remotely near being freedesktop compliant. I just had a look at the Freedesktop specification, and there are lots of random checks we need to make to be fully compliant. Some I don't understand, but others, like checking that e.g. /mnt/hdb3/.Trash isn't a symlink, are very helpful :)
If we want to be compatible, I guess we should use .Trash rather than porting it back to .trash
We could just have Puppy rename /root/.trash in an upgrade, or (safer) the trash roxapp could move anything in .trash to .Trash when you click on it.
Freedesktop spec:If the directory exists and passes the checks, a subdirectory of the $topdir/.Trash directory is to be used as the user's trash directory for this partition/device. The name of this subdirectory is the numeric identifier of the current user ($topdir/.Trash/$uid). When trashing a file, if this directory does not exist for the current user, the implementation MUST immediately create it, without any warnings or delays for the user.
When trashing a file, if an $topdir/.Trash-$uid directory does not exist, the implementation MUST immediately create it, without any warnings or delays for the user.
I don't like that part of the spec - it is so cumbersome it makes me want to ignore the spec and throw compatibility out the window. If you trash something from a filesystem that other people have access to, surely it is best to give them access to the trash too?
Freedesktop spec:When preparing a list of all trashed files (i.e. to show to the user), an implementation also MUST check for .Trash in all top directories that are known to it.
That is worse than the icon problem you mention - I can't think how it would even be feasible to display all files with our ROXapp approach. I realised another problem with my idea of symlinking anything you delete elsewhere into ~/.Trash - if you go to /mnt/sda1/.Trash or whatever and delete it, you will have dead symlinks. Maybe we would just have to put symlinks in ~.Trash to all the .Trash folders.
Maybe a separate menu option to empty the trash for each partition would be good?
Definitely something like that. But we could just have a menu option to show information on the trash directories, and it could list them, with their sizes, and buttons to empty them. HEY - we could have buttons here to open each trash directory, instead of trying to have one window that shows all trashed files. And we could even open this window when clicking on the roxapp. I think that would work quite well.
Freedesktop spec:A trash directory contains two subdirectories, named info and files.
Reading this carefully, it seems that even though the guy at Rox thinks he is freedesktop compliant, he really isn't. He has a directory for each deleted item inside .Trash, with info and files folders in each one of these directories. I'm inclined to say we stick with this approach, and don't have all that rubbish about $uid directories. Because actually, he isn't freedesktop compliant anyway, because the mechanism for restoring files is built into the roxapps, so we can't restore files that were trashed by something else, because they aren't in roxapps.
Freedesktop spec:The system SHOULD only support absolute pathnames in the “home trash

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#10 Post by dvw86 »

I agree. Let's just go ahead and do option 1 since it needs done anyways. I really don't like the sound of option 2. Option 3 could be a long term goal if you or I ever feel adventurous.

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

#11 Post by disciple »

OK, I found it easier to start with my version and merge select features from Achaw's version, rather than the other way around.

-I took the version from Dingo and fixed the bugs introduced by Barry's modifications for Dingo (it didn't play the sound, or restore the "empty" icon if you deleted or restored the last item in the trash).
-I then added some of Achaw's features and bugfixes, most notably putting the trashed item in a "Files" subdirectory, so that you can safely trash files called .DirIcon, AppRun or AppInfo.xml, and restoring a desktop icon (if there was one originally).
Because I started with the code from Dingo, people with older Puppies will need to either edit the scripts, or move/link their existing icons (from inside the Trash roxapp) to /usr/local/lib/X11/pixmaps/trashcan_empty48.png and /usr/local/lib/X11/pixmaps/trashcan_full48.png
-I didn't add the "restore all" feature as I don't think it is useful, but it would be easy to add if people want it.
-I commented out the "quickly empty trash" entry in AppInfo.xml, as I think that option is dangerous, but it will still work if you uncomment it.
-I think it will now work in a multiuser system, but haven't tested that.

---------------------------------------------------
HELP WANTED - SOMEONE WITH A LITTLE KNOWLEDGE AND 5-30 MINUTES...
1. I simplified Achaw's feature of writing information about the trashed item to an "info" file, so that instead of parsing the "info" file like he did, it just displays the entire contents of the file, so that it is even easier to add additional information. I would like to add the size of the trashed item to this file, I just don't know how to find it.
I don't know what other information people would find useful - maybe permissions? Change/modify/Access times? The names of links to this item that we removed from the pinboard (these are stored in the "shortcut" file so it would be easy to do)?
This information is written around line 101 of AppRun.

---------------------------------------------------
OTHER IMPROVEMENTS THAT WOULD BE NICE
2. Action buttons (delete this item, restore this item) in the info window.
If we added these it would make a lot of sense to bring up the info window on double click, instead of opening the trashed item with whatever Rox opens it with, as I have it doing now. I think you could still do this just with xmessage, but i don't know how to get at the exit codes.

3. A check for space in the filesystem that contains the trash folder, when a file from elsewhere is sent to the trash. Also, a message to confirm if you want to delete a large file (I don't know - 5, 10, 20 MB?) from outside this filesystem would also be useful.

4. Maybe we should consolidate the code a little - at the moment the original file's path is stored in two places - in the info file and in the apprun file itself. If we took it out of the AppRun file, maybe this file could be a symlink just like .DirIcon and AppInfo.xml?

5. If you send several items at once to the trash, it would be nice to see them in the trash together (i.e. as one trashed item) - this might be a little tricky to do.

6. We could fix it so that it restores all shortcuts on the pinboard, not just one, but I don't think this is that important.

7. What would be very useful is another option on the main trash right-click menu, that will generate some sort of list of files in the trash, with other information, such as size, deletion date, and file extension, (probably by reading the info files). This list could be used to sort files by things like extension and size, which isn't possible currently (maybe in a spreadsheet would be easiest).
Attachments
Trash.tar.gz
(14.69 KiB) Downloaded 1007 times
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

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

#12 Post by disciple »

OK, I figured out how to do number 2 (I'll upload tomorrow after I test a little more carefully).
For the desktop links in number 1 I am just putting a yes or no, rather than names.
I would really like to know a command to get a sensible printout of the size of a file or directory, and I am quite keen on having the permissions and times as well.
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#13 Post by dvw86 »

disciple wrote: I would really like to know a command to get a sensible printout of the size of a file or directory.
Try "du"
http://www.ss64.com/bash/du.html wrote: du

Disk Usage - report the amount of disk space used by the specified files and for each subdirectory.

SYNTAX
du [options]... [file]...

With no arguments, `du' reports the disk space for the current directory. Normally the disk space is printed in units of 1024 bytes, but this can be overridden

OPTIONS

`-a'
`--all'
Show counts for all files, not just directories.

`-b'
`--bytes'
Print sizes in bytes, overriding the default block size (*note
Block size::).

`-c'
`--total'
Print a grand total of all arguments after all arguments have been
processed. This can be used to find out the total disk usage of a
given set of files or directories.

`-D'
`--dereference-args'
Dereference symbolic links that are command line arguments. Does
not affect other symbolic links. This is helpful for finding out
the disk usage of directories, such as `/usr/tmp', which are often
symbolic links.

`-h'
`--human-readable'
Append a size letter such as `M' for megabytes to each size.
Powers of 1024 are used, not 1000; `M' stands for 1,048,576 bytes.
Use the `-H' or `--si' option if you prefer powers of 1000.

`-H'
`--si'
Append a size letter such as `M' for megabytes to each size. (SI
is the International System of Units, which defines these letters
as prefixes.) Powers of 1000 are used, not 1024; `M' stands for
1,000,000 bytes. Use the `-h' or `--human-readable' option if you
prefer powers of 1024.

`-k'
`--kilobytes'
Print sizes in 1024-byte blocks, overriding the default block size
(*note Block size::).

`-l'
`--count-links'
Count the size of all files, even if they have appeared already
(as a hard link).

`-L'
`--dereference'
Dereference symbolic links (show the disk space used by the file
or directory that the link points to instead of the space used by
the link).

`--max-depth=DEPTH'
Show the total for each directory (and file if -all) that is at
most MAX_DEPTH levels down from the root of the hierarchy. The
root is at level 0, so `du --max-depth=0' is equivalent to `du -s'.

`-m'
`--megabytes'
Print sizes in megabyte (that is, 1,048,576-byte) blocks.

`-s'
`--summarize'
Display only a total for each argument.

`-S'
`--separate-dirs'
Report the size of each directory separately, not including the
sizes of subdirectories.

`-x'
`--one-file-system'
Skip directories that are on different filesystems from the one
that the argument being processed is on.

`--exclude=PAT'
When recursing, skip subdirectories or files matching PAT. For
example, `du --exclude='*.o'' excludes files whose names end in
`.o'.

`-X FILE'
`--exclude-from=FILE'
Like `--exclude', except take the patterns to exclude from FILE,
one per line. If FILE is `-', take the patterns from standard
input.

On BSD systems, `du' reports sizes that are half the correct values
for files that are NFS-mounted from HP-UX systems. On HP-UX systems,
it reports sizes that are twice the correct values for files that are
NFS-mounted from BSD systems. This is due to a flaw in HP-UX; it also
affects the HP-UX `du' program.

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

#14 Post by disciple »

Thanks.

OK, I have finished with it now. I added some more information in the info window and added action buttons for everything.
I changed it so that the info window is shown when you click on the trash.
I fixed a bug in restoring pinboard shortcuts to files with spaces in the name.
I changed it so that when you restore an item you can choose to cancel, or to overwrite or trash an existing file/folder with the same name.
I made it fix the trash icon when you click on it if it showing as full when it is actually empty.
I might have added other features, but I can't recall :)

The only issue is that what the info window shows for "Extension" is silly if the file doesn't have an extension. But there isn't really a good way around this.

Have fun!
Attachments
Trash.tar.gz
(15.47 KiB) Downloaded 1044 times
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#15 Post by HairyWill »

works good for me

1. Why bother trying to list the file extension, you have the full filename already.

2. The du -h listing with sizes is great. I think it would be better if you used the full listing rather than cutting off the file names.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

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

#16 Post by disciple »

1. Because I want to make a script for the main trash menu that will parse all the info files and output a csv file (or something) with each trashed item on a new line. Then if I have lots of things in the trash I can use it to find the things I want quickly.
This way it will be simpler, otherwise the imaginary script would have to find the extension anyway.
Unfortunately I have run out of time at the moment :)

2. We could, but why?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#17 Post by dvw86 »

Thanks,
I'll play with it and if it works well in Puppy 3, I will put it in Pupeee beta 5.

User avatar
dvw86
Posts: 636
Joined: Thu 05 May 2005, 00:55
Location: Washington State

#18 Post by dvw86 »

I forgot to mention that I pulled "shred" off of my Eeepc Xandros install. It works in Pupeee and I was going to add it to the trash application. This would give us a "Securely Empty Trash" option.
Attachments
shred.tar.gz
shred from Xandros
(19.14 KiB) Downloaded 739 times

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#19 Post by HairyWill »

2. We could, but why?[/quote]because you have a line in there already for every file and folder. Alternatively pipe the du output through tail -1 so that you only show the total rather than loads of lines that contain nothing else other than a size.

The use case for showing the filenames.
Imagine I am searching for the deleted file foo.bar. I think it was buried several levels deep in one of four directory structures that I deleted yesterday. If you show all the filenames it makes it relatively easy to scan over to find the file.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

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

#20 Post by disciple »

Thanks Will - I only just saw that :(
Obviously I didn't test carefully enough after adding that feature. I think it is best to go with piping it through tail -1, otherwise I think it gets overcomplicated. In a situation like you describe you'd probably better off searching for it some other way, e.g. with find.

With a little help from Muggins, here's a first version of the script I described before, to parse the info files and show a summary of everything in the trash:

Code: Select all

#! /bin/sh

export MAIN_DIALOG='
<window title="All this is in the trash!" icon-name="gtk-delete">
<vbox>
  <tree>
    <label>Name|Location|Size|Deletion Date|Type|Extension|Had desktop shortcut?</label>
    <input>cat /tmp/trashitems</input>
    <variable>TREE</variable>
    <height>570</height><width>790</width>
  </tree>
  <hbox>
    <button ok></button>
  </hbox>
</vbox>
</window>
'

for i in ~/.Trash/*/Info; do cat "$i" | tr '\n' '|' | sed 's/Name = /\n/'; done \
| sed 's/Location = //' | sed 's/Size = //' | sed 's/Deletion Date = //' \
| sed 's/Type = //' | sed 's/Extension = //' | sed 's/Had desktop shortcut? = //' \
| sed 1d > /tmp/trashitems

cat /tmp/trashitems | sed -e 's/</?/g' | sed -e 's/>/?/g' > /tmp/trashitems

gtkdialog3 --program=MAIN_DIALOG --center
rm /tmp/trashitems
That bug you found is a bit unfortunate, as it means this script won't correctly list any folders deleted with that version of the Trash. Apart from that I think these are the only issues:
- It obviously won't include files deleted by old versions of the trash (before we implemented the info files), and won't properly list any that were deleted by one of the Dingo alphas or betas that had the info files, but without most of the information. I don't think we should try to make it backwards compatible though.
- It can't sort properly by size. I really like the "human-readable" sizes, so I'm trying to think of the best way of doing this. We could add another line to the info files (and this script), with the file sizes all in the same units (I think this is the best thing to do). We could instead add a button to sort by size, and the code would be rather more complicated. We could put the units at the front of the size. Any better ideas?
- We really need to modify the main trash script so that the "extension" field is blank for folders. I guess we just need to test for a folder before writing this field...
- If you sort by location, files deleted from the same directory don't seem to be in any logical order. I guess this is a reason to use the full path instead, as someone suggested.

Any comments?
Do you know a good gtkdialog program? Please post a link here

Classic Puppy quotes

ROOT FOREVER
GTK2 FOREVER

Post Reply