Review Request: Make mouse cursor size configurable

Chusslove Illich caslav.ilic at gmx.net
Sun Jul 17 21:00:05 BST 2011



> On July 12, 2011, 8:56 a.m., Christoph Feck wrote:
> > kcontrol/input/xcursor/xcursortheme.cpp, line 73
> > <http://git.reviewboard.kde.org/r/101701/diff/1/?file=24784#file24784line73>
> >
> >     Do you mean the sizes are always > 0, or do you mean the number of entries in the list is > 0 ("never empty")?
> >     
> >     Do we need some logic to prevent it saying "Available sizes:" when only one size is available? But I am not sure if i18n can handle that.
> 
> Lukas Sommer wrote:
>     It means "never empty".
>     
>     This could be a solution to the plural problem:
>     
>             // The translation is aware of plural forms. i18ncp uses the first integer argument to
>             // distinguish plural forms. The first and the second argument are QString. So we use
>             // sizeList.size() as third argument to provide proper support for plural forms. This 
>             // works, although it is never referenced with %3 in the string itself. Although we
>             // provide english strings only for "1 item" and for "more than 1 item", but i18ncp
>             // will silently expand to as many plural forms as necesarry in the target language.
>             m_description = i18ncp(
>               "@info/plain This is the description of the cursor themes. The first argument is the "
>                 "original description that comes from the index.theme file. The second argument is "
>                 "the list of available sizes, which is never empty. This string is localized with "
>                 "support for plural forms: You can make different singular/plural translations "
>                 "depending on the number (!) of list items in the second argument.",
>               "%1 (Size: %2)"            /* only 1 item in sizeListString      */
>               "%1 (Available sizes: %2)" /* more than 1 item in sizeListString */
>               ).arg(m_description).arg(sizeliststring).arg(sizeList.size());
>     
>     I'll test this after holiday.
> 
> Chusslove Illich wrote:
>     i18ncp() should not be used for clever tricks. The plural string should
>     always be the direct pluralization of the singular string.
>     
>     I think it would be just fine to leave it at the original version, with "...
>     Available sizes: ..." even if there is only one size. Also no need to
>     mention in the context that list of sizes is never empty.
>     
>     Otherwise, use two separate messages with ordinary if-selection.
>
> 
> Lukas Sommer wrote:
>     What's about merging both approaches?
>     
>             int sizeListSize = sizeList.size();
>             QString sizeListString = QString::number(sizeList.takeFirst());
>             while (!sizeList.isEmpty())
>             {
>                 sizeListString.append(", ");
>                 sizeListString.append(QString::number(sizeList.takeFirst()));
>             };
>             if (sizeList.size() == 1)
>                 m_description = i18ncp(
>                     "@info/plain This is the description of the cursor themes. The first argument is "
>                         "the original description that comes from the index.theme file. The second "
>                         "argument is the size (in pixel). Example: 'OriginalDescription (Size: 24)'",
>                     "%1 (Size: %2)").arg(m_description).arg(sizeListString);
>             else // sizeList.size() > 1
>                 /* The translation is aware of plural forms. i18ncp uses the first integer argument to
>                    distinguish plural forms. The first and the second argument are QString. So we use
>                    sizeList.size() as third argument to provide proper support for plural forms. This 
>                    works, although it is never referenced with %3 in the string itself. Although we
>                    provide english strings only for "1 item" and for "more than 1 item", but i18ncp
>                    will silently expand to as many plural forms as necesarry in the target language. */
>                 m_description = i18ncp(
>                     "@info/plain This is the description of the cursor themes. The first argument is "
>                         "the original description that comes from the index.theme file. The second "
>                         "argument is the list of available sizes (in pixel). This string is localized "
>                         "with support for plural forms: You can make different singular/plural "
>                         "translations depending on the number (!) of list items in the second "
>                         "argument. Example: 'OriginalDescription (Available sizes: 24, 36, 48)' has "
>                         "the plural form for 3 because the list has 3 items.",
>                     "%1 (Available size: %2)"  /* only 1 item in sizeListString - will never be used */
>                     "%1 (Available sizes: %2)" /* more than 1 item in sizeListString */
>                     ).arg(m_description).arg(sizeListString).arg(sizeListSize);
>     
>     This way we have a good translation for only 1 size: (Size: 24). In this case the user can't do anything but use this size. And in the case of more than 1 size, the user can determine himself which size he wants to use: (Available sizes: 24. 36, 48)
>     
>     Otherwise, we could also drop the "if" block and use only the "else" block ...
>     
>     What do you think?

Plural messages really are to be used only when a part of the sentence
grammatically depends on a number, and that number itself is part of the
sentence. So there should not be any kind of plural message here.

>From the style viewpoint, I personally would stick with single "Available
sizes: ..." regardless of how many sizes there actually are. If a special
message is used for the case of size == 1, I have no clear preference
between "Size:" and "Available size:".


- Chusslove


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101701/#review4633
-----------------------------------------------------------


On June 20, 2011, 10:04 a.m., Lukas Sommer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101701/
> -----------------------------------------------------------
> 
> (Updated June 20, 2011, 10:04 a.m.)
> 
> 
> Review request for KDE Base Apps, KDE Runtime, kdelibs, and Christoph Feck.
> 
> 
> Summary
> -------
> 
> X11 mouse cursor themes can contain cursors in multiple sizes, making them pseudo-scalable.
> 
> It is yet possible in KDE to configure manually the mouse cursor size (editing kcminput.rc). However, the GUI of the corresponding KControl module didn't provide support to change this. This patch add support for changing the mouse cursor size to the GUI.
> 
> This are mostly GUI related changes. The underlying data structure XCursorTheme did yet provide support for choosing different sizes and only needed some adjustments.
> 
> 
> This addresses bug 90444.
>     http://bugs.kde.org/show_bug.cgi?id=90444
> 
> 
> Diffs
> -----
> 
>   kcontrol/input/xcursor/xcursortheme.cpp a987487 
>   kcontrol/input/xcursor/themepage.ui 2e38054 
>   kcontrol/input/xcursor/xcursortheme.h b474086 
>   kcontrol/input/xcursor/themepage.h 902148f 
>   kcontrol/input/xcursor/themepage.cpp 24b9efe 
>   kcontrol/input/xcursor/previewwidget.h f4d2c4e 
>   kcontrol/input/xcursor/previewwidget.cpp 3c264fc 
>   kcontrol/input/xcursor/cursortheme.h 8f7834b 
>   kcontrol/input/xcursor/legacytheme.h 23c9d5f 
> 
> Diff: http://git.reviewboard.kde.org/r/101701/diff
> 
> 
> Testing
> -------
> 
> Tested locally. Works fine for me. Also when using non-standard font DPI values.
> 
> 
> Screenshots
> -----------
> 
> 
>   http://git.reviewboard.kde.org/r/101701/s/188/
> 
>   http://git.reviewboard.kde.org/r/101701/s/189/
> 
> 
> Thanks,
> 
> Lukas
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110717/b2473507/attachment.htm>


More information about the kde-core-devel mailing list