Right now Digikam has two modes: Viewing and Editing. It seems to me
that there actually needs to be a third mode, Organizing, which would have less emphasis on things like zooming and panning but would have more emphasis on tagging, deleting, grouping (see bug #121310), filing into albums, and making little touchups like redeye removal. I find that the first time I go through new photos from the camera, I am organizing them and need these features to be readily available. However, the future times that I go through the photos my emphasis is on enjoying the photos, not on organizing them. What do you think? -- Dotan Cohen http://bido.com http://what-is-what.com Please CC me if you want to be sure that I read your message. I do not read all list mail. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Dotan Cohen wrote:
> Right now Digikam has two modes: Viewing and Editing. It seems to me > that there actually needs to be a third mode, Organizing, which would > have less emphasis on things like zooming and panning but would have > more emphasis on tagging, deleting, grouping (see bug #121310), filing > into albums, and making little touchups like redeye removal. I find > that the first time I go through new photos from the camera, I am > organizing them and need these features to be readily available. > However, the future times that I go through the photos my emphasis is > on enjoying the photos, not on organizing them. > > What do you think? > > I agree that it would be useful to have more flexible organising capabilities in digikam, since it already is/appears to be a photo management tool, I think it would already help a lot if digikam could handle multiple selections in the directory/album tree for moving them around. Since digikam relies a lot on storing stuff in a database (tags and metadata), with this comes the burden of re-implementing common filesystem tools in an accessible manner. (Unless Nepomuk is going to be handling the database, but I don't like nepomuk) I'd also like group renaming for directories and such. More intelligent matching of RAW files to their JPEG counterparts, or any image and their derivatives (done by digikam or an external program like the gimp). Cheers PS, off-topic, but I noticed that a lot of messages here go unanswered, I don't think that's a good sign! _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Simon Oosthoek a écrit :
> Dotan Cohen wrote: > >> Right now Digikam has two modes: Viewing and Editing. It seems to me >> that there actually needs to be a third mode, Organizing, which would >> have less emphasis on things like zooming and panning but would have >> more emphasis on tagging, deleting, grouping (see bug #121310), filing >> into albums, and making little touchups like redeye removal. I find >> that the first time I go through new photos from the camera, I am >> organizing them and need these features to be readily available. >> However, the future times that I go through the photos my emphasis is >> on enjoying the photos, not on organizing them. >> >> What do you think? >> >> >> > > I agree that it would be useful to have more flexible organising > capabilities in digikam, since it already is/appears to be a photo > management tool, I think it would already help a lot if digikam could > handle multiple selections in the directory/album tree for moving them > around. > > Since digikam relies a lot on storing stuff in a database (tags and > metadata), with this comes the burden of re-implementing common > filesystem tools in an accessible manner. (Unless Nepomuk is going to be > handling the database, but I don't like nepomuk) > I don't understand exactly what do you mean, which common filesystem tools do you need ? > I'd also like group renaming for directories and such. Please add a wish in bko if there is not already one. > More intelligent > matching of RAW files to their JPEG counterparts, or any image and their > derivatives (done by digikam or an external program like the gimp). > > There is already a wish about that in bko. > Cheers > > PS, off-topic, but I noticed that a lot of messages here go unanswered, > I don't think that's a good sign! > I think the message was unanswered because it was a general idea, with no precise thought about what to be done. If we are more precise we can start discussing the possible guis, and what people like and what people do not like. Cheers, Julien > _______________________________________________ > 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 |
Julien Narboux wrote:
> Simon Oosthoek a écrit : > >> Dotan Cohen wrote: >> >> >>> Right now Digikam has two modes: Viewing and Editing. It seems to me >>> that there actually needs to be a third mode, Organizing, which would >>> have less emphasis on things like zooming and panning but would have >>> more emphasis on tagging, deleting, grouping (see bug #121310), filing >>> into albums, and making little touchups like redeye removal. I find >>> that the first time I go through new photos from the camera, I am >>> organizing them and need these features to be readily available. >>> However, the future times that I go through the photos my emphasis is >>> on enjoying the photos, not on organizing them. >>> >>> What do you think? >>> >>> >>> >>> >> I agree that it would be useful to have more flexible organising >> capabilities in digikam, since it already is/appears to be a photo >> management tool, I think it would already help a lot if digikam could >> handle multiple selections in the directory/album tree for moving them >> around. >> >> > Please add a wish in bko if there is not already one. > >> Since digikam relies a lot on storing stuff in a database (tags and >> metadata), with this comes the burden of re-implementing common >> filesystem tools in an accessible manner. (Unless Nepomuk is going to be >> handling the database, but I don't like nepomuk) >> >> > I don't understand exactly what do you mean, which common filesystem > tools do you need ? > even in graphical tools there are advanced ways of managing directories. I'd lile to batch-rename directories, move groups of directories at once, etc. I know there are tools inside digikam to manipulate the files, I'm not talking about those. Other tools I've mentioned above and below. >> I'd also like group renaming for directories and such. >> > Please add a wish in bko if there is not already one. > >> More intelligent >> matching of RAW files to their JPEG counterparts, or any image and their >> derivatives (done by digikam or an external program like the gimp). >> >> >> > There is already a wish about that in bko. > no-no on this list? > >> Cheers >> >> PS, off-topic, but I noticed that a lot of messages here go unanswered, >> I don't think that's a good sign! >> >> > > I think the message was unanswered because it was a general idea, with > no precise thought about what to be done. If we are more precise we can > start discussing the possible guis, and what people like and what people > do not like. > Well, this is a list called "digikam-users", IMO users should always get an answer when they manage to find the mailinglist to post a problem. The reply can be a semi-canned response pointing to bko, acknowledging the problem or even better, providing a quick hint towards a solution. No reply means ignoring a possible new user, friend, contributor, etc. Developers and alpha/beta users can handle a lot more terse responses, users need some friendly pointers. Cheers Simon _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Simon Oosthoek a écrit :
> Julien Narboux wrote: > >> Simon Oosthoek a écrit : >> >> >>> Dotan Cohen wrote: >>> >>> >>> >>>> Right now Digikam has two modes: Viewing and Editing. It seems to me >>>> that there actually needs to be a third mode, Organizing, which would >>>> have less emphasis on things like zooming and panning but would have >>>> more emphasis on tagging, deleting, grouping (see bug #121310), filing >>>> into albums, and making little touchups like redeye removal. I find >>>> that the first time I go through new photos from the camera, I am >>>> organizing them and need these features to be readily available. >>>> However, the future times that I go through the photos my emphasis is >>>> on enjoying the photos, not on organizing them. >>>> >>>> What do you think? >>>> >>>> >>>> >>>> >>>> >>> I agree that it would be useful to have more flexible organising >>> capabilities in digikam, since it already is/appears to be a photo >>> management tool, I think it would already help a lot if digikam could >>> handle multiple selections in the directory/album tree for moving them >>> around. >>> >>> >>> >> Please add a wish in bko if there is not already one. >> >> >>> Since digikam relies a lot on storing stuff in a database (tags and >>> metadata), with this comes the burden of re-implementing common >>> filesystem tools in an accessible manner. (Unless Nepomuk is going to be >>> handling the database, but I don't like nepomuk) >>> >>> >>> >> I don't understand exactly what do you mean, which common filesystem >> tools do you need ? >> >> > I usually manage files and directories using basic shell commands, but > even in graphical tools there are advanced ways of managing directories. > I'd lile to batch-rename directories, move groups of directories at > once, etc. I know there are tools inside digikam to manipulate the > files, I'm not talking about those. Other tools I've mentioned above and > below. > As Digikam is based on the real directory structure, maybe you can manage directories using standard tools such as Dolphin, but still it would be nice to have such feature in Digikam itself. >>> I'd also like group renaming for directories and such. >>> >>> >> Please add a wish in bko if there is not already one. >> >> >>> More intelligent >>> matching of RAW files to their JPEG counterparts, or any image and their >>> derivatives (done by digikam or an external program like the gimp). >>> >>> >>> >>> >> There is already a wish about that in bko. >> >> > I know about bugs.kde.org, I didn't check before posting, is that a > no-no on this list? > >> >> >>> Cheers >>> >>> PS, off-topic, but I noticed that a lot of messages here go unanswered, >>> I don't think that's a good sign! >>> >>> >>> >> I think the message was unanswered because it was a general idea, with >> no precise thought about what to be done. If we are more precise we can >> start discussing the possible guis, and what people like and what people >> do not like. >> >> > > Well, this is a list called "digikam-users", IMO users should always get > an answer when they manage to find the mailinglist to post a problem. > The reply can be a semi-canned response pointing to bko, acknowledging > the problem or even better, providing a quick hint towards a solution. > No reply means ignoring a possible new user, friend, contributor, etc. > > Developers and alpha/beta users can handle a lot more terse responses, > users need some friendly pointers. > Sorry I did not mean one has to be not friendly, new users are always welcome, I just meant that I did not answer myself in the first place because I had no strong opinion about this. Cheers, Julien > Cheers > > Simon > _______________________________________________ > 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 |
Julien Narboux wrote:
> Simon Oosthoek a écrit : > > >> I know about bugs.kde.org, I didn't check before posting, is that a >> no-no on this list? >> >> > what is a no-no ? > Something that's "not done", a faux pas >>>> PS, off-topic, but I noticed that a lot of messages here go unanswered, >>>> I don't think that's a good sign! >>>> >>> I think the message was unanswered because it was a general idea, with >>> no precise thought about what to be done. If we are more precise we can >>> start discussing the possible guis, and what people like and what people >>> do not like. >>> >>> >>> >> Well, this is a list called "digikam-users", IMO users should always get >> an answer when they manage to find the mailinglist to post a problem. >> The reply can be a semi-canned response pointing to bko, acknowledging >> the problem or even better, providing a quick hint towards a solution. >> No reply means ignoring a possible new user, friend, contributor, etc. >> >> Developers and alpha/beta users can handle a lot more terse responses, >> users need some friendly pointers. >> >> > > Sorry I did not mean one has to be not friendly, new users are always > welcome, > I just meant that I did not answer myself in the first place because I > had no strong opinion about this. > This list has quite a lot of traffic and obviously there's regular visitors, developers and newcomers, all of them users. My observation was that often questions and "reports" of problems receive no reply from anyone, which gives the impression that digikam developers are not so much oriented towards users as to themselves. This may not be "true", but it's the impression I get. Cheers Simon _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
2010/3/18 Simon Oosthoek <[hidden email]>:
> Julien Narboux wrote: >> Simon Oosthoek a écrit : >> >> >>> I know about bugs.kde.org, I didn't check before posting, is that a >>> no-no on this list? >>> >>> >> what is a no-no ? >> > Something that's "not done", a faux pas >>>>> PS, off-topic, but I noticed that a lot of messages here go unanswered, >>>>> I don't think that's a good sign! >>>>> >>>> I think the message was unanswered because it was a general idea, with >>>> no precise thought about what to be done. If we are more precise we can >>>> start discussing the possible guis, and what people like and what people >>>> do not like. >>>> >>>> >>>> >>> Well, this is a list called "digikam-users", IMO users should always get >>> an answer when they manage to find the mailinglist to post a problem. >>> The reply can be a semi-canned response pointing to bko, acknowledging >>> the problem or even better, providing a quick hint towards a solution. >>> No reply means ignoring a possible new user, friend, contributor, etc. >>> >>> Developers and alpha/beta users can handle a lot more terse responses, >>> users need some friendly pointers. >>> >>> >> >> Sorry I did not mean one has to be not friendly, new users are always >> welcome, >> I just meant that I did not answer myself in the first place because I >> had no strong opinion about this. >> > Julian, I didn't mean to imply that you were being unfriendly ;-) > > This list has quite a lot of traffic and obviously there's regular > visitors, developers and newcomers, all of them users. My observation > was that often questions and "reports" of problems receive no reply from > anyone, which gives the impression that digikam developers are not so > much oriented towards users as to themselves. This may not be "true", > but it's the impression I get. To respond to all messages in this list is impossible. Developper use bugzilla. the advance is to preserve post to infinite instead some week for a mailing list. Information is shared between developpers and other users : it's public. We manage talk, history, and solution. It's a clean QA tool for developpers. A mailing is not a clean tool for developpers. It's the hell to manage in time. This is why developpers are not too active in this mailling. For small problem, it's fine, for indeep problems which need long reflexions, it's impossible to do. The solution is to use bugzilla instead. We are aware of users feedback of course. this is the goal of open source. This is is to share information between users as experience and feedback. It's not a developper room. Gilles Caulier > > Cheers > > Simon > _______________________________________________ > 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 |
Gilles Caulier wrote:
>> >> This list has quite a lot of traffic and obviously there's regular >> visitors, developers and newcomers, all of them users. My observation >> was that often questions and "reports" of problems receive no reply from >> anyone, which gives the impression that digikam developers are not so >> much oriented towards users as to themselves. This may not be "true", >> but it's the impression I get. >> > > To respond to all messages in this list is impossible. > For a single person it is, but lots of people are on the list, users could help each other too, by pointing to the bugzilla for problems/wishes that need the eyes of developers. This list appears to be used as a portal between users and developers only, not between users themselves. It would be nice if more advanced users help the newcomers to either get their problems fixed with using digikam, or to guide them towards b.kde.o But to summarise the rest of your response: use bugzilla at bugs.kde.org to get digikam developers attention. This is easy for anyone to use as reply for mails appearing to be bugreports or wishes ;-) Cheers Simon _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Simon Oosthoek-6
> Well, this is a list called "digikam-users", IMO users should always get
> an answer when they manage to find the mailinglist to post a problem. > The reply can be a semi-canned response pointing to bko, acknowledging > the problem or even better, providing a quick hint towards a solution. > No reply means ignoring a possible new user, friend, contributor, etc. > Well, I've filed or triaged well over 1200 bugs at BKO. I intend to file a feature request on this "organizing mode" but I wanted community feedback first. It would be a major new feature and instead of polluting the bug with arguments I was hoping to hear others opinions here. -- Dotan Cohen http://bido.com http://what-is-what.com _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
In reply to this post by Dotan Cohen
I did think the majority of postings here get at least one answer. I was going to reply to this one myself, but wanted a look at the current interface first, and didn't find the time (and still haven't).
-------------------------- Sent using BlackBerry ----- Original Message ----- From: Dotan Cohen <[hidden email]> To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]> Sent: Fri Mar 19 08:10:01 2010 Subject: Re: [Digikam-users] Organizing mode > Well, this is a list called "digikam-users", IMO users should always get > an answer when they manage to find the mailinglist to post a problem. > The reply can be a semi-canned response pointing to bko, acknowledging > the problem or even better, providing a quick hint towards a solution. > No reply means ignoring a possible new user, friend, contributor, etc. > Well, I've filed or triaged well over 1200 bugs at BKO. I intend to file a feature request on this "organizing mode" but I wanted community feedback first. It would be a major new feature and instead of polluting the bug with arguments I was hoping to hear others opinions here. -- Dotan Cohen http://bido.com http://what-is-what.com _______________________________________________ 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 |
Free forum by Nabble | Edit this page |