GNU bug report logs - #21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Anders Lindgren <andlind <at> gmail.com>
Cc: Keith David Bershatsky <esq <at> lawlist.com>, 21415 <at> debbugs.gnu.org
Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Date: Tue, 22 Sep 2015 11:36:30 +0200

> I can take a look at it. However, the experience I had with the previous
> bug was that it's immensely hard to follow what happens when it comes to
> frame resizing and placement. So what I will do is to first reimplement the
> NSTRACE package and then start looking for the problem.

OK.  As far as frame resizing is concerned I wrote some rudimentary
Elisp support.  Set the variable ‘frame-size-history’ to a value like
'(100) and you will get a (partly cryptic) list of requests to resize a
frame and whether and how the request got honored.

> By the way, is
> there some kind of deadline coming up?

Not for bugs like this.  It's only short before a release that we only
fix regressions introduced since the last release.

> Also, things are starting to get so complicated so that we would need to
> state what each concept mean so that they can be implemented the same way
> on all systems. (When I wrote my "multicolumn" package I found tons and
> tons of things that differed between systems, I just want to make sure we
> don't introduce more such things.)

One thing that should work uniformly accross platforms is the
‘frame-geometry’ function as well as the recently introduced
‘frame-edges’.  Since I was never able to verify these for OS X it would
be a good start to make sure they deliver correct results there first.
Done that, we should have a common platform to discuss the remaining
issues.

> In addition, we really must write test
> cases automatically walking through all transitions, ensuring that nothing
> breaks in the future,

One problem with automatic test cases is that numbers may lie about the
effect you see on screen.  For example, Emacs can resize your scroll bar
width with completely correct metrics but since Gtk+ usually refuses to
change scroll bar widths, the visual appearance is devastating.  But
obviously, automatic test cases would be very useful.

> but also as this is a good way to describe the
> intended behavior.

Such description should be found in the frame geometry section of the
Elisp manual.

> I don't know what you mean by "fullboth", so I can't comment on what would
> happen when you collate "fullscreen" and "fullboth".

"fullboth" is our misnomer for "maximized", that is, the frame should
occupy the full work area of the display and its "maximize" button
should indicate that the frame can be restored to its normal size (the
latter implies that a maximized frame usually keeps its title bar).

A "fullscreen" frame, OTOH, occupies the entire display area (including
a task bar) and has no title bar.

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.