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
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
