GNOME Bugzilla – Bug 563364
Show two timezones in the calendar's day view
Last modified: 2009-06-15 17:22:47 UTC
I heard Chen talking about such feature, but it seems he's busy with other things now, thus I decided to help him with it a bit. Mayby Suman can review this, it's not so much about calendaring.
Created attachment 124018 [details] [review] proposed evo patch for evolution;
Patch looks great! Nice work! The second timezone selector menu could be replicated in Edit -> Preferences -> Calendar and Tasks. It needs to be made more prominent. The way it is right now is probably too obscure for the average user. Also, when two timezones are displayed in the view, it'd be nice to have them labeled as such. As we discussed on IRC, maybe the column tool-tip could display the timezone. These are the only two comments that I had. Everything else looks great. Feel free to commit this patch right away and implement these ^^ in further commits.
Created attachment 124808 [details] [review] proposed evo patch ][ for evolution; addresses the above things except tooltips. The item is a GnomeCanvasItem, which is not derived from a GtkWidget, thus I cannot use "query-tooltip" there. otherwise it would be easy to implement even tooltips with timezone information. I also added keys to the scheme, changed their names and used locations instead of timezone ids for storing.
Awesome stuff, do you have a screenshot?
Created attachment 124920 [details] screen shot not yet :)
On first note, I think the time column deserves a heading. Atleast it wasn't very intuitive, in current state. Think, how we can solve this problem.
I agree, but not much space for the location; neither tooltips work easily for GnomeCanvasItem-s. I'm opened for any suggestions ;)
Do you really need to expose calendar_config_free_day_second_zones() ? Is it worth an API?? IMO, it'd be better to document calendar_config_get_day_second_zones() returns a newly allocated GSList whose items are newly allocated strings and let the caller handle free'ing it. Although, it's okay to use it as a static function within calendar-config.c Minor nitpick - please don't do: #define CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST CALENDAR_CONFIG_DAY_SECOND_ZONE "s" #define CALENDAR_CONFIG_DAY_SECOND_ZONES_MAX CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST "_max" Instead: #define CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST CALENDAR_CONFIG_PREFIX "/display/day_second_zones" #define CALENDAR_CONFIG_DAY_SECOND_ZONES_MAX CALENDAR_CONFIG_PREFIX "/display/day_second_zone_max" Or define another proper prefix if you like :) Other than that the patch looks great!
(In reply to comment #8) > Do you really need to expose calendar_config_free_day_second_zones() ? Is it > worth an API?? IMO, it'd be better to document > calendar_config_get_day_second_zones() returns a newly allocated GSList whose > items are newly allocated strings and let the caller handle free'ing it. > Although, it's okay to use it as a static function within calendar-config.c I use that function on 3 different places, once in a cal-prefs-dialog, once in e-day-view-time-item, and once a calendar-config. Thus I decided to have an API for that. > Minor nitpick - please don't do: > #define CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST CALENDAR_CONFIG_DAY_SECOND_ZONE > "s" > #define CALENDAR_CONFIG_DAY_SECOND_ZONES_MAX > CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST "_max" > Instead: > #define CALENDAR_CONFIG_DAY_SECOND_ZONES_LIST CALENDAR_CONFIG_PREFIX > "/display/day_second_zones" > #define CALENDAR_CONFIG_DAY_SECOND_ZONES_MAX CALENDAR_CONFIG_PREFIX > "/display/day_second_zone_max" You do not like compiler features, do you? :) I was just lazy to write 3 almost same rows, this helped me to keep same prefix for same thing without much checking. But I'll change it before committing.
Committed to trunk. Committed revision 37060. I only changed defines of paths, nothing else. Commit announced.
No, Patch does NOT look right. Having C two times as mnemonics (for "Se_cond zone" and the "_Close" button) sucks, in fact. And since when do we use "zone" instead of "time zone"?!
(In reply to comment #11) > No, Patch does NOT look right. > Having C two times as mnemonics (for "Se_cond zone" and the "_Close" button) > sucks, in fact. Can you reproduce that with other than english locale, say with czech? ;) Anyway, I overlooked that, I'm sorry. > And since when do we use "zone" instead of "time zone"?! Since when it's way too long and would enlarge whole column in some ugly way. ------- Feel free to reopen, and I will try to not forget during next version development phase.
*** Bug 227902 has been marked as a duplicate of this bug. ***
*** Bug 331375 has been marked as a duplicate of this bug. ***