Digikam and the KDE
Locked
12
12
 
|
On Sunday 09 October 2011 14:12:26 Karl Günter Wünsch wrote:
... > Digikam will be another casualty of the switch as Akonadi and > Nepomuk integration scatters information all over the place (or is lost on > a regular basis when one of their databases acts up which they often do) - > so having a more stable, dedicated basis for storage (which isn't messed up > by the rest of the desktop environment on a regular basis) would be highly > desireable, as it currently stands I'll just switch for my organizing needs > to another program... Digikam 2.1.0 still has using Nepomuk as an option, you can choose - to store data into Nepomuk - to read data from Nepomuk separately in the configuration dialog (metadata section) Remco _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Anders Lund
On Sunday 09 October 2011, Anders Lund wrote:
> Difficult/new things are hard to achieve. There is nothing new about Akonadi or Nepomuk - but they are getting further and further away from ever becoming stable and usable for the average user. The more programs use these the less stable they become and the more resources are wasted on a database server (or two) just to support features almost nobody beyond the developers sees any sense in. > Not being able to use that lattest > kdepim myself, I look forward to doing that, as much as I enjoy the evolving > benefits of nepomuk. I agree that there is still work to be done before it > works, but the promises makes it worth while :) It's going the direction of mandatory bloat - and all it promises to me only is even more bloat and data insecurity. > Already you do not need very much > in order to build kde applications, and digikam does not require anything but > what it uses. I would like an option to have digikam not to include face detection (pure bloat, useless for 100% of my or my wife's pictures) and have it not use either Nepomuk or Akonadi - those two I have never had any positive experience yet, only the need to delete corrupted databases because another software trashed the structure or the database server was unhappy about an update (or lack of update)... > > If you do not want to go through the trouble of building the software on your > own but still want to stay up to date, use a system/distro that does ;) Akonadi and Nepomuk are IMHO broken by design - I want to be able to separate the information which is important to me (for example data from digikam) from data which is totally unimportant (some odd cache which can easily be regenerated) which is practically impossible with those two components... The worst offender isn't digikam, it's kmail 2 there the brokenness of the design extends to losing emails while downloading them from pop3 servers as the new data flow first downloads the email into the transient database cache and from that writes the message to the disk - when there is the slightest glitch in this chain the mail is trapped in the database (which eventually get's wiped out because of the ever recurring problems with the databases) and lost. So I would dearly love a digikam without any (even build time) dependency on either Nepomuk or Akonadi - not just an option to not use them, I want to totally disable Nepomuk or Akonadi on my system. So next time I get around to tinker with my system I will delete all programs which are dependent on these two components and whatever is gone is gone and I will look for alternatives... regards Karl Günter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Le 09/10/2011 15:05, Karl Günter Wünsch a écrit :
> Akonadi and Nepomuk are IMHO broken by design may be use xfce and digikam? unselect the kipi plugin you don't need and voilà > worst offender isn't digikam, it's kmail 2 there the brokenness of the design > extends to losing emails while downloading them from pop3 servers use imap? jdd -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pigeons_music http://www.youtube.com/watch?v=FGgv_ZFtV14 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Sunday 09 October 2011, jdd wrote:
> may be use xfce and digikam? unselect the kipi plugin you don't need > and voilà I'll see if digikam still compiles without Akonadi and Nepomuk being available at all... It's worse enough that face detection can't be disabled outright in a similar way! > > > worst offender isn't digikam, it's kmail 2 there the brokenness of the design > > extends to losing emails while downloading them from pop3 servers > > use imap? IMap is not an option for various reasons, so kmail 2 is the first one to go to be replaced with Thunderbird... But that's off topic and not part of the discussion here. regards Karl Günter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Karl Günter Wünsch
Am Sonntag, 9. Oktober 2011 schrieb Karl Günter Wünsch:
> On Sunday 09 October 2011, Anders Lund wrote: > > Difficult/new things are hard to achieve. > > There is nothing new about Akonadi or Nepomuk - but they are > getting further and further away from ever becoming stable and > usable for the average user. The more programs use these the less > stable they become and the more resources are wasted on a database > server (or two) just to support features almost nobody beyond the > developers sees any sense in. > > > Not being able to use that lattest > > kdepim myself, I look forward to doing that, as much as I enjoy > > the evolving benefits of nepomuk. I agree that there is still > > work to be done before it works, but the promises makes it worth > > while :) > > It's going the direction of mandatory bloat - and all it promises > to me only is even more bloat and data insecurity. > > > Already you do not need very much > > in order to build kde applications, and digikam does not require > > anything > > but > > > what it uses. > > I would like an option to have digikam not to include face > detection (pure bloat, useless for 100% of my or my wife's > pictures) This is entirely against open source strategy: Release if early and let it evolve. I remember the time where DK was almost unusable. Does this mean not to release it at all? May be in two or four years face recognition is one of the killer features but to get it there you have to start somewhere. If it does not work for you don't use it. > and have it not use either Nepomuk or Akonadi - those > two I have never had any positive experience yet, only the need to > delete corrupted databases because another software trashed the > structure or the database server was unhappy about an update (or > lack of update)... I never had such problems with nepomuk. I tried the DK integration and it worked flawless. As I don't need it I switched it off. The Akonadi stuff is a different beast. The idea is great but I don't see the benefit for DK. > > > If you do not want to go through the trouble of building the > > software on > > your > > > own but still want to stay up to date, use a system/distro that > > does ;) > > Akonadi and Nepomuk are IMHO broken by design - I want to be able > to separate the information which is important to me (for example > data from digikam) from data which is totally unimportant (some > odd cache which can easily be regenerated) which is practically > impossible with those two components... The worst offender isn't > digikam, it's kmail 2 there the brokenness of the design extends > to losing emails while downloading them from pop3 servers as the > new data flow first downloads the email into the transient > database cache and from that writes the message to the disk - when > there is the slightest glitch in this chain the mail is trapped in > the database (which eventually get's wiped out because of the ever > recurring problems with the databases) and lost. So I would dearly > love a digikam without any (even build time) dependency on either > Nepomuk or Akonadi - not just an option to not use them, I want to > totally disable Nepomuk or Akonadi on my system. So next time I > get around to tinker with my system I will delete all programs > which are dependent on these two components and whatever is gone > is gone and I will look for alternatives... Hm, afaik DK does not need nepomuk and akonadi if you compile it yourself. Martin > regards > Karl Günter > _______________________________________________ > 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 Sunday 09 October 2011, Martin (KDE) wrote:
> This is entirely against open source strategy: Release if early and > let it evolve. > I remember the time where DK was almost unusable. Does > this mean not to release it at all? May be in two or four years face > recognition is one of the killer features but to get it there you have > to start somewhere. If it does not work for you don't use it. It also is a normal open source strategy to have rather controversial features - especially if they depend on instable and pre beta libraries (which IMHO is the state of the face detection libraries) - to be optional so that you can leave them out. I can't get one of the base libraries on which face detection depends to compile on my system - so I have become accustomed to rip it out of digikam whenever I compile a new version. It would really be easy to make it a compile time option but my offer to create a patch was declined arguing that it is impossible to compile digikam without face detection... regards Karl Günter _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Karl Günter Wünsch
2011/10/9 Karl Günter Wünsch <[hidden email]>:
> On Sunday 09 October 2011, todd rme wrote: >> You are saying Digikam developers should >> have to do that all over again, AND re-implement all the stuff that >> the KDE developers had already done, which means it would take even >> longer. > Digikam will be another casualty of the switch as Akonadi and > Nepomuk integration scatters information all over the place (or is lost on a > regular basis when one of their databases acts up which they often do) - so > having a more stable, dedicated basis for storage (which isn't messed up by > the rest of the desktop environment on a regular basis) would be highly > desireable, as it currently stands I'll just switch for my organizing needs to > another program... Your understanding of the situation is completely backwards. The whole point of both nepomuk and akonadi is "having a more stable, dedicated basis for storage". The situation before, and still the situation to an extent, is that KDE "scatters information all over the place". One of the reasons for the switch to nepomuk was to have a central storage location for all metadata information. So you are basically asking to replace nepomuk...with something like nepomuk. The same is the case for akonadi. Previously, PIM data was scattered all over the place, both on the filesystem and between applications. Akonadi provides a central storage location for all PIM-related information. The implentation may not be perfect yet, they are trying to do something no one has tried to do before and it is taking some work, but what you are asking for is exactly what they are intended to do. You are not going to find what you are asking for on any other desktop environment or PIM suite, period. -Todd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Le 09/10/2011 16:16, todd rme a écrit :
> whole point of both nepomuk and akonadi is "having a more stable, > dedicated basis for storage". if so, why is nepomuk labelled "search on the desktop"? jdd -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pigeons_music http://www.youtube.com/watch?v=FGgv_ZFtV14 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On Søndag den 9. oktober 2011, jdd wrote:
> Le 09/10/2011 16:16, todd rme a écrit : > > whole point of both nepomuk and akonadi is "having a more stable, > > dedicated basis for storage". > > if so, why is nepomuk labelled "search on the desktop"? Nepomuk deals with metadata + file indexing. All documents can be tagged/rated/commented, like we can do in digikam in fact, and metadata is indexed from - potentially - all file types with nepomuk, similar to what digikam does with images. Files containing text is also indexed for text search. The difference from digikam is that metadata known to nepomuk is available to any application interrested, through a standard interface, so that metadata produced by one application is available for others. With digikam, this means that if metadata is shared through nepomuk, they can be used for example in file manager or other image viewers etc. Right now, to send images pr email for example, you would select them in digikam and then use the built in send function. With nepomuk, you could go the other way round and search for images with a certain tag or other metadata from the attach file function of kmail. Etc etc ... -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
A lots of people clam that digiKAm is too relevant of KDE and you want
to ncrease again the depency ? We have worked hvery hard to make a database interface delegate to image anagement. I won't to ask to others developers that we trash all this work to replace it by Nepomuk stuff. I don't have any idea about Nepomuk stability... I know the status of digiKam DB interface, and it's not perfect. Marcel as written an interface between digiKam DB and Nepomuk. It's enough. If somebody want to improve it, why not, but we will never replace digiKam DB by Nepomuk. It's just my developper viewpoint of course... Gilles Caulier 2011/10/9 Anders Lund <[hidden email]>: > On Søndag den 9. oktober 2011, jdd wrote: >> Le 09/10/2011 16:16, todd rme a écrit : >> > whole point of both nepomuk and akonadi is "having a more stable, >> > dedicated basis for storage". >> >> if so, why is nepomuk labelled "search on the desktop"? > > Nepomuk deals with metadata + file indexing. All documents can be > tagged/rated/commented, like we can do in digikam in fact, and metadata is > indexed from - potentially - all file types with nepomuk, similar to what > digikam does with images. Files containing text is also indexed for text > search. > > The difference from digikam is that metadata known to nepomuk is available to > any application interrested, through a standard interface, so that metadata > produced by one application is available for others. > > With digikam, this means that if metadata is shared through nepomuk, they can > be used for example in file manager or other image viewers etc. Right now, to > send images pr email for example, you would select them in digikam and then > use the built in send function. With nepomuk, you could go the other way round > and search for images with a certain tag or other metadata from the attach > file function of kmail. Etc etc ... > > > > -- > Anders > _______________________________________________ > 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 Søndag den 9. oktober 2011, Gilles Caulier wrote:
> A lots of people clam that digiKAm is too relevant of KDE and you want > to ncrease again the depency ? Absolutely not, I simply tried do explain the idea of nepomuk. > We have worked hvery hard to make a database interface delegate to > image anagement. I won't to ask to others developers that we trash all > this work to replace it by Nepomuk stuff. > > I don't have any idea about Nepomuk stability... I know the status of > digiKam DB interface, and it's not perfect. So far, digikam is faster and more stable for filtering, taggning and more. In fact I miss the functionality of digikam when using the current nepomuk tagging/commenting/rating interface as found in dolphin or gwenview. > Marcel as written an interface between digiKam DB and Nepomuk. It's > enough. If somebody want to improve it, why not, but we will never > replace digiKam DB by Nepomuk. Noone asks you to. I think possibly offering the value added to an image collection by using digikam through nepomuk - as the interface does - might be added value for kde users. I for example would not find the ability to find an image based on digikam tags or rating from another application a bad thing at all. I do think in fact making features optional is good, since we do not all use the same bits and pieces of digikam, which have many different offerings. Maybe making some things optional can also benefit users by allowing a less crowded ui. > It's just my developper viewpoint of course... > > Gilles Caulier -- Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |