Re: [Shotwell] facebook upload is failing

[Adam Dingle]

On Mon, Jul 26, 2010 at 9:42 AM, Filip Slunecko wrote:

> Hi,
>
> I am trying to upload pictures to Facebook and I am still getting this
> error.
>
>
> Publishing to Facebook can't continue because the service returned a
> bad response.
> Session description object has no session key.
>
> (shotwell:5135): GLib-CRITICAL **: g_strsplit: assertion `string != NULL'
> failed
>
>
> Shotwell version 0.5.2, Fedora 13 x64.
> Thank you for help.
>


Filip,

could you try uploading from Shotwell 0.6?  We made some publishing fixes in
that version and so the next step is to find out whether those fixes solve
your problem or not.  I don't know whether Fedora currently provides a
Shotwell 0.6 package, but you should be able to build Shotwell 0.6 fairly
easily using the steps here:

http://yorba.org/shotwell/install

If the problem still occurs with 0.6, let us know and we'll investigate
further.

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] unable to connect to facebook

[Adam Dingle]

Alex,

On Tue, Jul 27, 2010 at 1:23 AM, Alex Insaurralde  wrote:

> I just recently installed Shotwell and I am very impressed with the
> features.


Thanks!


> One feature I tried to use is the "publish" to Facebook.  I entered my
> email and password but got this error message.  I tried several times to
> reconnect but I get the same message. Any ideas on what to do next?
>
> I've attached a png of the error message.
>


This mailing list doesn't allow attachments, so we can't read the error
message.  Could you provide it as text?  What version of Shotwell are you
running?  Does your password contain any non-ASCII characters (i.e.
characters with accent marks)?  We've had some problems with those in the
past, though I believe those are fixed in the trunk build now.

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Copying shotwell data to another platform

[Adam Dingle]

Peter,

On Mon, Jul 26, 2010 at 8:50 PM, Peter DO Smith  wrote:

> I need to copy my photo library (now maintained in Shotwell) from Linux to
> MS Windows (yes, I know, heresy) so that other members of my family can
> enjoy my photo library.


We've never tried this, so we'll be curious to hear how this turns out.


> The documentation for Sqlite says that the database
> file is cross-platform.
> 1) does this mean I can simply copy the database file across to MS Windows
> and use as is?
>

You'll certainly need to copy the entire .shotwell directory, which includes
the database, thumbnails and other files.  The database file should work
cross-platform as mentioned in the Sqlite documentation.


> 2) if I created an identical path on the MS Windows system can I use the
> database file without further changes?
>

As far as we know, yes.


> 3) alternatively will I need to write a small program (Python is my
> preference) to adjust the path in PhotoTable.filename?
>

If you change the path then yes, you'll need do this.


> 4) if so, is an absolute path necessary or can I use a relative path?
>

You'll need to use an absolute path.


> 5) what other considerations should I keep in mind?
>

None that I can think of.  :)


>
> This raises the more general question of copying a Shotwell library to
> another machine in a different location. Do you plan to make provision for
> that?
>

Perhaps we could add a command to save the entire library plus Shotwell's
database to an archive which could be copied to another machine.  Feel free
to file a ticket if you'd like to see that.

Over time, I hope we can keep more of Shotwell's state (including, for
example, thumbnails) in the directories where photos live.  If we could ever
get to the point where *all* of Shotwell's state is stored in those
directories then you'd be able to copy to another machine simply by copying
the library directory itself, which would be nice.  I don't think that will
happen in the foreseeable future, though.

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] event date format

[Adam Dingle]

Peter,

Shotwell doesn't use the locale's setting since we've chosen our own date
format which we think looks simpler and easier to read (e.g. "Tue Jun 29,
2010").  It's true that with our date format the numbers don't line up
vertically in neat columns since we begin with an abbreviated day of the
week, which always has 3 characters but whose width may vary in a
variable-width font.  We could consider allowing the user to customize the
date format we display; feel free to file a ticket for this if you like.

adam

On Mon, Jul 26, 2010 at 3:17 PM, Peter DO Smith  wrote:

> I find the date format for the event list (left hand bar) confusing. When I
> have many entries it is easier to scan them quickly if a simple date format
> is used that lines up in neat columns. I tried changing the date_fmt entry
> in my locales file to correct this (I am using Ubuntu 10.04) but it had no
> effect, although the change was visible in Ubuntu.
>
> Does Shotwell use the locales setting for the date format?
>
> Peter
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

[Shotwell] call for sidebar icons

[Adam Dingle]

Shotwell users,

thanks to some great recent work by Philip Beam we now have code in trunk
that displays icons in the sidebar.  This is great.  But we don't yet have
actual icons that look satisfactory for all our sidebar items.  Is there
some designer out there who'd like to design and/or recommend icons for us
to use?  Here's how our icons look today:

with GNOME icon theme: http://www.yorba.org/download/image/sidebar-gnome.png

with Humanity icon theme:
http://www.yorba.org/download/image/sidebar-humanity.png

Here are the questions we'd like answers to:

- What icon should we use for the Last Import item?

- What icon (if any) should we use for each individual event in the sidebar?

- What icon should we use for the Tags folder?  And for each individual tag?

- What icons should we use for the Cameras folder and for each individual
camera (not shown in the screenshots above)?

We're planning to ship Shotwell 0.7 in just a couple of weeks, so we'd be
interested in design ideas relatively soon - thanks!

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Sea rate to South America

[Adam Dingle]

Shotwell list subscribers,

apologies that the spam below made it onto this list.  We've now 
reconfigured our mailing list software so that messages from non-members 
will have to wait for manual approval, so spam of this sort should not 
happen again.

adam

On 08/08/2010 09:51 PM, Bestcom/Kyle wrote:
> Attn: Director of freight
> From: China bestcom logistics
> Dear All,
> Good day, We are forwarder agent in china, we hope to establish business 
> relationship with you.
> Below is our new rate,pls note.
> Shenzhen to BUENOS AIRES/MONTEVIDEO/SANTOS/RIO DE 
> JANEIRO/ITAJAI:USD2200/4350/4350
> Shanghai to BUENOS AIRES/MONTEVIDEO/SANTOS/RIO DE 
> JANEIRO/ITAJAI:USD2230/4450/4450
> Ningbo to BUENOS AIRES/MONTEVIDEO/SANTOS/RIO DE 
> JANEIRO/ITAJAI:USD2210/4410/4410
>
>
> Remark,
> A.Our rate are all in for FOB shipment,not include local charge.
> B.Our rate can be negotiate basis on regular shipment.
> C.Our rate not valid for chinese forwarder,accept booking from actual shipper 
> only.
> D.Freight prepaid for MB/L only and HB/L for shipper request.
> Any questions,please feel free contact us.
>
>
>
> Mr.Kyle Zhang(Sales Supervisor)
> BESTCOM LOGISTICS&  TRADING LIMITED
> Shenzhen,Gangdong,China
> Tel:+86 755 36946994  3698
> Fax:+86 755 23444313
> Email:k...@bestcom-group.com
> Msn:bestcomk...@hotmail.com
> Website:www.bestcom-group.com
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Connect to Facebook Fails

[Adam Dingle]

On 08/02/2010 08:05 PM, Clifford Snow wrote:
> When I attempt to publish to Facebook I receive the following error message:
>
> Publishing to Facebook can't continue because the service returned a bad
> response.Session description object has no session key
> To try publishing to another service, select one from the above menu.
>
> I am on Fedora 13 using Shotwell 0.5.2
>
>
> Shotwell publishes to Picasa 'Web albums..  flickr is not an option for me
> at this time.
>
> I believe that Shotwell Connector is setup correctly in Facebook.  ( All
> permissions checked.)
>
> Any suggestions?
>

Clifford,

I believe that this problem was fixed in Shotwell 0.6.  If you can build 
Shotwell 0.6 from source as described at 
http://yorba.org/shotwell/install/ , I'm hopeful that will fix your 
problem.  If it doesn't, let us know and we can investigate further.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] I can't use sw-glade cause of make failure.

[Adam Dingle]

ZedTuX,

if you're on a 64-bit architecture and want to build the Glade library, 
you need to build libraw with the following command:

make CFLAGS='-O4 -I. -w -fPIC'

We've been meaning to add this to our build instructions but haven't 
gotten around to doing that yet (see 
http://trac.yorba.org/ticket/1695).  I hope this helps -

adam

On 08/08/2010 01:53 PM, ZedTuX wrote:
> Hi all,
>
> I'm still working of ticket #1702, and the first part of it is done.
> Im now looking to implement it in Shotwell, mean I have to work on GUI
> and Vala code.
>
> I'm using Subversion to get always the latest code. I start the sw-glade
> script and it return me this message:
>
> Run './configure --enable-build-for-glade' and then 'make' to generate
> shared library.
>
> So, I've execute the configure and then the make. And here is my
> problem, the make command failed with this error:
>
> cc src/main.o src/AppWindow.o src/CollectionPage.o src/Thumbnail.o
> src/DatabaseTables.o src/ThumbnailCache.o src/image_util.o
> src/CheckerboardLayout.o src/PhotoPage.o src/Page.o src/ImportPage.o
> src/GPhoto.o src/SortedList.o src/EventsDirectoryPage.o src/Dimensions.o
> src/Box.o src/Photo.o src/Orientation.o src/util.o src/BatchImport.o
> src/Dialogs.o src/Resources.o src/Debug.o src/Sidebar.o
> src/ColorTransformation.o src/EditingTools.o src/DataObject.o
> src/DataCollection.o src/LibraryWindow.o src/CameraTable.o
> src/DirectWindow.o src/Properties.o src/CustomComponents.o src/Config.o
> src/Event.o src/International.o src/Workers.o src/system.o src/AppDirs.o
> src/PixbufCache.o src/WebConnectors.o src/FacebookConnector.o
> src/CommandManager.o src/Commands.o src/SlideshowPage.o
> src/LibraryFiles.o src/FlickrConnector.o src/Printing.o src/Tag.o
> src/TagPage.o src/PicasaConnector.o src/Screensaver.o
> src/PhotoFileAdapter.o src/PhotoFileFormat.o src/PhotoFileSniffer.o
> src/PhotoMetadata.o src/GRaw.o src/GdkSupport.o src/JfifSupport.o
> src/RawSupport.o src/MimicManager.o src/TrashPage.o src/PngSupport.o
> src/PhotoExporter.o src/DirectoryMonitor.o src/LibraryMonitor.o
> src/OfflinePage.o src/LastImportPage.o src/AlienDatabase.o
> src/AlienDatabaseImportJob.o src/AlienDatabaseImportDialog.o
> src/FSpotDatabaseDriver.o src/FSpotDatabaseTables.o -O2 -g -pipe -fPIC
> -DG_UDEV_API_IS_SUBJECT_TO_CHANGE  `pkg-config --libs atk gdk-2.0
> gee-1.0 gtk+-2.0 glib-2.0 libexif sqlite3 gexiv2 gconf-2.0 libgphoto2
> libsoup-2.4 libxml-2.0 unique-1.0 webkit-1.0 gudev-1.0 dbus-glib-1
> gdk-x11-2.0 gthread-2.0` `./libraw-config --libs` -export-dynamic
> -shared -o libshotwell.so
> /usr/bin/ld: /usr/local/lib/libraw_r.a(libraw_cxx_mt.o): relocation
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a
> shared object; recompile with -fPIC
> /usr/local/lib/libraw_r.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make: *** [libshotwell.so] Erreur 1
>
> So, I have downloaded the latest version of LibRaw, compile it and
> installed it (make, make install), but still same issue.
>
> Could you help me please ?
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell newest build questions

[Adam Dingle]

stesind,

On 08/10/2010 04:06 AM, stesind wrote:
> Hi,
>
> I just compiled latest SVN version of Shotwell. Amazing stuff!

Thanks!

> But I
> have a question. I imported the images yesterday. Now after starting
> shotwell it eats one of my cores completely. What does it do? Currently
> I'm not importing.
>

This is a known problem in the trunk at this time: see 
http://trac.yorba.org/ticket/2377 .  We're currently investigating this 
as a high priority.

> I have one wish. You have now events and tags on the left sidebar. Could
> you extend it to a metadata browser? It should allow to select multiple
> tags. Tags also should be dates and maybe camera, lens information,
> folders and more rankings like colors. Selection can be done by pressing
> CRTL button and as an AND operation.

Yes - we agree this could be a nice feature.  See 
http://trac.yorba.org/ticket/2275 and http://trac.yorba.org/ticket/1587 .

> Since most of the data must be
> already in the database implementation should be possible before 0.7
> release.
>

It's too late to implement this feature for 0.7, which we're planning to 
release in the next couple of weeks.  It's a reasonable candidate for 
0.8 or 0.9, however.  Thanks for the suggestion!

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Trac ticket subscription

[Adam Dingle]

On 08/06/2010 12:57 PM, Jan-Christoph Borchardt wrote:
> Is it possible to subscribe to all the Shotwell ticket changes in Trac?
>
> I know there is a RSS feed, but Launchpad already uses mail notifications so
> I’m more comfortable with that for bugs. Adding myself manually to the cc
> list for every bug does not seem to be a good idea.
>
> http://trac.yorba.org/wiki/TracNotification was of no avail.
>
> If you can add me to a global cc list for Shotwell tickets, feel free to do
> that. :)
>

Jan-Christoph,

I've added you to the default CC list for Shotwell on our Trac server.  
This means that you will be automatically added to the CC list on any 
new Shotwell tickets created from now on.  Unfortunately I don't know of 
any easy way to add you to the CC list for all the existing Shotwell 
tickets in Trac, but of course you can add yourself manually for the 
tickets that interest you most.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] I can't use sw-glade cause of make failure.

[Adam Dingle]

ZedTuX,

 > Ok, so how do you proceed to edit GUI ?

that depends what you want to do.  Shotwell's preferences dialog is 
implemented using Glade, so you can edit it there.  You can also add 
Glade to add new dialogs to Shotwell.  Most of Shotwell's user 
interface, however, doesn't come from Glade: it's generated via GTK 
calls in the Shotwell code.  If you want to add a new tree to the 
Shotwell sidebar, for example, then you'll need to study the existing 
Shotwell code that constructs the sidebar and make the changes there, 
not in Glade.  The Shotwell architecture overview at 
http://trac.yorba.org/wiki/ShotwellArchitectureOverview is essential 
reading to get you started.

adam

On 08/09/2010 02:41 PM, ZedTuX wrote:
> Ok, so how do you proceed to edit GUI ?
>
>
> On lun., 2010-08-09 at 14:30 -0700, Jim Nelson wrote:
>
>> That's normal.  The warning messages are coming from Glade itself, and
>> currently Shotwell only has 3 Glade dialogs (the TextEntry dialog is
>> reused in various places).
>>
>> -- Jim
>>
>> On Mon, Aug 9, 2010 at 1:44 PM, ZedTuX  wrote:
>>  Ok, Adam fixed my issue, the compilation is now working
>>  great !
>>
>>  But I still can't edit glade files.
>>  When I execute the sw-glade script, it make a lot of warning
>>  in the
>>  terminal, then open glade. But in glade I only can see 3
>>  windows
>>  (text_entry_dialog1, preferences_dialog and
>>  alien-db-import_dialog).
>>
>>
>>
>>  On dim., 2010-08-08 at 22:53 +0200, ZedTuX wrote:
>>  >  Hi all,
>>  >
>>  >  I'm still working of ticket #1702, and the first part of it
>>  is done.
>>  >  Im now looking to implement it in Shotwell, mean I have to
>>  work on GUI
>>  >  and Vala code.
>>  >
>>  >  I'm using Subversion to get always the latest code. I start
>>  the sw-glade
>>  >  script and it return me this message:
>>  >
>>  >  Run './configure --enable-build-for-glade' and then 'make'
>>  to generate
>>  >  shared library.
>>  >
>>  >  So, I've execute the configure and then the make. And here
>>  is my
>>  >  problem, the make command failed with this error:
>>  >
>>  >  cc src/main.o src/AppWindow.o src/CollectionPage.o
>>  src/Thumbnail.o
>>  >  src/DatabaseTables.o src/ThumbnailCache.o src/image_util.o
>>  >  src/CheckerboardLayout.o src/PhotoPage.o src/Page.o
>>  src/ImportPage.o
>>  >  src/GPhoto.o src/SortedList.o src/EventsDirectoryPage.o
>>  src/Dimensions.o
>>  >  src/Box.o src/Photo.o src/Orientation.o src/util.o
>>  src/BatchImport.o
>>  >  src/Dialogs.o src/Resources.o src/Debug.o src/Sidebar.o
>>  >  src/ColorTransformation.o src/EditingTools.o
>>  src/DataObject.o
>>  >  src/DataCollection.o src/LibraryWindow.o src/CameraTable.o
>>  >  src/DirectWindow.o src/Properties.o src/CustomComponents.o
>>  src/Config.o
>>  >  src/Event.o src/International.o src/Workers.o src/system.o
>>  src/AppDirs.o
>>  >  src/PixbufCache.o src/WebConnectors.o
>>  src/FacebookConnector.o
>>  >  src/CommandManager.o src/Commands.o src/SlideshowPage.o
>>  >  src/LibraryFiles.o src/FlickrConnector.o src/Printing.o
>>  src/Tag.o
>>  >  src/TagPage.o src/PicasaConnector.o src/Screensaver.o
>>  >  src/PhotoFileAdapter.o src/PhotoFileFormat.o
>>  src/PhotoFileSniffer.o
>>  >  src/PhotoMetadata.o src/GRaw.o src/GdkSupport.o
>>  src/JfifSupport.o
>>  >  src/RawSupport.o src/MimicManager.o src/TrashPage.o
>>  src/PngSupport.o
>>  >  src/PhotoExporter.o src/DirectoryMonitor.o
>>  src/LibraryMonitor.o
>>  >  src/OfflinePage.o src/LastImportPage.o src/AlienDatabase.o
>>  >  src/AlienDatabaseImportJob.o src/AlienDatabaseImportDialog.o
>>  >  src/FSpotDatabaseDriver.o src/FSpotDatabaseTables.o -O2 -g
>>  -pipe -fPIC
>>  >  -DG_UDEV_API_IS_SUBJECT_TO_CHANGE  `pkg-config --libs atk
>>  gdk-2.0
>>  >  gee-1.0 gtk+-2.0 glib-2.0 libexif sqlite3 gexiv2 gconf-2.0
>>  libgphoto2
>>  >  libsoup-2.4 libxml-2.0 unique-1.0 webkit-1.0 gudev-1.0
>>  dbus-glib-1
>>  >  gdk-x11-2.0 gthread-2.0` `./libraw-config --libs`
>>  -export-dynamic
>>  >  -shared -o libshotwell.so
>>  >  /usr/bin/ld: /usr/local/lib/libraw_r.a(libraw_cxx_mt.o):
>>  relocation
>>  >  R_X86_64_32 against `.rodata.str1.1' can not be used when
>>  making a
>>  >  shared object; recompile with -fPIC
>>  >  /usr/local/lib/libraw_r.a: could not read symbols: Bad value
>>  >  collect2: ld returned 1 exit status
>>  >  make: *** [libshotwell.so] Erreur 1
>>  

Re: [Shotwell] I can't use sw-glade cause of make failure.

[Adam Dingle]

ZedTuX,

to learn about .ui files, you could read the section "Dynamic Menu 
Creation" in chapter 9 of Andrew Krause's book "Foundations of GTK+ 
Development", which I highly recommend (see http://www.gtkbook.com).  If 
you don't have access to that book, you could read the GtkUIManager 
tutorial at http://live.gnome.org/GnomeLove/UIManagerTutorial and/or the 
GtkUIManager reference documenation at 
http://library.gnome.org/devel/gtk/stable/GtkUIManager.html .

adam

