Re: Introducing Photos
On 05/11/2012 11:30 AM, Michael Biebl wrote: 2012/5/11 Martyn Russell: On 05/10/2012 08:24 PM, John Stowers wrote: Correct me if I am wrong, but I thought GNOME only depended on tracker-store and not the indexer? The two are in the same tarball release, so it would be up to packagers to separate them and AFAIK, that's not been the case at all (at least on Fedora and Ubuntu). Hey Michael, This is not quite true. Ubuntu is using the Debian package, and in Debian I've split the miners into separate packages. I.e., you can use tracker-store without having the filesystem miner installed. Interesting, I didn't know. Thanks for the clarification. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
2012/5/11 Martyn Russell : > On 05/10/2012 08:24 PM, John Stowers wrote: >> >> Correct me if I am wrong, but I thought GNOME only depended on >> tracker-store and not the indexer? > > > The two are in the same tarball release, so it would be up to packagers to > separate them and AFAIK, that's not been the case at all (at least on Fedora > and Ubuntu). This is not quite true. Ubuntu is using the Debian package, and in Debian I've split the miners into separate packages. I.e., you can use tracker-store without having the filesystem miner installed. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On 05/10/2012 08:24 PM, John Stowers wrote: The point is that we already use Tracker in GNOME (Documents and Boxes depend on it) and I don't see any reason for existing apps to stop using it and while we could compromise on some code-duplication, its certainly a big issue if there is two entities harvesting metadata from tons of photos on every GNOME installation. Correct me if I am wrong, but I thought GNOME only depended on tracker-store and not the indexer? The two are in the same tarball release, so it would be up to packagers to separate them and AFAIK, that's not been the case at all (at least on Fedora and Ubuntu). If GNOME now depends on the indexer, that is incredibly good news. Perhaps this cycle we might get useful search in GNOME; in nautilus and the shell at least We've been pushing integration in various ways for a while. I recently helped the tracker-search GNOME shell extension maintainer improve his work to offer much better sorting of results... see: https://github.com/cewee/tracker-search Really nice to be able to find a document out of thousands in a seconds from the shell. We only really have tagging support in Nautilus, I would like to have replaced search by now, but it's just not happened yet. I have been using tracker happily for years to manage large collections of papers and documents and could not live without it. Great to hear :) -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
> > The point is that we already use Tracker in GNOME (Documents and Boxes > depend on it) and I don't see any reason for existing apps to stop > using it and while we could compromise on some code-duplication, its > certainly a big issue if there is two entities harvesting metadata > from tons of photos on every GNOME installation. Correct me if I am wrong, but I thought GNOME only depended on tracker-store and not the indexer? If GNOME now depends on the indexer, that is incredibly good news. Perhaps this cycle we might get useful search in GNOME; in nautilus and the shell at least I have been using tracker happily for years to manage large collections of papers and documents and could not live without it. John ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On Thu, 2012-05-10 at 19:10 +0100, Martyn Russell wrote: > We would gladly ONLY index data that's of interest to the user/desktop > applications if you could come up with heuristics for that. I touched on > that somewhat in my response earlier. Also, having superfluous coverage > is better than wondering why a file is not indexed; we get more reports > of the former generally. > > Perhaps we do approach this the wrong way (detecting files > created/updated instead of asking apps to report files they're > interested in), but one had to come before the other and you don't get > community support/adoption without a working solution first. We're going off on a tangent, and I'm not sure I have a good answer for this. Applications telling you which types of file they want to have the metadata indexed for might be one way. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
It is my understanding that Jon had discussions with the developers of these
applications, and for various reasons it was decided that writing something
from scratch is better. For EoG and GThumb the reason given was that their
maintainers did not have time to work on a major redesign, and for Shotwell it
was an architectural issue with the program.
Please feel free to correct me if I am misrepresenting something. :-)
Debarshi,
Can you repurpose gThumb to meet your goals? It meets many (most?) of
your goals already, and lives in the gnome ecosystem (bugzilla, git,
etc). It has a plugin system for experimenting with new features
(including new metadata sources). It already has
Flickr/Facebook/whatever uploading. The sidebar already groups things
into a tree of real filesystems and devices, plus artificial groupings
("Catalogs", "Selections"). It already has editing and printing. It has
no sqlite dependency.
Mostly, the effort would be to add the shell integration bits, and a
slicker gnome-shell-ish UI. The basic image-handling framework is there
already.
The primary maintainer, Paolo, indicated that he didn't have time to do
the work himself [1], but if you're keen on doing the work, I doubt he'd
be opposed to a "next generation" unstable branch...
This is meant as a helpful suggestion, rather than as stop-energy or
bike-shedding :-)
- Mike
[1] http://mail.gnome.org/archives/gthumb-list/2011-December/msg0.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On 05/10/2012 06:32 PM, Bastien Nocera wrote: On Thu, 2012-05-10 at 20:14 +0300, Zeeshan Ali (Khattak) wrote: On Thu, May 10, 2012 at 7:50 PM, Alberto Ruiz wrote: Shotwell is widely deployed and used, it has a team of people working on it, and a commercial backer. These are VERY important things, prolly the most important things to take into account, you worry too much about the data store technologies, Tracker is great, but it is by no means the only accepted data store in the desktop. The point is that we already use Tracker in GNOME (Documents and Boxes depend on it) and I don't see any reason for existing apps to stop using it and while we could compromise on some code-duplication, its certainly a big issue if there is two entities harvesting metadata from tons of photos on every GNOME installation. That's not a good enough reason. Sure it would be nicer if all the apps used the same technology, but it shouldn't get in the way of producing great apps with a great experience. As for the "two entities harvesting metadata", does it make sense for Tracker to index things that nothing is interested in? I'll let you discuss this amongst yourselves ;) We would gladly ONLY index data that's of interest to the user/desktop applications if you could come up with heuristics for that. I touched on that somewhat in my response earlier. Also, having superfluous coverage is better than wondering why a file is not indexed; we get more reports of the former generally. Perhaps we do approach this the wrong way (detecting files created/updated instead of asking apps to report files they're interested in), but one had to come before the other and you don't get community support/adoption without a working solution first. -- Regards, Martyn Founder and CEO of Lanedo GmbH. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
Hi, On Thu, May 10, 2012 at 12:50 PM, Alberto Ruiz wrote: ... > That's not a reason at all, Yorba seems open to work on making Shotwell more > GNOME 3 friendly... so those widgets can be shared anyway > >> >> 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? > > > No. > > That makes as much sense as saying that Epiphany should have been written > from scratch when the "Web" designs were proposed. We had a browser, a new > design, and developers happy to follow those deisgns. Sorry, that is totally irrelevant. The real story is that we had folks show up, say they were excited about the design, have the chops to pull it off, and want to work closely with us in the open to make it real. How they went about coding it was entirely up to them. They chose the most effective way for themselves. That happened to be reusing code - as it often does. > Writing software from scratch is almost always a bad idea: > http://www.joelonsoftware.com/articles/fog69.html Which is why it was pointed out that Photos has/can/will reuse a lot of existing code (from Documents, eog, etc). This is particularly important for allowing us to experiment with our design patterns. Despite what you may have heard from some folks not involved in GNOME design, we have been working very hard on this for quite some time now. The patterns emerge as we explore solving new design problems. This is why it is important to explore a variety of different application types. And to have a high bandwidth, trusting, fluid, and reactive relationship with the developers. See https://live.gnome.org/Design/Apps/ for more examples of these apps we want to experiment with. > Shotwell is widely deployed and used, it has a team of people working on it, > and a commercial backer. These are VERY important things, prolly the most > important things to take into account, you worry too much about the data > store technologies, Tracker is great, but it is by no means the only > accepted data store in the desktop. Sure, Shotwell is great. No denying that. I recommend you use it. What we should not be doing, however, is discouraging new work by highly motivated and talented community members like Debarshi just because there is another app out there in the world. He's excited about the designs, wants to work in the open, understands the GNOME way, and is really excellent to work with. No one else has stepped up to make Photos yet. Regarding the data formats and such. In some cases it doesn't make a bit of difference. But there are design implications. For example, we need the core apps in the finding and reminding set to work very closely together. * The Web view must be able to save photos in the Photos storage/library (https://live.gnome.org/Design/Apps/Web#Tentative_Design). * Content selection must be able to access the Photos storage/library (https://live.gnome.org/GnomeOS/Design/Whiteboards/ContentSelection#Tentative_Design) > If Yorba is open to follow the designs from the GNOME design team, I can't > see any reason why we shouldn't go that way. IMHO is the quickest and more > sustainable path to have a great photo browsing experience for GNOME 3. I have been talking to the Yorba folks for a few years now. In fact, Matthias and I were very early adopters of Shotwell and provided some of the earliest patches and shipped it (in Fedora) before anyone else. I think it is an open question whether the Shotwell team is even interested in making Shotwell into Photos, making a core GNOME app, doing design in the open, allowing our translation and bug teams to do their thing. I would love to see that happen. However, I can certainly see why it would be very challenging to try to change the direction, design, and architecture of a stable and widely deployed app. I have been involved in way too many of those kind of direction changes to recommend it to anyone. It is much better in my opinion to reuse the code where it makes sense and start off on a new direction without the fetters of past expectations. And most importantly be free to fail. With Photos we can be free to fail, faster. That said, I love the work the Yorba team has been doing and I applaud them for targeting the GNOME user experience. That's good for everyone. I would love to work more closely with them. But, obviously, that is really up to them. Regardless of what decisions they make regarding Shotwell I hope to work more closely with this awesome team. In the open :) But either way I'm happy to just have them making great apps for GNOME. Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On Thu, 2012-05-10 at 20:14 +0300, Zeeshan Ali (Khattak) wrote: > On Thu, May 10, 2012 at 7:50 PM, Alberto Ruiz wrote: > > Shotwell is widely deployed and used, it has a team of people working on it, > > and a commercial backer. These are VERY important things, prolly the most > > important things to take into account, you worry too much about the data > > store technologies, Tracker is great, but it is by no means the only > > accepted data store in the desktop. > > The point is that we already use Tracker in GNOME (Documents and Boxes > depend on it) and I don't see any reason for existing apps to stop > using it and while we could compromise on some code-duplication, its > certainly a big issue if there is two entities harvesting metadata > from tons of photos on every GNOME installation. That's not a good enough reason. Sure it would be nicer if all the apps used the same technology, but it shouldn't get in the way of producing great apps with a great experience. As for the "two entities harvesting metadata", does it make sense for Tracker to index things that nothing is interested in? I'll let you discuss this amongst yourselves ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On Thu, May 10, 2012 at 7:50 PM, Alberto Ruiz wrote: > Shotwell is widely deployed and used, it has a team of people working on it, > and a commercial backer. These are VERY important things, prolly the most > important things to take into account, you worry too much about the data > store technologies, Tracker is great, but it is by no means the only > accepted data store in the desktop. The point is that we already use Tracker in GNOME (Documents and Boxes depend on it) and I don't see any reason for existing apps to stop using it and while we could compromise on some code-duplication, its certainly a big issue if there is two entities harvesting metadata from tons of photos on every GNOME installation. > If Yorba is open to follow the designs from the GNOME design team, I can't > see any reason why we shouldn't go that way. IMHO is the quickest and more > sustainable path to have a great photo browsing experience for GNOME 3. +1 and its really nice to see that Yorba is very serious about GNOME integration. Having said that I do feel that they need to do a bit more on this front. For starters they really should use our infra (bugzilla, git, mailing-list etc). -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
2012/5/9 Debarshi Ray > > 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. > That's not a reason at all, Yorba seems open to work on making Shotwell more GNOME 3 friendly... so those widgets can be shared anyway > 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? > No. That makes as much sense as saying that Epiphany should have been written from scratch when the "Web" designs were proposed. We had a browser, a new design, and developers happy to follow those deisgns. Writing software from scratch is almost always a bad idea: http://www.joelonsoftware.com/articles/fog69.html Shotwell is widely deployed and used, it has a team of people working on it, and a commercial backer. These are VERY important things, prolly the most important things to take into account, you worry too much about the data store technologies, Tracker is great, but it is by no means the only accepted data store in the desktop. If Yorba is open to follow the designs from the GNOME design team, I can't see any reason why we shouldn't go that way. IMHO is the quickest and more sustainable path to have a great photo browsing experience for GNOME 3. -- Cheers, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
On Thu, 2012-05-10 at 02:47 +, Debarshi Ray wrote: > 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? Shotwell's database is presumably optimized for what Shotwell needs to do. Tracker, as a generic metadata storage, could index that via an appropriate plugin and mirror Shotwell's metadata in the Tracker DB. As for the user interface, Shotwell's *works* right now and has its own assumptions and reasons. The design page for Photos doesn't say much about the intended behavior of the program, yet. As far as I can tell, that page has mockups for the toplevel views - the first view in the "one window drilldown" pattern [1]. However, there is no description of the levels below that one. What happens when you select an Album (kind of like an Event in Shotwell's parlance)? Do you get shown the same as for Places or People? Could those be implemented just with Shotwell's concept of tags, some face recognition, and some geographic info? (What happens when your photos don't have GPS data and you select Places?) Is the Photos view a timeline of everything? Why are the connected devices like phones and cameras shown in the Albums, and what happens when you select them? If the design just hasn't contemplated those things yet, it's perfectly fine, of course - it's pending work. But you'd probably get something working much faster by refactoring Shotwell's code and exploring a new toplevel UI for it, than by writing everything from scratch. (By the way, also check out the comparisons and sub-patterns in Jenifer Tidwell's "Picture Manager" pattern [2].) [1] http://designinginterfaces.com/patterns/one-window-drilldown/ [2] http://designinginterfaces.com/patterns/picture-manager/ Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
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
Re: Introducing Photos
> 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 pgpmatbT8e8XY.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
A quick followup: in my last post I didn't mean to accuse the GNOME design team of being uncooperative. In fact, we have had some past discussions about this in which we've realized that there are differences between Shotwell today and the vision in the GNOME Photos design document, both in the underlying data model and in the user interface. I've just now been in touch with Jon McCann, who explained that he thought we had concluded together that Shotwell was too different and that GNOME Photos should be a separate app. This might have been a misunderstanding, since I think it's not yet clear whether these programs should be separate. We'll discuss this more soon. Debarshi, you're certainly welcome to be part of that discussion. adam On Wed, May 9, 2012 at 2:11 AM, Adam Dingle wrote: Debarshi, hello from Yorba, makers of Shotwell. 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. 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. If it's felt that some features in Shotwell are unnecessary for a basic photo program, we're also open to factoring those out of the base program into plugins. We have an active development team and an enthusiastic user community. I'd love to see us work together rather than embarking on separate efforts. adam On Fri, 4 May 2012 15:24:38, Debarshi Ray wrote: Hello everybody! Around 10 days ago I started implementing Photos as laid out in these designs: https://live.gnome.org/Design/Apps/Photos The Git tree is at: http://git.gnome.org/browse/gnome-photos Currently the application does not do much other than showing a blank window, but most of the underlying plumbing is in place and from here on I expect the program to start becoming useful. A guiding principle of mine has been to share as much of the UI code and the basic structure of the application with Documents. Documents and Photos have a lot in common, and even though one is not going to be a clone of the other, it makes sense not to reinvent the wheel. Why u no like Javascript?! -- I toyed with the idea of writing Photos in Javascript. However, after spending an evening fighting with a Python 3 / gobject-introspection based application and failing to get anywhere, and the fact that I am not familiar with all the ins and outs of GJS, I decided to stick with something that I know inside out. Having said that, the custom widgets written for Documents are written in C, so we just copy them over into the Photos tree. Also, the relevant widgets from Eye of GNOME, if required. This brings us to ... Eye of GNOME, GThumb or Shotwell It is my understanding that Jon had discussions with the developers of these applications, and for various reasons it was decided that writing something from scratch is better. For EoG and GThumb the reason given was that their maintainers did not have time to work on a major redesign, and for Shotwell it was an architectural issue with the program. Please feel free to correct me if I am misrepresenting something. :-) Future plans At the moment I am not going to push Photos as a widely publicized feature for GNOME 3.6, but I do expect it to be functional in a "preview release" sort of way. Will keep you informed as things unfold. Happy hacking, Debarshi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Introducing Photos
Debarshi, hello from Yorba, makers of Shotwell. 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. 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. If it's felt that some features in Shotwell are unnecessary for a basic photo program, we're also open to factoring those out of the base program into plugins. We have an active development team and an enthusiastic user community. I'd love to see us work together rather than embarking on separate efforts. adam On Fri, 4 May 2012 15:24:38, Debarshi Ray wrote: Hello everybody! Around 10 days ago I started implementing Photos as laid out in these designs: https://live.gnome.org/Design/Apps/Photos The Git tree is at: http://git.gnome.org/browse/gnome-photos Currently the application does not do much other than showing a blank window, but most of the underlying plumbing is in place and from here on I expect the program to start becoming useful. A guiding principle of mine has been to share as much of the UI code and the basic structure of the application with Documents. Documents and Photos have a lot in common, and even though one is not going to be a clone of the other, it makes sense not to reinvent the wheel. Why u no like Javascript?! -- I toyed with the idea of writing Photos in Javascript. However, after spending an evening fighting with a Python 3 / gobject-introspection based application and failing to get anywhere, and the fact that I am not familiar with all the ins and outs of GJS, I decided to stick with something that I know inside out. Having said that, the custom widgets written for Documents are written in C, so we just copy them over into the Photos tree. Also, the relevant widgets from Eye of GNOME, if required. This brings us to ... Eye of GNOME, GThumb or Shotwell It is my understanding that Jon had discussions with the developers of these applications, and for various reasons it was decided that writing something from scratch is better. For EoG and GThumb the reason given was that their maintainers did not have time to work on a major redesign, and for Shotwell it was an architectural issue with the program. Please feel free to correct me if I am misrepresenting something. :-) Future plans At the moment I am not going to push Photos as a widely publicized feature for GNOME 3.6, but I do expect it to be functional in a "preview release" sort of way. Will keep you informed as things unfold. Happy hacking, Debarshi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Introducing Photos
Hello everybody! Around 10 days ago I started implementing Photos as laid out in these designs: https://live.gnome.org/Design/Apps/Photos The Git tree is at: http://git.gnome.org/browse/gnome-photos Currently the application does not do much other than showing a blank window, but most of the underlying plumbing is in place and from here on I expect the program to start becoming useful. A guiding principle of mine has been to share as much of the UI code and the basic structure of the application with Documents. Documents and Photos have a lot in common, and even though one is not going to be a clone of the other, it makes sense not to reinvent the wheel. Why u no like Javascript?! -- I toyed with the idea of writing Photos in Javascript. However, after spending an evening fighting with a Python 3 / gobject-introspection based application and failing to get anywhere, and the fact that I am not familiar with all the ins and outs of GJS, I decided to stick with something that I know inside out. Having said that, the custom widgets written for Documents are written in C, so we just copy them over into the Photos tree. Also, the relevant widgets from Eye of GNOME, if required. This brings us to ... Eye of GNOME, GThumb or Shotwell It is my understanding that Jon had discussions with the developers of these applications, and for various reasons it was decided that writing something from scratch is better. For EoG and GThumb the reason given was that their maintainers did not have time to work on a major redesign, and for Shotwell it was an architectural issue with the program. Please feel free to correct me if I am misrepresenting something. :-) Future plans At the moment I am not going to push Photos as a widely publicized feature for GNOME 3.6, but I do expect it to be functional in a "preview release" sort of way. Will keep you informed as things unfold. Happy hacking, Debarshi -- Give a man ssh access, he'll still need a computer. Give him a computer, he'll give ssh access to you. -- Ashish Shukla pgpZp4SjDwNqx.pgp Description: PGP signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
