Openmoko Bug #1762: [illume bar menu] menu will hiding after qt-keypad when creating texts
Openmoko Public Trac
bugs at docs.openmoko.org
Fri Aug 29 09:29:16 CEST 2008
#1762: [illume bar menu] menu will hiding after qt-keypad when creating texts
---------------------------+------------------------------------------------
Reporter: wendy_hung | Owner: zecke
Type: defect | Status: assigned
Priority: high | Milestone: Om2008.9
Component: E - Illume | Version:
Severity: major | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
---------------------------+------------------------------------------------
Changes (by raster):
* owner: raster => zecke
* status: reopened => assigned
Comment:
oooh the COMPOSE window (that lists all the matches in the dictionary).
you have to be in the middle of editing a word with the keyboard! that is
a separate window to the keyboard window. the keyboard window is below -
that one is not.
problem - it's an override-redirect window. it bypasses the window
manager. which means e/illume have zero control over it - they know
nothing about it. e (the window manager) has been bypassed.
unfortunately.... there isn't a lot e can do about it. not until qpe
changes it to be managed. the problem is.. if it changes to be managed -
it will be like any normal window and e will want to manage it as such...
and that also causes problems. so there isn't much to be done here right
now. it's between zecke and me as to what do to - but i can't do a fix (i
didn't know it was the compose box - i thought it was the keyboard - which
is under the slipshelf of illume and that is fine. it's this extra
override-redirect window that covers the application window area that is
the problem).
zecke - what do you want to do? if this area was part of the qpe kbd (like
the illume one) it wouldn't be a problem. if its override-redirect... it's
really hard to do anything as the wm knows nothing of these windows. it
cant maintain stacking. if it become managed - we have whole bunch of
issues... like a managed window that needs to not have the wm do any
special re-sizing and arranging? and right now all windows get this if
they are managed... this could replace the softmenu window contents - but
then you'd need softmenu for non-qtopia apps too... again. kettle of
problems. simplest is not have it override and make it part of the
keyboard window and just have the window be bigger. but.. willing to talk.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1762#comment:5>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list