[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Window out of Screen?
On Fri, 29 Dec 2006 19:16:39 +0100 Andreas Volz <firstname.lastname@example.org> babbled:
> Am Fri, 29 Dec 2006 10:50:47 +0900 schrieb Carsten Haitzler (The
> > > This happens because I use synaptic on my notebook with a bigger
> > > resolution. If I open it with ssh on my pc I couldn't resize the
> > > windows height. Ok, this could happen, but I expect that the
> > > "maximize window" button should maximize the window _not_ under the
> > > shelf. I found out that maximize behaves wrong if the window is
> > > slightly below a shelf. You could easily reproduce it:
> > well 1. that's because the app asks to be that size as it "remembers"
> > its own size and asks for it again next time it runs.
> Ok, but E17 is the window manager. A window couldn't force its size as
> I understand it. So why shoudln't E17 limit the max size to screen size
> even if the app requests a bigger size.
because there are perfectly legitimate reasons to ask for windows bigger than
the screen depending on usage patterns of the app. E can't make such quality
choices for you. There are options for windows to have e override the
application requests for size, location etc. (remember and lock options) for
these kind of things, but e isn't going to go do this by default as it will
likely cause more problems than it would solve.
> Same with window position. If a app requests a position outside a
> window E17 should simply move it so that it's complete inside the
> viewable screen.
again - there are legitimate reasons. example:app creates window off screen
then slides it onto the screen much like e does with effects when changing
> I think such a policy would solve most of the problems. You should see
> it with the users eyes. Which E17 user hadn't yet seen this too big
> opened windows and missplaced dialog windows?
as i said above - there are ways to "fix" this - but they are not a default. in
fact no wm i have ever used does this by default. if the app is stupid - then
the app will behave in a stupid manner. most application authors are very much
unaware of the stupidity they code into their apps. apps that try and remember
their own geometry, desktops, state etc. invariably get it wrong unless the
authors are very good and can think ahead. e17 has features to say "no - stupid
app. don't do that!" and fix it itself.
> > > Do you think this behaviour is good? I don't think so.
> > it just happens to be how it works as unlike maximize routines in
> > other wm's/desktops it is extremely generic and handles all sorts of
> > obstacles of all shapes and sizes everywhere. it just happens to be
> > how it's written and you see a bi-product of it.
> I had never problems like this with e.g. Metacity. (Ok, I've other
> problems with Metacity, but that's another story...) It's too easy to
> say: "stupid application!" We couldn't rewrite all apllications or
> use alternatives :-)
because the INTENTIONS of the application can't always be divined in code in a
wm - this, eventually leads to other nasty bugs when e gets it wrong. 'es
maximize code happens to work that way because it is very generic to handle
cases that simpler code doesn't. the bi-product is what you see. right now i
don't have time to look into it - i am massively backlogged on even my email
and i have a tonne of things to do. you will need to live with it as-is, or
send patches (and such patches would then limit functionality - i won't go
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)