From: Andreas V. <li...@br...> - 2006-12-30 10:20:11
|
Am Sat, 30 Dec 2006 11:08:14 +0900 schrieb Carsten Haitzler (The Rasterman): > On Fri, 29 Dec 2006 19:16:39 +0100 Andreas Volz <li...@br...> > 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... regards Andreas |