From: Vadik M. <vad...@mt...> - 2004-09-27 08:55:34
Attachments:
borders.patch
|
This patch hopefully should fix fullscreen mode in OO Impress. -- With best regards, Vadik Mironov <vad...@mt...> |
From: Kim W. <ki...@wo...> - 2004-09-27 16:56:08
|
I suspect you are right that there are problems with applications requesting fullscreen at startup. Could you please specify exactly which problem you are trying to solve and how I can reproduce it? Your patch will, however, in a number of cases not do what it should. When E16 "fullscreens" an application it does (among other things) - set border to borderless - figure out what the fullscreen size and location should be, taking into account xinerama configuration (don't span xinerama screens) and (if enabled) struts, as e.g. in don't cover panel apps. I think that calling EwinSetFullscreen() in stead of ResizeEwin() may be part of fixing the problem correctly. /Kim Vadik Mironov wrote: > This patch hopefully should fix fullscreen mode in OO Impress. > > > > ------------------------------------------------------------------------ > > --- ./etalon/e16/e/src/borders.c 2004-09-21 08:50:31.000000000 +0000 > +++ ./hacked/e16/e/src/borders.c 2004-09-26 16:58:04.349805664 +0000 > @@ -486,6 +486,13 @@ > /* if it hasn't been placed yet.... find a spot for it */ > x = ewin->x; > y = ewin->y; > + > + /* if it is already fullscreen */ > + if(ewin->st.fullscreen) > + { > + ResizeEwin(ewin,VRoot.w,VRoot.h) ; > + } > + > if ((!ewin->client.already_placed) && (!manplace)) > { > /* Place the window below the mouse pointer */ |
From: Andreas V. <li...@br...> - 2004-09-30 08:25:18
|
Am Mon, 27 Sep 2004 18:55:56 +0200 schrieb Kim Woelders: > I suspect you are right that there are problems with applications > requesting fullscreen at startup. > Could you please specify exactly which problem you are trying to solve > and how I can reproduce it? > > Your patch will, however, in a number of cases not do what it should. > When E16 "fullscreens" an application it does (among other things) > - set border to borderless > - figure out what the fullscreen size and location should be, taking > into account xinerama configuration (don't span xinerama screens) > and (if enabled) struts, as e.g. in don't cover panel apps. There is still another problem with fullscreen mode. I've some "On Top" stacking windows (pager, iconbox...). If I fullscreen some applications (mplayer in X mode (sdl works), gthumb,...) the "On Top" windows are still on top. Perhaps E should set a fullcreen window automatic as the most "On Top" window. But this has also other problems. For example blender is a fullscreen window, but opens new normal windows. So if blender is "On Top" all new windows open "behind" it. Perhaps it's a solution if E changes all "On Top" windows to normal windows if one window has fullscreen and after fullscreen the windows get their "On Top" back. Perhaps it's a solution to make this configurable for users who like this? Or should I write this topic in a bug report? regards Andreas |
From: Kim W. <ki...@wo...> - 2004-09-30 16:08:18
|
Andreas Volz wrote: > There is still another problem with fullscreen mode. I've some "On > Top" stacking windows (pager, iconbox...). If I fullscreen some > applications (mplayer in X mode (sdl works), gthumb,...) the "On Top" > windows are still on top. Perhaps E should set a fullcreen window > automatic as the most "On Top" window. But this has also other > problems. For example blender is a fullscreen window, but opens new > normal windows. So if blender is "On Top" all new windows open > "behind" it. > Blender is actually not a fullscreen app in the sense that it does not use the _NET_WM_STATE_FULLSCREEN hint but is a normal window requesting to be borderless and occupy the entire screen. Just an example of something that doesn't simplify the issue. > Perhaps it's a solution if E changes all "On Top" windows to normal > windows if one window has fullscreen and after fullscreen the windows > get their "On Top" back. Perhaps it's a solution to make this > configurable for users who like this? > I don't like the princple that the appearance of one window changes stacking properties of other windows. That just seems wrong to me. We can have multiple fullscreen windows on separate areas/desktops, should the existence of those affect stacking on desktops without fullscreen windows? Should we restack when entering/leaving a view containg a fullscreen window? I think that would be messy. > Or should I write this topic in a bug report? > Feel free to file a bug report. However, I don't expect to change anything until somebody comes up with a really good plan on how to do this right. /Kim |
From: <and...@st...> - 2004-09-30 19:56:32
|
On Thu, 30 Sep 2004, Kim Woelders wrote: > Andreas Volz wrote: > > There is still another problem with fullscreen mode. I've some "On > > Top" stacking windows (pager, iconbox...). If I fullscreen some > > applications (mplayer in X mode (sdl works), gthumb,...) the "On Top" > > windows are still on top. Perhaps E should set a fullcreen window > > automatic as the most "On Top" window. But this has also other > > problems. For example blender is a fullscreen window, but opens new > > normal windows. So if blender is "On Top" all new windows open > > "behind" it. > > > Blender is actually not a fullscreen app in the sense that it does not > use the _NET_WM_STATE_FULLSCREEN hint but is a normal window requesting > to be borderless and occupy the entire screen. > Just an example of something that doesn't simplify the issue. > > > Perhaps it's a solution if E changes all "On Top" windows to normal > > windows if one window has fullscreen and after fullscreen the windows > > get their "On Top" back. Perhaps it's a solution to make this > > configurable for users who like this? > > > I don't like the princple that the appearance of one window changes > stacking properties of other windows. That just seems wrong to me. > We can have multiple fullscreen windows on separate areas/desktops, > should the existence of those affect stacking on desktops without > fullscreen windows? Should we restack when entering/leaving a view > containg a fullscreen window? I think that would be messy. > > > Or should I write this topic in a bug report? > > > Feel free to file a bug report. However, I don't expect to change > anything until somebody comes up with a really good plan on how to do > this right. > > /Kim I can confirm that this fullscreen behaviour is only in e16, Metacity handles the problems with "On top" and fullscreen windows "properly". There is bound to be problems if e16 continues to handle fullscreen windows slightly differently from other windows managers. For the sake of compability, this fullscreen windows behavior should be the same in e16 as in Gnome's Metacity and the KDE's kwin. Or else, no one will want to use the fullscreen feature, because it will break on some systems. I've filed a couple of bug-reports on e16's fullscreen windows previously, maybe I can help by doing some testing or something? Andreas R=F8sdal |
From: Kim W. <ki...@wo...> - 2004-09-30 22:55:38
|
Andreas R=F8sdal wrote: > I can confirm that this fullscreen behaviour is only in e16, Metacity > handles the problems with "On top" and fullscreen windows "properly". > There is bound to be problems if e16 continues to handle fullscreen > windows slightly differently from other windows managers. For the sake = of > compability, this fullscreen windows behavior should be the same in e16= as > in Gnome's Metacity and the KDE's kwin. Or else, no one will want > to use the fullscreen feature, because it will break on some systems. > I've filed a couple of bug-reports on e16's fullscreen windows previous= ly, > maybe I can help by doing some testing or something? >=20 Allright then :) I have added an option to raise windows requesting fullscreen mode (in the "Window Placement Settings" dialog). That probably fixes some, but not all problems. /Kim |
From: Vadik M. <vad...@mt...> - 2004-09-28 10:50:39
Attachments:
borders-2.patch
|
27 =D1=E5=ED=F2=FF=E1=F0=FC 2004 16:55, Kim Woelders =ED=E0=EF=E8=F1=E0=EB: > I suspect you are right that there are problems with applications > requesting fullscreen at startup. > Could you please specify exactly which problem you are trying to solve > and how I can reproduce it? As I said, i've got a problem with OO Impress. When you open a presentation= =20 and press F9 for a fullscreen mode, the new window gets dimension from pare= nt=20 OO window. Before the mapping event come, there is two configure event with= =20 dimensions of the parent window. And window already have=20 _NET_WM_STATE_FULLSCREEN. When mapping event come,then after adoption, stat= e=20 is already fullscreen (ewin->st.fullscreen=3D=3D1) , but in further adoptio= n this=20 do not considered somehow.=20 > > Your patch will, however, in a number of cases not do what it should. > When E16 "fullscreens" an application it does (among other things) > - set border to borderless > - figure out what the fullscreen size and location should be, taking > into account xinerama configuration (don't span xinerama screens) > and (if enabled) struts, as e.g. in don't cover panel apps. Okey, but then EwinSetFullscreen should be changed, because it assumes that= =20 window comes in normal state, but it doesn't. Besides, this window already= =20 borderless. And on my opinion there is no need to sync state of window hint= s=20 another time. Probably it will better just call ScreenGetGeometry. Leave=20 decision to you. > > I think that calling EwinSetFullscreen() in stead of ResizeEwin() may > be part of fixing the problem correctly. > > /Kim Here is the patch. =2D-=20 With best regards, Vadik Mironov =09 <vad...@mt...> |
From: Kim W. <ki...@wo...> - 2004-09-28 19:45:19
|
Vadik Mironov wrote: > 27 =D1=E5=ED=F2=FF=E1=F0=FC 2004 16:55, Kim Woelders =ED=E0=EF=E8=F1=E0= =EB: >=20 >>I suspect you are right that there are problems with applications >>requesting fullscreen at startup. >>Could you please specify exactly which problem you are trying to solve >>and how I can reproduce it? >=20 >=20 > As I said, i've got a problem with OO Impress. When you open a presenta= tion=20 > and press F9 for a fullscreen mode, the new window gets dimension from = parent=20 > OO window. Before the mapping event come, there is two configure event = with=20 > dimensions of the parent window. And window already have=20 > _NET_WM_STATE_FULLSCREEN. When mapping event come,then after adoption, = state=20 > is already fullscreen (ewin->st.fullscreen=3D=3D1) , but in further ado= ption this=20 > do not considered somehow.=20 >=20 >=20 >>Your patch will, however, in a number of cases not do what it should. >>When E16 "fullscreens" an application it does (among other things) >>- set border to borderless >>- figure out what the fullscreen size and location should be, taking >> into account xinerama configuration (don't span xinerama screens) >> and (if enabled) struts, as e.g. in don't cover panel apps. >=20 >=20 > Okey, but then EwinSetFullscreen should be changed, because it assumes = that=20 > window comes in normal state, but it doesn't. Besides, this window alre= ady=20 > borderless. And on my opinion there is no need to sync state of window = hints=20 > another time. Probably it will better just call ScreenGetGeometry. Leav= e=20 > decision to you. >=20 >=20 >>I think that calling EwinSetFullscreen() in stead of ResizeEwin() may >>be part of fixing the problem correctly. >> >>/Kim >=20 >=20 > Here is the patch. >=20 OK, I never tried the F9 fullscreen mode, only the Ctrl-Shift-j one. I have committed a fix, essentially calling EwinSetFullscreen(). Thanks, /Kim |
From: Vadik M. <vad...@mt...> - 2004-09-29 09:30:49
|
28 =D1=E5=ED=F2=FF=E1=F0=FC 2004 19:45, Kim Woelders =ED=E0=EF=E8=F1=E0=EB: > > > > Here is the patch. > > OK, I never tried the F9 fullscreen mode, only the Ctrl-Shift-j one. > I have committed a fix, essentially calling EwinSetFullscreen(). > > Thanks, > /Kim > OK, but now there is another issue with OO. I found, that if there are some= =20 buttons on desktop, then they will be layd out over maximized window of OO.= =20 Is this a bug or feature? =2D-=20 With best regards, Vadik Mironov =09 <vad...@mt...> |
From: Kim W. <ki...@wo...> - 2004-09-29 17:25:49
|
Vadik Mironov wrote: > OK, but now there is another issue with OO. I found, that if there are some > buttons on desktop, then they will be layd out over maximized window of OO. > Is this a bug or feature? > Yes, it's a known bug/feature that (most) buttons are on-top. You can toggle them on/off with Ctrl-Alt-B. /Kim |