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

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



On Sat, 30 Dec 2006 11:16:24 +0100 Andreas Volz <lists@brachttal.net> babbled:

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

as i said - there are remember and lock options for such apps. the apps save
their own size/location or whatever to a config file themselves then load it
back up (and ask for that geometry - in fact they set the "user specified" hint
- meaning "the user specified that i am to be here at this size" and e honors
that hint - as it should, as the "user specified it". the only way around that
is the lock and remember features that you can use in combination to lock the
app out from moving/resizing its own window, and then use e's remember stuff to
have e itself have a preference for where to put a window and at what size. e
will even adjust these remembered geometries for resolution changes - unlike
almost all apps, so the windows remain on screen and in the place you probably
intended them to be anyway (eg bottom-right corner of the screen even if
resolution changed between when e last recorded the geometry and now).

> regards
> Andreas
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)