Saving directory trees in Gtkam
Locked
Saving directory trees in Gtkam
 
|
Hi there,
I thought it would be useful to have an option to download a whole directory tree in Gtkam with a single command, I have also seen other people complain about this on the web. I'm attaching a simple patch that adds such option to the tree view's context menu. I hope you find a useful thing to have. (I'm only not too confident about my use of GTK) Greetings -- balrog 2oo5 |
gtkam-save-tree.patch (13K)
Re: Saving directory trees in Gtkam
|
|
On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote:
> Hi there, > I thought it would be useful to have an option to download a whole > directory tree in Gtkam with a single command, I have also seen other > people complain about this on the web. I'm attaching a simple patch > that adds such option to the tree view's context menu. I hope you find > a useful thing to have. (I'm only not too confident about my use of > GTK) > Greetings Hmm. The patch works. However ... Do we really want to recreate the directory tree on the camera, or download all files from the into the same directory? Ciao, Marcus ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
In reply to this post by andrzej zaborowski
On Wed, 7 Sep 2005 [hidden email] wrote: > Send Gphoto-devel mailing list submissions to > [hidden email] > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/gphoto-devel > or, via email, send a message with subject or body 'help' to > [hidden email] > > You can reach the person managing the list at > [hidden email] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Gphoto-devel digest..." > > > Today's Topics: > > 1. Re: Saving directory trees in Gtkam (Marcus Meissner) > > --__--__-- > > Message: 1 > Date: Wed, 7 Sep 2005 21:39:46 +0200 > From: Marcus Meissner <[hidden email]> > To: andrzej zaborowski <[hidden email]> > Cc: [hidden email] > Subject: Re: [gphoto-devel] Saving directory trees in Gtkam > > On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote: >> Hi there, >> I thought it would be useful to have an option to download a whole >> directory tree in Gtkam with a single command, I have also seen other >> people complain about this on the web. I'm attaching a simple patch >> that adds such option to the tree view's context menu. I hope you find >> a useful thing to have. (I'm only not too confident about my use of >> GTK) >> Greetings > > > Hmm. > > The patch works. However ... > > Do we really want to recreate the directory tree on the camera, or > download all files from the into the same directory? > > Ciao, Marcus > Marcus, I have not tried the patch, but I would say that it depends on the camera. For example, the sq905 cameras could conceivably be helped by such an arrangement. Here is the situation: 1. There are no actual directories on the camera, and no FAT. No names, either. There is only something which might be considered as a sequential list, with location of entries in it determined only by line number. 2. For each photo on the camera, one entry equals one frame, _except_ if the entry is for a clip (which can be done on a certain camera setting by holding down the shutter button, causing the camera to shoot frames until either the button is let go or the camera is full). If a clip has been taken, then that clip gets one entry in the list, along with an indication of how many frames are in the clip. 3. The driver has to make sense of (1) and (2), in view of the fact that the camera has no actual file system on it, so a file system is faked. It is considered that, in "/" on the camera, each single photo is a file, and each clip is a subdirectory, containing the individual frames in that clip, as files in the subdirectory. Clips of course could be handled differently; the OEM driver makes each clip into an AVI file. But the way described seemed like at least one good way to do it. So, the point is, I think it would be very nice to be able to preserve this "subdirectory" structure when downloading photos. I tried to do this at the driver level quite some time ago, and found out that I could not because such a thing was not built into the infrastructure. However, I am not aware of any other cameras for which any similar situation applies. Come to think of it, I guess it could apply to a camera which has an internal memory and also a memory card. In that case if there were name collision (for example, IMG001.JPG is found both in the internal memory and also on the card, which the camera thinks is a separate location) then one might find such a feature useful there. But if the camera numbers the photos sequentially regardless of the physical location on the camera, there would be no need for this feature. I suppose that I should try the patch. I did see the previous letter announcing it, but IIRC the patch was munged for me by some funny way of attaching it. Namely, I did not see anything in the "Attachments:" field, but instead received a long message full of funny characters, apparently containing the tarball as part of the body of the message, and I did not know exactly how to deal with that. So, if someone would send it to me in such a way that I can deal with it, I would be appreciative. Theodore Kilgore ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
In reply to this post by Marcus Meissner-4
On 07/09/05, Marcus Meissner <[hidden email]> wrote:
> On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote: > > Hi there, > > I thought it would be useful to have an option to download a whole > > directory tree in Gtkam with a single command, I have also seen other > > people complain about this on the web. I'm attaching a simple patch > > that adds such option to the tree view's context menu. I hope you find > > a useful thing to have. (I'm only not too confident about my use of > > GTK) > > Greetings > > > Hmm. > > The patch works. However ... > > Do we really want to recreate the directory tree on the camera, or > download all files from the into the same directory? > > Ciao, Marcus > Personally I think it is important to be able to recreate the state of the camera that you can see through gtkam on a harddisk. A user may have arranged the pictures inside the camera into groups using gtkam itself, using the camera's interface or an external card reader. Also having a copy of the whole directory structure it will later be possible to restore the state of the camera seen from gtkam. A potential advantage of downloading into a tree instead of the same directory could be keeping the order of filenames assigned by camera. Having them all in one directory could in some cases mix them up. Beside this, both options can be added, I just found this one useful and as my previous camera supported "usb-storage", I got used to downloading the whole content of the card at once, and then moving the the files between directories on the hard disk, which was much faster than that camara's memory. Greetings -- balrog 2oo5 ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
andrzej zaborowski wrote:
> Personally I think it is important to be able to recreate the state of > the camera that you can see through gtkam on a harddisk. A user may > have arranged the pictures inside the camera into groups using gtkam > itself, using the camera's interface or an external card reader. Also > having a copy of the whole directory structure it will later be > possible to restore the state of the camera seen from gtkam. That is very unlikely on the camera, because it is not conformant with DCF filesystem standard. As for already having done that using an external card reader then he does not need it. > A potential advantage of downloading into a tree instead of the same > directory could be keeping the order of filenames assigned by camera. The only issue I see is conflicting file names. > Having them all in one directory could in some cases mix them up. EXIF is your friend. I only trust that. The file time too. > Beside this, both options can be added, I just found this one useful > and as my previous camera supported "usb-storage", I got used to > downloading the whole content of the card at once, and then moving the > the files between directories on the hard disk, which was much faster > than that camara's memory. I'd love to be able to automatically download them and sort them in folder timestamped using EXIF.... I'll do that later, eventually gtkam needs a lot of love. Hub ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote:
> > gtkam needs a lot of love. > :) I don't know if any distros are including it anymore ... at least it is not in fedora core 4. Seems kcamera (or ?) is expected to be use instead with FC. This means fewer users and fewer that will even know about trying to improve it. AFAIK there is no gui capture/control with the alternates, no ultra-cool LCD like view you get with gtkam. -- Patrick Mansfield ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
[hidden email] wrote:
> I don't know if any distros are including it anymore ... at least it is > not in fedora core 4. Seems kcamera (or ?) is expected to be use instead > with FC. Not even in extras? But yes, Fedora seems to remove lot of things. For example Gnumeric and AbiWord has been pushed to Extras, and I have ranted about that already. gtkam is in universe in Ubuntu. Hub ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
On Sat, Sep 10, 2005 at 04:33:44AM -0400, Hubert Figuiere wrote:
> [hidden email] wrote: > > > I don't know if any distros are including it anymore ... at least it is > > not in fedora core 4. Seems kcamera (or ?) is expected to be use instead > > with FC. > > Not even in extras? Nope. I installed it from an rpm at http://repo.nrpms.net, though I am using one built from CVS (and went ahead and just removed my rpm one). It is/was not in any of the repos contained in this rpm (an rpm that just installs repos in /etc/yum.repos): http://www.fedorafaq.org/yum > But yes, Fedora seems to remove lot of things. For example Gnumeric and > AbiWord has been pushed to Extras, and I have ranted about that already. I use both of those too. I still have oo installed (need ooimpress for ppt) but oo is a pig to start and a large download for updates (~100MB, and they seem to update about twice a month). -- Patrick Mansfield ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
In reply to this post by andrzej zaborowski
Patrick Mansfield wrote: >On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote: >> >> gtkam needs a lot of love. >> >:) >I don't know if any distros are including it anymore ... at least it is >not in fedora core 4. Seems kcamera (or ?) is expected to be use instead >with FC. I do not keep up with these matters in any detail, but I would think this is regrettable. >This means fewer users and fewer that will even know about trying to >improve it. A problem, if true. >AFAIK there is no gui capture/control with the alternates, no ultra-cool >LCD like view you get with gtkam. >-- Patrick Mansfield Very true. And let me add to this: Gtkam seems to me to work much more reliably than any of the other setups which are supposed to do the same thing. I sometimes have problems with it, but this is probably due to the fact that I deal with weird, el cheapo cameras. I have had much more trouble with all of the alternatives to gtkam that I know of. Some of them refuse to display thumbnails (perhaps because those programs _assume_ that the camera is actually providing thumbnails, or something like that?). Some of them will jam up when trying to handle a difficult camera like an sq905 running in mixed single mode and clip mode and will then munge the data in half of the frames. In contrast, gtkam can handle the problems at least 98% of the time in those special situations which probably do not come up with better-behaved cameras. And if occasionally there is a glitch, then it will work better if one tries again. Thus, in the README and in the "manual" section for the cameras which I support, I strongly recommend gtkam as a GUI frontend for the camera. Perhaps this is a good occasion to let the gtkam developers know that there is someone here who really does appreciate their work. Based upon the good old empirical test, they have done a lot of things right. Theodore Kilgore ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
[hidden email] wrote:
> > Patrick Mansfield wrote: > >> On Thu, Sep 08, 2005 at 08:05:52PM -0400, Hubert Figuiere wrote: >> >>> >>> gtkam needs a lot of love. >>> > >> :) > > >> I don't know if any distros are including it anymore ... at least it is >> not in fedora core 4. Seems kcamera (or ?) is expected to be use instead >> with FC. > > > I do not keep up with these matters in any detail, but I would think > this is regrettable. > >> This means fewer users and fewer that will even know about trying to >> improve it. > > > A problem, if true. > >> AFAIK there is no gui capture/control with the alternates, no ultra-cool >> LCD like view you get with gtkam. > > >> -- Patrick Mansfield > > > Very true. And let me add to this: > > > Gtkam seems to me to work much more reliably than any of the other > setups which are supposed to do the same thing. I sometimes have > problems with it, but this is probably due to the fact that I deal with > weird, el cheapo cameras. I have had much more trouble with all of the > alternatives to gtkam that I know of. Some of them refuse to display > thumbnails (perhaps because those programs _assume_ that the camera is > actually providing thumbnails, or something like that?). Some of them > will jam up when trying to handle a difficult camera like an sq905 > running in mixed single mode and clip mode and will then munge the data > in half of the frames. In contrast, gtkam can handle the problems at > least 98% of the time in those special situations which probably do not > come up with better-behaved cameras. And if occasionally there is a > glitch, then it will work better if one tries again. > > Thus, in the README and in the "manual" section for the cameras which I > support, I strongly recommend gtkam as a GUI frontend for the camera. > > Perhaps this is a good occasion to let the gtkam developers know that > there is someone here who really does appreciate their work. Based upon > the good old empirical test, they have done a lot of things right. Good point. I have no cheapo cameras for testing (I have "only" the Canon EOS 350D, the Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with GTKam), but I will keep GTKam in Mandriva Linux, as there are probably enough people under our customers who have a cheap digital camera without exchangeable memory cards. Till ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
On Sat, 10 Sep 2005, Till Kamppeter wrote: > I have no cheapo cameras for testing (I have "only" the Canon EOS 350D, the > Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with GTKam), > but I will keep GTKam in Mandriva Linux, as there are probably enough people > under our customers who have a cheap digital camera without exchangeable > memory cards. > > Till > Thanks. And there do exist people who use them, for various reasons. For example, about a week ago there was a talk-back to an article featured on Linux Today, and somebody brought up the usual whine about lack of hardware support for Linux. He got a response from someone else, who averred that the situation is just not so bad as it gets painted and itemized several unusual items of hardware which seem to be well supported. The first example was a Kidz Cam, bought for his daughter (something like 6 to 8 years old). IIRC they had some trouble with the camera in Windows, and they tried it in Linux. So the daughter fires up Linux to download the photos from it. Made me really proud. The Kidz Cam is one of those cameras you could buy last Christmas at WalMart for less than $20, and it has in it an sq905. Theodore Kilgore ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
In reply to this post by Till Kamppeter
> I have no cheapo cameras for testing (I have "only" the Canon EOS 350D, > the Fuji F10, and the Minolta DiMAGE F200, so only the 350D works with > GTKam), but I will keep GTKam in Mandriva Linux, as there are probably > enough people under our customers who have a cheap digital camera > without exchangeable memory cards. With current CVS the other cameras should be supported too. As for which cameras, currently all Kodak and Canon owner need libgphoto2. That's quite a market share. Hub ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
Re: Saving directory trees in Gtkam
|
|
In reply to this post by andrzej zaborowski
On Fri, Sep 09, 2005 at 01:34:43AM +0200, andrzej zaborowski wrote:
> On 07/09/05, Marcus Meissner <[hidden email]> wrote: > > On Sun, Sep 04, 2005 at 11:42:36PM +0200, andrzej zaborowski wrote: > > > Hi there, > > > I thought it would be useful to have an option to download a whole > > > directory tree in Gtkam with a single command, I have also seen other > > > people complain about this on the web. I'm attaching a simple patch > > > that adds such option to the tree view's context menu. I hope you find > > > a useful thing to have. (I'm only not too confident about my use of > > > GTK) > > > Greetings > > > > > > Hmm. > > > > The patch works. However ... > > > > Do we really want to recreate the directory tree on the camera, or > > download all files from the into the same directory? > > > > Ciao, Marcus > > > > Personally I think it is important to be able to recreate the state of > the camera that you can see through gtkam on a harddisk. A user may > have arranged the pictures inside the camera into groups using gtkam > itself, using the camera's interface or an external card reader. Also > having a copy of the whole directory structure it will later be > possible to restore the state of the camera seen from gtkam. > A potential advantage of downloading into a tree instead of the same > directory could be keeping the order of filenames assigned by camera. > Having them all in one directory could in some cases mix them up. > Beside this, both options can be added, I just found this one useful > and as my previous camera supported "usb-storage", I got used to > downloading the whole content of the card at once, and then moving the > the files between directories on the hard disk, which was much faster > than that camara's memory. I have applied the patch as-is now. Ciao, Marcus ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Gphoto-devel mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/gphoto-devel |
«
Return to gphoto-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |