KIntNumInput::setTemplate(const QString &template)
caslav.ilic at gmx.net
Thu Sep 14 12:36:11 BST 2006
>> [: Tom Albers :]
>> I think QSpinBox needs to be subclassed for it, but then then the
>> valueFromText will be pretty complicated: How to extract the number
>> back from the complete text? Walk from min to max and compare strings
>> seems not very efficient (even when I completly ignore the doubleInt
>> variant). Any ideas?
> [: Tom Albers :]
> Could someone please look at this mail and set me in the right
As far as parsing is concerned, I could see (though, not before end of
September) what needs to be done with KLocalizedString to make it easier.
We were discussing in another thread possibilities for semantic marking of
placeholders, and I would even like to make plural handling in that way
(current way has some limitations I don't like). Eg. future plural
messages might look like:
i18np("Delete this file?", "Delete these <kn>%1</kn> files?", nFiles)
or in context of ki18n*:
ki18np("Delete this file?",
"Delete these <kn>%1</kn> files?").subs(nFiles).toString()
where <kn> would be one of series of KDE semantic tags, instead of current
Translators know that they should not touch tags, so in case of
KIntNumInput, it would be easy to split the message correctly.
However, I didn't reply to this thread before, because the basic idea of
such a widget is doubtfull in my view. For one, in many places programmers
put only the number into the box, and text as invariant element outside,
so there is this discrepancy in style. Then, even with correct plural,
such messages, composed of some text, some widgets, usually end up with
even uglier problems. Very good example (favorite of Hasso Tepper) would
be setting yearly recurrence of events in KOrganizer :)
This makes me wonder if perhaps we should just forget about fixing
KIntNumInput, and think about altogether different widget.
My idea was a "sentence control" widget, where there would be a normal
sentence presented in the dialog, with parts highlighted in some way.
Then, when the user clicks on the highlighted element, whatever type of
widget would pop up in place, containing only the basic form of whatever
is being set. As soon as the user clicks away, widget disappears and the
sentence is properly updated via ki18n* call. A KLocalizedString sent to
such a widget could be:
ki18n("Repeat every <kgui id='wday'>%1</kgui> of "
Again, translators are used to keeping the tags, and they could even
rearrange widgets into correct order for their language. As soon as the
user changes one sentence element, the sentence is simply updated within
where KLocalizedString would take care of visual transformation of <kgui>
tags, same as with any other semantic <k*> tags.
Implementing this, however, is *way* out of my capabilities :)
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel