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
------------------------------------------------------------------------------
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