On 08/11/2010 10:51 AM, ZedTuX wrote:
> Adam,
>
> Okay, I will re-read this, but I'm intrigued about *.ui files. Could
> give me more about them please ?
>
> On mar., 2010-08-10 at 10:29 -0700, Adam Dingle wrote:
>
>> ZedTuX,
>>
>>   >  Ok, so how do you proceed to edit GUI ?
>>
>> that depends what you want to do.  Shotwell's preferences dialog is
>> implemented using Glade, so you can edit it there.  You can also add
>> Glade to add new dialogs to Shotwell.  Most of Shotwell's user
>> interface, however, doesn't come from Glade: it's generated via GTK
>> calls in the Shotwell code.  If you want to add a new tree to the
>> Shotwell sidebar, for example, then you'll need to study the existing
>> Shotwell code that constructs the sidebar and make the changes there,
>> not in Glade.  The Shotwell architecture overview at
>> http://trac.yorba.org/wiki/ShotwellArchitectureOverview is essential
>> reading to get you started.
>>
>> adam
>>
>> On 08/09/2010 02:41 PM, ZedTuX wrote:
>>  
>>> Ok, so how do you proceed to edit GUI ?
>>>
>>>
>>> On lun., 2010-08-09 at 14:30 -0700, Jim Nelson wrote:
>>>
>>>
>>>> That's normal.  The warning messages are coming from Glade itself, and
>>>> currently Shotwell only has 3 Glade dialogs (the TextEntry dialog is
>>>> reused in various places).
>>>>
>>>> -- Jim
>>>>
>>>> On Mon, Aug 9, 2010 at 1:44 PM, ZedTuX   wrote:
>>>>   Ok, Adam fixed my issue, the compilation is now working
>>>>   great !
>>>>
>>>>   But I still can't edit glade files.
>>>>   When I execute the sw-glade script, it make a lot of warning
>>>>   in the
>>>>   terminal, then open glade. But in glade I only can see 3
>>>>   windows
>>>>   (text_entry_dialog1, preferences_dialog and
>>>>   alien-db-import_dialog).
>>>>
>>>>
>>>>
>>>>   On dim., 2010-08-08 at 22:53 +0200, ZedTuX wrote:
>>>>   >   Hi all,
>>>>   >
>>>>   >   I'm still working of ticket #1702, and the first part of it
>>>>   is done.
>>>>   >   Im now looking to implement it in Shotwell, mean I have to
>>>>   work on GUI
>>>>   >   and Vala code.
>>>>   >
>>>>   >   I'm using Subversion to get always the latest code. I start
>>>>   the sw-glade
>>>>   >   script and it return me this message:
>>>>   >
>>>>   >   Run './configure --enable-build-for-glade' and then 'make'
>>>>   to generate
>>>>   >   shared library.
>>>>   >
>>>>   >   So, I've execute the configure and then the make. And here
>>>>   is my
>>>>   >   problem, the make command failed with this error:
>>>>   >
>>>>   >   cc src/main.o src/AppWindow.o src/CollectionPage.o
>>>>   src/Thumbnail.o
>>>>   >   src/DatabaseTables.o src/ThumbnailCache.o src/image_util.o
>>>>   >   src/CheckerboardLayout.o src/PhotoPage.o src/Page.o
>>>>   src/ImportPage.o
>>>>   >   src/GPhoto.o src/SortedList.o src/EventsDirectoryPage.o
>>>>   src/Dimensions.o
>>>>   >   src/Box.o src/Photo.o src/Orientation.o src/util.o
>>>>   src/BatchImport.o
>>>>   >   src/Dialogs.o src/Resources.o src/Debug.o src/Sidebar.o
>>>>   >   src/ColorTransformation.o src/EditingTools.o
>>>>   src/DataObject.o
>>>>   >   src/DataCollection.o src/LibraryWindow.o src/CameraTable.o
>>>>   

Re: [Shotwell] Add or modify tags

[Adam Dingle]

> It should still be possible to merge those commands. This is how such a
> add/modify tags could behave:
>
> 1) Shows a list of tags of the selected photo(s) (with active checkboxes) in
> a dialog window, and a single line text field with a comma, separated list
> of tags. We automatically, append "," and focus in that text field.
>
> Adding one or multiple tags simply means to start typing them.
> Keyboard lovers can edit the list of tags in the text field.
> Mouse lovers can de-select tags to remove them.
>
> 2) If multiple photos are selected, basically behave the same, but have
> common tags be bold, and tags that are only on a subset of photos
> nonbold/italic. Adding a new tag adds them to all photos, removing an italic
> tag, removes them for all that have that one.
>
> This allows adding tags to all selected photos, removing common tags, and
> rename tags on all selected photos and would still IMHO be more intuitive
> than the current solution. (It took me some time to find out why modify tags
> wouldn't work when I had multiple photos selected)
>

I'd like to think that something like this could work.  I'm not 
absolutely convinced that the list with checkboxes is even necessary, 
though; perhaps we could just have the text-based list with bolding, at 
least as a first implementation.

I've created a ticket "possibly combine Add Tags and Modify Tags 
commands" at http://trac.yorba.org/ticket/2382 .  That will be a good 
place for further discussion about this.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Howto find undated photos?

[Adam Dingle]

Sebastian,

thanks for trying out Shotwell and sending us your detailed comments.

On 08/11/2010 05:41 AM, Sebastian Spaeth wrote:
> Hi all, I just tested the latest release on my 8k photo set and worked
> for 8 hours with shotwell. Propably a lot has already changed since
> then, but anyway here is my feedback:
>
> First the ugly:
>
> - Importing from a Ubuntu-mounted Windows share does not work I then
>tried to import from ~/.gvfs/blabla which imported about 3k photos or
>so before shotwell simply crashed (repeatedly). Copying the share to
>my desktop and importing from a local folder worked fine though.
>

You say that importing from a mounted Windows share "does not work" - 
what do you mean by this?  When you try to import from the share, does 
Shotwell display an error or simply ignore the files?  Were you 
attempting to link or copy the photos into Shotwell?  I just tried to 
reproduce this by importing photos from a Windows share into Shotwell 
0.6.1 on my machine, and it worked fine for me.

It sounds like you're able to reproduce the crash you're seeing when 
importing from ~/.gvfs/foo.  We'd love to see a backtrace for this.  
Ideally you could build Shotwell from trunk, run it from gdb, import 
from ~/.gvfs/foo and then send us the backtrace generated upon crashing 
(assuming that the crash still occurs in trunk).  If you want to do this 
and need any extra information about how to proceed then just let us know.

> - Some of my images were undated, although shotwell had imported them
>into folders that made sense (2005/07/15/foo.jpg) etc. Is that due to
>a lack of exiv information? I can debug the specific photo files in
>question.
>

Yes - if there is no EXIV information then Shotwell will have treat the 
image as undated.  Some users would like us to use the photo's file time 
as the image date instead in that case; we're currently undecided about 
whether to make that change since we think file times may not always be 
relevant or useful.

> - The worst thing overall, is that I was not able to find those undated
>photos in my list, as I worked along my events and it does not seem to be
>possible to filter photos that are not assigned to an event. Am I
>right that this would be: http://trac.yorba.org/ticket/1632?  (always
>place Undated folder at bottom of event list)
>
>In general it would be great to be able to search for undated photos
>and/or photos that are not assigned to any one event. I nearly
>overlooked a couple of events (like my marriage) because those photos
>never showed up under any "event".
>

You're right that it's a major limitation that you can't currently find 
undated photos and/or photos which belong to no event, and we hope to 
fix this soon.  As Jan-Christoph pointed out, the ticket 
http://trac.yorba.org/ticket/1712 is tracking this issue, more or less.

By the way, Shotwell does currently include an Undated folder (mentioned 
in http://trac.yorba.org/ticket/1632) but that's not quite what you're 
looking for.  The Undated folder contains all events which Shotwell 
can't place under any year in the sidebar tree because those events 
contain only undated photos.  Currently Shotwell does not place undated 
photos into any event at import time, but you can still place them into 
events manually, at which time those events will be in the Undated folder.

> - Adding a tag over multiple photos works fine, but modifying does
>not. This hurt when I discovered I had mistyped a tag and wanted to
>mass-rename a tag. I know that some mp3 taggers show all common tags
>if you select multiple and allow you to mass-rename common tags among
>files. This would have helped me.
>

I assume that you realize that you can right click any tag in the 
sidebar and choose the Rename command to rename it.  It's true that 
Shotwell doesn't let you rename a tag only in a selected set of photos, 
however.

> - Tag autocompletion please :)
>(http://trac.yorba.org/ticket/1334). Typing the name of my son over
>and over again was tiresome and very prone to typos.
>

Yes - we want this too.  :)

> - I ended up with quite many tags. If I had a simple search bar that
>dynamically reduced the list of tags to those potentially matching
>that would help me find appropriate tags more easily. I guess that is
>different from the more generic issue: http://trac.yorba.org/ticket/80
>(Search box) which would also be helpful. (Find all images of my son
>in 2009 etc)
>

We are hoping to implement an all-in-one search box which lets you 
search by tag, title, filename and so on.  The design of the search box 
is still up for discussion, but probably you'll be able to simply type a 
string to perform a search over all fields, or to select a particular 
search type.  If you select a search by tag, it would be nice if the 
search box would autocomplete tag names.  I'm not quite sure whether 
this i

Re: [Shotwell] Howto find undated photos?

[Adam Dingle]

Sebastian,

On 08/12/2010 02:44 AM, Sebastian Spaeth wrote:
> On Wed, 11 Aug 2010 12:02:57 -0700, Adam Dingle  wrote:
>
>> You say that importing from a mounted Windows share "does not work" -=20
>> what do you mean by this?
>>  
> I select "import from folder" in my stock Ubuntu and I get the file
> chooser dialog. In this, I don't see my mounted Windows shares, so I
> cannot select it. Mounted windows shares, as in I used the standard
> "Connect to server"->  "Windows share" thingie in Ubuntu.
>

You can of course open the mounted Windows share in Nautilus and drag 
the folder directly into Shotwell to import it.  But if you want to use 
the File->Import From Folder menu item instead, then you're right that 
Shotwell does not list network shares in the resulting dialog.  It would 
be nice to include them there: I've created a ticket at 
http://trac.yorba.org/ticket/2392 .

>
> Sure thing it has to treat them as undated. I am no fan of using the
> files mtime, which is pretty meaningless on my system as I copied the
> files around over the years and the mtime has been changed a couple of
> time. I would rather see them remain as undated, as squeezing my 1999
> photos into 2006, just because I happened to copy them around then.
>

I'm inclined to agree: the mtime may well be meaningless and I think 
it's safer not to use it.

>> By the way, Shotwell does currently include an Undated folder (mentioned
>> in http://trac.yorba.org/ticket/1632) but that's not quite what you're
>> looking for.  The Undated folder contains all events which Shotwell
>> can't place under any year in the sidebar tree because those events
>> contain only undated photos.  Currently Shotwell does not place undated
>> photos into any event at import time, but you can still place them into
>> events manually, at which time those events will be in the Undated folder.
>>  
> That is interesting and certainly not the case in 0.6.1 (or I missed it
> even after looking explicitly for it). One more reason to switch to trunk.
>

The Undated folder *is* present in 0.6.1.  To see it, import a photo 
which has no EXIF date, then select the photo and and choose Events->New 
Event.  The photo will be placed in a new event, which will appear in 
the Undated folder because the photo in the event has no date.

>> I assume that you realize that you can right click any tag in the
>> sidebar and choose the Rename command to rename it.  It's true that
>> Shotwell doesn't let you rename a tag only in a selected set of photos,
>> however.
>>  
> DOH, it is so obvious now that you say that. No, I had not tried to do
> that. However, it only solves my problem partially. My son's name is
> Oliver, so I have a frequently used tag "Oliver". On a couple of photos
> I mistyped and typed "oliver" (hey, why case sensitivity BTW?!!! :-)).
>

You're right: I think there's not much reason for Shotwell tag names to 
be case-sensitive.  I've filed a ticket to fix this at 
http://trac.yorba.org/ticket/2391 .

> - I had a couple of crashes (3 or so) at seemingly random points.
>
>> Again, if you could get us backtraces for these we'd be eternally=20
>> grateful.  :)
>>  
> I'll get into a habit of running shotwell trunk under gdb :)
>

Alternatively, you could set up your machine to generate a core dump 
whenever an application crashes, and then use gdb to get a backtrace 
from the core dump afterward.  That might be easier since you wouldn't 
need to run under gdb every time.  If you want more detailed advice 
about how to do this then just let me know.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Howto find undated photos?

[Adam Dingle]

