Qtopia-interest Archive, March 2008
QtopiaApplication, placing and sizing of a QMessageBox and window managers
Message 1 in thread
Hey,
in a window management environment the window manager has certain power. It
can place a window, it can resize a window and it is free to ignore most of
the hints a window sets according to the specification.
Yesterday I got a bit annoyed of enlightenment and QtopiaApplication arguing
about the position of the QMessageBox.
Basicly you have code in qtopiaapplication.cpp which acts on resize and show
events for a qmessagebox and then is calling QtopiaApplication::showDialog
which is then trying to set a fixedSize. The easy fix is to try to force the
size and position (no infinite loop due this) only once instead of arguin
with the window manager. E.g. a call to setMinimumSize is good enough in our
use case and the window manager should handle and place the window just fine.
But while looking at the code I wonder if some of the shortcuts could be
avoided by moving functionality into Qt?
-E.g is it needed to swallow LayoutRequests and set WA_Moved on the
QMessgaeBox. If there is a performance issue with Qt, can it be fixed there?
-Poking internals of QMessageBox to get access to the QDialogButtonBox to
hide the buttons because there is a different button policy for Qtopia. But
then again QDialogButtonBox is already supporting Win, Mac, Gnome, KDE
layouts, why did you decide against adding a Qtopia like layout style with
not showing the buttons? E.g. the PhoneStyle could return Qtopia like button
layout and you avoid this ugly poking in internals and you would save code
as well... and have something maintainable, managable... If statically
adding the Qtopia layout mode is not possible, what about allowing to add
new modes at runtime? When adding these hacks in QtopiaApplication did you
communicate with Oslo at all? Did they encourage you to go for an
eventFilter? To be honest this would be something hard to believe.
-more stuff...
happy hacking
z.
--
[ signature omitted ]
