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 ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
