I'm a bit confused by the relationships between the concepts
of folder, album and collection in Digikam. For example, if I have my pictures in folders in an external drive, would each folder become an Album in Digikam? Would sub-folders become sub-albums? Are the pictures actually copied to the albums? Or do the pictures remain in their original folders and just meta-data and thumbnails are integrated in the db? And what's a collection? Just a set of folders? All this is not clear in the manual and it is important before the beginner user decides the structure of its DB. Thanks Agus _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Albums are just directories. Collections are sets of directories.
Nothing is copied into the db except metadata. Thumbnails are created and stored in a separate db. You pretty much just get a view of the filesystem. If you move things around in digikam, they are moved around in the filesystem. Andrew On 16/06/15 16:04, Agustin Lobo wrote: > I'm a bit confused by the relationships between the concepts > of folder, album and collection in Digikam. For example, > if I have my pictures in folders in an external drive, > would each folder become an Album in Digikam? Would sub-folders > become sub-albums? > Are the pictures actually copied to the albums? Or do the pictures > remain in their original folders and just meta-data and thumbnails > are integrated in the db? > And what's a collection? Just a set of folders? > > All this is not clear in the manual and it is important before the beginner user > decides the structure of its DB. > > Thanks > > Agus > _______________________________________________ > 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 |
If I have a directory named FOTOS with a subdirectory named 20130523,
do I get one Album and one sub-album or just 2 albums at the same level? Thanks On Tue, Jun 16, 2015 at 7:35 PM, Andrew Goodbody <[hidden email]> wrote: > Albums are just directories. Collections are sets of directories. Nothing is > copied into the db except metadata. Thumbnails are created and stored in a > separate db. You pretty much just get a view of the filesystem. If you move > things around in digikam, they are moved around in the filesystem. > > Andrew > > > On 16/06/15 16:04, Agustin Lobo wrote: >> >> I'm a bit confused by the relationships between the concepts >> of folder, album and collection in Digikam. For example, >> if I have my pictures in folders in an external drive, >> would each folder become an Album in Digikam? Would sub-folders >> become sub-albums? >> Are the pictures actually copied to the albums? Or do the pictures >> remain in their original folders and just meta-data and thumbnails >> are integrated in the db? >> And what's a collection? Just a set of folders? >> >> All this is not clear in the manual and it is important before the >> beginner user >> decides the structure of its DB. >> >> Thanks >> >> Agus >> _______________________________________________ >> 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 Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Album and sub-album. As I said, it is just a view of the file system so
the hierarchy is the same. Andrew On 17/06/15 07:32, Agustin Lobo wrote: > If I have a directory named FOTOS with a subdirectory named 20130523, > do I get one Album and one > sub-album or just 2 albums at the same level? > Thanks > > On Tue, Jun 16, 2015 at 7:35 PM, Andrew Goodbody <[hidden email]> wrote: >> Albums are just directories. Collections are sets of directories. Nothing is >> copied into the db except metadata. Thumbnails are created and stored in a >> separate db. You pretty much just get a view of the filesystem. If you move >> things around in digikam, they are moved around in the filesystem. >> >> Andrew >> >> >> On 16/06/15 16:04, Agustin Lobo wrote: >>> >>> I'm a bit confused by the relationships between the concepts >>> of folder, album and collection in Digikam. For example, >>> if I have my pictures in folders in an external drive, >>> would each folder become an Album in Digikam? Would sub-folders >>> become sub-albums? >>> Are the pictures actually copied to the albums? Or do the pictures >>> remain in their original folders and just meta-data and thumbnails >>> are integrated in the db? >>> And what's a collection? Just a set of folders? >>> >>> All this is not clear in the manual and it is important before the >>> beginner user >>> decides the structure of its DB. >>> >>> Thanks >>> >>> Agus Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
See inline:
Þann mið 17.jún 2015 06:32, skrifaði Agustin Lobo: > If I have a directory named FOTOS with a subdirectory named 20130523, > do I get one Album and one > sub-album or just 2 albums at the same level? You'll have the album FOTOS with a sub-album 20130523. >> On 16/06/15 16:04, Agustin Lobo wrote: >>> I'm a bit confused by the relationships between the concepts >>> of folder, album and collection in Digikam. For example, >>> if I have my pictures in folders in an external drive, >>> would each folder become an Album in Digikam? Would sub-folders >>> become sub-albums? >>> Are the pictures actually copied to the albums? Or do the pictures >>> remain in their original folders and just meta-data and thumbnails >>> are integrated in the db? >>> And what's a collection? Just a set of folders? As for your original question: Digikam respects the directory structure of your filesystems - this is important to know, because some other software do not, but create relationships via database 'tags' and softlinks. I think many Digikam users are so grateful for this transparency, and would be really annoyed if there was some esoteric layer between the file structure and their representation. The words 'album', 'folder' and 'directory' can be regarded as meaning the same thing, they just come from different naming conventions or vocabulary of different trades. Some other applications use terms like 'film-roll' in addition to those. Your translated Digikam interface may or may not respect the local conventions in your language. 'Album' comes from the Latin word 'albus' [1], meaning 'white' or 'blank', which became used in the 1650's for a kind of a scrapbook where scolars used to collect souvenirs or references and even for collection of "autographs of celebrated people". Albums for collection of photographic prints/films became known in the mid-1800's. Most of the Digikam vocabulary stems from terms in photography and/or printing, this is quite normal and even desirable. But of course, with new techniques in handling of digital images, there will be new terms without any links to the past - and the language metaphors will evolve. Best regards, Sveinn í Felli [1]: <http://www.etymonline.com/index.php?term=album> _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
Hi.
And why moving from one album to another on the same device is so slow process? I expect that this operation like moving on the filesystem is an easy operation. If i move files on file system they are not copied, so operation is quick, but then it takes some time to digikam make thumbnails, it's clear. But when I do this via digikam, it should not rebuild thumbnails, it should use already existed. So it's where further improvement can be made. Thanks Kostya Втр 16 Июн 2015 18:05:59 +0300, Agustin Lobo <[hidden email]> написал: I'm a bit confused by the relationships between the concepts _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Sveinn í Felli-2
Then, just to fully clarify:
From within digikam, 1. If I delete an Album, do I delete a folder? 2. If I rename an Album, do I rename a folder? If this is the case, it is kind of dangerous. If it is not the case, then the statement "The words 'album', 'folder' and 'directory' can be regarded as meaning the same thing" would be not true in what albums are concerned. Certainly, folder and directory are the same concept. But "album" (a common word in latin languages such as mine) is not a computer term but a common word which exact significance within digikam should be well defined. Same for "Collection", which is actually ambiguous. Thanks, Agus On Wed, Jun 17, 2015 at 11:02 AM, Sveinn í Felli <[hidden email]> wrote: > See inline: > > Þann mið 17.jún 2015 06:32, skrifaði Agustin Lobo: >> >> If I have a directory named FOTOS with a subdirectory named 20130523, >> do I get one Album and one >> sub-album or just 2 albums at the same level? > > > You'll have the album FOTOS with a sub-album 20130523. > >>> On 16/06/15 16:04, Agustin Lobo wrote: >>>> >>>> I'm a bit confused by the relationships between the concepts >>>> of folder, album and collection in Digikam. For example, >>>> if I have my pictures in folders in an external drive, >>>> would each folder become an Album in Digikam? Would sub-folders >>>> become sub-albums? >>>> Are the pictures actually copied to the albums? Or do the pictures >>>> remain in their original folders and just meta-data and thumbnails >>>> are integrated in the db? >>>> And what's a collection? Just a set of folders? > > > As for your original question: Digikam respects the directory structure of > your filesystems - this is important to know, because some other software do > not, but create relationships via database 'tags' and softlinks. I think > many Digikam users are so grateful for this transparency, and would be > really annoyed if there was some esoteric layer between the file structure > and their representation. > > The words 'album', 'folder' and 'directory' can be regarded as meaning the > same thing, they just come from different naming conventions or vocabulary > of different trades. Some other applications use terms like 'film-roll' in > addition to those. > Your translated Digikam interface may or may not respect the local > conventions in your language. > > 'Album' comes from the Latin word 'albus' [1], meaning 'white' or 'blank', > which became used in the 1650's for a kind of a scrapbook where scolars used > to collect souvenirs or references and even for collection of "autographs of > celebrated people". Albums for collection of photographic prints/films > became known in the mid-1800's. > > Most of the Digikam vocabulary stems from terms in photography and/or > printing, this is quite normal and even desirable. But of course, with new > techniques in handling of digital images, there will be new terms without > any links to the past - and the language metaphors will evolve. > > Best regards, > > Sveinn í Felli > > [1]: <http://www.etymonline.com/index.php?term=album> > > _______________________________________________ > 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 18/06/15 08:26, Agustin Lobo wrote:
> Then, just to fully clarify: > From within digikam, > 1. If I delete an Album, do I delete a folder? > 2. If I rename an Album, do I rename a folder? 1) Yes 2) Yes As I said, it is a view onto the filesystem. The same applies to the pictures and videos etc. as well. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Very dangerous. I suggest that, in the future, all Albums be virtual.
That is, initially you get Albums matching folders, but removing Albums should not imply removing folders. Removing folders should be done by using the OS. Digikam should deal with managing its database only. Note that for most users (specially novice users) having Albums and Virtual Albums can be confusing, and they could easily think that they are removing a virtual Album while they are removing a folder... with its pictures. Agus On Thu, Jun 18, 2015 at 11:58 PM, Andrew Goodbody <[hidden email]> wrote: > On 18/06/15 08:26, Agustin Lobo wrote: >> >> Then, just to fully clarify: >> From within digikam, >> 1. If I delete an Album, do I delete a folder? >> 2. If I rename an Album, do I rename a folder? > > > 1) Yes > 2) Yes > > As I said, it is a view onto the filesystem. > > The same applies to the pictures and videos etc. as well. > > Andrew > > _______________________________________________ > 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 Friday 19 June 2015 09:41:30 Agustin Lobo wrote:
> Very dangerous. I suggest that, in the future, all Albums be virtual. > That is, initially you get Albums matching folders, but removing > Albums should not > imply removing folders. Removing folders should be done by using the OS. Digikam > should deal with managing its database only. > Note that for most users (specially novice users) having Albums and > Virtual Albums can be confusing, > and they could easily think that they are removing a virtual Album > while they are removing a folder... with its pictures. Isn't that a design decision? And digikam went one way, you prefer another... Perhaps Darktable would be more to your taste. And also, if Digikam 'deal[s] with managing its database only', how are you going to cull the images that are blurred, or just not good enough to keep? Remco _______________________________________________ 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 09:41 schrieb Agustin Lobo: > Very dangerous. I suggest that, in the future, all Albums be virtual. > That is, initially you get Albums matching folders, but removing > Albums should not > imply removing folders. Removing folders should be done by using the OS. Digikam > should deal with managing its database only. > Note that for most users (specially novice users) having Albums and > Virtual Albums can be confusing, > and they could easily think that they are removing a virtual Album > while they are removing a folder... with its pictures. > > Agus > > No, I do not agree at all. That digikam reflects the directories and files just naturally, as they are in the file system, is one of its great advantages. It makes everything more transparent and easy to maintain. One can use/move/add/delete folders and files also outside of digikam using the file system or saving from an other application (like gimp etc.) into folders/albums. Backup is easy too, this way. If I delete an image or a folder I want to have it deleted. It's my computer, not facebook or google. I don't want "deleted" and deleted things, and in the end not knowing if something is really deleted or not, respectively having to use another application to clean up and synchronize file system with "virtual stuff". I don't want to have other folder names than those that physically appear on my HD. A virtual album view would be another layer, making things even more complicated. More database access, slower, more possibilities for errors and bad synchronization... no, thanks. No no, just keep it as is, digikam! Daniel -- 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 Remco Viëtor
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. 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. Agus On Fri, Jun 19, 2015 at 10:09 AM, Remco Viëtor <[hidden email]> wrote: > On Friday 19 June 2015 09:41:30 Agustin Lobo wrote: >> Very dangerous. I suggest that, in the future, all Albums be virtual. >> That is, initially you get Albums matching folders, but removing >> Albums should not >> imply removing folders. Removing folders should be done by using the OS. > Digikam >> should deal with managing its database only. >> Note that for most users (specially novice users) having Albums and >> Virtual Albums can be confusing, >> and they could easily think that they are removing a virtual Album >> while they are removing a folder... with its pictures. > > Isn't that a design decision? And digikam went one way, you prefer > another... Perhaps Darktable would be more to your taste. > > And also, if Digikam 'deal[s] with managing its database only', how are you > going to cull the images that are blurred, or just not good enough to keep? > > 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 Daniel Bauer-2
I can see your point. Every option has advantages and disadvantages.
Perhaps, considering virtual Albums do exist in Digikam already, it could be possible offering the option of always making virtual Albums and never use "hard" Albums. The decision would be up to the user. What I would do for sure is not using the term "Albums" for "hard" Albums as they are just Folders. Using the term folder would make it clear that the user is dealing with the structure of its disk, not with something internal to Digikam. if Album is identical to folder, using that term increases complexity with no gain of information, thus increases confusion. Agus On Fri, Jun 19, 2015 at 10:19 AM, Daniel Bauer <[hidden email]> wrote: > > > Am 19.06.2015 um 09:41 schrieb Agustin Lobo: >> >> Very dangerous. I suggest that, in the future, all Albums be virtual. >> That is, initially you get Albums matching folders, but removing >> Albums should not >> imply removing folders. Removing folders should be done by using the OS. >> Digikam >> should deal with managing its database only. >> Note that for most users (specially novice users) having Albums and >> Virtual Albums can be confusing, >> and they could easily think that they are removing a virtual Album >> while they are removing a folder... with its pictures. >> >> Agus >> >> > > No, I do not agree at all. > > That digikam reflects the directories and files just naturally, as they are > in the file system, is one of its great advantages. It makes everything more > transparent and easy to maintain. One can use/move/add/delete folders and > files also outside of digikam using the file system or saving from an other > application (like gimp etc.) into folders/albums. Backup is easy too, this > way. > > If I delete an image or a folder I want to have it deleted. It's my > computer, not facebook or google. > > I don't want "deleted" and deleted things, and in the end not knowing if > something is really deleted or not, respectively having to use another > application to clean up and synchronize file system with "virtual stuff". I > don't want to have other folder names than those that physically appear on > my HD. > > A virtual album view would be another layer, making things even more > complicated. More database access, slower, more possibilities for errors and > bad synchronization... no, thanks. > > No no, just keep it as is, digikam! > > Daniel > > -- > 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 Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
Very dangerous... really. Not more than Another GUI abstraction layer which will be less understandable by end users. It's logic to see WHERE are files on computer. This is not a weird design, but how computer users play with it since a lots of decades. This is also a design that digiKam users want from the start. Ex : iPhoto/Aperture : where are files ??? Copied and cached into private repository. KPhotoAlbum : there is no FS view. You don't care about FS view. No problem with digiKam. Create a collection, put all images on the root as well, and start to sort/group items in virtual albums named Tags. Go to Tags album view and you will have same behaviors than iPhoto like applications. Gilles Caulier 2015-06-19 10:30 GMT+02:00 Agustin Lobo <[hidden email]>: First, this is a design suggestion, yes. And designing according to _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Daniel Bauer-2
Hi,
I have to agree with Daniel. The current implementation of Digikam is very nice, open and transparent. Any application can update the folders and pictures without any limitations. If Digikam would change the way it works now, I would regret it a lot and would make me look for alternative software. Andreas On 19.06.2015 10:19, Daniel Bauer wrote: > > > Am 19.06.2015 um 09:41 schrieb Agustin Lobo: >> Very dangerous. I suggest that, in the future, all Albums be virtual. >> That is, initially you get Albums matching folders, but removing >> Albums should not >> imply removing folders. Removing folders should be done by using the >> OS. Digikam >> should deal with managing its database only. >> Note that for most users (specially novice users) having Albums and >> Virtual Albums can be confusing, >> and they could easily think that they are removing a virtual Album >> while they are removing a folder... with its pictures. >> >> Agus >> >> > > No, I do not agree at all. > > That digikam reflects the directories and files just naturally, as > they are in the file system, is one of its great advantages. It makes > everything more transparent and easy to maintain. One can > use/move/add/delete folders and files also outside of digikam using > the file system or saving from an other application (like gimp etc.) > into folders/albums. Backup is easy too, this way. > > If I delete an image or a folder I want to have it deleted. It's my > computer, not facebook or google. > > I don't want "deleted" and deleted things, and in the end not knowing > if something is really deleted or not, respectively having to use > another application to clean up and synchronize file system with > "virtual stuff". I don't want to have other folder names than those > that physically appear on my HD. > > A virtual album view would be another layer, making things even more > complicated. More database access, slower, more possibilities for > errors and bad synchronization... no, thanks. > > No no, just keep it as is, digikam! > > Daniel > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
Hello,
as a developer of digiKam let me clarify some things and and explain why this idea is not feasible. digiKam is build around the same model as filesystem. Which means, basic functionalities which can be done in file manager can be also done in digiKam.Now if you don't like the filesystem organization, you go with advanced features such as tagging and metadata. It might look simple, but in digikams code, only to click another album and to display it, a lot of operations are done. We have long history of troubles when it comes to keeping metadata synchronized and image versions. I rewrote that code at least 3 times, and still didn't manage to make everybody happy about it. Synchronization is madness, because users have all sort of workflows, where some stuff is done from file manager, some stuff done with digiKam, some stuff done with other programs. A open source project is about small incremental changes, we can't simply throw half of digikam away and rewrite it in a different matter. Maybe companies like Adobe have money and resources. Here digiKam has barely 3 part-time developers. Veaceslav On Fri, Jun 19, 2015 at 10:30 AM, Agustin Lobo <[hidden email]> 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. > 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. > Agus > > On Fri, Jun 19, 2015 at 10:09 AM, Remco Viëtor <[hidden email]> wrote: >> On Friday 19 June 2015 09:41:30 Agustin Lobo wrote: >>> Very dangerous. I suggest that, in the future, all Albums be virtual. >>> That is, initially you get Albums matching folders, but removing >>> Albums should not >>> imply removing folders. Removing folders should be done by using the OS. >> Digikam >>> should deal with managing its database only. >>> Note that for most users (specially novice users) having Albums and >>> Virtual Albums can be confusing, >>> and they could easily think that they are removing a virtual Album >>> while they are removing a folder... with its pictures. >> >> Isn't that a design decision? And digikam went one way, you prefer >> another... Perhaps Darktable would be more to your taste. >> >> And also, if Digikam 'deal[s] with managing its database only', how are you >> going to cull the images that are blurred, or just not good enough to keep? >> >> 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 Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
2015-06-19 10:41 GMT+02:00 Agustin Lobo <[hidden email]>: I can see your point. Every option has advantages and disadvantages. Debate about this kind of typo is ridiculous. We have well "My Images" dir on your home directory, and there is no problem with it. Album want mean a directory where i know that i only put multimedia files. That all. It's simple to understand... Gilles Caulier >> Very dangerous. I suggest that, in the future, all Albums be virtual. >> That is, initially you get Albums matching folders, but removing >> Albums should not >> imply removing folders. Removing folders should be done by using the OS. >> Digikam >> should deal with managing its database only. >> Note that for most users (specially novice users) having Albums and >> Virtual Albums can be confusing, >> and they could easily think that they are removing a virtual Album >> while they are removing a folder... with its pictures. >> >> Agus >> >> > > No, I do not agree at all. > > That digikam reflects the directories and files just naturally, as they are > in the file system, is one of its great advantages. It makes everything more > transparent and easy to maintain. One can use/move/add/delete folders and > files also outside of digikam using the file system or saving from an other > application (like gimp etc.) into folders/albums. Backup is easy too, this > way. > > If I delete an image or a folder I want to have it deleted. It's my > computer, not facebook or google. > > I don't want "deleted" and deleted things, and in the end not knowing if > something is really deleted or not, respectively having to use another > application to clean up and synchronize file system with "virtual stuff". I > don't want to have other folder names than those that physically appear on > my HD. > > A virtual album view would be another layer, making things even more > complicated. More database access, slower, more possibilities for errors and > bad synchronization... no, thanks. > > No no, just keep it as is, digikam! > > Daniel > > -- > 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 _______________________________________________ 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 Andreas Neumann
2015-06-19 10:47 GMT+02:00 Andreas Neumann <[hidden email]>: Hi, And this will never done... (:-))) Gilles Caulier _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Agustin Lobo
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 |
In reply to this post by Agustin Lobo
Am 19.06.2015 um 09:41 schrieb Agustin Lobo:
> Very dangerous. I suggest that, in the future, all Albums be virtual. > That is, initially you get Albums matching folders, but removing > Albums should not > imply removing folders. Removing folders should be done by using the OS. Digikam > should deal with managing its database only. ... Doesn't it exactly do that? For file managing digikam uses the resources of the operating system, as it should. 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. cu Peter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Free forum by Nabble | Edit this page |