GNOME.org
 

Re: Introducing Photos

On 05/10/2012 03:47 AM, Debarshi Ray wrote:

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.
I think the photo applications around GNOME are one of the most re-invented of all :) 


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.
I will admit, I was a little disappointed with the SQLite dependency recently too. Mostly because I moved my photos to a server (from a USB external SSD). Of course, I likely could have fixed up the db myself, but then I realised that storing photos by date seems quite rudimentary. In a lot of cases, events occur over > 1 day and I found myself wishing Shotwell had created $year/$event/ directory structures (or something like that) so I could easily navigate the file system there AND when using tools like Rygel or other UPNP servers, the folder structure would make complete sense to navigate there too. As it is right now, finding images on the disk is easy enough in Shotwell, but not otherwise. 


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?
With Tracker, I think it is a useful tool but what makes life harder for us as a community, is that we're not selling a complete sealed solution like Apple are. With Apple, you have iTunes and a way of handling ALL media. This is useful because then your devices keep media in the *right places*. With Tracker, we have to guess (to some extent) and it can be hit-and-miss. For example, recently we had a case where someone was downloading a lot of kernel tarballs to the XDG Downloads area and we (of course) index that recursively by default. That's not a usual user case, but it is noticed. Apple doesn't have this problem. 

(it has been suggested that we avoid indexing source code by default)
I've also seen other issues recently on Fedora (more so) and Ubuntu where Tracker extractors or extensions (like GStreamer or the GNOME Shell extension 'tracker-search') don't work because distros aren't providing all the packages (GStreamer backends or GIR) by default to help Tracker operate to its potential. This looks bad for Tracker and I think what we're still doing (even now) is improving the defaults to help distros avoid complaints from users (the SCHED_IDLE situation is a classic case).
There is also a divide between some community members as to how Tracker should operate, either: 

a) It's told what to index and when (there are some APIs for this)
b) It's monitoring and automated (as is currently done)


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?
On the UI side, I like both Shotwell and the new mockups for gnome-photos. I think the later has more of the Apple look/feel, but I wonder how far shotwell is from replicating that. 


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.
Interestingly, I think it's likely we will see hand held cameras slowly die out over the next few years with the increasing advance in technology around camera phones and smart phones shipping those. The Samsung Galaxy S III has an 8 mega-pixel camera on it (that's what my old Canon 350D had not long ago).
With that in mind, it's likely people will increasingly use online services to share images, not sync to their machines. Though I am one of those people that loves Shotwell and the feature to import images because I like to keep all mine on my own server here at home. I think you need that service too. 


I'd love to see us
work together rather than embarking on separate efforts.


I would too.

--
Regards,
Martyn

Founder and CEO of Lanedo GmbH.
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]