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