> hello from Yorba, makers of Shotwell. Hi, Adam! We met in Berlin at the Collabora party during the Desktop Summit. You probably remember me as one of the authors of Solang. For those who don't know Solang (http://git.gnome.org/browse/solang) was a photo manager that I wrote during the dying days of GNOME 2.x. It used Tracker >= 0.7.x as its meta-data store and GEGL (a bit too ahead of its time, maybe) for editing. The viewing, tagging, searching was functional, but the editing part was quite rudimentary when I stopped working on it for various reasons. > Shotwell's goals are exactly those laid out in the design document below: > to be a lightweight, elegant photo browser/viewer for GNOME supporting > basic manipulation, easy photo sharing/publishing, slideshows and so on. > ??If the GNOME team feels that Shotwell has failed in meeting those goals, > we're highly interested in discussing how Shotwell could be enhanced or > improved to get there. Well, one thing, I guess we all agree, is that reinventing the wheel is bad. Especially so for a project like ours. Having said that, one thing which I have always complained about Shotwell was the fact that it asks me to import my photos into what looks like a private SQLite database. A quick "git grep sqlite" does reveal some dependency on it. You would remember that I discussed with you and Jim Nelson in Berlin about the possibility of using Tracker instead. At that point you had reservations about Tracker and were reluctant to use it. Tracker is a complex beast and there are consequences in having a hard dependency on it. But today, the Documents application has a hard dependency on Tracker. It uses it for querying documents, marking them as favourite, and so on. And in many ways, the Photos application is very closely related to Documents. So, while one can find ways to implement the same using a different technology, does it really make sense to diverge so much in the underlying implementation for these core applications? Or should we try to stay as close to each other possible and consolidate on the underlying foundations? Secondly, Boxes, Documents and Photos (can potentially) share a lot of widgets. Therefore, for these reasons, if you look at the gnome-photos tree, it is almost a clone of the gnome-documents application. So from Shotwell's point of view, would it make sense to replace its existing SQLite store and UI? Would it not be as good as writing from scratch? However, one thing that I really like about Shotwell is its editing controls. This is why I got the idea that Shotwell aims to fill the gap between GIMP/Darktable/Rawstudio on one side and a very elementary photo application on the other. In fact, the designs for Photos has a "Open with $PHOTOLAB" option. So now, that there seems to have been some kind of misunderstanding, all this is up for discussion. > Integration with GNOME has always been a top priority for us and we're open > to prioritizing development tasks that core GNOME developers feel are > important. I am curious about the way you embed Flickr's API_SECRET in FlickrPublishing.vala. Ofcourse, what else can you do? Even in a proprietary application the key has to be in a form that is readable by the binary. But is Flickr happy about this? The reason I am asking is that various people have requested adding support for Flickr in GNOME Online Accounts. However, unless we have a clear answer about this issue, GNOME, as a project, can not really recommend its downstreams to just slip in a key somewhere in the binary package. > I'd love to see us > work together rather than embarking on separate efforts. True. So, is Geary (http://redmine.yorba.org/projects/geary/wiki) going to be the new Mail (https://live.gnome.org/Design/Apps/Mail) application for GNOME? :-) Happy hacking, Debarshi
Attachment:
pgpUdkZeSWzzE.pgp
Description: PGP signature