KIntNumInput::setTemplate(const QString &template)

Tom Albers tomalbers at
Wed Sep 20 09:06:28 BST 2006

Op Thursday 14 September 2006 13:36, schreef Chusslove Illich:
> >> [: 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
> > direction?
> 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
> rich-text visuals.
> 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 "
>        "<kgui id='wmonth'>%2</kgui>")
> 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
> the widget:
> kmsg.subs(day).subs(month).toString()
> 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 :)

Mine too. ;-(
I think it would be nice to have though. 


More information about the kde-core-devel mailing list