On Thu, 2012-05-10 at 02:47 +0000, 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 [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
