Of course deleting a file has to be possible from within Digikam.
Deleting a picture,as any editing., will be rarely an unintended action, What I'm talking about is about deleting a folder in the disk by deleting an Album from within Digikam. This is what I think the user should be protected against. Agus On Fri, Jun 19, 2015 at 11:15 AM, Remco Viëtor <[hidden email]> wrote: > On Friday 19 June 2015 10:30:47 Agustin Lobo wrote: >> First, this is a design suggestion, yes. And designing according to >> user's experiences is the most fundamental advantage >> for developers of OSS. > >> Your view of "you like it, you use it; you >> don't like it, use something else" is, besides being unnecessarily >> rude , totally opposed to OSS philosophy. > > As you say, that is _my_view_; you can disagree with it, of course, and > apparently you do. Calling it rude, well, that's your opinion. I was just > trying to point you to a program that seemed closer to the way you wanted > things done. I won't go into any discussion of "OSS philosophy". > > >> Second, I was obviously referring to file management. Obviously, the >> editing tasks must change files. But this would rarely be >> an unintended action (although Digikam has the means of protecting the >> user of eventual errors in this case), while >> deleting an Album while thinking you are deleting just something >> internal to Digikam can easily happen. > > And you did miss my point about the culling, which is where I at least want > to physically and permanently delete files that are either fails or almost- > duplicates. And as those are raw files, I'd rather do that from within > Digikam. Same for experimental edits taht I want to get rid of (disk space > is cheap, but keeping all images and every possible edit it comsuming it a > bit too fast for my taste). > > Well, I probably offended you again with my differing opinions... > Guess I'll shut up now > > Remco > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Peter Mc Donough
On Fri, Jun 19, 2015 at 11:40 AM, Peter Mc Donough
<[hidden email]> wrote: > ... > Doesn't it exactly do that? For file managing digikam uses the resources of > the operating system, as it should. No, it does not: if you remove an Album you remove a Folder. The behaviour I suggest is just that removing an Album would remove that information from Digikam. In my opinion, removing the folder should be done by a different tool or through the OS. > You can easily get what you want by adding a tag to a group of photos and > using the powerful search options of digikam for creating just the virtual > collection when you want it. > > Remove the tag and your virtual collection disappears. True, I agree. But I'm talking about preventing users to unintentionally delete a folder by deleting an album. A assets managing system must be very protective. > cu > Peter > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 19-6-2015 12:10, Agustin Lobo wrote:
> On Fri, Jun 19, 2015 at 11:40 AM, Peter Mc Donough > <[hidden email]> wrote: >> You can easily get what you want by adding a tag to a group of photos and >> using the powerful search options of digikam for creating just the virtual >> collection when you want it. >> >> Remove the tag and your virtual collection disappears. > True, I agree. But I'm talking about preventing users to > unintentionally delete a folder > by deleting an album. from a user on this list or anywhere on the internet, that the folder disappeared after deleting the album. I can't talk for other users, but it seems you are trying to have a problem solved that does not exist. Best regards, Boudewijn _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
Am 19.06.2015 um 12:10 schrieb Agustin Lobo:
> On Fri, Jun 19, 2015 at 11:40 AM, Peter Mc Donough > <[hidden email]> wrote: > >> ... >> Doesn't it exactly do that? For file managing digikam uses the resources of >> the operating system, as it should. > > No, it does not: if you remove an Album you remove a Folder. > The behaviour I suggest is just that removing an Album would remove > that information > from Digikam. In my opinion, removing the folder should be done by a > different tool or through the OS. So an option which replaces the expression "Album" with "Folder" would solve the whole problem by making it clear to the user that deleting "Folder" will sends his collection to the orcus;-) BTW In digikam's handbook, in "Album View", you will find: "Deleting an Album When you delete an Album from digiKam it will be moved into the KDE Trash Can. ..." cu Peter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Boudewijn
Am 19.06.2015 um 12:26 schrieb Boudewijn: > On 19-6-2015 12:10, Agustin Lobo wrote: >> True, I agree. But I'm talking about preventing users to >> unintentionally delete a folder >> by deleting an album. > It never happened to me. Did it happen to you? I never read a complaint > from a user on this list or anywhere on the internet, that the folder > disappeared after deleting the album. > > I can't talk for other users, but it seems you are trying to have a > problem solved that does not exist. > And how about preventing users from - unintended crash of HD? - unintentionally publishing private stuff on facebook? or even - bad taste in selecting images? - missing talent when taking photos? When deleting an alum (I just tried) a BIG warning appears: "These albums will be *removed* *irrevocably* from data storage medium" furthermore, if you don't check "delete instead of moving to trash" your album is still in the trash and you can even undo your "unintenional deleting". What more can one do? Let the computer shout: "Hey, think again!", an electric shock via keyboard? This is really an unexisting problem. Sorry. -- Daniel Bauer photographer Basel Barcelona http://www.daniel-bauer.com room in Barcelona: https://www.airbnb.es/rooms/2416137 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Peter Mc Donough
Yes, exactly, and even there (and that's page 28!) there is no mention
to the fact that what is really being sent to the trash is the actual folder. Agus On Fri, Jun 19, 2015 at 12:34 PM, Peter Mc Donough <[hidden email]> wrote: > > BTW In digikam's handbook, in "Album View", you will find: > "Deleting an Album When you delete an Album from digiKam it will be moved > into the KDE Trash Can. ..." _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Daniel Bauer-2
Agreed. Whilst I find the terminology somewhat obtuse, your data is *your* responsibility. I use RAID5 on btrfs for my shots (don't bother telling me it's experimental, I've been using it since it was announced years ago). Before I start working I take a snapshot of the entire collection. When I'm finished I take another, and back up the difference as an incremental. Basic bloody housekeeping. What are your photos worth to you folks - take some responsibility. LVM may offer similar, but I only rarely use it.
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Daniel Bauer-2
Daniel,
On Fri, Jun 19, 2015 at 12:40 PM, Daniel Bauer <[hidden email]> wrote: > >> I can't talk for other users, but it seems you are trying to have a >> problem solved that does not exist. Yes, of course: and that's what a good software analyst does. ... > When deleting an alum (I just tried) a BIG warning appears: > "These albums will be *removed* *irrevocably* from data storage medium" Even there, the last step before deleting, it does not mention that what the user is going to remove is the folder! The bottom problem is that you are all too used to think that Albumm == Folder, but: 1. Outside Digikam, in the real world from where new users come from, an Album is not a Folder. A folder can contain even different kinds of files. Actually, most folders in the world do have files of different types. Folder is a totally different concept to Album. 2. Nowhere in the manual is the term Album defined, even more, nowhere it says that, within Digikam, Album == Folder. Agus _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 19/06/2015 13:08, Agustin Lobo a écrit :
> an Album is not a Folder. A folder can contain > even different kinds of files. Actually, most folders in the world do > have files of different types. Folder is a totally different > concept to Album. two things: * in the delete album windows, is given the complete tree of the album (/data/myphotos/mydate), so the content deleted is fairly obvious - this is the kde windows AFAIK * *but* there may be a problem: digikam do *not* show if there is something in the folder but images. If the folder have in it text files (just tested), it removes all. Kde do also, but in dolphin it's easy to see if there is other files. rmdir (CLI) do not remove non empty folder. So there could be two solutions: 1) do not remove non empty folders. The user may have to look in the folder elsewhere, it may be confusing 2) show inside digikam every kind of file, greyed out, or marked "not an image" in fact I would like to have the second option. don't know if it's possible without too much rewriting thanks jdd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
On 19-6-2015 13:29, jdd wrote:
> Le 19/06/2015 13:08, Agustin Lobo a écrit : > >> an Album is not a Folder. A folder can contain >> even different kinds of files. Actually, most folders in the world do >> have files of different types. Folder is a totally different >> concept to Album. > > So there could be two solutions: > > 1) do not remove non empty folders. The user may have to look in the > folder elsewhere, it may be confusing > > 2) show inside digikam every kind of file, greyed out, or marked "not an > image" > > in fact I would like to have the second option. don't know if it's > possible without too much rewriting > as that implies that there is a problem to be solved in the first place. I can imagine a third option, a check if there is any (hidden?) file with another extension than those managed by DigiKam. If that is the case, give the user a warning that there files in that directory that are not visible through DigiKam. Again: I use DigiKam to manage photo's (and more and more often video's). I don't have audiobooks, application letters or tax files in the directory structure that is for photo data. All files in a specific directory containing photo-data are just that: files relating to those photo's. In my case, if I were to delete a specific photo-directory, I also wanted to delete everything in that directory. Best regards, Boudewijn _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
On 19-6-2015 13:08, Agustin Lobo wrote:
> Daniel, > On Fri, Jun 19, 2015 at 12:40 PM, Daniel Bauer<[hidden email]> wrote: >> > >>> >>I can't talk for other users, but it seems you are trying to have a >>> >>problem solved that does not exist. > Yes, of course: and that's what a good software analyst does. I think that that is what a sales person does. A good software analyst solves problems that are there, but of which the users have not yet realized it exists. Your initial question whas: what is the difference between folders, albums and collections. Their meanings in DigiKam have been explained at some length now. Is their meaning clear to you now (even if you had preferred to see another name for your workflow)? Apart from the definition of the label "album" vs "directory" or "folder" (or other name for a collection of files), is there something else that holds you back from using DigiKam? Best regards, Boudewijn _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
Hmm, I thought I live in the real world and for me Album = Folder. When I had still all paper based Pictures, they were sorted in an Album. If I throw it away, all the pix were gone.. I do not see a problem here and as many others would be disappointed if this changes. Please understand, that while in OSS everyone can contribute it is NOT a democracy. BR Chris. 2015-06-19 13:08 GMT+02:00 Agustin Lobo <[hidden email]>: Daniel, _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Le 20/06/2015 17:14, Christoph Huckle a écrit :
> Hmm, I thought I live in the real world and for me Album = Folder. > When I had still all paper based Pictures, they were sorted in an Album. > If I throw it away, all the pix were gone.. the rule is: *never* work on the original, always on a copy... by the way, it's only a word, is it hard coded? I guess it could be changed by the user, may be even without recompiling digikam (after all I could patch command.com in the win95 days :-) look: /usr/share/kde4> grep -R "Album" * apps/plasma/plasmoids/nowplaying/contents/ui/CompactLayout.qml: AlbumArt { apps/plasma/plasmoids/nowplaying/contents/ui/FullLayout.qml: AlbumArt { apps/plasma/plasmoids/nowplaying/contents/ui/MetadataLine.qml: property bool showAlbum: true apps/plasma/plasmoids/nowplaying/contents/ui/MetadataLine.qml: showAlbum = plasmoid.readConfig("displayAlbum"); apps/plasma/plasmoids/nowplaying/contents/ui/MetadataLine.qml: if (showAlbum && source.album != '') { (some more lines) :-) jdd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |