[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Enhanced Trash functionality
From:       Jonathan Hunt <jhuntnz () users ! sourceforge ! net>
Date:       2003-11-25 10:18:28
[Download RAW message or body]

Sorry I have cut and paste to reply to two messages at once (i did not receive 
the emails so I copied them from the archives).

> If you want to have it widely usable outside KDE I suggest you provide a C 
> interface. If not, then you can just as well use Qt.
That is a point. Perhaps what I will do is write a standalone C library and 
then make a KDE C++ wrapper class.

>Do you really think it is a good idea to put information for just a few files 
>into some database file, which normally has some binary content, and is 
>therefore not transferable between different CPU architectures?
I am looking at using the suggested sqlite (http://www.hwaci.com/sw/sqlite/) 
(is this an acceptable dependancy for the KDE project). I don't won't to us 
an XML file (although its an option) because it would be slower for searching 
thru trying to find the file u last deleted (which is what I think people 
tend to be doing most with their trash). Using SQL makes searching easy & 
hopefully efficient.

> Why not begin() + end() like the STL if it's the same concept?
Good point

>>       TrashBin (const char *dir = "~/.Trash");

> I think ~ is expanded by the shell and usually not part of a path.
> Better use ".Trash" as default and in the code check if the parameter is a 
> relative path and if yes, base it on $HOME or something like that.
I realise that - just showing the concept ;-).

> clear() or empty() would be nice :)
This is correct - my mistake.

>> class TrashItem
>> {
>>       void restore();
>>       string getfilename();
>
>Why use std::string here and const char* above?

This is how I prefer to handle strings. When calling a function const char * 
is as easy as anything else to use (readonly) but my return uses string 
rather than a char * it means you don't have to worry about freeing the 
memory or anything because this is all taken care of by the string class - 
and a good implementation will not be inefficient (ie copy the entire string 
on function returning) but will be near to the speed of returning a pointer. 
I think this is good logic but feel free to correct me.

Right - I think this is enough to begin work on a C library and small C 
executable as long as using sqlite is acceptable to everyone.

Cheers,
Jonny
-- 
Jonathan Hunt (The Real Jonathan Hunt) <jhuntnz@users.sourceforge.net>
Jabber at jhuntnz@jabber.org
"He is no fool who gives what he cannot keep to gain what he cannot lose."
Jim Elliot

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]