On 08/12/2010 03:51 AM, Sebastian Spaeth wrote:
> Sebastian Spaeth  wrote:
>
>>> By the way, Shotwell does currently include an Undated folder (mentioned
>>> in http://trac.yorba.org/ticket/1632) but that's not quite what you're
>>> looking for.  The Undated folder contains all events which Shotwell
>>> can't place under any year in the sidebar tree because those events
>>> contain only undated photos.  Currently Shotwell does not place undated
>>> photos into any event at import time, but you can still place them into
>>> events manually, at which time those events will be in the Undated folder.
>>>
>> That is interesting and certainly not the case in 0.6.1 (or I missed it
>> even after looking explicitly for it). One more reason to switch to trunk.
>>  
> I just thought about this and I think it is not working as
> intended. First of all, I tried it on 2 machines, one 1 I linked, on the
> 2nd I copied to a local library.
>
> When linking there won't be an "undated" folder of course, so that won't
> work there.
>
> When copying I had photos (in 0.6.1) that were in dated folders
> (2005/07/24/...) but who had no exiv date and did not end up in any
> event.
>

Right - that's expected and is how Shotwell works today.  As I mentioned 
in my previous message, if a photo is undated (i.e. has no EXIF date) 
then Shotwell will not place it into any event.  You'll see the Undated 
folder only if you manually place undated photos into events; then those 
events will appear in the Undated folder.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Howto find undated photos?

[Adam Dingle]

Son,

On 08/11/2010 06:12 PM, Son Hua wrote:
> Hi all,
>
> More on the undated photos problem. I think that the way Shotwell 
> organizes  photos according to events is limited not only for undated 
> photos but also photos we have classified (manually) before.

Agreed.  We hope to improve this.

>
> Say, I collect a number of photos on the internet, for example, photos 
> related to motion, and put them into a folder named Motion before. Now 
> I want to import these photos into Shotwell. The way of organising 
> with events will simply scatter my photos to different dates and I'll 
> have no way to find them among other events at the moment. Even if 
> some of them can be found manually, how can I tag all newly imported 
> photos with the tag "motion"?

In the upcoming 0.7 release (and in the trunk today) there's a Last 
Import sidebar item which shows you all the photos you've just 
imported.  So after your import you can select Last Import, select all 
photos in the view and then choose Tags->Add Tags.

>
> I love to use Shotwell for its simplicity, but the way of using event 
> to organise stuffs automatically is just too limited and does not fit 
> well for me. Are Shotwell developers having any plans to allow custom 
> organization, or simply using existing folder names to organize 
> (similar to Lightroom), or any other more efficient approaches?

We plan to add a file tree to the sidebar which lets you browse your 
photos according to their layout on hard disk 
(http://trac.yorba.org/ticket/1594).  That will be convenient to use if 
you've already organized them into disk folders.  As Vincent pointed out 
in another message, we'd also like let the user customize the import 
directory hierarchy, which is currently fixed at year/month/day 
(http://trac.yorba.org/ticket/1597).  It might also be nice if the user 
could attach tags during import (http://trac.yorba.org/ticket/1586) 
and/or rename photos to a user-configurable pattern when importing 
(http://trac.yorba.org/ticket/1942).  Hopefully some of these 
improvements will come in the next couple of releases after 0.7.  As 
always, we welcome feedback about which of these would be most valuable 
to you.

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Final call for testing 0.7

[Adam Dingle]

Peter,

yes - we do want to include the Mallard-based documentation in this 
release.  To be clear, we also plan to update the existing Shotwell user 
guide (http://trac.yorba.org/wiki/UsingShotwell0.6) for this and future 
releases - it will not go away.  The user guide will be linear (you can 
read it like a book) and comprehensive.  The Mallard-based documentation 
will be topical and task-oriented, and may not include every little 
detail about everything Shotwell can do.  I think these two 
documentation resources will complement each other well.

Robert's Mallard documentation is a good start, but there's more work to 
be done as Jim described in his comments on our Mallard ticket at 
http://trac.yorba.org/ticket/1143 .  That ticket is currently assigned 
to David Velazquez.  David, are you planning to complete the Mallard 
documentation following Jim's suggestions?  Or Peter, do you want to 
work on that?  We're hoping to ship Shotwell 0.7 by the end of next 
week, so we could use some help here soon.

adam

On 08/12/2010 02:30 AM, Peter DO Smith wrote:
> Are you going to use Robert Ancell's mallard based documentation for this
> release? I was thinking of contributing to his documentation.
>
> On Thu, Aug 12, 2010 at 6:47 AM, Jim Nelson  wrote:
>
>
>> Hello,
>>
>> Shotwell 0.7 is on the horizon and we could use your help.  Now would be a
>> great time to test trunk and make sure we're not missing anything
>> important.  0.7 is a short development cycle, so the feature list isn't
>> long, but does feature some long-asked-for goodies:
>>
>> * F-Spot import (thank you Bruno Girin!)
>> * Last Import page
>> * Directory scan at startup (which verifies that all your photos are
>> present; any that are not are moved to the "Missing Files" page)
>> * Numerous bug fixes
>>
>> Although we have more bugs to attack, the final release will look very
>> similar to what is in trunk right now.
>>
>> If you're interested, follow the directions here for getting the source and
>> building it:
>>
>> http://www.yorba.org/shotwell/install/#source
>>
>> If you find bugs or issues please feel free to report them here on the
>> mailing list or via our Trac ticketing system at:
>>
>> http://trac.yorba.org/
>>
>> Here's to 0.7!
>>
>> -- Jim Nelson
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Final call for testing 0.7

[Adam Dingle]

OK - I've now reassigned the Mallard ticket 
(http://trac.yorba.org/ticket/1143) to Peter.  Peter, thanks for 
offering to help out on this.  Please read Jim's latest comments on the 
ticket and let us know if you have any other questions, either about the 
work to be done or about the tools/processes involved.  It might be best 
to continue the discussion by appending comments to the Mallard ticket 
itself.

Note that we have not yet updated the Shotwell user guide for 0.7 
(http://trac.yorba.org/ticket/2393) and once we do so we'll want to 
merge those changes into the Mallard documentation, though I think those 
changes will be pretty modest.  Thanks again for your help!

adam

On 08/12/2010 11:37 AM, Peter DO Smith wrote:
> David, Adam, I would like to help out with the documentation. We just need
> to work out how to coordinate our work.
> Peter
>
> On Thu, Aug 12, 2010 at 8:33 PM, David Velazquez<
> david.velazque...@gmail.com>  wrote:
>
>
>> I'm still working on it but due to reasons of a more personal nature I
>> haven't been able to get muck work done recently. If Peter can do it, then
>> by all means please remove me as owner. I'd love to contribute but the time
>> frame and events in my life have made it unlikely I'll be able to do much by
>> the time you want to roll .7 out the door.
>>
>>
>> On Thu, Aug 12, 2010 at 2:02 PM, Adam Dingle  wrote:
>>
>>  
>>> Peter,
>>>
>>> yes - we do want to include the Mallard-based documentation in this
>>> release.  To be clear, we also plan to update the existing Shotwell user
>>> guide (http://trac.yorba.org/wiki/UsingShotwell0.6) for this and future
>>> releases - it will not go away.  The user guide will be linear (you can read
>>> it like a book) and comprehensive.  The Mallard-based documentation will be
>>> topical and task-oriented, and may not include every little detail about
>>> everything Shotwell can do.  I think these two documentation resources will
>>> complement each other well.
>>>
>>> Robert's Mallard documentation is a good start, but there's more work to
>>> be done as Jim described in his comments on our Mallard ticket at
>>> http://trac.yorba.org/ticket/1143 .  That ticket is currently assigned to
>>> David Velazquez.  David, are you planning to complete the Mallard
>>> documentation following Jim's suggestions?  Or Peter, do you want to work on
>>> that?  We're hoping to ship Shotwell 0.7 by the end of next week, so we
>>> could use some help here soon.
>>>
>>> adam
>>>
>>>
>>> On 08/12/2010 02:30 AM, Peter DO Smith wrote:
>>>
>>>
>>>> Are you going to use Robert Ancell's mallard based documentation for this
>>>> release? I was thinking of contributing to his documentation.
>>>>
>>>> On Thu, Aug 12, 2010 at 6:47 AM, Jim Nelson   wrote:
>>>>
>>>>
>>>>
>>>>  
>>>>> Hello,
>>>>>
>>>>> Shotwell 0.7 is on the horizon and we could use your help.  Now would be
>>>>> a
>>>>> great time to test trunk and make sure we're not missing anything
>>>>> important.  0.7 is a short development cycle, so the feature list isn't
>>>>> long, but does feature some long-asked-for goodies:
>>>>>
>>>>> * F-Spot import (thank you Bruno Girin!)
>>>>> * Last Import page
>>>>> * Directory scan at startup (which verifies that all your photos are
>>>>> present; any that are not are moved to the "Missing Files" page)
>>>>> * Numerous bug fixes
>>>>>
>>>>> Although we have more bugs to attack, the final release will look very
>>>>> similar to what is in trunk right now.
>>>>>
>>>>> If you're interested, follow the directions here for getting the source
>>>>> and
>>>>> building it:
>>>>>
>>>>> http://www.yorba.org/shotwell/install/#source
>>>>>
>>>>> If you find bugs or issues please feel free to report them here on the
>>>>> mailing list or via our Trac ticketing system at:
>>>>>
>>>>> http://trac.yorba.org/
>>>>>
>>>>> Here's to 0.7!
>>>>>
>>>>> -- Jim Nelson
>>>>> ___
>>>>> Shotwell mailing list
>>>>> Shotwell@lists.yorba.org
>>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ___
>>>> Shotwell mailing list
>>>> Shotwell@lists.yorba.org
>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>>>
>>>>
>>>>
>>>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Final call for testing 0.7

[Adam Dingle]

Martin,

thanks as always for your valuable observations and useful suggestions.

On 08/12/2010 02:09 PM, Martin Olsson wrote:
> Since you added RAW support in the last version I have now actually tried 
> Shotwell with
> my real photo collection. Here are some things that I noted (some minor 0.7.0 
> bugs at the end):
>
> First I ran into some already ticket stuff (so I'm just listen them as a +1 
> for 0.8.0):
> * I really really miss a Sharpen button or Sharpen slider (ticket #690).
>

Yes - this would be nice.  I've upped the ticket priority to high.

> * I don't want the "master copy" of any data in ~/.shotwell, I prefer if tags 
> are applied
> directly as metadata to the original photo files, ofc at very explicit 
> opt-in from the user. (ticket #1897).
>

Right.  Hopefully coming in the next couple of releases.

> Other issues I encountered in my workflow (these most likely not relevant for 
> 0.7.0):
> * I shoot RAW+JPG and the RAW photos look very poor since they are rendering 
> using "default settings".
> Here are some RAW+JPG equivalents directly from the camera (no 
> modifications). Are you passing any
> parameters to libraw when you do the conversion or is this a libraw 
> "bug"? Also I wonder if this affects
> all RAW capable cameras much or if different camera have different 
> specific problems...
> Anyway, import these:
> http://temp.minimum.se/shotwell_raw/
>

Yes - our rendering of RAW photos is not yet as nice as we'd like.  
There are various parameters we can specify to libraw when we do the 
conversion, and it's possible that we're not yet making the ideal 
choices.  We'd like our RAW rendering to match that performed by Eye of 
GNOME and Evince, but we're not there yet (this is 
http://trac.yorba.org/ticket/2246).  Even then, however, our rendering 
may not look as good as the JPEG coming off of the camera.  If you shoot 
RAW+JPEG and import both, we should manage them as a pair and optionally 
use the JPEG for rendering (http://trac.yorba.org/ticket/1772).  If no 
separate JPEG file is available but the RAW file has an embedded JPEG of 
sufficient size, we should optionally use it for rendering 
(http://trac.yorba.org/ticket/1771).

> * I would like to have "Camera: BLAH" in the basic metadata rather than 
> hidden away in the extended dialog.
>

Ticket at http://trac.yorba.org/ticket/2401 .

> * While cropping I'd like to be able to live preview the pixel size of the 
> crop region while I'm resizing it.
> Right now the "Size:" field in "basic info" is not updated until I finish 
> the crop by pressing OK.
>

A good suggestion.  Ticketed at http://trac.yorba.org/ticket/2397 .

> * It would be nice if the "basic metadata" panel was re-designed so that it 
> fits more and more stuff into itself
> the bigger I make it. So if I drag the horizontal splitter upwards, more 
> and more metadata shows up in this
> pane (right now I just get more gray space).
>

Worth considering; ticketed at http://trac.yorba.org/ticket/2401 .

> * I miss the ability to zoom out more than "fit photo to screen" (i.e. make 
> photo smaller than the photo viewport).
> This is useful for quickly previewing what the photo would look like 
> inserted into a blog post or similar
> (i.e. resized and inserted into the text).
>

A reasonable idea; ticketed at http://trac.yorba.org/ticket/2398 .

> * At some point I wanted to inspect a photo at 100% size to check noise 
> levels, sharpness etc. So I zoom to
> maximum but then I realized the UI doesn't tell me if "maximum zoom" 
> means "100% size" or not. I guess it
> does but I think it would be nice if there was some actual percentage 
> number that changed when the zoom slider
> is dragged just so that the user knows for sure what magnification he/she 
> is at. Since you don't have a status
> bar (which I think is a good thing) maybe some tiny popup window could 
> appear which goes away immediately when
> the user releases the zoom slider (similar to the Adjust dialog but a lot 
> smaller and hovering above the photo
> just above the zoom slider itself)?
>

Ticketed at http://trac.yorba.org/ticket/2399 .

> * A lot of important metadata is not viewable in Shotwell (but running exiv2 
> shows it), in particular:
> - I really miss "ISO Speed"
> - It would also be useful to have "Metering mode" and "White balance" 
> included.
> - And just for fun, it would be nice to include the EXIF "ShutterCount" 
> (i.e. total number of times the shutter
>   has opened on this particular camera).
> - What lens was used (mostly a DSLR feature but it's something I miss a 
> lot from Adobe Lightroom).
>   Not sure if this info is available in generic EXIF but it's certain 
> available in for example
>   "Exif.NikonLd2.LensIDNumber" (see http://www.exiv2.org/tags-nikon.html 
> etc).
>

All reasonable ideas; ticketd at http://trac.yorba.org/ticket/240

Re: [Shotwell] Face auto-detection

[Adam Dingle]

On 08/16/2010 07:18 AM, Gendre Sebastien wrote:
> Hello everybody. (I'm new here)
>
> Have you any plan to add the feature "face auto-detection"?
>
> The idea is to use the library OpenCV to auto-detect face of people in
> pictures and add their respectives names automatically to tags of
> respectives pictures.
>
> For more information about OpenCV: http://opencv.willowgarage.com/wiki/
>
> What do you think about this idea?
>

Yes - we'd like this too:

http://trac.yorba.org/ticket/1702

One user has been working on a preliminary implementation - for details, 
see the ticket above.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] mimics folder

[Adam Dingle]

On 08/15/2010 10:25 PM, stesind wrote:
> Hi,
>
> Asap as I start latest svn shotwell it starts to create JPEGs in the
> mimics folder. Each of them has a size of 2-3MByte. This is nearly the
> size of delevoped JPEGs. In my libary are a lot of CR2s. Every time
> shotwell eats a lot of my system performance. The mimics folder has a
> size of 15GByte. Why is it creating this files? I think it is totally
> useless since JPEGs are stored in the CR2 Raws. They should be used.
>

stesind,

First of all, note that it can be *very* slow to generate a display 
image from a RAW photo - it can take several seconds, which is an 
unacceptable amount of time for opening a photo.  So Shotwell needs to 
have a full-size JPEG available for each photo in the library.  This is 
why it generates the mimic JPEGs.

Now, we agree that it would be nice if Shotwell could use a JPEG 
embedded in a RAW file rather than generating its own JPEG mimic - this 
is http://trac.yorba.org/ticket/1771 .  But not all RAW files contain 
embedded JPEGs which are large enough for all editing needs, and so even 
after we implement this capability the user will be able to turn it on 
and off.  For example, CR2 photos from my Canon S90 camera contain 
embedded JPEGs which are 1600x1200 (to see the sizes for your camera, 
run 'exiv2 -p p foo.cr2' on one of your photos).  My monitor is 
1920x1080, so it would probably be reasonable to use these embedded 
JPEGs for displaying photos in Shotwell as long as I never need to zoom 
into a photo.  But, still, this should be a user option.  If the user 
enables the use of embedded JPEGs, then Shotwell will not generate the 
mimic JPEGs, but if you try to zoom into a resolution larger than the 
embedded JPEG then Shotwell will have to display a blurry photo (at 
least for several seconds; perhaps it could render the RAW image in the 
background and then update the display).

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Is requiring valac 0.9.5 really a good idea?

[Adam Dingle]

On 08/16/2010 12:58 AM, Marcel Stimberg wrote:
> Thanks Bruno and Robert for making this clear. Actually I was not that
> afraid of shotwell not being the photo manager in maverick because of
> this change (but it seems to I failed to convey this with my mail)
> :-).
>
> Still, I do not get the rationale to make a small change in the code
> just to get rid of some warnings and break building on any currently
> available distribution. It's nice that Ubuntu will include vala 0.9.5.
> (there are probably some bug fixes that are worth having), but for
> e.g. having a shotwell 0.7 Debian package this introduces an IMHO
> unnecessary delay until Debian catches up.
>
> But it's good to know that guys at yorba and ubuntu are aware of this
> issue, so I'm relaxed and looking forward to shotwell 0.7 (and
> maverick for that matter ;))
>

Thanks for all the comments about our new requirement of Vala 0.9.5 - 
I'm glad that people noticed this change at least.  :)  I know that it's 
a bit inconvenient for everyone to have to upgrade their Vala.  We've 
decided to require 0.9.5 for a couple of reasons:

1. We've been in touch with people at both Fedora and Ubuntu who have 
said they expect 0.9.5 to be in the next releases of those 
distributions.  So people will probably be building with 0.9.5 for a 
long time to come.  Before our recent change to Shotwell, there were 
tons of build warnings when building with 0.9.5, which were unpleasant.  
We've changed Shotwell to eliminate the warnings, though those changes 
now require 0.9.5 for building.

2. Before this change, Shotwell required only version 0.8.0 of Vala to 
build.  That version of Vala came out back in March, which is actually a 
fair amount of time ago in the world of Vala, where the language and 
library bindings are evolving quickly.  It actually makes us a bit 
uncomfortable to have people building Shotwell using older versions of 
Vala since we know that many Vala bugs are fixed with each release.

Because 0.9.5 should be installed by default in major distributions, I 
hope we'll be able to keep our Vala version dependency at 0.9.5 for some 
time to come.  Also, as Vala matures and stabilizes in the future I 
think we'll be more comfortable with building Shotwell using older 
versions of Vala, and at that point I expect we'll change our version 
dependency less often.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Handling RAW Files in Shotwell

[Adam Dingle]

Andrew,

On 08/16/2010 05:15 PM, Andrew Martin wrote:
> Hello Shotwell Team,
>
> Thank you for this fantastic photo manager for Linux! When I first tried
> Shotwell, I was blown away by the simplicity yet power that it provides. I
> have been happily using it for several months now and really am looking
> forward to future releases.
>

Thanks!  We love hearing feedback like this.  :)

> I shoot photos in RAW + JPEG, so I end up with 2 identically labeled files
> for each photo I take (e.g. _IMG_3845.CR2 and _IMG_3845.JPG). I love that
> Shotwell can display both RAW and JPEG files, but would it be possible to
> have Shotwell display these 2 files as only 1 image? Right now, when I look
> at any of my albums, I see 2 of each image. For the purpose of browsing
> images in Shotwell, just viewing the JPG makes sense. However, if I want to
> do more intense editing on the RAW file I can then open it in an external
> editor. What do you think about this idea of collapsing the view of the same
> JPG and RAW file together?
>

Yes - we agree this is a good idea.  We have a ticket for this here:

http://trac.yorba.org/ticket/1772

No promises, but I hope we'll be able to implement this in the next 
couple of releases.

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Event rename issue

[Adam Dingle]

Sebastian,

On 08/17/2010 10:54 AM, Sebastian Spaeth wrote:
> I just filed trac ticket
> http://trac.yorba.org/ticket/2425
>
> When renaming an event from by right-clicking on the key photo, I get a 
> dialog box and everything is fine. However, when invoking rename, by 
> right-clicking on the event in the sidebar and selecting "rename event" it 
> behaves very weird:
>
> - While importing (lots of) photos: There seems to be a short timeout that is 
> not reset when pressing a key. Select rename and type slowly "x". After a 
> short while the cursor jumps out of the box, you can't type anymore and no 
> rename seems to have occured.
>
> - Performing the above when the import finished works fine.
>
>
> I can reproduce this with latest trunk.
>

thanks for the bug report.  I can also reproduce this.  I suspect that 
the cursor jumps out of the box as soon as a new photo is imported into 
the event that you're renaming, but I'm not sure - we'll have to 
investigate.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Trash clarification

[Adam Dingle]

Sebastian,

On 08/18/2010 12:21 AM, Sebastian Spaeth wrote:
> I just read the mallard documentation at
> http://trac.yorba.org/browser/shotwell/trunk/help/organise-delete.page
> because I was not clear about how the shotwell trash operates and I am
> still not clear. The issue is the shotwell "Trash" function.
>
> Will "move to trash" in shotwell also move the original photo file to
> the Operating System's "trash"? I strongly suspect no, but then that
> should be spelled out somewhere probably.
>
> I am asking as I naively expect that in modern and integrated OSes a "move to
> trash" from within the application would basically behave similar to a
> "move to trash" on the file from within the file manager.
>

When you move a photo to the trash in Shotwell it is *not* moved to the 
desktop (operating system) trash - that happens only when you empty the 
Shotwell trash.  I agree that the documentation should make this more 
clear.  I've just updated the Shotwell user guide at 
http://trac.yorba.org/wiki/UsingShotwell0.6 to clarify this point.  As 
you may know, Shotwell 0.7 will include both an updated user guide and 
Mallard documentation.  Peter Smith is working on the Mallard 
documentation, so hopefully he can clarify this there as well.

> Either behavior would be fine for me, but it should be spelled out explicitly
> in that doc IMHO. Perhaps (post .7 this should be renamed to something
> less ambiguous, such as "mark as deleted" or "mark for deletion". Not sure.
>

In a future release we're considering moving files to the desktop trash 
as soon as you move them to the Shotwell trash, but have made no 
decision about this - feedback about this idea is welcome.

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] mimics folder

[Adam Dingle]

Steffen,

as I tried (perhaps unsuccessfully) to explain in a previous message, we 
do want to make it optional to create previews in the mimics folder.  Of 
course, if there are no previews there then Shotwell must display 
*something* when you open a RAW photo.  There are several choices here:

- display the JPEG file embedded in a RAW photo 
(http://trac.yorba.org/ticket/1771)

- display the JPEG photo which comes in a RAW+JPEG pair 
(http://trac.yorba.org/ticket/1772)

- simply display a blown-up thumbnail (which will look very blurry) and 
wait several seconds to display the decoded RAW image

Ultimately I think the user should be in control and should be able to 
choose any of these if they want.  Maybe the user should also be able to 
control the size of the preview files which Shotwell generates.  If your 
monitor is 1920x1080, then you might want to generate previews only at 
that size, in which case preview files will be much smaller though when 
zooming into a photo you'll have to wait a few seconds for the RAW 
rendering to complete.

None of this will happen for 0.7 (coming soon now!) but we will consider 
all of this as part of our feature planning for following releases.

adam

On 08/18/2010 12:15 AM, stesind wrote:
> If it is not possible to change this behaviour, could you make it
> optional to create previews in the mimics folder?
>
> Steffen
>
>
> Am Dienstag, den 17.08.2010, 09:59 +0200 schrieb stesind:
>
>> I just saw that the previews in the mimics folder are names uniquely.
>>
>>  
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photos Edited Externally Not Changed in Shotwell

[Adam Dingle]

That's right.  We've been hoping to make this completely automatic - 
every time Shotwell starts up it will notice photos which have changed 
and react accordingly.  We want Shotwell's startup to be very fast, 
though, and it's not yet clear whether this kind of update will make 
Shotwell too slow to start up if lots of files have changed.  If so, we 
might consider a manual refresh command as a few users on this thread 
have suggested.

adam

On 08/17/2010 08:50 PM, Jim Nelson wrote:
> Technically, no.  0.7 will merely detect if the file is missing or not at
> startup and mark it accordingly.  We're hoping in a future release to do a
> more thorough update when changes are detected.
>
> -- Jim
>
> On Tue, Aug 17, 2010 at 1:47 AM, Sebastian Spaethwrote:
>
>
>> On 2010-08-17, Peter DO Smith wrote:
>>  
>>> Yes, I have the same problem. A refresh button for events would solve the
>>> problem nicely.
>>> Peter
>>>
>> Isn't this addressed by the missing files feature (which requires a
>> restart of shotwell)? Of course, there need to be actions that can be
>> performed on those missing files, like "delete from shotwell" :)
>>
>> spaetz
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Plug-in architecture for Shotwell?

[Adam Dingle]

Peter,

On 08/18/2010 02:17 PM, Peter DO Smith wrote:
> Has a plug-in architecture for Shotwell been considered, something like that
> used in Gimp?
>

Yes: we agree this would be useful.  This is 
http://trac.yorba.org/ticket/1603 , which is a good place for further 
discussion of this idea.  We have lots of other features to build too, 
but I hope this will happen in the next few releases.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] IPTC tagging in Shotwell

[Adam Dingle]

David,

On 08/18/2010 04:13 PM, David Rolph wrote:
> Hi All,
>
> I'm a happy novice Shotwell user.
>

Glad you're happy so far!  :)

> I'd like to start tagging my photos.  At bit of hunting around leads me to
> believe that IPTC offers me the best chance of persistent tagging of my
> photos that extends beyond the boundaries of whatever tool I am using to
> view them.  This is attractive to me for many reasons.  My wife uses Picasa
> which I believe should be able to read and write those tags too.  If I send
> my photos to somebody else or perhaps an online service then I know my tags
> are going with them.  Basically, I'd like to tag my photos once, now and
> never again.
>

Yes - that makes sense.

> So I've updated to Shotwell 0.6 which I believe can read and write these
> tags.  But I'm not quite clear on how the write function works.  Is it
> necessary for me to Export in order to write the tags?  If I simply tag an
> image in Shotwell it doesn't seem to modify the original file.  When I
> select Export it gives me compression settings.  I'd prefer not to modify my
> image data (non destructive is a very attractive shotwell feature for me.)
>
> I did find some discussions of whether Shotwell should write the IPTC tags
> as they are changed or whether to reduce overhead it should not.  Does 0.6
> not automatically update the tags?
>

Shotwell 0.6 writes tags to files only at export time, and the upcoming 
Shotwell 0.7 will behave the same way.  We've had many requests for 
Shotwell to (optionally) write tags into existing photo files on the fly 
- this is http://trac.yorba.org/ticket/1290 .  I'm hopeful we'll be able 
to implement this in the next release or two.

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Problem while compiling - GExiv2 ver 2 required

[Adam Dingle]

Steffen,

it looks like you don't have gexiv2 0.2.0, which Shotwell 0.7 requires.  As
mentioned on the gexiv2 web page (http://trac.yorba.org/wiki/gexiv2), you
can download gexiv2 0.2.0 here:

http://yorba.org/download/gexiv2/0.2/libgexiv2-0.2.0.tar.bz2

After extracting files from this archive, you can run 'make' and then 'sudo
make install' to build and install gexiv2 0.2.0.

(Alternatively, you can fetch the trunk version of gexiv2 as described on
the gexiv2 web page.  That currently has version number 0.2.0+trunk.)

I hope this helps!

adam

On Sat, Aug 21, 2010 at 2:30 PM, Steffen Sindzinski  wrote:

> Hi,
>
> I experienced while compiling latest shotwell from svn the following
> message:
>
> Requested 'gexiv2 >= 0.2.0' but version of GExiv2 is 0.1.90+trunk
>
> I installed the latest version but this is still 0.1.90+trunk. Do you
> have any hints to work around?
>
> Regards,
>
> Steffen
>
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell 0.7.0 - a digital photo manager for the GNOME desktop

[Adam Dingle]

Vincent,

On 08/21/2010 09:01 AM, Vincent wrote:
> Great news!
>
> Can we have the list of all the bug that have been fixed in this release? I
> don't find the correct search therme in http://trac.yorba.org :-(
>

There are many.  :)

Unfortunately our bug tracking setup doesn't let you search for this 
very easily.  I hope we'll be able to improve this at some point.  In 
the meantime, here's a list of all the bugs that have *ever* been fixed 
in Shotwell:

http://trac.yorba.org/query?status=closed&max=400&component=shotwell&order=id&col=id&col=summary&col=component&col=status&col=owner&col=type&col=priority&col=reporter&report=16&desc=1&type=bug

All bugs with ticket number 2223 and higher in this list were filed 
after Shotwell 0.6 was released, so those were all fixed in 0.7.  There 
were also some older bugs fixed in 0.7, of course.  Another way to see 
all our fixed bugs is to look at our timeline view 
(http://trac.yorba.org/timeline) and view only opened/closed tickets.  
Of course, that will also show you closed tickets which represent 
features, not bugs, and will also show you closed tickets for other 
Yorba projects.

Once again, I hope we can make some changes to our bug tracking setup to 
make this sort of query easier at some point.

cheers
adam

> Thanks in advance,
>
> Vincent
>
> On Sat, Aug 21, 2010 at 3:33 AM, Lucas Beeler  wrote:
>
>
>> Yorba has released Shotwell 0.7.0, a major update to our digital photo
>> manager. This release includes a host of new features, such as:
>>
>>   * Migration support for F-Spot users: Shotwell can import photos directly
>> from your F-Spot library, preserving tags and ratings.
>>
>>   * Photos can be rated on a 1-5 star scale or marked as rejected. A filter
>> button supports viewing only photos of a specified rating or better.
>>
>>   * A new Last Import page in the sidebar gives you instant access to your
>> most recently imported photo roll.
>>
>>   * Sidebar functionality and appearance have been improved with new icons
>> and inline renaming.
>>
>>   * Shotwell scans your library files at startup, looking for changes.
>> Maintains library consistency when working with photos in other
>> applications.
>>
>>   * Numerous bug fixes and translation updates.
>>
>> We highly recommend that all Shotwell users upgrade.
>>
>> Yorba would like to thank all of our bug testers and translators,
>> without whom this release would not have been possible.
>>
>> You can download a source tarball from the Shotwell home page at:
>> http://www.yorba.org/shotwell/
>>
>> Binaries for Ubuntu Lucid and Maverick users will be available on
>> Yorba's Launchpad PPA 
>> (https://launchpad.net/~yorba/+archive/ppa
>> )
>> within a few days.
>>
>> -- Lucas Beeler
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell 0.7.0 - a digital photo manager for the GNOME desktop

[Adam Dingle]

Yes - it's great that 0.7 is out the door!

This was the first Shotwell release where a number of substantial 
contributions came from people outside Yorba.  I'd particularly like to 
thank the following contributors:

- Bruno Girin implemented importing from F-Spot.  This was a significant 
feature and required numerous patch iterations, so many thanks to Bruno 
for his patience working through the various issues which arose.  By the 
way, Bruno recently wrote a great blog post about contributing to 
Shotwell: 
http://brunogirin.blogspot.com/2010/08/contributing-to-shotwell.html .

- Philip Beam wrote the code that displays icons in the sidebar.  This 
is a very nice visual improvement.

- Marcel Stimberg implemented tag autocompletion.  His final patch came 
only in the last week before the 0.7 release - I'm glad this made it!

- Andrew Higginson improved some of our icons and sent a patch that 
makes Shotwell use more stock icons, which helps our visual consistency.

I'd like to make one clarification about the list of new features 
below.  Shotwell 0.7 does scan your library files at startup to see 
which files are missing, but will not yet update thumbnails if files 
have changed externally.  We had code to do this in the trunk for a 
while, but pulled it before the 0.7 release because we weren't satisfied 
with Shotwell's startup performance (which is very important to us) in 
the case where many files had changed externally.  I'm hopeful this 
feature will return to trunk before too long.

adam

On 08/20/2010 06:33 PM, Lucas Beeler wrote:
> Yorba has released Shotwell 0.7.0, a major update to our digital photo
> manager. This release includes a host of new features, such as:
>
>* Migration support for F-Spot users: Shotwell can import photos directly
>  from your F-Spot library, preserving tags and ratings.
>
>* Photos can be rated on a 1-5 star scale or marked as rejected. A filter
>  button supports viewing only photos of a specified rating or better.
>
>* A new Last Import page in the sidebar gives you instant access to your
>  most recently imported photo roll.
>
>* Sidebar functionality and appearance have been improved with new icons
>  and inline renaming.
>
>* Shotwell scans your library files at startup, looking for changes.
>  Maintains library consistency when working with photos in other
>  applications.
>
>* Numerous bug fixes and translation updates.
>
> We highly recommend that all Shotwell users upgrade.
>
> Yorba would like to thank all of our bug testers and translators,
> without whom this release would not have been possible.
>
> You can download a source tarball from the Shotwell home page at:
> http://www.yorba.org/shotwell/
>
> Binaries for Ubuntu Lucid and Maverick users will be available on
> Yorba's Launchpad PPA (https://launchpad.net/~yorba/+archive/ppa)
> within a few days.
>
> -- Lucas Beeler
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Enhancement: Copy Files

[Adam Dingle]

Lu,

On 08/24/2010 04:51 AM, Lu Timdale wrote:
> Hi,
>
> I really love the way 0.7 came together.  I especially love the rating system.
>   I really don't think it could be much better.  Ratings are stored in the 
> exif
> data of the files, you can set the rating easily, and filter as well.  It's a
> thing of beauty.  :-)
>

I'm glad you like our rating system!  I should point out, though, that 
Shotwell stores ratings in EXIF data only when you export photos or drag 
them to Nautilus.  (We are considering storing ratings and other 
metadata in photo files all the time in a future release, at least as a 
user option - that's http://trac.yorba.org/ticket/1290 .)

> However, now that I've rated some files, I'd like to copy them and create
> another folder (external to shotwell) for emailing, sharing.
>
> Ideally, I would
> 1. Go to whatever view (sorting, filtering by whatever means... tags, rating,
> etc.)
> 2. Select some files
> 3. Copy (right click>  Copy, Ctrl+C, File>  Copy)
> 4. Open Nautilus
> 5. Paste
>
> I don't need to export the files and resample them, I just need the actual 
> files
> as they are.
>

You can simply select the files, then drag them to a Nautilus window.  
Shotwell will copy the files and will embed their ratings in EXIF data.

We might support copy/paste someday (http://trac.yorba.org/ticket/1098) 
but we don't have that yet.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

[Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Shotwell friends and fans,

now that 0.7 is out the door we're beginning development of Shotwell 
0.8, tentatively scheduled for release in November.  The following 
features are our top priorities for 0.8:

- importing/playing videos (ticket #855 at http://trac.yorba.org/report/16)
- optionally storing tags and other metadata in photo files at all times 
(#1290)
- automatically refreshing thumbnails, tags and other metadata when 
photos have been modified externally (#2476)
- automatically importing files which have been added to the library 
directory (#2478)
- allowing the user to configure the naming pattern for directories 
where imported photos are placed (#1597)
- a No Event page that shows all photos which belong to no event 
(typically because they have no EXIF date) (#1712)

Some of these are features which didn't quite make 0.7.  Of course, we 
hope to implement additional features as time permits.  I've added this 
list to the Development section on the Shotwell wiki page 
(http://trac.yorba.org/wiki/Shotwell) and we'll keep it up to date there 
as the feature set for this release evolves.  Feedback is welcome, as 
always!

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Bengt,

thanks for the suggestion.  A search box of some sort (
http://trac.yorba.org/ticket/80) is high on our list and is quite possibly
the top priority after the other features I mentioned.  If all goes well
this could even make 0.8, though I can't promise that.  We hope to implement
a more sophisticated metadata search capability (
http://trac.yorba.org/ticket/1587) within the next couple of releases as
well.

cheers
adam

On Tue, Aug 24, 2010 at 5:31 PM, Bengt Thuree  wrote:

> How about a search function similar to F-Spot?
>
> Since you aim to replace f-spot..
>
> /Bengt
>
> On Tue, 2010-08-24 at 17:23 -0700, Adam Dingle wrote:
> > Shotwell friends and fans,
> >
> > now that 0.7 is out the door we're beginning development of Shotwell
> > 0.8, tentatively scheduled for release in November.  The following
> > features are our top priorities for 0.8:
> >
> > - importing/playing videos (ticket #855 at
> http://trac.yorba.org/report/16)
> > - optionally storing tags and other metadata in photo files at all times
> > (#1290)
> > - automatically refreshing thumbnails, tags and other metadata when
> > photos have been modified externally (#2476)
> > - automatically importing files which have been added to the library
> > directory (#2478)
> > - allowing the user to configure the naming pattern for directories
> > where imported photos are placed (#1597)
> > - a No Event page that shows all photos which belong to no event
> > (typically because they have no EXIF date) (#1712)
> >
> > Some of these are features which didn't quite make 0.7.  Of course, we
> > hope to implement additional features as time permits.  I've added this
> > list to the Development section on the Shotwell wiki page
> > (http://trac.yorba.org/wiki/Shotwell) and we'll keep it up to date there
> > as the feature set for this release evolves.  Feedback is welcome, as
> > always!
> >
> > adam
> >
> > ___
> > Shotwell mailing list
> > Shotwell@lists.yorba.org
> > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
> >
>
> --
> With Regards
>
> Bengt Thuree
> be...@thuree.com
>
>
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Thanks to everyone for all the ideas on this email thread and for all 
the enthusiasm.  I think I can safely say that we won't be able to 
implement everything suggested here for 0.8, sadly.  But these are all 
great ideas and I hope we can get to them all within the next few releases.

It might not be so hard to implement a feature that emails photos (using 
the default email client the user has selected in their GNOME 
preferences) and, as Todd pointed out, that might be a very useful 
feature for some less sophisticated users especially.  We'll look into 
that as a possibility for 0.8.

It would also be nice to implement at least one enhancement related to 
photo searching/organization (search by name, Ctrl+click to search 
multiple tags or hierarchical tags).  No promises, but we'll try to keep 
these near the top of our priority list as well since there's clearly a 
lot of interest in these features.

cheers
adam

On 08/25/2010 07:17 AM, Ingo Lütkebohle wrote:
> On 25.08.2010 14:42, Vincent wrote:
>
>> Is there any new about hierarchical tags?
>> Is it still a good candidate for 0.8? It would be one of the last thing that
>> F-Spot has (and Shotwell not)  and it is very usefull.
>>  
> Hierarchical tags have some user-interface issues and, IMHO, introduce
> additional complexity for functionality that can also be achieved using
> combination search (tag a and tag b).
>
> Additionally, many tag-uis allow you to list which other tags are
> present on objects that have a particular tag. For example, see
> delicious.com. This also facilitates the browsing functionality that
> some people like hierarchy for.
>
> cheers,
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Gilles,

On 08/25/2010 11:25 PM, Gilles wrote:
>
> Hello All
>
> I have recently discovered shotwell and seem to answer to my quest of
> good photo manager.
>
> A little suggestion, is there a way to normalise name of pictures during
> the import ? for example, i alway rename my picture in lower cases, is
> it an option to do this ? if no, perhaps a new impovement ?
>

I agree this would be a nice feature, but we don't have this yet.  We 
have a ticket for this at http://trac.yorba.org/ticket/1942 - that's a 
good place for further discussion about this.

> Thanks in advance and continue your great job on shotwell.
>

Thanks - I'm glad you like Shotwell!

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Gendre,

On 08/25/2010 12:35 PM, Gendre Sebastien wrote:
> For send Photo via email, why don't use a part of Nautilus-Send-to (Like
> RhyThmbox)?
>
> With this we can send photos (or videos) to contact via email, Jabber
> (Empathy), Bluetooth, etc...
>

that's a great suggestion.  That would allow the user to send to many 
destinations, not just email, and would also make Shotwell more 
consistent with the GNOME desktop in general.  I hope we can do this.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Translation mistake in french

[Adam Dingle]

Vincent,

On 08/26/2010 06:59 AM, Vincent wrote:
> Hi gents,
>
> I don't really know if this is the good place to tell it, but there is a
> mistake in the "Photo" menu, where
>
> "_Adjust Date and Time..."
>
> is translated has :
>
>   "L'ajustement de l'heure n'a pas pu être annuler sur le fichier photo
> suivante."
>
> (See image attach for more detail)
>
> So this file: 
> http://www.transifex.net/projects/p/shotwell/c/default/view/po/fr.po
> should be corrected (line 2412).
>

thanks very much for pointing this out.  We'll fix this for 0.7.1 
(hopefully coming today!)

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] How to force a db rebuild, or rescan the Pictures directory

[Adam Dingle]

Brian,

in this situation, you can simply reimport the Pictures folder into 
Shotwell.  Shotwell will ignore any photos which are already in its 
library, and will import the others.

And yes, in 0.8 we do plan to extend Shotwell so it can notice the new 
files and import them automatically (there will probably be a preference 
checkbox to enable this behavior).

cheers
adam

On 08/26/2010 01:57 PM, Brian Candler wrote:
> Hi,
>
> I think this is probably a FAQ, but I can't find the answer.
>
> I have 0.7.0-1~lucid1 running under Ubuntu Lucid x86_64. In a fit of
> reorganisation, I decided to move a bunch of existing photos (which I'd
> already manually catalogued by year) under ~/Pictures//..., where
> Shotwell keeps its photos.
>
> Unfortunately, they don't appear in Shotwell, and I think this is because
> they're not in Shotwell's library database.
>
> I've found there's a ticket for 0.8 to handle this automatically:
> http://trac.yorba.org/ticket/2478
>
> but until then, is there a way I can force Shotwell to rebuild its database
> of photos? Or tell it to rescan or import pictures in-place?
>
> I'm a bit scared of using "Import from Folder" when the files are already
> under the Pictures folder, in case they get overwritten in situ - unless
> someone can confirm this is safe.
>
> Otherwise, I was thinking that I could move all the photos into some other
> directory, wipe Shotwell's database, import them all - which should copy
> them under Pictures - and then delete the other location. I'd rather avoid
> such a potentially destructive set of actions if at all possible.
>
> Many thanks,
>
> Brian.
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

(Replying to the mailing list.)

On 08/26/2010 01:01 PM, Peter DO Smith wrote:
> Would not the planned plugin architecture be a good place to implement
> things like this?
> Then we could write plugins to do our favourite transformations.
>

Yes, as long as we provide hooks which allow plugins to transform photos 
at import time.  That would seem like a nice capability to offer.

> How far off is the implementation of a plugin architecture? I accept this is
> a far from trivial task.

This is honestly probably still a couple of releases away since we're 
still missing a number of other basic features, and since many of 
Shotwell's internal APIs (which will be exposed to plugins) are still in 
flux as Shotwell matures.

> What language tools would the plugin architecture
> support? My vote would be for Python.
>

I think we should build our plugin system using libpeas 
(http://live.gnome.org/Libpeas).  Then plugin authors will be able to 
use C, Python or JavaScript as they please.

adam

>> Gilles,
>>
>> On 08/25/2010 11:25 PM, Gilles wrote:
>>  
>>> Hello All
>>>
>>> I have recently discovered shotwell and seem to answer to my quest of
>>> good photo manager.
>>>
>>> A little suggestion, is there a way to normalise name of pictures during
>>> the import ? for example, i alway rename my picture in lower cases, is
>>> it an option to do this ? if no, perhaps a new impovement ?
>>>
>>>
>> I agree this would be a nice feature, but we don't have this yet.  We
>> have a ticket for this at http://trac.yorba.org/ticket/1942 - that's a
>> good place for further discussion about this.
>>
>>  
>>> Thanks in advance and continue your great job on shotwell.
>>>
>>>
>> Thanks - I'm glad you like Shotwell!
>>
>> adam
>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

On 08/26/2010 02:39 PM, Bruno Girin wrote:
> On Thu, 2010-08-26 at 14:22 -0700, Adam Dingle wrote:
>
>
>> I think we should build our plugin system using libpeas
>> (http://live.gnome.org/Libpeas).  Then plugin authors will be able to
>> use C, Python or JavaScript as they please.
>>  
> If C is an option does it mean that you could potentially write a plugin
> in Vala too?
>

Absolutely.  By the way, gedit now uses libpeas for its own plugin 
system (in fact libpeas evolved out of gedit - see 
http://log.istique.net/2010-06-03/announcing-libpeas.html) and some 
gedit plugins are written in Vala (including one of my favorite gedit 
plugins: http://yorba.org/valencia/  :)  .

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Update to 0.7.1

[Adam Dingle]

Dominic,

On Thu, Aug 26, 2010 at 6:20 PM, D.W. Lloyd  wrote:

> Hi,
>
> On Ubuntu Lucid, I tried to update from 0.5.1+trunk to 0.7.1 by:
>
> $ sudo add-apt-repository ppa:yorba/ppa
> $ sudo apt-get update
> $ sudo apt-get install shotwell
>
> It seemed to go OK, but when I run Shotwell I still get 0.5.1+trunk. I
> wonder if this is connected to the fact that I previously compiled
> Shotwell when I was working on ticket 1939. Is there something I have to
> do to get 0.5.1+trunk to go away?
>

Your PPA update placed Shotwell 0.7.1 in /usr/bin.  If you previously
compiled and installed Shotwell 0.5.1+trunk yourself, that binary is
probably in /usr/local/bin, which appears first in your PATH, so that's the
version that's running.

If you still have the source directory where you build Shotwell 0.5.1, cd to
that directory and type "sudo make uninstall".  That should remove 0.5.1 and
you will be only left with 0.7.1.

If that directory is no longer around, then you should probably download the
0.5.1 sources, cd there and type "sudo make uninstall".  Alternatively, you
could simply remove /usr/local/bin/shotwell, but that won't be a clean
uninstall and you'll still have other Shotwell-related files in /usr/local
that could potentially affect your 0.7.1.

I hope this helps.  If you're still stuck, email again and we'll figure it
out.

cheers
adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] How to force a db rebuild, or rescan the Pictures directory

[Adam Dingle]

(Replying to the mailing list.)

Simon,

good point.  I consider that a bug, and have just created a ticket for 
this here:

http://trac.yorba.org/ticket/2487

adam

On 08/26/2010 04:40 PM, Simon Spannagel wrote:
> Hej Adam,
>
> but the problem in doing it this way is, that Shotwell would not 
> recognize edited pictures as a copy of an original one - so I get them 
> twice in the database...
>
> greetings,
> simon
>
>
> Am 26.08.2010 23:11, schrieb Adam Dingle:
>> Brian,
>>
>> in this situation, you can simply reimport the Pictures folder into
>> Shotwell.  Shotwell will ignore any photos which are already in its
>> library, and will import the others.
>>
>> And yes, in 0.8 we do plan to extend Shotwell so it can notice the new
>> files and import them automatically (there will probably be a preference
>> checkbox to enable this behavior).
>>
>> cheers
>> adam
>>
>> On 08/26/2010 01:57 PM, Brian Candler wrote:
>>> Hi,
>>>
>>> I think this is probably a FAQ, but I can't find the answer.
>>>
>>> I have 0.7.0-1~lucid1 running under Ubuntu Lucid x86_64. In a fit of
>>> reorganisation, I decided to move a bunch of existing photos (which I'd
>>> already manually catalogued by year) under ~/Pictures//..., where
>>> Shotwell keeps its photos.
>>>
>>> Unfortunately, they don't appear in Shotwell, and I think this is 
>>> because
>>> they're not in Shotwell's library database.
>>>
>>> I've found there's a ticket for 0.8 to handle this automatically:
>>> http://trac.yorba.org/ticket/2478
>>>
>>> but until then, is there a way I can force Shotwell to rebuild its 
>>> database
>>> of photos? Or tell it to rescan or import pictures in-place?
>>>
>>> I'm a bit scared of using "Import from Folder" when the files are 
>>> already
>>> under the Pictures folder, in case they get overwritten in situ - 
>>> unless
>>> someone can confirm this is safe.
>>>
>>> Otherwise, I was thinking that I could move all the photos into some 
>>> other
>>> directory, wipe Shotwell's database, import them all - which should 
>>> copy
>>> them under Pictures - and then delete the other location. I'd rather 
>>> avoid
>>> such a potentially destructive set of actions if at all possible.
>>>
>>> Many thanks,
>>>
>>> Brian.
>>> ___
>>> Shotwell mailing list
>>> Shotwell@lists.yorba.org
>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>>
>>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Up next: Shotwell 0.8

[Adam Dingle]

Peter,

there should be no need for libpeas to have explicit support for Vala.  
The magical thing about Vala is that the Vala compiler generates 
GObject-based C code, which can be used just about anywhere that C code 
normally works.

adam

On 08/27/2010 12:06 AM, Peter DO Smith wrote:
> Thanks Adam, that is good news. Will you wait for Vala support in Libpeas?
>
> On Thu, Aug 26, 2010 at 11:22 PM, Adam Dingle  wrote:
>
>
>> (Replying to the mailing list.)
>>
>>
>> On 08/26/2010 01:01 PM, Peter DO Smith wrote:
>>
>>  
>>> Would not the planned plugin architecture be a good place to implement
>>> things like this?
>>> Then we could write plugins to do our favourite transformations.
>>>
>>>
>>>
>> Yes, as long as we provide hooks which allow plugins to transform photos at
>> import time.  That would seem like a nice capability to offer.
>>
>>
>>   How far off is the implementation of a plugin architecture? I accept this
>>  
>>> is
>>> a far from trivial task.
>>>
>>>
>> This is honestly probably still a couple of releases away since we're still
>> missing a number of other basic features, and since many of Shotwell's
>> internal APIs (which will be exposed to plugins) are still in flux as
>> Shotwell matures.
>>
>>
>>   What language tools would the plugin architecture
>>  
>>> support? My vote would be for Python.
>>>
>>>
>>>
>> I think we should build our plugin system using libpeas (
>> http://live.gnome.org/Libpeas).  Then plugin authors will be able to use
>> C, Python or JavaScript as they please.
>>
>> adam
>>
>>
>>   Gilles,
>>  
>>>> On 08/25/2010 11:25 PM, Gilles wrote:
>>>>
>>>>
>>>>  
>>>>> Hello All
>>>>>
>>>>> I have recently discovered shotwell and seem to answer to my quest of
>>>>> good photo manager.
>>>>>
>>>>> A little suggestion, is there a way to normalise name of pictures during
>>>>> the import ? for example, i alway rename my picture in lower cases, is
>>>>> it an option to do this ? if no, perhaps a new impovement ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> I agree this would be a nice feature, but we don't have this yet.  We
>>>> have a ticket for this at http://trac.yorba.org/ticket/1942 - that's a
>>>> good place for further discussion about this.
>>>>
>>>>
>>>>
>>>>  
>>>>> Thanks in advance and continue your great job on shotwell.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Thanks - I'm glad you like Shotwell!
>>>>
>>>> adam
>>>>
>>>> ___
>>>> Shotwell mailing list
>>>> Shotwell@lists.yorba.org
>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>>>
>>>>
>>>>
>>>>  
>>>
>>>
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] How to force a db rebuild, or rescan the Pictures directory

[Adam Dingle]

Brian,

On 08/27/2010 02:14 AM, Brian Candler wrote:
> The dialog prompts the following:
>
>Shotwell can copy the photos into your library or it can link to the
>photos without duplicating them.
>
>[Cancel] [Copy into Library] [Create Links]
>
> Does it matter which I choose in this case, given that the files are already
> within the library?
>

It does not matter: if files are already inside the library directory, 
then Shotwell won't copy them.  Given this, it's a bit silly that we 
pose the question in this situation since it will probably only confuse 
the user.  I've just ticketed this here: http://trac.yorba.org/ticket/2488 .

> Now I think about it, I guess when it says "Create Links" it doesn't
> actually mean creating symlinks inside the library, but just that the
> database entry refers directly to the original location in the filesystem.
> Is that right?
>

Yes, that's right.

> If so, perhaps the language could be clearer. How about:
>
>Shotwell can copy the photos into your library directory or it can use
>them in their original location.
>
>[Cancel] [Copy into Library] [Use where they are]
>

You're right: the term "Create Links" could be confusing since it sounds 
like we might be creating symbolic links, but we're not.  I've ticketed 
this at http://trac.yorba.org/ticket/2489 .

> Maybe there could be another option which is to copy into library and delete
> from the original location, which would be useful when importing from a
> camera.
>

I think users will usually use Shotwell's built-in camera import 
feature, which does ask whether to delete files from the camera, rather 
than dragging from the camera's mounted filesystem into Shotwell.  For 
advanced users, we might still implement a drag-and-drop modifier key 
which causes the files to be moved rather than copied in this situation; 
see http://trac.yorba.org/ticket/603 .

cheers
adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Storing event in filesystem path

[Adam Dingle]

Thanks for all the discussion on this thread about Shotwell and 
filesystem paths.  It's great to see how different users are using (and 
want to use) Shotwell!

I completely agree that one size does not fit all.  Some users don't 
care at all about filesystem paths: they simply want to import their 
photos into a library directory and then work with them using a photo 
program that lets them forget about where they are all stored 
physically.  Other users do care, however: they want control over where 
photos are placed and may have large existing photo collections which 
they have organized into folders manually.

Both of these viewpoints are reasonable.  Today, however, Shotwell only 
really works well for users who don't care where their files are, since 
it uses a fixed directory pattern at import time and since it doesn't 
expose photos' physical locations through the user interface.

We plan to evolve Shotwell so that it can make both kinds of users 
happy.  One step in that direction is letting the user choose a file 
naming pattern (http://trac.yorba.org/ticket/1597) to be used at import 
time, which we're hoping to implement in 0.8.

We'd also like to implement a directory folder tree in the sidebar which 
you can use to browse through photos in their physical locations 
(http://trac.yorba.org/ticket/1594).  With that, a user like Brian 
should be happy, I think: when using that tree, moving a photo from 
folder to folder will actually move it on the filesystem, and renaming a 
sidebar item will rename the directory.  This would make Shotwell behave 
a lot more like gThumb.  We could provide an option to display either 
the classic event tree or a folder tree as the user prefers.

I know that many users would also like to be able to drag photos to 
applications other than Nautilus, as suggested in this thread.  The 
reason we can't do that today is that Shotwell doesn't currently keep 
up-to-date full-resolution photos on hard disk, and it's hard to 
generate these on the fly at drag-and-drop time due to the way that GTK 
drag and drop works.  The solution is to (optionally) have Shotwell 
generate full-resolution copies on disk after every edit 
(http://trac.yorba.org/ticket/1798).  That will use more disk space, but 
will make drag and drop to applications work.

One final thought: we agree that it would be great if Shotwell could 
store more of its state along with photo files so that they can be 
seamlessly shared among photo applications (but still cache it in a 
SQLite database for fast access, presumably).  One big step in that 
direction is storing metadata in photo files on the fly 
(http://trac.yorba.org/ticket/1290).

adam

On 08/27/2010 07:34 AM, Lu Timdale wrote:
> I think we can agree that one size does not fit all.
>
> This applies for
> 1.  Storage of the new files in whatever file naming pattern chosen by the 
> user
> (exif>  filesystem/sqlite)
>   [I believe this is coming in 0.8]
> or
> 2.  Organizing existing files in library to match that pattern (exif/sqlite>
> filesystem)
> or
> 3.  Extracting parameters (event name, etc.) based on filesystem info
> (filesystem>  sqlite/exif)
>
> I don't see this as a problem, if it is done as optional approach based on a
> checkbox or two.
>
> It doesn't mean that the default can't be whatever the yorba team sees as the
> most used scenario.  Currently I see this as point 1 only.
>
> Howeer, keep in mind that even iTunes has a setting to "keep my music 
> organized"
> or "let me organize it myself".  I believe in their case, it applies for all
> music, not just new.
>
>
> I am desperately waiting on 1 before I can switch over to use shotwell.
> I personally would also see value in 2 and 3.
> 2) I have changed my mind about how I want the files organized every few
> years.   So there are slight variations on the structure of the files.   It is
> virtually impossible to restructure the old content manually.  This will never
> change unless it's automated.
> 3) My existing photo library (about 12 years / 200GB) have event name info
> embedded in the folder names and/or filenames.  It would be good if I didn't
> have to redo all this work and it could be imported into Shotwell... the best
> photo management app.  :-)It is again virutally impossible to do this
> manually.
>
>
>
> 2&  3 can be somewhat alleviated by allowing file system view of the folders
> that have been added to the library.
>
>
> I believe the real intent of this topic is that if a user WANTS all 3 sources 
> of
> data (exif/sqlite/filesystem) to be in sync, he/she should have that option
> avaiable to them.
>
> Just my 2 cents.  :-)
>
>
>
> Lu Timdale
> lutimd...@yahoo.com
>
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bi

Re: [Shotwell] Go to Event

[Adam Dingle]

Yes - this is a good idea.  We have a ticket for this at 
http://trac.yorba.org/ticket/2248.  I've just upped the ticket priority 
to high since I think this would be useful and might not be too hard to 
implement.

adam

On 08/27/2010 01:07 PM, Simon Spannagel wrote:
> Hej,
>
> that would be really great - if I access pictures by clicking on one of
> the tags, I can't find out to which event that photo belongs. This is
> especially for landscape photos very important.
> So an entry in the context menu would solve this issue - and I could
> easily jump to the event (and the selected photo?) to see, if there are
> other (untagged) photos available.
>
> Greetings,
> Simon
>
>
>
> Am 27.08.2010 21:55, schrieb D.W. Lloyd:
>
>> How about adding "Go to Event" to the right-click menu for photos?
>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Lost 99% of my tags and events

[Adam Dingle]

Ralf,

On 08/29/2010 05:59 AM, Ralf Butler wrote:
> Hi there,
>
> After updating my library location, restarting shotwell it crashed.

How did you update your library location?  Did you rename your library 
directory, change the directory in Shotwell's preferences dialog, or both?

I'm sorry to hear that Shotwell crashed.  If you can reproduce this 
crash we'd certainly like to hear about it, including a sequence of 
steps that make the crash happen.

> Tried to start it a 2nd time and ... voila ... nearly all my tags and events 
> are gone!!!
> All thumbnails are still there, however they all are listed under 'Missing 
> Files'.
>
> Is there any way to get my tags and events back?
>

Yes - you'll get your tags and events back if you move your photo files 
back to the location where Shotwell thinks they should be.  For example, 
if your library directory was originally /home/Pictures and you renamed 
it to /home/Photos, you'll see the behavior you described: Shotwell will 
list all your photos as missing since it can't find them in 
/home/Pictures.  If you rename Photos back to Pictures, your tags and 
events will come back the next time you restart Shotwell.

Unfortunately in Shotwell 0.7 you must keep your library directory in 
one place - you can't rename it while keeping your tags and events.  We 
know this is a significant limitation, and we're hoping to improve this 
in Shotwell 0.8.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photo-viewer and importing photos.

[Adam Dingle]

Chris,

On 08/28/2010 06:56 AM, Chris Game wrote:
> Niggles on Shotwell 0.6.1 photo-viewer: could a rotate-left icon be
> added to the toolbar as well as rotate-right? I always seem to need
> the left rather than the right on my stuff.

As Mattias helpfully pointed out, you can press the Ctrl key to reverse 
the rotation direction.

> Secondly, there is no
> 'delete' command on the toolbar or the menus or the context menu
> (again in the viewer). This makes sorting wheat from chaff on
> importing new photos more work that necessary (or I could use eog
> instead of Shotwell but that seems unnecessary).
>

Yes - it would be useful to be able to delete photo files from the 
viewer.  We have a ticket for this here:

http://trac.yorba.org/ticket/2231

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell improvements and existing users

[Adam Dingle]

On 08/28/2010 08:00 AM, Florian Manach wrote:
> Hi everybody,
>
> First message here, so let me introduce myself.
>
> Florian, 24, France.
> System&  Network Administrator, Linux enthousiast, Ubuntu user and
> amateur photographer.
>

Welcome, Florian!  :)

> I discovered Shotwell when I knew it will be part of Ubuntu 10.10.
>
> First of all, I want to congratulate all the project team for making
> such a simple, pleasant to use, photo management system.
>

Thanks!  :)

> Reading the mailing list, I've learned that many of the improvements I
> want before actually switch from "Nautilus directory based management"
> to Shotwell will be included in the next versions (like in-file tagging,
> possibility to specify a path when importing).
>
> Let me now explain, what I think would be good for these improvements.
>
> One of the thing preventing me from switching NOW is that the tags are
> not stored in the files in the stable version. So I think I will wait
> for the stable version including this feature to switch to Shotwell.
>
> So when you will add this feature, I think it should be good to add a
> way for existing users to use it.
>
> Use case : Bob uses Shotwell and tags his photos. Tags are stored on the
> database. A new versions pops up and now, Bob can choose to store the
> tags inside the files. But what to do with his existing library. I think
> Bob should have the possibility by and option for an example, when he
> chooses to embed the tags in his photos, to embed all his previous tags,
> to his previous tagged photo files.
>
> To make it simple : When you add an option on the workflow, I think you
> should also add a way for existing users to apply it to their existing
> photo library and not only for the pictures handled since they activate
> the option.
>

Thanks for the suggestion, and I completely agree: when the user enables 
the option to store tags in photo files, we should (perhaps optionally?) 
write all existing tags into the Shotwell library.  Of course, this may 
take some time, but it will happen in the background so you'll be able 
to continue to use Shotwell while tags are being written.  In Shotwell 
0.8, we're planning to display a progress bar at the bottom of the 
sidebar (immediately above the Basic Information pane) when background 
operations like this are taking place (see 
http://trac.yorba.org/ticket/2491 ).

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell should not unmount the camera for importing

[Adam Dingle]

On 08/29/2010 08:27 PM, David Velazquez wrote:
> I agree with you here. Asking a beginner if it's ok to unmount a device
> before proceeding is counter-intuitive to me. If I were just starting off
> with Linux common sense would probably dictate that a device should be
> mounted before anything can be done with it. I get that it needs to be
> unmounted from one application to be used by another (or at least I think
> that's what happens), but that's not necessarily common knowledge and
> certainly would not be for someone new to all of this.
>

I also agree.  In case it's not obvious to some of you on this mailing 
list, Shotwell can only import photos from a camera when it's 
*unmounted*.  When it's mounted, by contrast, the camera's filesystem 
shows up in Nautilus but Shotwell cannot read it.  Yes, this is 
confusing to beginners (and probably not only to beginners).

> On Sun, Aug 29, 2010 at 5:55 PM, thibaut bethune
> wrote:
>
>
>> Hi,
>>
>>  From a beginner point of view, having Shotwell asking if the camera
>> has to be unmounted before importing sounds a bit weird..!
>>
>> Lots of applications (see gThumb with Martin Pitt's patch) want to
>> unmount cameras before proceeding but it's a mistake to me. Once
>> unmounting, it can't be accessible through Nautilus for instance.
>> Applications should not fight against the system so Nautilus and
>> Shotwell could be able to share the device.
>>
>> Maybe you could look at phraymd (Python application) which succeed in
>> importing photos without unmounting the camera, which seems to be the
>> only way to proceed. For what i know i think that spillz (phraymd
>> developper) makes use of GVfs for that. Once he pointed out the GVfs
>> FUSE hack explained here :
>> http://davidz25.blogspot.com/2008/10/getting-gvfs-and-fuse-right.html,
>> adding : "Of course, the GVfs API provides higher level access than
>> what FUSE gives, so I will ultimately use that in phraymd."
>>  

I agree it would be nice if Shotwell could import photos from a camera 
without unmounting, and thanks for pointing out that phraymd does that.  
I don't know if that would be technically easy, though.  I've created a 
ticket (http://trac.yorba.org/ticket/2498) to track that idea.

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photo-viewer and importing photos.

[Adam Dingle]

Chris,

there's not as much horizontal toolbar space available as you might 
think: we want Shotwell to run on netbooks with a 1024-pixel horizontal 
resolution.  At that size, there's no more room for another rotate 
button in the main Shotwell application.  I suppose we could add one 
just to the direct viewer, but I think it's nice to have this be 
consistent between the main application and the viewer.

The Shotwell list may not be so easy to find, but I hope that the new 
help documentation which shipped with Shotwell 0.7 will help with this 
kind of question.  If you choose Help->Contents and choose the topic 
"Rotate or flip a photo", you'll see this:

You can rotate your photos left and right (clockwise and
counterclockwise) with the Rotate button on the toolbar of most
views. You can also make a mirror image of any photo.

To rotate right, click on the Rotate button. To rotate left, press
and hold the Ctrl key and then click the button. Both commands are
available in the Photos menu too.

adam

On 08/30/2010 12:30 PM, Chris Game wrote:
> Yes thanks to Mattias for pointing that out, but I would just say
> that the interface looks wrong with just the one rotation arrow
> showing, there is plenty of space for another, and that the Shotwell
> list is not easy to find for the general user of the application!
>
> Regds, Chris Game
>
> On Mon, 30 Aug 2010, Adam Dingle wrote:
>
>> Chris,
>>
>> On 08/28/2010 06:56 AM, Chris Game wrote:
>>> Niggles on Shotwell 0.6.1 photo-viewer: could a rotate-left icon be
>>> added to the toolbar as well as rotate-right? I always seem to need
>>> the left rather than the right on my stuff.
>>
>> As Mattias helpfully pointed out, you can press the Ctrl key to 
>> reverse the rotation direction.
>>
>>> Secondly, there is no
>>> 'delete' command on the toolbar or the menus or the context menu
>>> (again in the viewer). This makes sorting wheat from chaff on
>>> importing new photos more work that necessary (or I could use eog
>>> instead of Shotwell but that seems unnecessary).
>>>
>>
>> Yes - it would be useful to be able to delete photo files from the 
>> viewer. We have a ticket for this here:
>>
>> http://trac.yorba.org/ticket/2231
>>
>> adam
>>
>>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] new icon for shotwell?¿

[Adam Dingle]

Dani,

On 08/26/2010 03:51 AM, Dani Planas Armangue wrote:
> Shotwell is becoming one of the best photo manager for gnome desktoip.
> now ubuntu will include it on next release, you need a good image, a
> good brand. I hope you like.
>
> first impresions are important.
>

thanks for your icon proposal.  This mailing list doesn't allow 
attachments, so the best way to send binary files is to upload them to a 
file hosting service and post the URL here.  I've put your tar file here:

http://yorba.org/download/scratch/lightgraphite_shotwell_icon.tar

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photo-viewer and importing photos.

[Adam Dingle]

On 08/30/2010 12:50 PM, Brian Candler wrote:
> On Mon, Aug 30, 2010 at 12:42:09PM -0700, Adam Dingle wrote:
>
>> there's not as much horizontal toolbar space available as you might
>> think: we want Shotwell to run on netbooks with a 1024-pixel horizontal
>> resolution.  At that size, there's no more room for another rotate
>> button in the main Shotwell application.
>>  
> Improve the tool tip? It currently just says "Rotate the photo right" unless
> you happen to know to press Ctrl.
>
> Maybe "Rotate the photo right (press ctrl for left)" ?
>

That's a good suggestion.  We'll implement this soon: 
http://trac.yorba.org/ticket/2499

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Irc channel setup

[Adam Dingle]

By popular demand, we've now set up an IRC channel for Shotwell: it's 
#shotwell at irc.gnome.org (also known as GimpNet).  I've updated the 
wiki to mention this channel as well.

The Shotwell developers do tend to use email more than IRC so the 
mailing list is still probably the best place to get many questions 
answered.  But #shotwell should be a great place for community 
discussion and I'm sure the Shotwell developers will show up sometimes 
too.  :)  Enjoy!

adam

On 08/25/2010 05:05 PM, David Velazquez wrote:
> There was a channel setup on freenode for shotwell, #shotwell, a few months
> ago but it never quite gained traction and I think the 3 or so people that
> were hanging out in there have since stopped. I think this would be a great
> idea to get the community in one place and talking.
>
> On Wed, Aug 25, 2010 at 2:17 PM, Tajidin Abdwrote:
>
>
>> I was wondering that its time for yorba to set up a Irc channel if you need
>> help to do so i could be of service. I feel like shotwell has become mature
>> enough that its a good idea now. Also introduce the other products
>> available
>> from Yorba. To really have some traction in Open Source.
>> What do you think Adam?
>>
>>
>> Tajidin
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell improvements and existing users

[Adam Dingle]

Simon,

thanks for the suggestion.  I think that we'll start out just by 
implementing options 1 and 2 from your message.  Regarding option 3, I'm 
reluctant to remind the user since we never want Shotwell to be 
annoying, but we could possibly provide a command you can run manually 
to write tags to files.  I'm hopeful that Shotwell will still be 
pleasant to use even when in-file tagging is turned on, but we'll see 
what the performance is like once this is implemented.

cheers
adam

On 08/30/2010 03:02 PM, Simon Spannagel wrote:
> Hejsan,
>
> what about a 3-way-option to set Shotwell's behaviour according to the
> in-file-tags:
> 1) in-file-tagging off: no additional metadata will be written into the
> photos.
> 2) on-the-fly in-file-tagging: every change is immediately written into
> the file
> 3) in-file-tagging sometimes (like an update): this could give the user
> the posibility to work as fast as now with Shotwell, but "store" the
> metadata to his files on certain points. Perhaps he could be reminded
> like "The tags of 321 photos are not written to the files. Do you want
> to do that now? (This could slow down Shotwell for a while.)"
>
> This would cover the above mentioned problem as well: the first time,
> the user starts his new Shotwell-version, he would be kindly reminded,
> that 10.000 photos are waiting to be updated with tags... :-D
>
> Greetings,
> Simon
>
>
>
> Am 30.08.2010 18:56, schrieb Adam Dingle:
>
>> Thanks for the suggestion, and I completely agree: when the user enables
>> the option to store tags in photo files, we should (perhaps optionally?)
>> write all existing tags into the Shotwell library.  Of course, this may
>> take some time, but it will happen in the background so you'll be able
>> to continue to use Shotwell while tags are being written.  In Shotwell
>> 0.8, we're planning to display a progress bar at the bottom of the
>> sidebar (immediately above the Basic Information pane) when background
>> operations like this are taking place (see
>> http://trac.yorba.org/ticket/2491 ).
>>
>> adam
>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photo-viewer and importing photos.

[Adam Dingle]

On 08/31/2010 12:09 PM, Bruno Girin wrote:
> So I think that being able to handle the situation where you run out of
> space gracefully would be better than arbitrarily not including useful
> controls.
>
> My suggestion would be to only display the icons with no text if the
> width of the toolbar is below the width of the image pane: this way you
> can deal properly with all the use cases mentioned above and have a
> "rotate left" button too.
>

Yes, we should degrade gracefully, and we don't do a great job of that 
today: the zoom slider currently disappears first when space is short, 
which is not very useful.  See http://trac.yorba.org/ticket/2445 .  I 
agree that if possible, we should display icons with no text when 
there's a limited amount of space.  We're still undecided about having 
both left and right rotate buttons since we want to keep the toolbar 
button set small, but we'll think more about this.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

[Shotwell] Shotwell engineering position

[Adam Dingle]

Yorba would like to hire a full-time software engineer to join the 
Shotwell development team in the immediate future.  If interested, you 
must have permission to work in the U.S. and must be able to work in our 
office in San Francisco - we are not considering remote candidates right 
now.  You must have experience developing large programs in C and/or an 
object-oriented language such as C++, Java or C#.  Experience with GNOME 
and/or GTK development would be helpful but is not absolutely required.  
Enthusiasm about open source and/or photography is a big plus.  You can 
read more on our Web site at http://yorba.org/jobs/ .  Thanks!

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Photo-viewer and importing photos.

[Adam Dingle]

On 09/01/2010 04:26 AM, Peter DO Smith wrote:
> Chris,
> Within Shotwell the Del button works in the following views
> 1) the icon view
> 2) the intermediate view after double click
> 3) the full screen view after F11
> These are all the views of the main Shotwell program.
>
> I tried opening the Shotwell viewer from the file manager as you described
> and then the Del button does not work. Considering it works within ALL the
> normal views I would guess that the developers may have intended not to
> allow deletion from there, or alternatively it was an oversight and it is
> good that we should bring it to their attention. But the developers will
> know.
>

Yes - we'd like to implement deletion in the Shotwell viewer, but 
haven't gotten to that yet.  The ticket 
http://trac.yorba.org/ticket/2231 tracks this.  This is a popular 
request, so I've just upped the ticket priority to high; I hope we can 
implement this for 0.8.

cheers
adam

> Either way, can I suggest we strive for some civility in these discussions?
> We are all on the same side and have no need to prove a point.
>
> On Wed, Sep 1, 2010 at 12:17 AM, Chris Game  wrote:
>
>
>>  
>>> Chris, the Del button is a convenient shortcut that works in all views.
>>>
>>>
>> (All together now) Oh no it doesn't!
>>
>> Try opening a folder of photos in the file manager, r-click on one and
>> 'Open in Shotwell Photo Viewer'; in the SPV hit 'Delete', result: no
>> action!
>>
>> (Give me some credit for trying that for goodness sake!)
>>
>> On the arrow usability issue there's an old piece of advice worth
>> bearing in mind: 'Keep things as simple as possible', it reduces the
>> chance of mistakes however experienced you are. Relying on shortcuts
>> or tooltips is making things complicated.
>>
>> Regards, Chris Game
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] XCF / Versioning support?

[Adam Dingle]

On 09/01/2010 04:02 PM, e.m.fields wrote:
> Hi. Ubuntu user, I've been running around trying to nail down which of the
> photomanager applications can suit my needs, between f-spot and digikam.
> Checking out shotwell now, as it's moving to standard in 10.10 "Maverick"
> release.  Looks good.
>

Hello!

> Main feature requests that I've found has (too late) been added in F-spot is
> the much-needed XCF support, as well as decent versioning system for images,
> and file-folder monitoring.  I would like to know if these exist in
> shotwell, or if plans to do so are in near-future.
>
> 1. XCF support
> XCF is the native GIMP image editor image format, necessary for users who
> rely heavily on this standard linux application.
> i . Make sure that shotwell is able to index and view XCF files.
> ii. Make an edit in gimp, export as JPEG/PNG and have this edit added to
> shotwell
> iii. Open in GIMP for an edit, and save as XCF, and have this edit added to
> shotwell.
>

Shotwell has no support for XCF today.  Regarding your question (ii): 
Shotwell can open a photo in an external editor, and if you open a JPEG 
photo in GIMP from within Shotwell and save your changes in JPEG format, 
Shotwell will notice the change and update its thumbnails.  (If you open 
the photo from GIMP *outside* Shotwell and save, then Shotwell 0.7 will 
not notice the change, but the trunk build will since we've implemented 
this recently.)

I've just added a ticket for us to support XCF format (and/or its 
possible successor, OpenRaster): http://trac.yorba.org/ticket/2509 .  
This is probably not near the top of our priority list for the next 
couple of releases, but patches are gladly accepted!  :)

> 2. Versioning
> F-spot has a great versioning system, and digikam has moved in this
> direction as well.  Multiple versions of one image can be "stacked" on top
> of the original, and user can select between versions, as well as designate
> new images as versions of another.
> i. Does versioning exist in shotwell?
>
> ii. Can other files be added and linked as a version of the same image?
>

Shotwell's versioning system today is primitive.  Each photo essentially 
has two versions: the original and the edited version (which 
incorporates both external edits and edits performed within Shotwell).  
You can view the original version of any photo by pressing the Shift key 
within Shotwell, and the Revert to Original command reverts back to the 
original version.

We've thought about more complex versioning schemes and are potentially 
open to those, though it's very important to us to keep the user 
experience simple, so we've made no decisions about this.  See 
http://trac.yorba.org/ticket/2474 .


> 3. Filesystem folder monitoring
> A big feature request, and I think people would really agree with me here
> after experiencing it -
> Monitoring of folders, aka "Watching folders for new images".
> use case: I add an image to a folder designated as a "watched folder" in
> shotwell, and shotwell automatically recognizes and imports this image on
> next startup.  HUGELY important if you're going to be shifting around your
> image files in any other way, which is one of my  biggest gripes with
> F-Spot.
> i. Does it exist for shotwell?
>
> ii. Are there any plans for adding this in the future?
>

Folder monitoring is not in 0.7, but we've just implemented this in the 
trunk, so it will be in 0.8.  Note that we auto-import from the library 
directory only.  I hope that in a future release we'll support multiple 
watched folders.

If you want to try this in the trunk, you need to specify --auto-import 
on the command line when you run Shotwell (this option will go away 
soon).  See http://trac.yorba.org/ticket/2478 .

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell over NFS + shared access

[Adam Dingle]

Take,

thanks for your thoughts, and I'm glad that you like Shotwell overall!  
It's true that Shotwell today is designed for the single-user case and 
does not work well when your library is on an NFS share or when several 
users run it on the same machine.  Lots of users want to be able to 
share photos easily on a local network (or across the Internet), and we 
want to extend Shotwell to be able to handle that use case: see 
http://trac.yorba.org/ticket/1292 .  That might involve using a 'real' 
database (e.g. MySQL) as you suggest and/or some sort of peer-to-peer 
communication between Shotwell instances; we haven't yet decided exactly 
how this will work.  In any case, this feature won't be in the next 
release (0.8) but I hope we'll get to it in the next few releases since 
lots and lots of people want this.  :)

cheers
adam

On 09/03/2010 12:33 AM, Take wrote:
> Hello.
>
> I recently installed shotwell and imported my photo directory. Even if
> shotwell isn't perfect (nor ready) yet I'm already quite impressed.
> Before this I haven't found any sofware which could've even managed to
> import my ~26000 photos. Here's some initial toughts of mine, I'm quite
> sure someone else has already suggested these, so if someone gets
> annoyed by 'repost' I'm sorry.
>
> However, even with shotwell there's this one design/ideology issue which
> isn't even near optimal on todays world. Every application, including
> shotwell, thinks that there's "My photos", not "Our photos". So, even if
> it's possible, the default setting is that there's no one else on same
> computer/network who'd want to access those family photos as well.
>
> Obviously that's a problem to balance between easy setup and additional
> features, but I'd really like to see support for some 'real' database in
> addition to sqlite. Currently I'm running shotwell on NFS-share, which
> kind-of-works, but I can't use shotwell simultaneously from multiple
> computers due to database access. The same scenario applies with
> multiuser-computer, since if user A has shotwell running and user B
> tries to open it in a new session it doesn't work either.
>
> Optimal solution would be to add setting/something for MySQL/PSql/Sqlite
> so that if user doesn't want (or can't) setup an real database sqlite
> would do and for "experienced" users it'd still be an option.
>
>
> Another issue I ran into, related to shared access, is that for some
> reason shotwell starts up _really_ slowly when I access database and
> photos over wifi-link&  NFS. Startup takes several minutes and most of
> the time waiting there's little or no traffic at all on wlan0. I
> understand that ie. opening sqlite over slow(ish) link takes some time,
> but since there's no traffic I don't know what's taking so long. Startup
> progress goes up to 48% and stalls there for a good while. Most likely
> this would be solved with "real" database server instead of sqlite, but
> that's a bit annoying anyways.
>
>
> Anyways, keep up the good work! I really do like and appreciate the work
> of dev-team so far. Thank you all.
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] support to publish to blogspot (blogger)

[Adam Dingle]

Ben,

that's a reasonable idea, so I've created a ticket for this at 
http://trac.yorba.org/ticket/2522 .  I hope that within the next few 
releases Shotwell will support plugins which can implement exporting to 
various hosting sites (http://trac.yorba.org/ticket/182), which may make 
this easier.

adam

On 09/06/2010 08:09 PM, Ben Podoll wrote:
> Is there a way (or is it in the roadmap) to publish to
> blogspot.com(blogger)? We've been using Picasa for the last few years
> since we never
> really liked F-Spot, and we wanted easy support to publish to our blogs. I
> really like how Shotwell is coming along, and support for publishing to
> blogspot would be ideal. Thoughts/Comments?
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Sharpening tool

[Adam Dingle]

Florian,

sharpening (http://trac.yorba.org/ticket/690) is currently at priority 
'high' in our ticket database, which means we think there's some chance 
it will make 0.8, though it's not on our top list of features for 0.8 
(which are listed on our Wiki page at 
http://trac.yorba.org/wiki/Shotwell).  If it doesn't make 0.8 then I 
think it will be a strong candidate for 0.9.  Patches gladly accepted.  :)

adam

On 09/06/2010 07:17 AM, Florian Manach wrote:
> Hi everyone.
>
> I just wanted to know if advanced retouching and editing tools like
> "Sharpenning" are planned for the next versions.
>
> Thx in advance.
>
> Florian
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Using GNU Autotools

[Adam Dingle]

Valentin,

obviously you've put a lot of work into this patch, and we appreciate 
that.  The fact that Shotwell doesn't use autotools, isn't a bug, though 
- it's a feature.  :)  The Shotwell team explicitly decided not to use 
autotools for our project because we find autotools to be hackish, 
bloated, and slow.  We really like the fact that you can check out 
Shotwell and build immediately, which would not be possible with 
autotools.  We've tried hard to write our Makefile to conform to the GNU 
Makefile conventions 
(http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html) 
so that it is as compatible as possible with those generated by 
autotools.  So it's not obvious to me what problem we would solve in 
Shotwell by switching to autotools - if our Makefile is currently 
limiting packagers in some way, please let me know and we can try to fix it.

Some other people would also like to see GNOME move away from 
Autotools.  You can read one such proposal here:

http://aruiz.synaptia.net/siliconisland/2010/03/buildj-build-configuration-for-the-mases.html

Finally, I'll say that we're not opposed to build systems in general - 
we just don't like Autotools.  If you wanted to submit a patch to make 
Shotwell build with waf, for example, I think that might be fine.

cheers
adam

On 09/07/2010 05:42 AM, Valentin David wrote:
> I take the freedom to send you a patch to make use of the GNU
> Autotools (i.e. Automake, Autoconf and Libtool) for the project
> Shotwell.
>
> http://www.valentindavid.com/files/shotwell-autotools.patch
>
> The integration of Vala into Automake is still fishy, and would not
> work properly for your project. Actually your project was an
> interesting example on the limitations of Vala integration into
> Automake. So in the patch here, the support is made by hand. However I
> will try to file bugs to the Automake project so that you will be able
> to use easily Vala with the future versions of Automake.
>
> The integration of gettext is also weird in Automake. But at least it
> works. However seeing their mailing list it will probably easier to
> use it in the future. I noticed that some languages had errors that
> gettext would report. I fixed jp.po. I also disabled bad entries in
> pl.po. This last one should be carefully checked. I am not really used
> with using gettext, and I had no ideas how to fix those entries.
>
> Automake proposes a nice way add a test-suite. Specially since 1.11
> (with colors and in parallel). I recommend you start to use it. (I
> think it answers your #1068). If you have an example of test case you
> want to add, I can show you how.
>
> The patch would certainly work with Autoconf 2.65. But I set the
> requirement to 2.67. I advise you to use recent versions of the
> Autotools. After all it distributes all it needs in the tarball, so
> anybody who wants to compile from the source tarball does not need to
> have the autotools. Except if they desire to change the makefiles or
> the configuration script. So no point to lower the requirements on
> them for portability.
>
> To make a distribution tarball, it is advised to use "make -j
> distcheck" and fix any problem until you get a nice message like that:
>
> ==
> shotwell-0.7.1+trunk archives ready for distribution:
> shotwell-0.7.1+trunk.tar.gz
> shotwell-0.7.1+trunk.tar.bz2
> ==
>
> Then you know that the package is sane. For example someone might want
> to compile in a separate directory from the source directory. And this
> works smoothly with Automake. Also you are sure that all your clean
> rules are right. And all your tests succeeded.
>
> To test the patch:
>
> $ svn co -r2197 svn://svn.yorba.org/shotwell/trunk shotwell
> $ cd shotwell
> $ wget -O - http://www.valentindavid.com/files/shotwell-autotools.patch
> | patch -p0
> $ chmod +x bootstrap # the patch does not do it, but a svn commit would save 
> it
> $ ./bootstrap
> $ ./configure
> $ make -j
> $ make -j distcheck
>
>
> By default it uses silent rules (I think it is nice like that), so
> that you do not see very complex command lines. If you wish to see
> what is called use:
> make V=1
>
> I did not try it on mingw, but I tried to make the rules and
> configuration so that it works as the old Makefile. The debian scripts
> should probably be updated. Feel free to ask me to help fixing the
> rest if you desire to apply the patch.
>
> I can do the same for gexiv2 if you wish.
>
> Best regards,
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Picasa Upload Fail

[Adam Dingle]

Ken,

thanks for your bug report and helpful sleuthing.  I just looked at 
AppDirs.vala and saw that if Shotwell is unable to create any of several 
directories under .shotwell then it will exit unexpectedly.  Instead, in 
this situation we should display a dialog with an error message and then 
exit.  I've ticketed this at http://trac.yorba.org/ticket/2532 .  I hope 
we can fix this for the upcoming 0.7.2 release.

And as for just why Shotwell can't create 
/home/kjernigan/.shotwell/tmp/13887 in your particular case, well, I 
don't know.  I'd stare at the file/directory permissions very carefully.  :)

cheers
adam

On 09/07/2010 08:32 PM, Kenneth Jernigan wrote:
> I owe a correction and more information.  The database file ended up on the
> root drive (a ReiserFS partition...).  Anyhow, I found the method to call
> the Shotwell with the debug commands.  And here is what I receive:
>
> L 13887 2010-09-07 23:29:14 [MSG] main.vala:69: Verifying database ...
> L 13887 2010-09-07 23:29:14 [DBG] DatabaseTables.vala:291: Database schema
> version 8 created by app version 0.7.0
> L 13887 2010-09-07 23:29:15 [DBG] main.vala:181: 0.747172 seconds to
> Gtk.main()
>
> ** ERROR **: AppDirs.vala:106: Unable to create temporary directory
> /home/kjernigan/.shotwell/tmp/13887
> aborting...
> Aborted
>
>
>
> The folder   /home/kjernigan/.shotwell   links to the folder
> /usr/share/shotwell/.shotwell
>
> Both users are members of a group that has full read/write access to the
> /usr/share/shotwell/.shotwell directory.  Any ideas?
>
> Thanks,
> Ken
>
> On Tue, Sep 7, 2010 at 11:09 PM, Kenneth Jerniganwrote:
>
>
>> I see someone created a new ticket 2530 for a similar problem.  I've
>> connected via Shotwell to my Picasa account and can see existing albums and
>> create new albums.  But when Shotwell tries to upload a picture, Shotwell
>> crashes without any error message.  I have been able to publish to Facebook
>> and export images as well as edit photos without any problems.  I am running
>> Ubuntu Lucid and Shotwell 0.7.1.
>>
>> Just an FYI... I have, perhaps, an unusual setup (and perhaps ill-advised).
>>   However, I am running with the Shotwell database on a permanent NTFS
>> partition.  The Shotwell database folder is hard-linked to the NTFS
>> partition folder.  As for my photos, they are stored in ~/Pictures, which is
>> a hard link to a different permanent NTFS partition.  The NTFS partitions
>> are from legacy dual-boot installs which I've not entirely purged.  I do
>> share the database and pictures directory between two users, but I always
>> ensure that only one of us is running Shotwell.  I doubt this setup
>> attributes to the problem, but wanted to share it.
>>
>> Let me know if there is anything I can do to provide debug information.
>>
>> Ken
>>
>>  
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] XMP files outside photo

[Adam Dingle]

  Yes - we've thought about this too.  See this ticket:

http://trac.yorba.org/ticket/1879

adam

On 09/09/2010 08:15 AM, Mattias Põldaru wrote:
> I found a new string from F-Spot today:
> "Never modify image files.\n"
> "Write XMP files next to the images instead."
>
> This option might be worth considering for Shotwell as well, at least
> for importing.
>
> Best regard
> Mattias
>
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] XMP files outside photo

[Adam Dingle]

  Florian,

you're not wrong about this.  This is also in our ticket database here:

http://trac.yorba.org/ticket/1798

There are two separate questions here:

1. Where should Shotwell store metadata (such as keywords)?

a) only in its own database
b) in sidecar XMP files
c) in the image files themselves

2) Where should Shotwell store full-resolution JPEGs of edited photos?

a) in memory only
b) in a separate file in the same directory as the original JPEG
c) in the original JPEG file (renaming the original to something like 
photo007.orig.jpg)

Today, we've implemented only 1a and 2a.  Eventually I think it would be 
great if these could be user options, since I think it's unlikely that 
any particular choices here will make everyone happy.

adam

On 09/09/2010 02:29 PM, Florian Manach wrote:
> I thought there was a ticket submitted by Ubuntu to save the
> modification in a copy of the original jpeg so the modified version is
> always accessible on the filesystem itself.
>
> Am I wrong ?
>
> Le jeudi 09 septembre 2010 à 23:18 +0300, Mattias Põldaru a écrit :
>> Ühel kenal päeval, N, 2010-09-09 kell 08:48, kirjutas Adam Dingle:
>>> Yes - we've thought about this too.  See this ticket:
>>>
>>> http://trac.yorba.org/ticket/1879
>>>
>>> adam
>> It's so nice, whatever idea new to me I happen to stumble on, Yorba team
>> already has it planned for Shotwell :)
>>
>> Mattias
>>
>>
>>> On 09/09/2010 08:15 AM, Mattias Põldaru wrote:
>>>> I found a new string from F-Spot today:
>>>> "Never modify image files.\n"
>>>> "Write XMP files next to the images instead."
>>>>
>>>> This option might be worth considering for Shotwell as well, at least
>>>> for importing.
>>>>
>>>> Best regard
>>>> Mattias
>>>>
>>>>
>>>> ___
>>>> Shotwell mailing list
>>>> Shotwell@lists.yorba.org
>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>> ___
>>> Shotwell mailing list
>>> Shotwell@lists.yorba.org
>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Some new feature proposal

[Adam Dingle]

  Florian,

glad you're now using Shotwell!  :)  Thanks for your suggestions, which 
sound reasonable.  I've ticketed them here:

http://trac.yorba.org/ticket/2539

http://trac.yorba.org/ticket/2540

adam

On 09/10/2010 12:58 AM, Florian Manach wrote:
> Hi everyone,
>
> After several weeks observing the Shotwell developpement and testing the
> application, I finnaly jumped in an began to use it.
>
> So during these weeks, I said several times to myself "It would be good
> if gnagnagnagnagna..." So I thought I could suggest you these features.   
>
> I already suggested a few of them, those remaining are mostly relative
> to the tags.
>
> - Copyright Informations : For those who can't store copyright, artist
> or author information with a function of theire camera, I think it
> should be good to have a way, inside Shotwell or at the import, to store
> that in the picture.
>
> - Give the same title to multiple files : It's impossible as far as I
> know and it's a pain to add the same title to my 300 photos of the
> Eiffel Tower.
>
> - Preset the title with the event name : as an option, just for people
> who don't want to entitle their 5 kilophotos.
>
>
> It's just some feature proposal, as I see you are very aware of our
> feedbacks...
>
> Thx again for the great work,
>
> Florian
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Duplicate a photo

[Adam Dingle]

Emanuele,

2010/9/11 caccolangrifata 

> Hi!
>
> I use Shotwell since 0.4 version bla bla :) and you're doing a great
> work.
>

Thanks!


>
> I'm writing here because I think "Duplicate" command must work
> differently.
> When a photo is duplicated a copy of that photo is created in
> "~/Immagini//MM/DD/" folder even if the photo is linked.
> I think duplicated photo file must be saved in the same folder of the
> origin file, because if I link photo I don't want save my photo to
> Shotwell default folder.



That's a reasonable suggestion.  Since Shotwell is non-destructive, it might
even be nice if the Duplicate command didn't create any new photo file at
all - the duplicate copy in Shotwell could simply share the original file.
 In any case, I've created a ticket here:

http://trac.yorba.org/ticket/2545

adam
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Exporting tags

[Adam Dingle]

  Simon,

we could consider something like this, but how would this work exactly?  
I suppose the export dialog could have a checkbox called "Export 
metadata", checked by default.  If this checkbox is cleared, then 
Shotwell would not export tags, ratings or titles.  But now suppose that 
a photo imported into Shotwell has tags, ratings and titles which came 
from the original JPEG file, and that the user then added one more tag 
in Shotwell.  If the user chooses not to export metadata, then would 
Shotwell export only the tags that were present in the original photo, 
or none at all?

adam

On 09/14/2010 02:07 AM, Simon Spannagel wrote:
> Hej everybody,
>
> I want to propose another feature:
> I realized, that the actual export functionality of shotwell
> automatically exports all tags, ratings (and titles?) to the created files.
>
> I think this should be only an option and not the standard procedure -
> perhaps I could have some private tags which I don't want to share with
> others.
>
> What do you think about this?
>
> kind regards,
> Simon
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Standardize some keyboard shortcuts

[Adam Dingle]

  Milos,

I think we'll keep the current shortcuts for two reasons:

1) We want Shotwell's shortcuts to be consistent with other GNOME 
applications.  The GNOME interface guidelines recommend that Ctrl+0 
restore the zoom level to normal size (see 
http://library.gnome.org/devel/hig-book/stable/input-keyboard.html.en#standard-shortcuts
 
).  Given this, it makes sense to use Ctrl+1 and Ctrl+2 to zoom to 
different levels.

2) Many users who rate photos will probably want to apply ratings using 
the keyboard much more often then they will want to zoom to specific 
levels.  For this reason, it makes sense for the keyboard rating 
shortcuts to be as easy to type as possible.

adam

On 09/14/2010 09:15 AM, Milos Popovic wrote:
> In other software
> Key 1 zooms to 100%
> Key 2 zooms to 200%
>
> If it is implemented in Shotwell, ratings can be managed with Ctrl
> +[1,2,3,4,5]
>
> What do you think about this?
>
>
> Best regards,
> Miloš Popović
>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Exporting tags

[Adam Dingle]

  OK, sounds good.  I've ticketed this here:

http://trac.yorba.org/ticket/2556

greetings from San Francisco,
adam

On 09/14/2010 09:57 AM, Simon Spannagel wrote:
> Hej Adam, hej Florian and list,
>
> I think - like Florian does - then Shotwell shouldn't export any
> metadata at all. I assume that in most cases there is no need for
> restoring the original imported metadata (and how would you separate
> that data from added ones if we get in-file-tags with the next version?)
> for exporting a file.
> To keep things simple, the user has just to decide whether he wants to
> export the whole metadata or nothing at all. I think this would be enough.
>
> Further I agree with Vincent that this should not be the default, but
> the checkbox you proposed seems to be a very good (and quick'n'easy)
> option for solving this issue...
>
> greetings from Sverige,
> Simon
>
>
>
> Am 14.09.2010 16:41, schrieb Adam Dingle:
>> Simon,
>>
>> we could consider something like this, but how would this work exactly?
>> I suppose the export dialog could have a checkbox called "Export
>> metadata", checked by default.  If this checkbox is cleared, then
>> Shotwell would not export tags, ratings or titles.  But now suppose that
>> a photo imported into Shotwell has tags, ratings and titles which came
>> from the original JPEG file, and that the user then added one more tag
>> in Shotwell.  If the user chooses not to export metadata, then would
>> Shotwell export only the tags that were present in the original photo,
>> or none at all?
>>
>> adam
>>
>> On 09/14/2010 02:07 AM, Simon Spannagel wrote:
>>
>>> Hej everybody,
>>>
>>> I want to propose another feature:
>>> I realized, that the actual export functionality of shotwell
>>> automatically exports all tags, ratings (and titles?) to the created files.
>>>
>>> I think this should be only an option and not the standard procedure -
>>> perhaps I could have some private tags which I don't want to share with
>>> others.
>>>
>>> What do you think about this?
>>>
>>> kind regards,
>>> Simon
>>> ___
>>> Shotwell mailing list
>>> Shotwell@lists.yorba.org
>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>>
>> ___
>> Shotwell mailing list
>> Shotwell@lists.yorba.org
>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>>
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Standardize some keyboard shortcuts

[Adam Dingle]

  On 09/14/2010 11:46 AM, Øystein Walle wrote:
> Hi everyone, my first mail to the mailing list :)

Welcome!  :)

> Using numbers in combo with Ctrl is fine IMHO and I agree with Peter; I find
> that I rate photos more often than I inspect them at 100% zoom.
>
> There are large inconsistencies with the Shotwell photo viewer, however. It
> still uses only "1" for 100% zoom. It appears that also Ctrl+0 (but not only
> 0) does this, instead of fitting to window. But 2/Ctrl+2 does not produce
> 200% zoom.
>

Good point - somehow this escaped our notice until now.  I've created a 
ticket here:

http://trac.yorba.org/ticket/2558

We'll certainly fix this for 0.8.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Lots of main menu items disabled on Ubuntu Maverick, Shotwell 0.7.2

[Adam Dingle]

Benjamin,

thanks for the bug report.  This problem is known and is due to the
indicator-appmenu.  See:

http://trac.yorba.org/ticket/2553

https://bugs.launchpad.net/unity/+bug/637692

adam

On Wed, Sep 15, 2010 at 5:52 AM, Benjamin Humphrey wrote:

> Hi guys,
>
> I noticed in the main menu of Shotwell, a lot of menu items are disabled or
> "greyed out," such as:
>
> In the 'File' menu:
>
> Export
> Print
> Publish
> Set as desktop background
> Show in file manager
>
> Events > New Event
>
> Almost everything in the Photos and Tags menus
>
> I was trying to figure out why this might be. I do shoot in RAW, but this
> happens with JPG images as well. I am using the indicator-appmenu (global
> menu type thing in Ubuntu), but I don't think this is the problem as other
> options seem to work fine.
>
> I would screenshot but I suffer from this bug:
> https://bugs.launchpad.net/indicator-appmenu/+bug/603482
>
> It's interesting that the Export option is greyed out in the File menu, but
> if I drag and drop a photo to a folder or the desktop, it exports fine.
>
> I also don't seem to have an option to upload to Flickr, Facebook etc. I
> thought that feature was in Shotwell?
>
> Thanks,
>
> --
> Benjamin Humphrey
>
> interesting.co.nz
> ohso.co
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
>
___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Where is the "Library?"

[Adam Dingle]

  Kent,

the library is the directory you set in the Edit->Preferences dialog as 
"Import photos to:".  By default it's the XDG_PICTURES_DIR directory, 
which is probably ~/Pictures on your machine.  For more information, see 
the Importing Photos section in the Shotwell user guide:

http://trac.yorba.org/wiki/UsingShotwell0.7

adam

On 09/22/2010 12:32 PM, Kent Tenney wrote:
> Howdy,
>
> When I do File ->  Import from Folder
>
> I get the choice:
> "Shotwell can copy the photos into your library or it
> can link to the photos without duplicating them."
>
> Where is the Library which contains links or copies?
>
> Thanks,
> Kent
> ___
> Shotwell mailing list
> Shotwell@lists.yorba.org
> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Where is the "Library?"

[Adam Dingle]

  Kent,

On 09/22/2010 12:54 PM, Kent Tenney wrote:
> On Wed, Sep 22, 2010 at 2:39 PM, Adam Dingle  wrote:
>>   Kent,
>>
>> the library is the directory you set in the Edit->Preferences dialog as
>> "Import photos to:".  By default it's the XDG_PICTURES_DIR directory, which
>> is probably ~/Pictures on your machine.
> Ah, ok.
>
> I expected "can link to" to create links, but
> if "copy" is not chosen, no files are created in the Library ...

Aha - do you mean you expected Shotwell to create symbolic links to your 
photos?  It doesn't do that - if you choose "Create Links" then Shotwell 
merely uses the photos in place without copying.  Yes, we know this 
terminology is confusing, and we have a ticket open to address this:

http://trac.yorba.org/ticket/2489

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] IDE and Flickr feature

[Adam Dingle]

  Andrew,

On 09/27/2010 08:59 AM, Andrew France wrote:
>Hi,
>
> I discovered Shotwell in the Ubuntu 10.10 beta and it's exactly what
> I've been looking for to manage the various streams my photos go to,
> thank you!

I'm glad you like Shotwell!

> I usually upload my Flickr photos at a larger size so I got the source
> (SVN?! I've mirrored it on Github at http://github.com/Odaeus/shotwell)
> and started adding a custom option on the drop-down list along with a
> text-box to enter the dimension.
>
> This is the first time I've used the Vala language (it's quite nice),
> I've been using Vim, but is there another IDE you primarily use for
> development? Sorry if this has been asked before but I couldn't find the
> mailing list search?

Here at Yorba we also wanted a Vala IDE, so we wrote Valencia, a plugin 
that turns gedit into an IDE for Vala.  This is what we use for our own 
Shotwell development.  Check it out:

http://yorba.org/valencia/

Unfortunately our mailing lists are not yet searchable - we hope to fix 
this at some point (see http://trac.yorba.org/ticket/2181 ).  As a 
workaround, you can search all the lists at once using Google by 
including the term 'site:lists.yorba.org'.

> I got to the point where it works at a basic level for my big Flickr
> uploads but any feedback on best practice for how the custom-size
> feature should be implemented would be great. I assume it's a desirable
> feature! Making the Export Dialog code/interface reusable would be nice
> but I think it's beyond me.

Yes, I think this is a reasonable idea.  I might suggest having two text 
boxes (one for width, one for height) that are normally hidden, but 
appear when the user chooses the custom size option in the dropdown.  
This would work just like Shotwell's crop tool, which also offers a 
predefined list of dimensions but lets you enter custom dimensions as well.

cheers
adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Enhancements to tags

[Adam Dingle]

  Take,

thanks for your tagging suggestions.

On 09/27/2010 08:40 AM, Take wrote:
> I added a lots of tags to my photos, which raised few improvements I'd
> like to see in shotwell.
>
> 1) Select multiple tags
> I added tags to photos about who's on the photo and where they're taken.
> It'd be great if I could select multiple tags, so that I could ie. show up
> images which are taken at home and which include myself. This way it'd be
> simpler and faster to browse trough spesific photos on the collection.

Yes - this is a frequently requested feature:

http://trac.yorba.org/ticket/2275

> 2) Grouping of tags
> With tags "who" and "where" there'll be a lots of tags on the collection.
> It would be great if those could be grouped, so that I could have branches
> under tags, like "Locations" and "People".
>

Right. Lots of users want this as well:

http://trac.yorba.org/ticket/1401

> 3) Remove tag from multiple photos
> Couple of times I accidently added an tag to lots of pictures which was
> incorrect. I had to go trough them individually and remove that tag from
> each photo.

