[immodule-qt] Status of Qt 4 port and some questions

Lars Knoll lars at trolltech.com
Thu Oct 14 17:53:41 EEST 2004


On Thursday 14 October 2004 16:11, Daisuke Kameda wrote:
> Lars Knoll <lars at trolltech.com> wrote:
> > I'm finally back from my vacations and we have done most of the work of
> > importing your code to our current Qt4 branch. I'll shortly mention the
> > changes I have done up to now and then have some questions to you.
>
> Thank you for your work and report.
>
> > While importing the code into Qt4, I noticed, that some methods in the
> > API were not really needed and thus removed them:
> >
> > I removed:
> > * QApplication::postIMEvent as it's nothing else than qApp->postEvent,
> > and I couldn't see why you would need a slot for this.
>
> I think that this code is required because of compatibility with Qt/E.
> Probably, Yamaken will explain in detail.

I had a look at Qt/e 2.3.7 and there we only use qApp->sendEvent().

> > * QInputContext::deletionRequested(). I could remove this signal by using
> > a QPointer for QWidgetPrivate::ic. Now you can just call "delete this" in
> > case of an fatal error in the input context without dangling pointers in
> > other places.
>
> It sounds good.

Ok :)

> > I renamed QWidget::getInputContext() to QWidget::inputContext() as the
> > old name doesn't fit with our naming conventions.
> >
> > I will probably need to change a few more method names a little to fit
> > our naming conventions and to make it possible to implement text widgets
> > in a cross platform way (ie. QLineEdit should not have any #ifdef's for
> > X11, and should be able to achieve the same results on Qt/Windows).
>
> It is good, I think.

Ok :)

> > Now my questions:
> >
> > I had a look at your documentation of isPreeditRelocationEnabled(). As
> > fas as I understand you this is used to not loose the preedit string when
> > focusing a different widget. In this case the preedit string is
> > transferred over to the new focus widget. If I understand you correctly,
> > this is just a hack to not loose the string, and the correct behaviour
> > would be to keep the preedit string in the first widget so one can
> > continue when focus comes back to it. If that is indeed the desired
> > behaviour, I think I might have a way to implement it in the general
> > framework without lots of additional work for the implementors of input
> > methods. I think it might at the same time enable text widgets to support
> > reconversion.
>
> Sorry, it is difficult for me to reply to this question in detail.
> The desired behaviour is not single, I understand.
> The intention of our code which you understood is also one of it.
> Therefore, isPreeditRelocationEnabled() is needed as a flag.
>
> Probably, Yamaken who also develop uim will explain in more detail.
> Please give us detailed explanation, Yamaken.
>
> > QInputContext::language() currently returns a QString. Wouldn't a QLocale
> > object be more correct?
>
> I think so. Why isn't QLocale used in present code, Yamaken? Is an
> understanding that the code remains taking Qt3.2.x into consideration
> right?

I'll change this to a QLocale then if noone complains in the next few days.

> > The QInputContext::mouseHandler() method takes a parameter 'x'. Am I
> > correct that this is the current cursor position inside the preedit
> > string?
>
> I think that the value of x depend on the position which
> clicked the mouse instead of the current cursor position.
> So, QWidget::sendMouseEventToInputContext() is needed.

That means we should probably rather name the parameter 'cursorPosition' or 
something similar than 'x'. 

Thanks,
Lars



More information about the immodule-qt mailing list