[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    [Kde-pim] Re: Review Request: KHolidays: New Holiday Region
From:       "John Layt" <johnlayt () googlemail ! com>
Date:       2010-10-04 15:22:18
Message-ID: 20101004152218.28467.59019 () vidsolbach ! de
[Download RAW message or body]



> On 2010-10-04 13:16:27, David Jarvie wrote:
> > I wonder whether it would be better to group countries by continent, as for time \
> > zone selection. One reason might be if there were cases where a user's country is \
> > not in the list, but a neighbouring country might supply suitable holidays - in \
> > this case, grouping by continent would make it easier to find a neighbouring \
> > country (bearing in mind that not all other countries will be in the list \
> > either). 
> > I don't think the default column heading "Select" is intuitive enough when "Days \
> > Off" is displayed alongside. I suspect that many people (myself included) would \
> > normally equate "holiday" with "day off". In this case, it isn't obvious what the \
> > "Select" column would be for. Having some acquaintance with KDE holiday files, I \
> > think I may know what the distinction is, but without knowing KDE holiday files \
> > I'd be completely in the dark. In any case, it would be more natural for the \
> > "Days Off" column to precede the "Select" column (suitably renamed). 
> > In the documentation in the header, there should be an explanation as to why or \
> > why not a developer should choose to display the Language column. It isn't \
> > obvious, to me at least, that language would be relevant to choosing a holiday \
> > region. If one language was spoken in one region and another was spoken in \
> > another region, then I'd expect the holidays to be different, but that would be \
> > because it was a different region. And if a single holiday had a different name \
> > in one language from another, I'd expect the displayed name to follow the user's \
> > locale language, not the holiday file's. 
> > It's a pity that your indent will have to be changed to 2 spaces - it's much more \
> > legible using 4 spaces.

Some good points to think about.

I'm not sure about Continents, as that would make it less obvious for the main use \
case when finding your country when it does exist.  I'll have a play with the idea \
anyway.  The region name ordering does need some improvement, I'm working on some \
changes for holiday types which would allow us to split things up more so that should \
help.  Once we have more categories to select from then better sorting will be \
possible, in fact desirable as we will have non-geographical region based files.

I did struggle with the select/days-off thing.  The main use case would be where for \
example a UK business user wants to show on his calendar the holidays for England, \
Germany and the USA so he knows when his business clients have holidays, but \
obviously only wants the England holidays to count as Days Off for his scheduling or \
showing red highlights.  You're right the primary use is for a single region and it \
should default to being used as Days Off, it just seemed to me to have the second \
column be an opt-out named "Don't use for Days Off" was more awkward and inconsitent, \
i.e. one tick works as opt-in and the other as opt-out.  Perhaps clicking the first \
column should automatically select the second?  This will become especially important \
when we have categories and separate files for Public, Religious and Cultural \
holidays and more users will have cause to select multiple files.  I wonder if a \
combo box with values for "Don't Use", "Info Only", and "Days Off" might be better \
(but that wouldn't work in single selection mode)?  The tooltip and whatsthis \
probably need to explain the difference better, but it does depend on what the client \
uses it for, e.g. KOrganizer will use Days Off for scheduling, but the Plasma Clock \
will only use it for colouring days.

The Language column is an artifact of the holiday region files only supporting a \
single language and not having any translations available, without displaying the \
language the user wouldn't know which they were getting.  For example, Belgium has 3 \
official languages, ideally there would be a single holiday region file for the \
national holidays with i18n() taking care of the rest, but that's not possible yet \
(hopefully in 4.7 with a new xml file format and proper i18n tools).  I did think of \
only showing files available in the users language, but that would prevent \
multilingual people using files they need that are only in other languages.  So I \
left that to the app to decide if they wanted to filter for language.  Also if the \
app doesn't have much space they could hide the language column and just rely on the \
tooltip to show the difference.  Perhaps the middle ground would be to initially only \
list the current language, but have a button or tickbox to show all languages?  \
Anyway, I'll improve the docs.


- John


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5518/#review7963
-----------------------------------------------------------


On 2010-10-02 18:21:32, John Layt wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5518/
> -----------------------------------------------------------
> 
> (Updated 2010-10-02 18:21:32)
> 
> 
> Review request for kdelibs and KDE PIM.
> 
> 
> Summary
> -------
> 
> Implement a standard widget in the KHolidays library for clients to use to allow \
> users to select holiday regions to be displayed.  The widget provides a number of \
>                 modes and features to fit most use case scenarios I can think of:
> * A display only mode
> * A single Holiday Region selection mode
> * A multiple Holiday Region selection mode with optional secondary selection for \
>                 Days Off / preferred Holiday Region
> * A search line
> * Ability to modify level of detail displayed when space is limited
> 
> Some points to think about:
> 1) I've implemented Qt Designer plugin support for the widget using a KHolidays \
> specific plugin, but should the Designer support actually be at kdepimlibs level \
> instead, i.e. all kdepimlibs widgets in a  single shared plugin? 2) Naming of the \
> widget, enum and api calls 3) The layout of the selection boxes and columns
> 
> 
> Diffs
> -----
> 
> /trunk/KDE/kdepimlibs/includes/KHolidays/HolidayRegionSelector PRE-CREATION 
> /trunk/KDE/kdepimlibs/kholidays/CMakeLists.txt 1180311 
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.h PRE-CREATION 
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.cpp PRE-CREATION 
> /trunk/KDE/kdepimlibs/kholidays/holidayregionselector.ui PRE-CREATION 
> /trunk/KDE/kdepimlibs/kholidays/kholidays.widgets PRE-CREATION 
> 
> Diff: http://svn.reviewboard.kde.org/r/5518/diff
> 
> 
> Testing
> -------
> 
> Test client implementation done in the Plasma clock/calendar.
> 
> 
> Screenshots
> -----------
> 
> Widget example
> http://svn.reviewboard.kde.org/r/5518/s/523/
> 
> 
> Thanks,
> 
> John
> 
> 

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


[prev in list] [next in list] [prev in thread] [next in thread]