There's no need to remove these individually - you can remove them all 
at once. See the Tags section in the Shotwell user guide 
(http://trac.yorba.org/wiki/UsingShotwell0.7#Tags):

To remove a tag from one or more photos, first select that tag in the 
sidebar, then
select the photos you would like to remove, and choose
Tags ▸ Remove Tag "[name]" from Photos...

> 4) Drag tags to photos
> When browsing trough photos and tagging them it'd be great if I could drag
> tag to photos from sidebar. I know I can do this by dragging photos to
> tags, but it'd be IMO more usable if I could also drag tags to photos.

Seems like a reasonable idea. I've added a ticket at

http://trac.yorba.org/ticket/2601

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] some papercuts

[Adam Dingle]

  Simon,

On 09/27/2010 10:05 AM, Simon Spannagel wrote:
> Hej,
>
> after using Shotwell very intensively in the last days, I put together a
> small list of "papercuts", which annoyed me a lot after a while. Further
> I have some suggestions, some of them might have been already discussed...

Thanks for your suggestions.  We're also interested in fixing paper cuts 
since we want Shotwell to be polished and usable.

> Du you want me to open tickets for all these papercuts? :-)
> I wanted to wait for a possible discussion...

No need; I've already opened tickets for these as appropriate.  See my 
comments below.

