On Wed, 11 Aug 2010 12:02:57 -0700, Adam Dingle <[email protected]> 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.
That's why I tried the ~/.gvfs hack. And yes, I'll try to build the
current trunk and get a backtrace. I'll ask for help if I fail with gdb.
 (P.S. I am running trunk now under gdb now)

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

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.


> You're right that it's a major limitation that you can't currently find=20
> undated photos and/or photos which belong to no event, and we hope to=20
> fix this soon.

Yep, I am pretty sure you are aware of that, just wanted to throw in my
voice and saying that this has bitten me in real-world usage :).

> By the way, Shotwell does currently include an Undated folder (mentioned=
=20
> in http://trac.yorba.org/ticket/1632) but that's not quite what you're=20
> looking for.  The Undated folder contains all events which Shotwell=20
> can't place under any year in the sidebar tree because those events=20
> contain only undated photos.  Currently Shotwell does not place undated=20
> photos into any event at import time, but you can still place them into=20
> 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 assume that you realize that you can right click any tag in the=20
> sidebar and choose the Rename command to rename it.  It's true that=20
> Shotwell doesn't let you rename a tag only in a selected set of photos,=20
> 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?!!! :-)).
Renaming the tag oliver to Oliver effectively merging them, is not
possible. Mass editing the photos with tag oliver is not possible
either. So manual editing it was.

> We are hoping to implement an all-in-one search box which lets you=20
> search by tag, title, filename and so on.  The design of the search box=20
> is still up for discussion, but probably you'll be able to simply type a=
=20
> string to perform a search over all fields, or to select a particular=20
> search type.  If you select a search by tag, it would be nice if the=20
> search box would autocomplete tag names.  I'm not quite sure whether=20
> this is what you mean by "a search bar that dynamically reduced the list=
=20
> of tags to those potentially matching", though.

Not exactly. If I have a tag Boston_2003 and Boston_2008, and I start
typing "Bos" I want to see the possible autocompletions in a list as a
hint as to what I might want. Just hiding all tags in the tag list
that don't match the typed string would achieve that.=20

> > - A couple times I had clicked on an image in the viewer and the arrow
> >    keys would move the image around rather than navigating the image
> >    collection. Call me stupid but I had a hard time finding where I had
> >    to click to get back to the navigating. Not sure what could be done
> >    about this if at all.
> >=20=20=20=20
>=20
> If you got into a mode where the arrow keys move the image around, then=20
> you must have zoomed into the image slightly, either by using the mouse=20
> scroll wheel or by dragging the zoom slider at the bottom of the image.=
=20=20
> You can get back to the navigating mode simply by zooming back out, e.g.=
=20
> by using the scroll wheel.

Yep, that must have happened by accidentally sliding over my touchpad or
so. I managed by explicitly clicking the back/forward icons, but I tried
clicking on the image (which did not help). But as I said, I am not sure
there is a way

> > - 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 :)

> Not as such.  It's a longer-term goal of Shotwell to allow easy photo=20
> sharing across both local networks and the Internet, but we're not there=
=20
> yet.  See http://trac.yorba.org/ticket/1292 .

Yep, I was more thinking of a hacky script that adapts path names in
photo.db and stuff like that. I might create one myself :).

> Right.  Shotwell *will* add those tags when you export photos using the=20
> File->Export command.  We're also thinking of storing those tags into=20
> photo files on the fly, as many users have requested - this is=20
> http://trac.yorba.org/ticket/1290 .

Good to know that exporting the photos would embed the tags. THanks
again.

Sebastian
_______________________________________________
Shotwell mailing list
[email protected]
http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell

Reply via email to