Re: Alternative UI for changing time and timezone

[Mattias Holmlund <mattias holmlund gmail com>]

On 8/22/05, Bengt Thuree <bengt thuree com> wrote:
> Hi
> 
> > I didn't really understand the difference between "Set time" and "Auto
> > increment time" in your dialog. My idea is that if you select several
> > images, you edit the time on the first image until it is correct and
> > then the same adjustment (i.e. the same increase/decrease) will be
> > done to all the other images. I can't really see a reason why you
> > would want to set the same date and time to all images regardless of
> > their current date/time.
> The autoincrement time is nice, if you have say 20 pictures you have the
> wrong time and date on (or who do not have any time at all), and you want
> the physical name to be like <timestamp>-Home.jpg or something like that.
> Then you want to ensure that all pictures have a different time.

Ok, I see your point. My thinking was that the dialog only needed to
handle the case where all selected pictures have the same amount of
error in the timestamp. This is what happens if you haven't set the
clock in your camera correctly. In this case, we always do an
adjustment to the time on each picture by increasing or decreasing it
by a certain amount.

Setting the time on all images without taking into account the current
time on the images is a very different function. To me, this is a very
specialized function. I think that all cameras today add a timestamp
to the images when they are taken. The only time you might encounter
an image without a timestamp is the exif-information has been removed.
Another possible use-case is when you have images from a lot of
different cameras and you don't have time to do an accurate adjustment
for each camera and just want to set them "roughly right". I think
both these cases are uncommon. We should support them, but we must
somehow make the distinction between "relative adjustment" and setting
an absolute time (with or without auto-increment).

 
> 
> >
> > I have also removed the checkbox/radiobuttons before the dates and
> > times. If the user doesn't want to change the date and/or time, he can
> > just avoid changing them in the dialog.
> Not the best solution I think.
> Since you might want to change the time on 50 pictures, that all were
> taken during different days. You only want to change the timezone...
> I am not sure how you would ensure that the date is not changed, if for
> instance the user be mistake fiddle around with the calender box...
> 

This situation differs between "relative adjustments" and absolute.
For relative adjustments, you always specify an adjustment in
plus/minus days, hours, minutes and seconds. If you don't want to
change the date, then days is simply set to zero. You specify the
amount of relative adjustment by changing the date/time for the first
picture and all subsequent pictures will be adjusted the same amount.
If you only want to change the timezone, you simply set the adjustment
to zero (by not changing the date and time in the dialog) and then
specify the new timezone.

For the absolute adjustments, I believe that you always want to set
both date, time and timezone. How can you possibly have a set of
pictures that have one of them correct but not the other? If you only
want to change the timezone, you should use the "relative adjustment"
function and not the absolute.

> >
> > Regarding timezones: There are two timezone settings in my dialog. The
> > first one specifies the timezone that the time is currently in. The
> > second one allows you to adjust the timezone. Note that if you start
> > off with a timestamp in for example UTC, there is a difference between
> > adding two hours and setting the timezone to +02:00 versus to convert
> > the timezone to Europe/Stockholm, since only the latter one takes
> > daylight savings time into account.
> >
> 
> I think that the two timezones are good, and needed.
> 
> I have a weird computer here. My hardware clock is set to Australian time,
> but local time is Irish in Windows. Linux is not handling this to well
> though. (dual boot)

Then you know about the pain involved in timezone handling...
 
> Lets see how the final solution will be.
>
> Anyway, I have submitted my patch so you can check the code and use bits
> and pieces from it perhaps.

I will think some more and try to come up with a new layout.

I will focus on the GUI first and worry about the code later.

/Mattias

> 
> I think we will have a good time changing function later.
> 
> /Bengt
> 
> 
> _______________________________________________
> F-spot-list mailing list
> F-spot-list gnome org
> http://mail.gnome.org/mailman/listinfo/f-spot-list
>