>  * After deleting/renaming an event/tag, the sidebar jumps to the
>beginning and you have to scroll down again.

I can reproduce this only after deleting an event/tag, not after 
renaming.  I've filed a ticket at http://trac.yorba.org/ticket/2611 .

>  * it is impossible to mark mutliple pictures with "ctrl"+"arrow
>keys" and "space" like in the most common file managers.

Right: that's http://trac.yorba.org/ticket/2320 .  I've upped this 
ticket priority to high since a few people have noticed this now.

>  * the tags are shown nowhere in the single-picture-view.

Right.  This is http://trac.yorba.org/ticket/2238 .

>  * Sometimes there is an issue with scrolling - unfortunately I can't
>really say in which situations you can reproduce that behaviour -
>but it is very annoying. If you marked a picture and then scroll
>down, sometimes it just jumps back to the marked picture or a bit
>below.

Sorry to hear it.  If you can come up with a reproducible case we'd 
certainly like to hear about it.

>  * on adding tags to a picture, the suggestion of existing tags
>doesn't work for non-standard characters like "ö"

Good catch.  I've filed a ticket at http://trac.yorba.org/ticket/2612 .

>  * shotwell sometimes freezes without any reason for about 30sec,
>after that normal work is possible. Some as above: I have no idea
>how to reproduce that. Suggestions how I could see what is
>happening in this moment?

