emacs-devel
[Top][All Lists]
Advanced

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

Re: Infrastructural complexity.


From: Stefan Monnier
Subject: Re: Infrastructural complexity.
Date: Tue, 21 Jul 2009 12:13:56 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)

> The difficulty results exclusively from your assertion that the WM is
> not able to honor Emacs' requests of window placement.

There's really no way for Emacs to request a particular placement: maybe
when the frame is created, Emacs can sometimes specify the size and
position of that frame, but:
- it's only a hint, which the window-manager is allowed to disregard,
  and in practice window managers often disregard it, and for good
  reasons (e.g. the window would overlap with some other important
  window, or the position is incompatible with some other layout
  request from the user, or ...).
- it doesn't say what to do when one of the two frames gets
  resized/iconified/moved/... (because there's no protocol to convey the
  intention behind the choice of those specific size and position
  parameters).

> I can't judge
> that assertion because I practically always use only one frame that
> occupies the entire screen.  So maybe you're right - but a WM that
> doesn't honor its client's placement requests is a bad WM IMHO.

A good WM makes it possible for the user to explain to the WM what kind
of layouts he wants.  E.g. whether he wants windows to be tiled or not,
which windows are allowed to overlap which other windows, which windows
get placed manually, which ones should fit within the screen
boundaries...  The more such rules there are, the more likely it is that
they will collide with the application's placement request, in which
case the WM is justified to favor the user's config over the
application's request.
On top of that, 99% of the applications don't request any particular
placement, so the WM code handling it has *very* low priority.
And to really kill it off completely, most applications that make such
requests do it for the wrong reason (they're written with one
particular use-case in mind and completely disregard other situations,
so it's common for the WM to take such data with a big grain of salt).

I agree with Miles here: it's a non-starter.  If you want other reasons
for it, think about the difficulties we face already with timing issues
in requests for resizing/moving frames and/or controlling focus of newly
created frames.  We have lots and lots of bugs there, most of which are
a nightmare to fix because we're at the mercy of the WM.

> In three steps: (1) save a frame's window configuration, (2) tear off a
> window from that frame and re-purpose it into another frame, (3) restore
> the window configuration saved in step (1).  Gets you two windows with
> the same identity.  No fun here, no fun at all ...

I think such window-configurations shouldn't save window identities.
Especially if one wants to be able to restore one window-configuration in
a different frame (and/or save that config into a file).

In other words, I think that the issue of window-identity w.r.t
window-configurations is one where there's no way to win.  I think the
least breakage will happen when we give up on preserving
those identities.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]