From: Mick <mic...@gm...> - 2010-07-01 15:43:07
|
Hi All, I updated E17 from the cvs two days ago and I noticed that gkrellm2 which should be positioned at the bottom right corner of the screen, keeps being pushed up by the height of the bottom shelf. The shelf does not occupy the whole width of the bottom of the screen, so I'm not sure what pushes gkrellm up with this version of E17 I've just installed. I have added gkrellm at the startup apps for some time now, but as I said this was fine until now. I have tried setting up More/Remember/Name+Position, but it is still being pushed up. Any ideas? -- Regards, Mick |
From: Christopher M. <cpm...@co...> - 2010-07-02 00:33:49
|
On 07/01/2010 11:35 AM, Mick wrote: > Hi All, > > I updated E17 from the cvs two days ago and I noticed that gkrellm2 > which should be positioned at the bottom right corner of the screen, > keeps being pushed up by the height of the bottom shelf. Noticed this lately myself. Shelf position is not a factor, happens w/ any... assuming recent e_zone changes wrt shelf position(s) and "dirty" space... The shelf > does not occupy the whole width of the bottom of the screen, so I'm > not sure what pushes gkrellm up with this version of E17 I've just > installed. > See above > I have added gkrellm at the startup apps for some time now, but as I > said this was fine until now. I have tried setting up > More/Remember/Name+Position, but it is still being pushed up. > > Any ideas? Cheers, dh |
From: Mick <mic...@gm...> - 2010-07-03 07:55:58
|
On Friday 02 July 2010 01:31:11 Christopher Michael wrote: > On 07/01/2010 11:35 AM, Mick wrote: > > Hi All, > > > > I updated E17 from the cvs two days ago and I noticed that gkrellm2 > > which should be positioned at the bottom right corner of the screen, > > keeps being pushed up by the height of the bottom shelf. > > Noticed this lately myself. Shelf position is not a factor, happens w/ > any... assuming recent e_zone changes wrt shelf position(s) and "dirty" > space... This 'dirty space' you mention was not happening before - is this a bug? -- Regards, Mick |
From: Christopher M. <cpm...@co...> - 2010-07-03 13:22:35
|
On 07/03/2010 03:55 AM, Mick wrote: > On Friday 02 July 2010 01:31:11 Christopher Michael wrote: >> On 07/01/2010 11:35 AM, Mick wrote: >>> Hi All, >>> >>> I updated E17 from the cvs two days ago and I noticed that gkrellm2 >>> which should be positioned at the bottom right corner of the screen, >>> keeps being pushed up by the height of the bottom shelf. >> >> Noticed this lately myself. Shelf position is not a factor, happens w/ >> any... assuming recent e_zone changes wrt shelf position(s) and "dirty" >> space... > > This 'dirty space' you mention was not happening before - is this a bug? > I believe it is, yes. dh |
From: Andreas V. <li...@br...> - 2010-07-04 11:40:10
|
Am Thu, 1 Jul 2010 16:35:10 +0100 schrieb Mick: > Hi All, > > I updated E17 from the cvs two days ago and I noticed that gkrellm2 > which should be positioned at the bottom right corner of the screen, > keeps being pushed up by the height of the bottom shelf. The shelf > does not occupy the whole width of the bottom of the screen, so I'm > not sure what pushes gkrellm up with this version of E17 I've just > installed. > > I have added gkrellm at the startup apps for some time now, but as I > said this was fine until now. I have tried setting up > More/Remember/Name+Position, but it is still being pushed up. > > Any ideas? Yes, I've an idea. I did some commits in e_zone.c and e_border.c do fix some bugs in this area. I tested my use cases for around a week and it worked. Nice. Maybe I missed your use case. In "trunk/TEST/app/e/e_place_test" I implemented a little application to fit my tested use cases. I would like to understand your use case and how to correct handle it. Could you make a screenshot with some red arrows what is the situation and how it should behave in your eyes? Or a video if you like... regards Andreas |
From: Mick <mic...@gm...> - 2010-07-04 16:15:20
|
On Sunday 04 July 2010 12:37:31 Andreas Volz wrote: > Am Thu, 1 Jul 2010 16:35:10 +0100 schrieb Mick: > > Hi All, > > > > I updated E17 from the cvs two days ago and I noticed that gkrellm2 > > which should be positioned at the bottom right corner of the screen, > > keeps being pushed up by the height of the bottom shelf. The shelf > > does not occupy the whole width of the bottom of the screen, so I'm > > not sure what pushes gkrellm up with this version of E17 I've just > > installed. > > > > I have added gkrellm at the startup apps for some time now, but as I > > said this was fine until now. I have tried setting up > > More/Remember/Name+Position, but it is still being pushed up. > > > > Any ideas? > > Yes, I've an idea. I did some commits in e_zone.c and e_border.c do fix > some bugs in this area. I tested my use cases for around a week and it > worked. Nice. Maybe I missed your use case. > > In "trunk/TEST/app/e/e_place_test" I implemented a little application > to fit my tested use cases. I would like to understand your use case > and how to correct handle it. Could you make a screenshot with some red > arrows what is the situation and how it should behave in your eyes? Or > a video if you like... Hi Andreas, where would you like me to upload the screenshots? The behaviour of gkrellm is akin to dragging one of the desktop icons (e.g. the home or temp directory icon) to the bottom of the screen. When you release your mouse the icon is pushed upwards until it clears the height of the shelf on the bottom of the screen. With gkrellm this does not happen instantaneously, so it gives the impression that you can manually drag and drop gkrellm below the region of the shelf. However, when the gkrellm window dimensions is redrawn; e.g. when the wireless gkrellm drops the connection and collapses or when it is reinstated and expands, then the gkrellm is pushed upwards until it clears the height of the shelf. -- Regards, Mick |
From: Andreas V. <li...@br...> - 2010-07-04 18:45:17
|
Am Sun, 4 Jul 2010 17:15:11 +0100 schrieb Mick: > > Yes, I've an idea. I did some commits in e_zone.c and e_border.c do > > fix some bugs in this area. I tested my use cases for around a week > > and it worked. Nice. Maybe I missed your use case. > > > > In "trunk/TEST/app/e/e_place_test" I implemented a little > > application to fit my tested use cases. I would like to understand > > your use case and how to correct handle it. Could you make a > > screenshot with some red arrows what is the situation and how it > > should behave in your eyes? Or a video if you like... > > Hi Andreas, where would you like me to upload the screenshots? > > The behaviour of gkrellm is akin to dragging one of the desktop icons > (e.g. the home or temp directory icon) to the bottom of the screen. > When you release your mouse the icon is pushed upwards until it > clears the height of the shelf on the bottom of the screen. > > With gkrellm this does not happen instantaneously, so it gives the > impression that you can manually drag and drop gkrellm below the > region of the shelf. However, when the gkrellm window dimensions is > redrawn; e.g. when the wireless gkrellm drops the connection and > collapses or when it is reinstated and expands, then the gkrellm is > pushed upwards until it clears the height of the shelf. You could upload images here for free: http://imageshack.us/ Could you please try to set the "allow window overlap" option in the settings tab of the problematic shelf. The window placement algorithm ignores overlap shelfes. The replacement if windows with icccm request is needed as many apps have to brain dead logic that they always show the most important parts below shelfes or offscreen. Please tell me if this solves your problem. regards Andreas |
From: Mick <mic...@gm...> - 2010-07-04 22:49:33
|
On Sunday 04 July 2010 19:42:56 Andreas Volz wrote: > Am Sun, 4 Jul 2010 17:15:11 +0100 schrieb Mick: > > > Yes, I've an idea. I did some commits in e_zone.c and e_border.c do > > > fix some bugs in this area. I tested my use cases for around a week > > > and it worked. Nice. Maybe I missed your use case. > > > > > > In "trunk/TEST/app/e/e_place_test" I implemented a little > > > application to fit my tested use cases. I would like to understand > > > your use case and how to correct handle it. Could you make a > > > screenshot with some red arrows what is the situation and how it > > > should behave in your eyes? Or a video if you like... > > > > Hi Andreas, where would you like me to upload the screenshots? > > > > The behaviour of gkrellm is akin to dragging one of the desktop icons > > (e.g. the home or temp directory icon) to the bottom of the screen. > > When you release your mouse the icon is pushed upwards until it > > clears the height of the shelf on the bottom of the screen. > > > > With gkrellm this does not happen instantaneously, so it gives the > > impression that you can manually drag and drop gkrellm below the > > region of the shelf. However, when the gkrellm window dimensions is > > redrawn; e.g. when the wireless gkrellm drops the connection and > > collapses or when it is reinstated and expands, then the gkrellm is > > pushed upwards until it clears the height of the shelf. > > You could upload images here for free: > > http://imageshack.us/ This is how it shows at startup after it has been pushed up by the shelf region: http://yfrog.com/2mstartupsp and this is how it should be: http://yfrog.com/7fstartup2p > Could you please try to set the "allow window overlap" option in the > settings tab of the problematic shelf. The window placement algorithm > ignores overlap shelfes. > > The replacement if windows with icccm request is needed as many apps > have to brain dead logic that they always show the most important parts > below shelfes or offscreen. > > Please tell me if this solves your problem. This solves the problem of the gkrellm, in that it allows it to rest at the bottom of the right hand corner of the screen, but at the same time when I maximise a window it also stretches to the bottom of the screen, behind the bottom shelf. This is undesireable for me because a)the shelf covers the bottom end of the window which some applications are using for status info and b)the desktop on either side of the shelf is no longer available for launching the menu. The previous version I had installed did not need this setting to allow the gkrellm to be positioned at the bottom of the screen - which is really what I was after. -- Regards, Mick |
From: Andreas V. <li...@br...> - 2010-07-06 20:10:08
|
Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: Hello Mick, > This solves the problem of the gkrellm, in that it allows it to rest > at the bottom of the right hand corner of the screen, but at the same > time when I maximise a window it also stretches to the bottom of the > screen, behind the bottom shelf. This is undesireable for me because > a)the shelf covers the bottom end of the window which some > applications are using for status info and b)the desktop on either > side of the shelf is no longer available for launching the menu. What's about the option "below windows" in the shelf settings? Here is solves your use case. > The previous version I had installed did not need this setting to > allow the gkrellm to be positioned at the bottom of the screen - > which is really what I was after. I added two new configuration options in the window geometry settings. See the commit it should explain it. But it's easy to understand from the option text. Please test if this solves all your use cases or if still a problem exists. The SVN commit number for this change is 50083. This may help for the gkrellm problem. At least that gkrellm moves up on repaint. Maybe it doesn't solve the initial position problem. Could you please test it again with the new options and report the result here? regards Andreas |
From: Mick <mic...@gm...> - 2010-07-06 21:13:35
|
On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: > Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: > > Hello Mick, > > > This solves the problem of the gkrellm, in that it allows it to rest > > at the bottom of the right hand corner of the screen, but at the same > > time when I maximise a window it also stretches to the bottom of the > > screen, behind the bottom shelf. This is undesireable for me because > > a)the shelf covers the bottom end of the window which some > > applications are using for status info and b)the desktop on either > > side of the shelf is no longer available for launching the menu. > > What's about the option "below windows" in the shelf settings? Here is > solves your use case. Thank you Andreas, I am afraid it does not solve my case. The "below windows" setting allows maximised windows to overlap the shelf and hide it, while I want them not to do so. Please have a look at the screenshot below, the email window rests above the shelf, while gkrellm is at the bottom right hand side of the screen. This is how the previous version I had installed worked. This is also how the 'slit' in Fluxbox works and in its default settings neither dockapps in the slit, not the shelf/toolbar get overlapped by application windows. The screenshot shows what I mean. http://yfrog.com/5montopofshelfp > I added two new configuration options in the window geometry settings. > See the commit it should explain it. But it's easy to understand from > the option text. > > Please test if this solves all your use cases or if still a problem > exists. > > The SVN commit number for this change is 50083. > > This may help for the gkrellm problem. At least that gkrellm moves up > on repaint. Maybe it doesn't solve the initial position problem. Could > you please test it again with the new options and report the result > here? I would, but I don't know how to install what you have commited using my Gentoo OS and layman. It reports a different revision: * Running command "/usr/bin/svn up "/var/lib/layman/efl""... At revision 50085. (sorry but my knowledge of layman is limited). -- Regards, Mick |
From: Christopher M. <cpm...@co...> - 2010-07-06 21:24:40
|
On 07/06/2010 05:13 PM, Mick wrote: > On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: >> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: >> >> Hello Mick, >> >>> This solves the problem of the gkrellm, in that it allows it to rest >>> at the bottom of the right hand corner of the screen, but at the same >>> time when I maximise a window it also stretches to the bottom of the >>> screen, behind the bottom shelf. This is undesireable for me because >>> a)the shelf covers the bottom end of the window which some >>> applications are using for status info and b)the desktop on either >>> side of the shelf is no longer available for launching the menu. >> >> What's about the option "below windows" in the shelf settings? Here is >> solves your use case. > > Thank you Andreas, > > I am afraid it does not solve my case. The "below windows" setting allows > maximised windows to overlap the shelf and hide it, while I want them not to > do so. Please have a look at the screenshot below, the email window rests > above the shelf, while gkrellm is at the bottom right hand side of the screen. > This is how the previous version I had installed worked. This is also how the > 'slit' in Fluxbox works and in its default settings neither dockapps in the > slit, not the shelf/toolbar get overlapped by application windows. The > screenshot shows what I mean. > > http://yfrog.com/5montopofshelfp > > >> I added two new configuration options in the window geometry settings. >> See the commit it should explain it. But it's easy to understand from >> the option text. >> >> Please test if this solves all your use cases or if still a problem >> exists. >> >> The SVN commit number for this change is 50083. >> >> This may help for the gkrellm problem. At least that gkrellm moves up >> on repaint. Maybe it doesn't solve the initial position problem. Could >> you please test it again with the new options and report the result >> here? > > I would, but I don't know how to install what you have commited using my > Gentoo OS and layman. It reports a different revision: > > * Running command "/usr/bin/svn up "/var/lib/layman/efl""... > At revision 50085. > > (sorry but my knowledge of layman is limited). > I think the biggest issue here is that the new(est) code for layout does not account for shelves which do not take up the whole region. What I mean by this is simply this (example): Shelves which are placed on the bottom (or any position for that matter), are assumed to take up the whole width/height of the zone (in the new code). The old(er) code accounted for the possibility that shelves are not taking up all that space (ie: the shelf is set to 'shrink w/ content'). So what we see happening here is the new layout code assumes the shelf takes up the whole width of the zone/screen, so it places gkrellm not at the bottom right (where it should be), but rather placing it as if the shelf takes up the whole zone width. It's my 'theory' that the new placement code needs to account for shelves which do not take up all the available space.... just a theory mind you :) as I don't know all that code real well. This would not require any new config variables or anything ... just some changes in the layout code to account for shelves which are not taking up all the space. I apologize if this does not make any sense ... difficult to articulate what I mean :) dh |
From: Christopher M. <cpm...@co...> - 2010-07-06 21:38:24
|
On 07/06/2010 05:35 PM, Mick wrote: > On Tuesday 06 July 2010 22:24:30 you wrote: >> On 07/06/2010 05:13 PM, Mick wrote: >>> On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: >>>> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: >>>> >>>> Hello Mick, >>>> >>>>> This solves the problem of the gkrellm, in that it allows it to rest >>>>> at the bottom of the right hand corner of the screen, but at the same >>>>> time when I maximise a window it also stretches to the bottom of the >>>>> screen, behind the bottom shelf. This is undesireable for me because >>>>> a)the shelf covers the bottom end of the window which some >>>>> applications are using for status info and b)the desktop on either >>>>> side of the shelf is no longer available for launching the menu. >>>> >>>> What's about the option "below windows" in the shelf settings? Here is >>>> solves your use case. >>> >>> Thank you Andreas, >>> >>> I am afraid it does not solve my case. The "below windows" setting >>> allows maximised windows to overlap the shelf and hide it, while I want >>> them not to do so. Please have a look at the screenshot below, the >>> email window rests above the shelf, while gkrellm is at the bottom right >>> hand side of the screen. This is how the previous version I had >>> installed worked. This is also how the 'slit' in Fluxbox works and in >>> its default settings neither dockapps in the slit, not the shelf/toolbar >>> get overlapped by application windows. The screenshot shows what I >>> mean. >>> >>> http://yfrog.com/5montopofshelfp >>> >>>> I added two new configuration options in the window geometry settings. >>>> See the commit it should explain it. But it's easy to understand from >>>> the option text. >>>> >>>> Please test if this solves all your use cases or if still a problem >>>> exists. >>>> >>>> The SVN commit number for this change is 50083. >>>> >>>> This may help for the gkrellm problem. At least that gkrellm moves up >>>> on repaint. Maybe it doesn't solve the initial position problem. Could >>>> you please test it again with the new options and report the result >>>> here? >>> >>> I would, but I don't know how to install what you have commited using my >>> Gentoo OS and layman. It reports a different revision: >>> >>> * Running command "/usr/bin/svn up "/var/lib/layman/efl""... >>> At revision 50085. >>> >>> (sorry but my knowledge of layman is limited). >> >> I think the biggest issue here is that the new(est) code for layout does >> not account for shelves which do not take up the whole region. What I >> mean by this is simply this (example): >> >> Shelves which are placed on the bottom (or any position for that >> matter), are assumed to take up the whole width/height of the zone (in >> the new code). The old(er) code accounted for the possibility that >> shelves are not taking up all that space (ie: the shelf is set to >> 'shrink w/ content'). >> >> So what we see happening here is the new layout code assumes the shelf >> takes up the whole width of the zone/screen, so it places gkrellm not at >> the bottom right (where it should be), but rather placing it as if the >> shelf takes up the whole zone width. >> >> >> It's my 'theory' that the new placement code needs to account for >> shelves which do not take up all the available space.... just a theory >> mind you :) as I don't know all that code real well. This would not >> require any new config variables or anything ... just some changes in >> the layout code to account for shelves which are not taking up all the >> space. >> >> I apologize if this does not make any sense ... difficult to articulate >> what I mean :) > > Yes, exactly what you say makes perfect sense to me and perfectly describes my > observation! I have a wide screen laptop and the shelf both horizontally or > vertically does not cover the whole desktop width/height. On a smaller > screen/resolution it would probably cover the whole width so this issue would > not be noticed. Exactly ! (I experience the same problem here) I think it's just a small over-sight wrt shelf size. Should not be too big of a deal to change, but again, I don't know that code all that well. dh |
From: Andreas V. <li...@br...> - 2010-07-08 21:55:16
|
Am Tue, 06 Jul 2010 17:38:14 -0400 schrieb Christopher Michael: > On 07/06/2010 05:35 PM, Mick wrote: > > On Tuesday 06 July 2010 22:24:30 you wrote: > >> On 07/06/2010 05:13 PM, Mick wrote: > >>> On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: > >>>> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: > >>>> > >>>> Hello Mick, > >>>> > >>>>> This solves the problem of the gkrellm, in that it allows it to > >>>>> rest at the bottom of the right hand corner of the screen, but > >>>>> at the same time when I maximise a window it also stretches to > >>>>> the bottom of the screen, behind the bottom shelf. This is > >>>>> undesireable for me because a)the shelf covers the bottom end > >>>>> of the window which some applications are using for status info > >>>>> and b)the desktop on either side of the shelf is no longer > >>>>> available for launching the menu. > >>>> > >>>> What's about the option "below windows" in the shelf settings? > >>>> Here is solves your use case. > >>> > >>> Thank you Andreas, > >>> > >>> I am afraid it does not solve my case. The "below windows" > >>> setting allows maximised windows to overlap the shelf and hide > >>> it, while I want them not to do so. Please have a look at the > >>> screenshot below, the email window rests above the shelf, while > >>> gkrellm is at the bottom right hand side of the screen. This is > >>> how the previous version I had installed worked. This is also > >>> how the 'slit' in Fluxbox works and in its default settings > >>> neither dockapps in the slit, not the shelf/toolbar get > >>> overlapped by application windows. The screenshot shows what I > >>> mean. > >>> > >>> http://yfrog.com/5montopofshelfp > >>> > >>>> I added two new configuration options in the window geometry > >>>> settings. See the commit it should explain it. But it's easy to > >>>> understand from the option text. > >>>> > >>>> Please test if this solves all your use cases or if still a > >>>> problem exists. > >>>> > >>>> The SVN commit number for this change is 50083. > >>>> > >>>> This may help for the gkrellm problem. At least that gkrellm > >>>> moves up on repaint. Maybe it doesn't solve the initial position > >>>> problem. Could you please test it again with the new options and > >>>> report the result here? > >>> > >>> I would, but I don't know how to install what you have commited > >>> using my Gentoo OS and layman. It reports a different revision: > >>> > >>> * Running command "/usr/bin/svn up "/var/lib/layman/efl""... > >>> At revision 50085. > >>> > >>> (sorry but my knowledge of layman is limited). > >> > >> I think the biggest issue here is that the new(est) code for > >> layout does not account for shelves which do not take up the whole > >> region. What I mean by this is simply this (example): > >> > >> Shelves which are placed on the bottom (or any position for that > >> matter), are assumed to take up the whole width/height of the zone > >> (in the new code). The old(er) code accounted for the possibility > >> that shelves are not taking up all that space (ie: the shelf is > >> set to 'shrink w/ content'). > >> > >> So what we see happening here is the new layout code assumes the > >> shelf takes up the whole width of the zone/screen, so it places > >> gkrellm not at the bottom right (where it should be), but rather > >> placing it as if the shelf takes up the whole zone width. > >> > >> > >> It's my 'theory' that the new placement code needs to account for > >> shelves which do not take up all the available space.... just a > >> theory mind you :) as I don't know all that code real well. This > >> would not require any new config variables or anything ... just > >> some changes in the layout code to account for shelves which are > >> not taking up all the space. > >> > >> I apologize if this does not make any sense ... difficult to > >> articulate what I mean :) > > > > Yes, exactly what you say makes perfect sense to me and perfectly > > describes my observation! I have a wide screen laptop and the > > shelf both horizontally or vertically does not cover the whole > > desktop width/height. On a smaller screen/resolution it would > > probably cover the whole width so this issue would not be noticed. > > Exactly ! (I experience the same problem here) > > I think it's just a small over-sight wrt shelf size. Should not be > too big of a deal to change, but again, I don't know that code all > that well. It's hard to fill your wishes. I'll explain you why: The _e_zone_useful_geometry_calc() in e_zone.c calculates the useful space on the screen for windows. This includes moving after configure events or maximizing windows. So you like two things that work against. One one side you like to let the window move algorithm not respect the partly shelf as useful geometry. On the other side the maximizing algorithm should detect partly shelfes as not useful geometry. And this all with only one overlap option. So I think one solution would be to add another "overlay for maximize" option for shelf config or I hardcode that _e_zone_useful_geometry_calc() reacts in different ways depending on the desired action (move, maximize, ...) I've not yet decided. I'll try out and propose an implementation. Please tell me your opinion. regards Andreas |
From: Mick <mic...@gm...> - 2010-07-09 05:32:14
|
On Thursday 08 July 2010 22:52:23 Andreas Volz wrote: > Am Tue, 06 Jul 2010 17:38:14 -0400 schrieb Christopher Michael: > > On 07/06/2010 05:35 PM, Mick wrote: > > > On Tuesday 06 July 2010 22:24:30 you wrote: > > >> On 07/06/2010 05:13 PM, Mick wrote: > > >>> On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: > > >>>> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: > > >>>> > > >>>> Hello Mick, > > >>>> > > >>>>> This solves the problem of the gkrellm, in that it allows it to > > >>>>> rest at the bottom of the right hand corner of the screen, but > > >>>>> at the same time when I maximise a window it also stretches to > > >>>>> the bottom of the screen, behind the bottom shelf. This is > > >>>>> undesireable for me because a)the shelf covers the bottom end > > >>>>> of the window which some applications are using for status info > > >>>>> and b)the desktop on either side of the shelf is no longer > > >>>>> available for launching the menu. > > >>>> > > >>>> What's about the option "below windows" in the shelf settings? > > >>>> Here is solves your use case. > > >>> > > >>> Thank you Andreas, > > >>> > > >>> I am afraid it does not solve my case. The "below windows" > > >>> setting allows maximised windows to overlap the shelf and hide > > >>> it, while I want them not to do so. Please have a look at the > > >>> screenshot below, the email window rests above the shelf, while > > >>> gkrellm is at the bottom right hand side of the screen. This is > > >>> how the previous version I had installed worked. This is also > > >>> how the 'slit' in Fluxbox works and in its default settings > > >>> neither dockapps in the slit, not the shelf/toolbar get > > >>> overlapped by application windows. The screenshot shows what I > > >>> mean. > > >>> > > >>> http://yfrog.com/5montopofshelfp > > >>> > > >>>> I added two new configuration options in the window geometry > > >>>> settings. See the commit it should explain it. But it's easy to > > >>>> understand from the option text. > > >>>> > > >>>> Please test if this solves all your use cases or if still a > > >>>> problem exists. > > >>>> > > >>>> The SVN commit number for this change is 50083. > > >>>> > > >>>> This may help for the gkrellm problem. At least that gkrellm > > >>>> moves up on repaint. Maybe it doesn't solve the initial position > > >>>> problem. Could you please test it again with the new options and > > >>>> report the result here? > > >>> > > >>> I would, but I don't know how to install what you have commited > > >>> using my Gentoo OS and layman. It reports a different revision: > > >>> > > >>> * Running command "/usr/bin/svn up "/var/lib/layman/efl""... > > >>> At revision 50085. > > >>> > > >>> (sorry but my knowledge of layman is limited). > > >> > > >> I think the biggest issue here is that the new(est) code for > > >> layout does not account for shelves which do not take up the whole > > >> region. What I mean by this is simply this (example): > > >> > > >> Shelves which are placed on the bottom (or any position for that > > >> matter), are assumed to take up the whole width/height of the zone > > >> (in the new code). The old(er) code accounted for the possibility > > >> that shelves are not taking up all that space (ie: the shelf is > > >> set to 'shrink w/ content'). > > >> > > >> So what we see happening here is the new layout code assumes the > > >> shelf takes up the whole width of the zone/screen, so it places > > >> gkrellm not at the bottom right (where it should be), but rather > > >> placing it as if the shelf takes up the whole zone width. > > >> > > >> > > >> It's my 'theory' that the new placement code needs to account for > > >> shelves which do not take up all the available space.... just a > > >> theory mind you :) as I don't know all that code real well. This > > >> would not require any new config variables or anything ... just > > >> some changes in the layout code to account for shelves which are > > >> not taking up all the space. > > >> > > >> I apologize if this does not make any sense ... difficult to > > >> articulate what I mean :) > > > > > > Yes, exactly what you say makes perfect sense to me and perfectly > > > describes my observation! I have a wide screen laptop and the > > > shelf both horizontally or vertically does not cover the whole > > > desktop width/height. On a smaller screen/resolution it would > > > probably cover the whole width so this issue would not be noticed. > > > > Exactly ! (I experience the same problem here) > > > > I think it's just a small over-sight wrt shelf size. Should not be > > too big of a deal to change, but again, I don't know that code all > > that well. > > It's hard to fill your wishes. I'll explain you why: > > The _e_zone_useful_geometry_calc() in e_zone.c calculates the useful > space on the screen for windows. This includes moving after > configure events or maximizing windows. So you like two things that > work against. One one side you like to let the window move algorithm > not respect the partly shelf as useful geometry. On the other side the > maximizing algorithm should detect partly shelfes as not useful > geometry. And this all with only one overlap option. > > So I think one solution would be to add another "overlay for maximize" > option for shelf config or I hardcode that > _e_zone_useful_geometry_calc() reacts in different ways depending on > the desired action (move, maximize, ...) > > I've not yet decided. I'll try out and propose an implementation. > Please tell me your opinion. Andreas, as my understanding of the code is non-existent I am the least qualified person to make a recommendation here. However, what was the code two months ago when this functionality seemed to be available? Why was it working then? Can we go back to it? -- Regards, Mick |
From: Andreas V. <li...@br...> - 2010-07-11 07:55:10
|
Am Fri, 9 Jul 2010 06:31:34 +0100 schrieb Mick: > On Thursday 08 July 2010 22:52:23 Andreas Volz wrote: > > Am Tue, 06 Jul 2010 17:38:14 -0400 schrieb Christopher Michael: > > > On 07/06/2010 05:35 PM, Mick wrote: > > > > On Tuesday 06 July 2010 22:24:30 you wrote: > > > >> On 07/06/2010 05:13 PM, Mick wrote: > > > >>> On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: > > > >>>> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: > > > >>>> > > > >>>> Hello Mick, > > > >>>> > > > >>>>> This solves the problem of the gkrellm, in that it allows > > > >>>>> it to rest at the bottom of the right hand corner of the > > > >>>>> screen, but at the same time when I maximise a window it > > > >>>>> also stretches to the bottom of the screen, behind the > > > >>>>> bottom shelf. This is undesireable for me because a)the > > > >>>>> shelf covers the bottom end of the window which some > > > >>>>> applications are using for status info and b)the desktop on > > > >>>>> either side of the shelf is no longer available for > > > >>>>> launching the menu. > > > >>>> > > > >>>> What's about the option "below windows" in the shelf > > > >>>> settings? Here is solves your use case. > > > >>> > > > >>> Thank you Andreas, > > > >>> > > > >>> I am afraid it does not solve my case. The "below windows" > > > >>> setting allows maximised windows to overlap the shelf and hide > > > >>> it, while I want them not to do so. Please have a look at the > > > >>> screenshot below, the email window rests above the shelf, > > > >>> while gkrellm is at the bottom right hand side of the screen. > > > >>> This is how the previous version I had installed worked. > > > >>> This is also how the 'slit' in Fluxbox works and in its > > > >>> default settings neither dockapps in the slit, not the > > > >>> shelf/toolbar get overlapped by application windows. The > > > >>> screenshot shows what I mean. > > > >>> > > > >>> http://yfrog.com/5montopofshelfp > > > >>> > > > >>>> I added two new configuration options in the window geometry > > > >>>> settings. See the commit it should explain it. But it's easy > > > >>>> to understand from the option text. > > > >>>> > > > >>>> Please test if this solves all your use cases or if still a > > > >>>> problem exists. > > > >>>> > > > >>>> The SVN commit number for this change is 50083. > > > >>>> > > > >>>> This may help for the gkrellm problem. At least that gkrellm > > > >>>> moves up on repaint. Maybe it doesn't solve the initial > > > >>>> position problem. Could you please test it again with the > > > >>>> new options and report the result here? > > > >>> > > > >>> I would, but I don't know how to install what you have > > > >>> commited using my Gentoo OS and layman. It reports a > > > >>> different revision: > > > >>> > > > >>> * Running command "/usr/bin/svn up "/var/lib/layman/efl""... > > > >>> At revision 50085. > > > >>> > > > >>> (sorry but my knowledge of layman is limited). > > > >> > > > >> I think the biggest issue here is that the new(est) code for > > > >> layout does not account for shelves which do not take up the > > > >> whole region. What I mean by this is simply this (example): > > > >> > > > >> Shelves which are placed on the bottom (or any position for > > > >> that matter), are assumed to take up the whole width/height of > > > >> the zone (in the new code). The old(er) code accounted for the > > > >> possibility that shelves are not taking up all that space (ie: > > > >> the shelf is set to 'shrink w/ content'). > > > >> > > > >> So what we see happening here is the new layout code assumes > > > >> the shelf takes up the whole width of the zone/screen, so it > > > >> places gkrellm not at the bottom right (where it should be), > > > >> but rather placing it as if the shelf takes up the whole zone > > > >> width. > > > >> > > > >> > > > >> It's my 'theory' that the new placement code needs to account > > > >> for shelves which do not take up all the available space.... > > > >> just a theory mind you :) as I don't know all that code real > > > >> well. This would not require any new config variables or > > > >> anything ... just some changes in the layout code to account > > > >> for shelves which are not taking up all the space. > > > >> > > > >> I apologize if this does not make any sense ... difficult to > > > >> articulate what I mean :) > > > > > > > > Yes, exactly what you say makes perfect sense to me and > > > > perfectly describes my observation! I have a wide screen > > > > laptop and the shelf both horizontally or vertically does not > > > > cover the whole desktop width/height. On a smaller > > > > screen/resolution it would probably cover the whole width so > > > > this issue would not be noticed. > > > > > > Exactly ! (I experience the same problem here) > > > > > > I think it's just a small over-sight wrt shelf size. Should not be > > > too big of a deal to change, but again, I don't know that code all > > > that well. > > > > It's hard to fill your wishes. I'll explain you why: > > > > The _e_zone_useful_geometry_calc() in e_zone.c calculates the useful > > space on the screen for windows. This includes moving after > > configure events or maximizing windows. So you like two things that > > work against. One one side you like to let the window move algorithm > > not respect the partly shelf as useful geometry. On the other side > > the maximizing algorithm should detect partly shelfes as not useful > > geometry. And this all with only one overlap option. > > > > So I think one solution would be to add another "overlay for > > maximize" option for shelf config or I hardcode that > > _e_zone_useful_geometry_calc() reacts in different ways depending on > > the desired action (move, maximize, ...) > > > > I've not yet decided. I'll try out and propose an implementation. > > Please tell me your opinion. > > Andreas, as my understanding of the code is non-existent I am the > least qualified person to make a recommendation here. However, what > was the code two months ago when this functionality seemed to be > available? Why was it working then? Can we go back to it? Hello Mick, no we can't go back. It was only working because shelfes where ignored at large parts of the algorithm. If I now go back all my use cases will fail. The current behaviour is consistent, even if it doesn't fit your use case. I think a configuration option to decide between different options would be the best here. Even that I hate more options in E17... I'll try some things in the next days and post here when you should try it again. regards Andreas |
From: Andreas V. <li...@br...> - 2010-07-12 22:00:08
|
Am Sun, 11 Jul 2010 09:54:23 +0200 schrieb Andreas Volz: > Am Fri, 9 Jul 2010 06:31:34 +0100 schrieb Mick: > > > On Thursday 08 July 2010 22:52:23 Andreas Volz wrote: > > > Am Tue, 06 Jul 2010 17:38:14 -0400 schrieb Christopher Michael: > > > > On 07/06/2010 05:35 PM, Mick wrote: > > > > > On Tuesday 06 July 2010 22:24:30 you wrote: > > > > >> On 07/06/2010 05:13 PM, Mick wrote: > > > > >>> On Tuesday 06 July 2010 21:07:10 Andreas Volz wrote: > > > > >>>> Am Sun, 4 Jul 2010 23:49:16 +0100 schrieb Mick: > > > > >>>> > > > > >>>> Hello Mick, > > > > >>>> > > > > >>>>> This solves the problem of the gkrellm, in that it allows > > > > >>>>> it to rest at the bottom of the right hand corner of the > > > > >>>>> screen, but at the same time when I maximise a window it > > > > >>>>> also stretches to the bottom of the screen, behind the > > > > >>>>> bottom shelf. This is undesireable for me because a)the > > > > >>>>> shelf covers the bottom end of the window which some > > > > >>>>> applications are using for status info and b)the desktop > > > > >>>>> on either side of the shelf is no longer available for > > > > >>>>> launching the menu. > > > > >>>> > > > > >>>> What's about the option "below windows" in the shelf > > > > >>>> settings? Here is solves your use case. > > > > >>> > > > > >>> Thank you Andreas, > > > > >>> > > > > >>> I am afraid it does not solve my case. The "below windows" > > > > >>> setting allows maximised windows to overlap the shelf and > > > > >>> hide it, while I want them not to do so. Please have a > > > > >>> look at the screenshot below, the email window rests above > > > > >>> the shelf, while gkrellm is at the bottom right hand side > > > > >>> of the screen. This is how the previous version I had > > > > >>> installed worked. This is also how the 'slit' in Fluxbox > > > > >>> works and in its default settings neither dockapps in the > > > > >>> slit, not the shelf/toolbar get overlapped by application > > > > >>> windows. The screenshot shows what I mean. > > > > >>> > > > > >>> http://yfrog.com/5montopofshelfp > > > > >>> > > > > >>>> I added two new configuration options in the window > > > > >>>> geometry settings. See the commit it should explain it. > > > > >>>> But it's easy to understand from the option text. > > > > >>>> > > > > >>>> Please test if this solves all your use cases or if still a > > > > >>>> problem exists. > > > > >>>> > > > > >>>> The SVN commit number for this change is 50083. > > > > >>>> > > > > >>>> This may help for the gkrellm problem. At least that > > > > >>>> gkrellm moves up on repaint. Maybe it doesn't solve the > > > > >>>> initial position problem. Could you please test it again > > > > >>>> with the new options and report the result here? > > > > >>> > > > > >>> I would, but I don't know how to install what you have > > > > >>> commited using my Gentoo OS and layman. It reports a > > > > >>> different revision: > > > > >>> > > > > >>> * Running command "/usr/bin/svn up "/var/lib/layman/efl""... > > > > >>> At revision 50085. > > > > >>> > > > > >>> (sorry but my knowledge of layman is limited). > > > > >> > > > > >> I think the biggest issue here is that the new(est) code for > > > > >> layout does not account for shelves which do not take up the > > > > >> whole region. What I mean by this is simply this (example): > > > > >> > > > > >> Shelves which are placed on the bottom (or any position for > > > > >> that matter), are assumed to take up the whole width/height > > > > >> of the zone (in the new code). The old(er) code accounted > > > > >> for the possibility that shelves are not taking up all that > > > > >> space (ie: the shelf is set to 'shrink w/ content'). > > > > >> > > > > >> So what we see happening here is the new layout code assumes > > > > >> the shelf takes up the whole width of the zone/screen, so it > > > > >> places gkrellm not at the bottom right (where it should be), > > > > >> but rather placing it as if the shelf takes up the whole zone > > > > >> width. > > > > >> > > > > >> > > > > >> It's my 'theory' that the new placement code needs to account > > > > >> for shelves which do not take up all the available space.... > > > > >> just a theory mind you :) as I don't know all that code real > > > > >> well. This would not require any new config variables or > > > > >> anything ... just some changes in the layout code to account > > > > >> for shelves which are not taking up all the space. > > > > >> > > > > >> I apologize if this does not make any sense ... difficult to > > > > >> articulate what I mean :) > > > > > > > > > > Yes, exactly what you say makes perfect sense to me and > > > > > perfectly describes my observation! I have a wide screen > > > > > laptop and the shelf both horizontally or vertically does not > > > > > cover the whole desktop width/height. On a smaller > > > > > screen/resolution it would probably cover the whole width so > > > > > this issue would not be noticed. > > > > > > > > Exactly ! (I experience the same problem here) > > > > > > > > I think it's just a small over-sight wrt shelf size. Should not > > > > be too big of a deal to change, but again, I don't know that > > > > code all that well. > > > > > > It's hard to fill your wishes. I'll explain you why: > > > > > > The _e_zone_useful_geometry_calc() in e_zone.c calculates the > > > useful space on the screen for windows. This includes moving after > > > configure events or maximizing windows. So you like two things > > > that work against. One one side you like to let the window move > > > algorithm not respect the partly shelf as useful geometry. On the > > > other side the maximizing algorithm should detect partly shelfes > > > as not useful geometry. And this all with only one overlap option. > > > > > > So I think one solution would be to add another "overlay for > > > maximize" option for shelf config or I hardcode that > > > _e_zone_useful_geometry_calc() reacts in different ways depending > > > on the desired action (move, maximize, ...) > > > > > > I've not yet decided. I'll try out and propose an implementation. > > > Please tell me your opinion. > > > > Andreas, as my understanding of the code is non-existent I am the > > least qualified person to make a recommendation here. However, what > > was the code two months ago when this functionality seemed to be > > available? Why was it working then? Can we go back to it? > > Hello Mick, > > no we can't go back. It was only working because shelfes where ignored > at large parts of the algorithm. If I now go back all my use cases > will fail. The current behaviour is consistent, even if it doesn't > fit your use case. I think a configuration option to decide between > different options would be the best here. Even that I hate more > options in E17... > > I'll try some things in the next days and post here when you should > try it again. Hello Mick, I tried some yet existing configuration options and found a solution for your use case. Try a combination of position remember and the new window geometry settings. If you remember the gkrellm window in E17 to place at a specific position the new algorithm won't move it away. Maybe you've also some success with the window lock settings. Please play around with this options and tell me if this solves your special use case. regards Andreas |