1. Do you have lots of RAW photos?  Are you using any sort of network 
filesystem?

2. If you run the GNOME System Monitor, does it show Shotwell at 100% 
CPU during the 30 seconds?

3. You could try running Shotwell under gdb from a console window.  When 
the 30-second freeze occurs, type Ctrl+C in the console window to break 
into gdb, then type 'where' to get a backtrace.  We'd be interested to 
see this.

>  * Maybe generating bigger thumbnails for the "event-picture", the
>resolution seems to be not enough, in some of the event pictures I
>can see pixels.

Great catch - we hadn't noticed this before.  I've filed a ticket at 
http://trac.yorba.org/ticket/2613 .

>  * Deleting pictures out of the trash seems not to work on
>NTFS-partitons, only the trash is emptied, so the user assumes,
>that the files are gone - but they are still stored in their
>original place.

1. When you delete a picture out of the trash, does Shotwell display a 
dialog asking whether you want to only remove the file or to move the 
file to the desktop trash?

2. Assuming that the answer to (1) is yes, are you saying that even if 
you choose "Trash file", the file remains on the NTFS partition?

3. Are you sure that you have write access to the NTFS partition?

> Suggestions:
>
>  * After now using more than a hundred different tags for now 5500
>imported pictures it's getting really crowded in the sidebar. So I
>suggest to put up some categories for tags, just easy ones like
>"persons", "places" and so on. But we had that already, as I see
>in this moment...)

