[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Window out of Screen?

Am Sat, 30 Dec 2006 11:08:14 +0900 schrieb Carsten Haitzler (The

> On Fri, 29 Dec 2006 19:16:39 +0100 Andreas Volz <lists@brachttal.net>
> babbled:
> > Am Fri, 29 Dec 2006 10:50:47 +0900 schrieb Carsten Haitzler (The
> > Rasterman):
> > 
> > > > 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 virtual desktops.
> > 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 into
> that)

I'll live some more time with the current situation. It's not sooo bad.
The only problems are ssh opened apps from my laptop with a bigger
screen resolution. I need to figure out why these apps behave like they
behave. Perhaps I could try to change these apps. But thanks for your
explanations so long...