Hi,
ext Matthew Allum wrote:
>> For system dialogs (which take focus) coming on top of the fullscreen
>> application, the screen size was supposed to be switched back to normal
>> by the WM before it allows it on screen. If the dialog contents are
>> rendered before the dialog is shown, this could be a problem, but
>> doesn't that happen at expose event i.e. hopefully late enough that
>> the screen size is back at normal? If this cannot be guaranteed,
>> then it's better that the screen size would be changed only when
>> the topmost window changes.
>
> Note, this was just one potential problem - and with any problem
> theres going to be somekind of workaround. Its just special casing
> everything to 'subvert' randr is going to need alot and therefor I
> dont see what you gain from using randr to do it ?
Daniel wants to get rid of non-standard Xsp. :-)
>> >> And if that's the thing you're concerned about, then switching
>> >> screen orientation will be a similar problem and Matchbox should
>> >> anyway be fixed to notify only visible windows of the screen
>> >> geometry changes.
>> >
>> > Its not matchbox notifying the windows that the display size has
>> changed.
>>
>> Will the DPI change also for applications that don't have any mapped
>> windows on screen?
>
> No idea I guess this would be toolkit dependant.
>
>> (Did Matchbox unmap the windows when the are
>> backgrounded, or are they just not visible?)
>
> MB does not unmap windows unless they are minimised. It would be
> trivial to make it do so however.
>
> Any comments on my 'simple' non vt switching solution without randr ?
Using Xsp? Using TN instead of MB (why?)?
> It would be fairly easy to simulate in Xephyr if thats a worry btw.
- Eero
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