Right: this is http://trac.yorba.org/ticket/1401 , one of our 
most-requested feature ideas.

>  * It is impossible to adjust, which EXIF-data is shown in the lower
>left corner. This could be an option, so no "easy user" will be
>disturbed but still the "power user" has the posibility...

This is a reasonable idea.  I've added a comment with your suggestion to 
the existing ticket http://trac.yorba.org/ticket/2401 .

>  * An option for showing only photos with a special rating (for
>"rejected" as an example...) or even "** or below". In some cases
>this might be very useful...

Yes.  This capability will arrive one we implement complex boolean 
searches (http://trac.yorba.org/ticket/1587).

Thanks again for all your suggestions!

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] some papercuts

[Adam Dingle]

  On 09/28/2010 12:45 PM, Mattias Põldaru wrote:
>
> I can confirm it. On my computer it is easily reproducible.
>
> 1. Open an event with images enought to scroll, the thumbnail size does
> not matter
> 2. Select an image
> 3. Start scrolling not too fast, so you could see how the selected image
> jumps to the middle (vertically) one, often two times, as you keep
> scrolling
>
> This does not start happening every time, but if it does start, it
> happens with almost every try. It may be related to the mad scrolling I
> sometimes do with my thinkpad's touchstick middlebutton scroll. But
> after this starts, it happens even after closing and reopening shotwell.
>
>
> Regards
> Mattias

Mattias,

I'm unable to reproduce this in the Shotwell trunk on Ubuntu 10.10.  
What version of Shotwell do you have?  It sounds like the problem 
happens when you scroll with the touchstick middle button.  Does it also 
happen when you scroll using Page Up/Page Down, or when you use the 
scrollbar on the right side of the window?

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] some papercuts

[Adam Dingle]

  On 09/29/2010 02:47 PM, Simon Spannagel wrote:
>> 3. You could try running Shotwell under gdb from a console window.
>> When the 30-second freeze occurs, type Ctrl+C in the console window to
>> break into gdb, then type 'where' to get a backtrace.  We'd be
>> interested to see this.
> I'll do that the next time it occurs...
>

That would be great, and might help us understand what's going on here.

Regarding the NTFS deletion problem, I've filed a ticket at

http://trac.yorba.org/ticket/2624

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] search box enhancement

[Adam Dingle]

  Maciek,

yes, it was nice to meet you at FOSDEM and I'm glad we've been able to 
stay in touch after that.

I'm glad you're interested in contributing to Shotwell.  I think that 
the search box might be a bit ambitious as a first contribution, 
however.  We're currently planning to implement a search box in the 
Shotwell 0.9 time frame and I think the search box will be a major 
feature for that release.  It will replace the existing rating filter 
icon on the Shotwell toolbar, since you'll be able to use the search box 
to filter by rating, name and more as you suggested.  The design of the 
search box is still undetermined, but may involve some delicate user 
interface tradeoffs and the core Shotwell team will be highly involved 
in making those.

I think that any of the following projects would be challenging, but 
still approachable enough to attack in one semester:

