The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: QT 4.4 and Domino
by Troy Unrau on Tuesday 05/Feb/2008, @15:58
|
Solid will not have anything to do with this situation, as it's a hardware detection and presence library. X is still X.
|
[
Reply To This | View ]
|
Re: QT 4.4 and Domino
by Aaron Seigo on Tuesday 05/Feb/2008, @19:30
|
> It will also destroy performance over remote X11.
the obvious solution is to fall back to non-aliens. on request, the widgets can become non-aliens so this should be possible. just .. need to do it =)
> it will still flicker horribly,
compositing and aliens actually help quite a bit here. but you're right, it's still not perfect. i discussed with some x devs while in the airporate in melbourne last week about possible solutions. nothing on the near horizon yet, though.
|
[
Reply To This | View ]
|
Re: QT 4.4 and Domino
by Anon on Wednesday 06/Feb/2008, @00:58
|
"he obvious solution is to fall back to non-aliens. on request, the widgets can become non-aliens so this should be possible. just .. need to do it =)"
Would it be possible in principle to toggle this (with full-fledged KDE apps only, if need be) on-the-fly using a DBUS call? What about double-buffering of widgets which is hugely wasteful if a compositing window manager is running? Being able to easily turn either of these features on or off in all running KDE4 apps would be great :)
|
[
Reply To This | View ]
|
Re: QT 4.4 and Domino
by jos poortvliet on Wednesday 06/Feb/2008, @03:17
|
Turning of doublebuffering for widgets is NOT what you want, everything will look horrible even with compositing. That one needs TT to work on it...
|
[
Reply To This | View ]
|
|
Re: QT 4.4 and Domino
by Nick Shaforostoff on Wednesday 06/Feb/2008, @11:27
|
btw, what's about xcb adoption by Qt?
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|