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

[YamaKen]

Hi Lars, thank you for the work.

At Thu, 14 Oct 2004 16:53:41 +0200,
lars at trolltech.com wrote:
> 
> 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().

We can't use qApp->sendEvent() from a QInputContext on Qt/E.

> > > * 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 :)

The two are intended to make immodules compatible with
Qt/Embedded platform. Since QInputContexts on Qt/Embedded
platform will run on QWSServer process which is separated from
client application process, any QInputContexts cannot send
IMEvents by QApplication::postIMEvent() or
QApplication::sendEvent(). See QWSServer::sendIMEvent().

See also following explanations.

http://freedesktop.org/pipermail/immodule-qt/2004-September/000483.html

http://freedesktop.org/pipermail/immodule-qt/2004-August/000319.html (See section 4)

> > > 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 :)

I prefer your own way :)

> > > 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 spec had been decided to support Qt 3.2.x. We should use
QLocale at least for Qt4.

> > > 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'. 

I have no idea about a meaningful name that will not introduce
misunderstanding about mouse cursor and text cursor.

The 'x' is the current mouse cursor position as character offset
inside the preedit string, as same as
QWSInputMethod::mouseHandler() of Qt/Embedded. For example, it's
used for selecting a segment of preedit string


I'll reply other issues later, of course for other people.

-------------------------------
YamaKen  yamaken at bp.iij4u.or.jp