- slideshow transitions (http://trac.yorba.org/ticket/1081)
- straighten photo (http://trac.yorba.org/ticket/61)
- use pictures as screensaver (http://trac.yorba.org/ticket/1112)
- printing improvements (http://trac.yorba.org/ticket/1188, 
http://trac.yorba.org/ticket/1189)
- export to Gallery (http://trac.yorba.org/ticket/1585)
- upload video to YouTube (http://trac.yorba.org/ticket/1589)
- export slideshow to video (http://trac.yorba.org/ticket/1590)
- border fade effects (http://trac.yorba.org/ticket/1914)
- support .bmp and .gif images (http://trac.yorba.org/ticket/2154)
- publish to Blogger (http://trac.yorba.org/ticket/2522)
- Piwigo publishing (http://trac.yorba.org/ticket/2639)

Would any of these be of interest to you?  You could certainly look 
through the Shotwell ticket list for other ideas as well.

adam

On 10/04/2010 12:26 PM, Maciej Rumianowski wrote:
> Hi all,
>
> Firstly I would like to say thank you for a great software which is
> Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer
> Event on FOSDEM when I spoke with Adam:)
>
> This year on my University I have to do an individual project. I have
> spoken with my teacher and I can do what i want. So I have chosen
> Shotwell and I am thinking about an enhancement to implement.
>
> I thought about search box http://trac.yorba.org/ticket/80, but I am
> open for other options. I have one semester for my project (until end of
> January), and I should fit in that time span.
>
> About search box:
> Things that should be searchable are - tags, events, dates, titles,
> image metadata, other data (possibility to easily add new things to be
> searched for). Searches should be view aware. Search box should nicely
> integrate with the Shotwell's UI. Search box should have suggestions
> based on previous and possible searches. Search box shouldn't impact
> Shotwell's speed.
>
> Interested in your opinions.
>
> Cheers,
> Maciek
>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] search box enhancement

[Adam Dingle]

  Maciek,

On 10/05/2010 02:22 PM, Maciej Rumianowski wrote:
> Adam,
>
> I didn't realise that it so huge. My ambition is really big, because
> Shotwell will be my first open-source project that I contribute into the
> code.

Glad you're feeling ambitious.  :)

> I find "publish to Blogger (http://trac.yorba.org/ticket/2522)" and
> "Piwigo publishing (http://trac.yorba.org/ticket/2639)" interesting. In
> some of my applications I thought about publishing to such things as
> Blogger.
> Blogger is more known in Poland so I would like to work on it.

That sounds great.  Feel free to set yourself as the owner of the 
Blogger ticket so that others will realize that someone is working on it.

> I have forwarded the list of topics to my friends on University and
> maybe some of them will also work on Shotwell:)

Great - I hope you can recruit an army of Polish students to help 
develop our various features!  :)

adam

> Dnia 2010-10-05, wto o godzinie 13:43 -0700, Adam Dingle pisze:
>> Maciek,
>>
>> yes, it was nice to meet you at FOSDEM and I'm glad we've been able to
>> stay in touch after that.
>>
>> I'm glad you're interested in contributing to Shotwell.  I think that
>> the search box might be a bit ambitious as a first contribution,
>> however.  We're currently planning to implement a search box in the
>> Shotwell 0.9 time frame and I think the search box will be a major
>> feature for that release.  It will replace the existing rating filter
>> icon on the Shotwell toolbar, since you'll be able to use the search box
>> to filter by rating, name and more as you suggested.  The design of the
>> search box is still undetermined, but may involve some delicate user
>> interface tradeoffs and the core Shotwell team will be highly involved
>> in making those.
>>
>> I think that any of the following projects would be challenging, but
>> still approachable enough to attack in one semester:
>>
>> - slideshow transitions (http://trac.yorba.org/ticket/1081)
>> - straighten photo (http://trac.yorba.org/ticket/61)
>> - use pictures as screensaver (http://trac.yorba.org/ticket/1112)
>> - printing improvements (http://trac.yorba.org/ticket/1188,
>> http://trac.yorba.org/ticket/1189)
>> - export to Gallery (http://trac.yorba.org/ticket/1585)
>> - upload video to YouTube (http://trac.yorba.org/ticket/1589)
>> - export slideshow to video (http://trac.yorba.org/ticket/1590)
>> - border fade effects (http://trac.yorba.org/ticket/1914)
>> - support .bmp and .gif images (http://trac.yorba.org/ticket/2154)
>> - publish to Blogger (http://trac.yorba.org/ticket/2522)
>> - Piwigo publishing (http://trac.yorba.org/ticket/2639)
>>
>> Would any of these be of interest to you?  You could certainly look
>> through the Shotwell ticket list for other ideas as well.
>>
>> adam
>>
>> On 10/04/2010 12:26 PM, Maciej Rumianowski wrote:
>>> Hi all,
>>>
>>> Firstly I would like to say thank you for a great software which is
>>> Shotwell! I discovered Shotwell on OMG! Ubuntu! and after Gnome Beer
>>> Event on FOSDEM when I spoke with Adam:)
>>>
>>> This year on my University I have to do an individual project. I have
>>> spoken with my teacher and I can do what i want. So I have chosen
>>> Shotwell and I am thinking about an enhancement to implement.
>>>
>>> I thought about search box http://trac.yorba.org/ticket/80, but I am
>>> open for other options. I have one semester for my project (until end of
>>> January), and I should fit in that time span.
>>>
>>> About search box:
>>> Things that should be searchable are - tags, events, dates, titles,
>>> image metadata, other data (possibility to easily add new things to be
>>> searched for). Searches should be view aware. Search box should nicely
>>> integrate with the Shotwell's UI. Search box should have suggestions
>>> based on previous and possible searches. Search box shouldn't impact
>>> Shotwell's speed.
>>>
>>> Interested in your opinions.
>>>
>>> Cheers,
>>> Maciek
>>>
>>>
>

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Panorama feature/plugin for Shotwell

[Adam Dingle]

  On 10/06/2010 11:34 AM, Peter DO Smith wrote:
> Has a panorama feature/plugin been considered for Shotwell? Something along
> the lines of Hugin?

Yes: see http://trac.yorba.org/ticket/2466 .

> I have been using Hugin to stitch together photos into panoramas. While it
> is undoubtedly a most capable tool for creating panoramas its user interface
> design is difficult, counterintuitive and counterproductive. I think it is
> time that the elegant simplicity of the Shotwell approach was brought to
> bear on the problem of constructing panoramas.
> I think this would be a natural companion to Shotwell.

Agreed.  Patches welcome!  :)

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] feature request: title just like in picasa

[Adam Dingle]

  On 10/13/2010 09:48 AM, Jim Nelson wrote:
> Hello,
>
> On Wed, Oct 13, 2010 at 2:43 AM, Levente Torok  wrote:
>
>> Hi Guys again,
>>
>> I'd like to know if titles can be displayed in full screen mode (just
>> like in picasa).
>>
>>
> This is something we're considering: http://trac.yorba.org/ticket/2238
>
>
>> I am also missing a possibility to edit it as easy as in picasa
>> (one-by-one).
>> Or am I trying to use this tool in a way that is not its own?
>> Cheers,
>>
> I'm not sure what you mean by this.  Do you mean edit the image (crop,
> rotate, etc.) or edit its title, tags, etc.?

I believe that Levente was asking to be able to edit the caption in 
full-screen mode, just like in Picasa.  That's a reasonable idea and 
I've added a comment reflecting that to the ticket above.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Problems compiling on new installation of Fedora 13

[Adam Dingle]

  Tamer,

what version of valac are you using?  You can find out like this:

% valac --version

Shotwell requires at least Vala 0.9.7.

adam

On 10/14/2010 08:02 AM, nero wrote:
>Linux nero.in-design.com 2.6.34.7-56.fc13.i686 #1 SMP Wed Sep 15
> 03:33:58 UTC 2010 i686 i686 i386 GNU/Linux
>
> l-0.7.2 # make
> mkdir -p src
> /usr/bin/valac --ccode --directory=src --basedir=src -g
> --enable-checking --thread  \
>   --pkg=atk --pkg=gdk-2.0 --pkg=gee-1.0 --pkg=gtk+-2.0 --pkg=glib-2.0
> --pkg=libexif --pkg=sqlite3 --pkg=gexiv2 --pkg=gconf-2.0
> --pkg=libgphoto2 --pkg=libsoup-2.4 --pkg=libxml-2.0 --pkg=unique-1.0
> --pkg=webkit-1.0 --pkg=gudev-1.0 --pkg=dbus-glib-1 --pkg=gdk-x11-2.0
> --pkg=FixedKeyFile --pkg=ExtendedPosix --pkg=posix --pkg=LConv
> --pkg=gdk-none --pkg=libraw \
>   --vapidir=./vapi \
>   -X -D_PREFIX='"/usr/local"' -X -D_VERSION='"0.7.2"' -X
> -DGETTEXT_PACKAGE='"shotwell"' -X
> -D_LANG_SUPPORT_DIR='"/usr/local/share/locale"' \
>   -X -I./vapi \
>\
>   src/main.vala src/AppWindow.vala src/CollectionPage.vala
> src/Thumbnail.vala src/DatabaseTables.vala src/ThumbnailCache.vala
> src/image_util.vala src/CheckerboardLayout.vala src/PhotoPage.vala
> src/Page.vala src/ImportPage.vala src/GPhoto.vala src/SortedList.vala
> src/EventsDirectoryPage.vala src/Dimensions.vala src/Box.vala
> src/Photo.vala src/Orientation.vala src/util.vala src/BatchImport.vala
> src/Dialogs.vala src/Resources.vala src/Debug.vala src/Sidebar.vala
> src/ColorTransformation.vala src/EditingTools.vala src/DataObject.vala
> src/DataCollection.vala src/LibraryWindow.vala src/CameraTable.vala
> src/DirectWindow.vala src/Properties.vala src/CustomComponents.vala
> src/Config.vala src/Event.vala src/International.vala src/Workers.vala
> src/system.vala src/AppDirs.vala src/PixbufCache.vala
> src/WebConnectors.vala src/FacebookConnector.vala
> src/CommandManager.vala src/Commands.vala src/SlideshowPage.vala
> src/LibraryFiles.vala src/FlickrConnector.vala src/Printing.vala
> src/Tag.vala src/TagPage.vala src/PicasaConnector.vala
> src/Screensaver.vala src/PhotoFileAdapter.vala src/PhotoFileFormat.vala
> src/PhotoFileSniffer.vala src/PhotoMetadata.vala src/GRaw.vala
> src/GdkSupport.vala src/JfifSupport.vala src/RawSupport.vala
> src/MimicManager.vala src/TrashPage.vala src/PngSupport.vala
> src/PhotoExporter.vala src/DirectoryMonitor.vala src/LibraryMonitor.vala
> src/OfflinePage.vala src/LastImportPage.vala src/AlienDatabase.vala
> src/AlienDatabaseImportJob.vala src/AlienDatabaseImportDialog.vala
> src/FSpotDatabaseDriver.vala src/FSpotDatabaseTables.vala
> CollectionPage.vala:1747.9-1764.66: error: missing break statement at
> end of switch section
> CollectionPage.vala:1746.5-1746.42: error: missing return statement at
> end of method or lambda body
>   private Comparator get_sort_comparator() {
>   ^^
> CollectionPage.vala:1772.9-1780.61: error: missing break statement at
> end of switch section
> CollectionPage.vala:1771.5-1771.61: error: missing return statement at
> end of method or lambda body
>   private ComparatorPredicate get_sort_comparator_predicate() {
>   ^
> CollectionPage.vala:1822.9-1831.22: error: missing break statement at
> end of switch section
> DatabaseTables.vala:1267.5-1267.80: error: missing return statement at
> end of method or lambda body
>   public static Gee.HashMap?
> marshall_all_transformations(string? trans) {
>
> 
> ThumbnailCache.vala:214.9-219.30: error: missing break statement at end
> of switch section
> ThumbnailCache.vala:213.5-213.47: error: missing return statement at end
> of method or lambda body
>   private static ThumbnailCache get_cache_for(Size size) {
>   ^^^
> CheckerboardLayout.vala:966.9-997.18: error: missing break statement at
> end of switch section
> ImportPage.vala:560.5-560.58: error: missing return statement at end of
> method or lambda body
>   public override CheckerboardItem? get_fullscreen_photo() {
>   ^^
> ImportPage.vala:578.9-639.18: error: missing break statement at end of
> switch section
> Dimensions.vala:222.9-233.51: error: missing break statement at end of
> switch section
> Dimensions.vala:221.5-221.46: error: missing return statement at end of
> method or lambda body
>   public Dimensions get_scaled_by_constraint(int scale,
> ScaleConstraint constraint) {
>   ^^
> Photo.vala:505.9-513.43: error: missing break statement at end of switch
> section
> Photo.vala:504.5-504.46: error: missing return statement at end of
> method or lambda body
>   private PhotoFileReader get_backing_reader(BackingFetchMode mode) {
>   ^^
> Orientation.vala:51.9-74

Re: [Shotwell] creating events named after subfolders, while importing

[Adam Dingle]

On 10/27/2010 06:58 PM, Simon Spannagel wrote:



Am 27.10.2010 22:19, schrieb Jim Nelson:

directory structure within the sidebar?
We've been considering the latter: http://trac.yorba.org/ticket/1594

-- Jim
Ah, don't do that. In my opinion that would destroy the good and 
well-sorted experience the user gets - cause this folder view will 
always remind him how messed up his pictures are stored. I think you 
don't need this folder view in Shotwell - if one wants to browse the 
directories, one can still use his favourite file manager...


It's clear that some users care about where photos are stored and others 
don't.  The long-term plan for Shotwell is to add several more sidebar 
trees which the user can enable or disable as they like.  If you don't 
care about events and only want to browse through your photos according 
to their on-disk location, you'll be able to hide the event tree and 
turn on the folder tree.   Conversely, a user who only wants to use 
events will be able to show only that tree.  We may also add trees which 
will let you browse photos by


- geolocation: country, state, city and so on 
(http://trac.yorba.org/ticket/1473)

- import rolls (http://trac.yorba.org/ticket/1793)
- time: like events, but doesn't allow renaming/splitting/merging 
(http://trac.yorba.org/ticket/2747)

- cameras

and so on.  I hope this will make everyone happy.  :)

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Email privacy

[Adam Dingle]

Vincent,

Yes, this is a legitimate concern.  Fortunately, Trac allows you to use 
either your user ID or your email address in the CC list. I've replaced 
your email address with your ID (cameleon) in every ticket where you 
were on the CC list, so I believe it should no longer be exposed via any 
Yorba Trac pages.


Of course, it would better for our Trac server to obfuscate all email 
addresses on all pages accessed anonymously (i.e. without logging in).  
Trac has a configuration option which is supposed to enable such 
obfuscation, but I haven't been able to get it working.  We'll look into 
this more soon.  I've created a Yorba infrastructure ticket to track 
this issue: http://trac.yorba.org/ticket/2753 .  Feel free to add 
yourself to the CC list.  ;)


adam

On 11/02/2010 01:28 AM, Vincent wrote:

Hi,

My email address is actually victim of a huge quantity of spam, so I wonder
where it can come from and I google it, and the first results where the
yorba bug tracker, where email address of all subscribed bug is published
and accessible to all.

I believe this need to be changed quickly because it an important privacy
issue.

Regards,


___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Email privacy

[Adam Dingle]

An update: I've now successfully configured Yorba Trac so it won't 
display email addresses unless you've logged in.  It turns out this was 
easy; thanks for the suggestion.


adam

On 11/02/2010 12:05 PM, Adam Dingle wrote:

Vincent,

Yes, this is a legitimate concern.  Fortunately, Trac allows you to 
use either your user ID or your email address in the CC list. I've 
replaced your email address with your ID (cameleon) in every ticket 
where you were on the CC list, so I believe it should no longer be 
exposed via any Yorba Trac pages.


Of course, it would better for our Trac server to obfuscate all email 
addresses on all pages accessed anonymously (i.e. without logging 
in).  Trac has a configuration option which is supposed to enable such 
obfuscation, but I haven't been able to get it working.  We'll look 
into this more soon.  I've created a Yorba infrastructure ticket to 
track this issue: http://trac.yorba.org/ticket/2753 .  Feel free to 
add yourself to the CC list.  ;)


adam

On 11/02/2010 01:28 AM, Vincent wrote:

Hi,

My email address is actually victim of a huge quantity of spam, so I 
wonder

where it can come from and I google it, and the first results where the
yorba bug tracker, where email address of all subscribed bug is 
published

and accessible to all.

I believe this need to be changed quickly because it an important 
privacy

issue.

Regards,




___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell Business model

[Adam Dingle]

Vincent,

At the moment, Yorba is entirely supported by donations from myself (the 
founder) and a growing list of others who wish to support our projects.  
We are not able to pay our team members as much as they would make at 
for-profit software companies, but we are fortunate that they have 
generously decided to work for us anyway in the spirit of contributing 
to free software.  :)


In the future we hope to help support ourselves by doing consulting work 
related to our projects, but that remains only a future hope at this 
time.  :)


cheers
adam

On 11/08/2010 11:49 AM, Vincent wrote:

Hi,

I have just read a great french
articleabout
free softwares and their business model, and now I wonder: what is the
model beyond yorba. I have understand that you have a team of 5 peoples, and
I guess that they are payed to develop the core of shotwell (among other
things). I wonder from where the money come from, has shotwell is (and will
be forever) totally free of charge.

Am I wrong? Can you explain me how it works?

Best regards,


___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Piwigo and shotwell can now talk to each other

[Adam Dingle]

On 11/09/2010 01:20 AM, Jani Monoses wrote:

Hi,

On 11/08/2010 06:28 PM, Guillaume Viguier wrote:

Hi,

I just wrote a connector to allow shotwell to upload to Piwigo. There
are still a few limitations (see
http://piwigo.org/forum/viewtopic.php?id=16431&p=2 ) but the connector
works and allows you to send your pictures to a Piwigo installation.

The code can be found here:
https://github.com/guillaumev/piwigoshotwell


Two observations
- you can get rid of the Config.vala changes and keep the code cleaner 
if you use the generic set/get_publishing_string functions as the 
picasa, youtube and yandex services do in trunk.
- you set MediaType.VIDEO in capabilities but the code does not seem 
to handle video otherwise


Thanks for the code review, Jani!




I'd like to know how the shotwell team will go about testing and
integrating this into Shotwell.


the easiest would be to provide a link to a running piwigo instance 
where it can be tested. Also I think the Shotwell team prefers issues 
being open in trac and having the patch attached.


That's true.  In fact, after Guillaume sent his message to this list he 
posted a patch to http://trac.yorba.org/ticket/2639 and there's a 
discussion active there now.


adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] no tags and/or missing exif data

[Adam Dingle]

On 11/08/2010 01:53 PM, gs_triumph wrote:

i may be missing a trick here but i have come across a couple of problems :

A. Is there a way to display only images that have no tags.  i feel this
would be a very useful feature as i am trying to import around 40 cd's worth
of photographs to be organised using tags


Not at this time.  We're considering this as a future feature, though - 
see http://trac.yorba.org/ticket/1609 .



B.  Is it possible to show images that have no exif data other than
dimensions?  i have a number of old photos that were scanned from 7x5 prints
that have no exif data other than dimensions.  There is no date to filter on
so i cannot view them.


When you import these photos into Shotwell, they will not be placed in 
any event since they have no date.  In the trunk (and hence in the 
upcoming 0.8 release) there's a No Event item in the sidebar that will 
show all these photos.



any help appreciated.

p.s.  i am enjoying using shotwell.  the interface is nice n simple and i am
glad to see that new features (such as writing tags to the file) are in
development.


Glad you like it!  :)

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Some ideas

[Adam Dingle]

Kimaidou,

On 11/08/2010 01:03 AM, kimaidou wrote:

Hi people,

I would like to first thank the devs involved in shotwell. This software is
KISS. It is exactly what I was looking for : light, simple but powerfull.


Thanks!  :)


I have some ideas regarding functionalities I used in jbrout (one of my
favorite) which are very important when you import and classify some
pictures.

Basically, when you import new pictures in your library, you :
1/ import all of them
2/ first pass : select the bad ones to delete them
3/ rotate the pictures if necessary
4/ tag the pictures
5/ choose some pictures to export in you web photo gallery (optionnaly
classify them in separate folder with the month, as 2010-10 , 2010-11, etc.


Right - this is a very common workflow.


To accomplish all theses steps smoothly, I have some features missing in
shotwell :

1/
  a>  an option to automatically rename the pictures with the exif date on
import, such as "20100912_085635a.ext" .


Right.  This is http://trac.yorba.org/ticket/1942 .


b>  import videos as well (I have seen it will be released in one of the next
versions : great !!! )


Yes - video support is now mostly implemented in trunk and will be 
present in the upcoming 0.8 release.



2/ I personally use the "reject" vote to preselect all the pictures I want
to delete after this first pass. It could be great to just add a display
filter : "All the rejected pictures", so that we can just display them all,
then CTRL+a and "Delete"


This seems like a good idea.  I've ticketed this at 
http://trac.yorba.org/ticket/2786 .



3/ An option to rotate the original picture (and not only save the pref in
the database).


Coming in 0.8: see http://trac.yorba.org/ticket/2788 .


4/
a>To make this step easier, It coud be handy to display the tags in full
display mode and fullscreen mode (as the vote is displayed). This way when
browsing picture by picture, we can easily see wich pics are not taged /
which tags are missing.


Agreed.  This is http://trac.yorba.org/ticket/2238 .


b>  In the thumbnail mode, add a way to easily see all the pictures with no
tags (to help retag all theses pictures when the weather is rainy during a
winter week-end :) )


Yes - a few people have asked for this.  See 
http://trac.yorba.org/ticket/1609 .



c>  Add some handy shortcuts in full display / fullscreen mode :
* typing any letter pops up the "add tag" windows (CTRL T) : this way, no
need to CTRL+T : just type the first letters, then Enter


Under consideration: see http://trac.yorba.org/ticket/1899 .


* Press "Spacebar" selects the picture : when you get out the full display
or fullscreen mode, eg with ESC, the selection remains and you can decide to
do an action (mass tag, delete, etc.)


See my comments below about flagging photos.


5/
a>  Add a "basket" selection mode : a way to have a selection wich remains
when you click out of a picture ANd which remains between sessions. Jbrout
had this feature, and it was great because you could stop the "choosing job"
one day and go on another day.


Right: we want to implement this by letting the user flag photos, which 
is similar to your basket selection.  See 
http://trac.yorba.org/ticket/2756 .  Hopefully in 0.9.



c>  Optionnaly display the picture date under the thumbnail, so that you can
select and export easily all the picture taken e.g.during "2010, august."


Once we implement views as described below, you'll easily be able to 
select all the photos taken during that month.



d>  Another feature linked : i"n the Event view, allow to see all the
pictures recursively. Now, when I double click on "january", it shows the
events (the days) of this month when pictures have been taken, but you have
to double click on one of theses days to see the pictures. What if I want to
see all pictures of january ?


We'd like to let the user choose views, so that they can see either all 
events from January or all photos from January.  This is 
http://trac.yorba.org/ticket/2413 .



e>  Allow to export to FTP (I tried mounting a FTP with nautilus, but got an
error)


Did you get the error when you tried to mount the directory in Nautilus, 
or when you tried to export photos to the directory via Shotwell?  What 
did the error message look like?  Shotwell should be able to export to 
an FTP-mounted directory via Nautilus with no problem, I think.



Hum.. I have written a long email... I am just very excited about shotwell,
so I decided to give some feedback of my personal use... I hope I have not
been too direct (english is not my native language as you have read ;)


Your English is great!  Thanks for all the suggestions - we're 
considering most of them already, but this kind of feedback really helps 
us understand our users' priorities.  Cheers -


adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] no tags and/or missing exif data

[Adam Dingle]

On 11/09/2010 04:33 AM, gimi wrote:

Hello,

On 11/08/2010 10:53 PM, gs_triumph wrote:
i may be missing a trick here but i have come across a couple of 
problems :


A. Is there a way to display only images that have no tags.  i feel this
would be a very useful feature as i am trying to import around 40 
cd's worth

of photographs to be organised using tags

B.  Is it possible to show images that have no exif data other than
dimensions?  i have a number of old photos that were scanned from 7x5 
prints
that have no exif data other than dimensions.  There is no date to 
filter on

so i cannot view them.

any help appreciated.
The trick or current workaround for both points could be to use the 
"Last Import" category right after the import. There, you can tag them 
and even get the option "Photos / Adjust Date and Time" and "Events / 
New Event" when selecting at least one photo.


Yes - that might be one possible workflow that works with Shotwell today.


Indeed, they are hard to find because of the always changing menu entrys.

Found one problem there: After adjusting the photos are not moved and 
instead stay in the default folder 2000/01/01. Bug?


As you've noticed, when you adjust a photo's date/time, currently it 
does not move to a different event.  And yes, I think it should probably 
move in this situation.  See http://trac.yorba.org/ticket/1940 .


Using jhead to adjust the EXIF date from the command line before 
importing is not pleasing.


Agreed!  :)

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Moving items from No Event

[Adam Dingle]

Michal,

On 11/09/2010 11:15 PM, Michal Hrušecký wrote:

Hi,

first of all, thank you for your great work, I really like Shotwell.
It is easy to use and finally I put some order to all my photos thanks
to you and Shotwell.


Glad you like Shotwell! :)


Now the question part. As I've got some videos too, I tried trunk
version and it almost works even for videos.


Glad you were brave enough to try the current trunk build. :)


That almost is there
because all my imported videos ended up in No Event section.


Right. Unfortunately, most common video container formats don't seem to 
have metadata indicating when a video was filmed, as far as we know. So 
any video you import from your hard drive will end up in No Event. If 
you import videos directly from a camera, Shotwell will put them into 
events according to the date they were filmed.



I was
trying to convert them to theora and fill in the date tag, but that
didn't helped.


If the Theora format supports date tags, then we should enhance Shotwell 
to be able to read them. I've just ticketed this here:


http://trac.yorba.org/ticket/2796


I don't really need them to be tagged even with time,
but it would be nice to be able to make them part of an event. I tried
dragging them to the event and searched for some other means how to do
it, but didn't found a way, how to do it.


Dragging them to events should work, but is broken in the trunk at the 
moment. See


http://trac.yorba.org/ticket/2763

We'll fix this soon.

adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Shotwell Business model

[Adam Dingle]

On 11/10/2010 12:19 AM, Vincent wrote:

On Mon, Nov 8, 2010 at 9:06 PM, Adam Dingle  wrote:


(...) At the moment, Yorba is entirely supported by donations from myself
(the founder) and a growing list of others who wish to support our
projects.  (...)


Hi Adam,
Thanks for this quick answer. In fact, I was wondering if Canonical and Red
Hat (which now include Shotwell in their last distribution) also contribute
to the project (giving money or help fixing bug). Are they among the
"others" supporter of the project?

PS: Note that maybe my question are not appropriate on this list, if this is
the case don't hesitate to not answer, I can understand it may be
"sensitive" information.


Vincent,

both Canonical and Red Hat have been friendly and helpful to Yorba in 
many ways - they've passed on many bug reports and feature ideas and 
have worked closely with us to make sure that Shotwell works well in 
their distributions.


This list is really about Shotwell, not Yorba, and I'd prefer not to 
discuss monetary donations to Yorba here.  (I think it would be nice if 
the Yorba Web site could include a list of donors who wish to be 
recognized, though, and I hope we can can set that up soon.)


adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] no tags and/or missing exif data

[Adam Dingle]

On 11/09/2010 02:36 PM, gs_triumph wrote:

If i want to install a different distro of linux is there a way i can
preserve my current tags?


There are 3 ways to do this:

1. If you copy your ~/.shotwell directory to the new installation, and 
also copy all your photos to the new installation at the same file path 
where they were previously (e.g. ~/Pictures), then your entire Shotwell 
state will be preserved.


If you've renamed events or moved photos between events, then only this 
technique will preserve your event data, since events are stored only in 
Shotwell's database and cannot be written to photo file metadata.


2. In Shotwell 0.7, if you export all your photos, then Shotwell will 
write the tags into the exported photos.  If you then import the photos 
into a fresh install of Shotwell your tags will appear there.


3. The Shotwell trunk includes a feature to write tags to photo files on 
the fly.  If you're adventurous enough to run the trunk build, you can 
enable the checkbox "Write tags, titles and other metadata to photo 
files" in the Preferences dialog.  Then all your tags will be written to 
photo files even without exporting them, and will be preserved if you 
import them into another instance of Shotwell (or another photo program).


adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Re: [Shotwell] Moving items from No Event

[Adam Dingle]

On 11/10/2010 08:07 AM, Adam Dingle wrote:


Right. Unfortunately, most common video container formats don't seem 
to have metadata indicating when a video was filmed, as far as we 
know. So any video you import from your hard drive will end up in No 
Event. If you import videos directly from a camera, Shotwell will put 
them into events according to the date they were filmed.


I looked into this more today, and found that for the very common 
Quicktime/MP4 container format we should actually be able to get 
metadata indicating when a movie was filmed.  See 
http://trac.yorba.org/ticket/2796 for details.  I hope we can implement 
this for 0.8.


adam

___
Shotwell mailing list
Shotwell@lists.yorba.org
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell