From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 16028@debbugs.gnu.org
Subject: bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code
Date: Fri, 13 Dec 2013 11:12:39 +0100 [thread overview]
Message-ID: <52AADD97.5060801@gmx.at> (raw)
In-Reply-To: <831u1h7voj.fsf@gnu.org>
> But if we somehow could provide Drew with the frame dimensions that
> _should_ have resulted from the two changes his code does, then he
> could add a call to set-frame-size to request precisely those
> dimensions, and that should fix his problem, no?
I'm not sure. In principle Drew should be able to thumbify as follows:
(1) Save the current pixel sizess, font and scrollbar width.
(2) Set the new font size.
(3) Set the new scrollbar width.
(4) Set the new pixel sizes to some calculated from the ones saved in
(1) and the scale factor used in (2).
To dethumbify he would have to
(5) Set the new font size to the one saved in (1).
(6) Set the new scrollbar width to the one saved in (1).
(7) Set the new frame pixel sizes to the ones saved in (1).
I don't know whether this correctly restores window start positions but
at least it seems the only sane way to fix his problem with the current
trunk.
We could obviously store the new pixel values and either let any size
changing functions use the new values or provide a Lisp interface to
them and let Drew use that value in his calculations. Doing so would,
however, not eliminate the fact that the state of Emacs is inconsistent
while a resize operation is pending because the value returned by
`frame-pixel-height' is not in line with that of `frame-height'. The
programmer would still have to be aware of this inconsistency and
explaining such a thing in the manual or a doc-string would be quite a
nuisance. BTW, when creating a new frame, the inconsistency should be
observable on GNU/Linux as well.
I see only two ways to solve this inconsistency:
(1) Find some way to synch with the window manager as we do on
GNU/Linux.
(2) Apply the size changes with the commented-out code. The comment
motivating why we should not do this on Windows because of the
menubar wrapping issue doesn't make sense to me anyway: If we and
Windows can handle wrapping, we'll do that when Windows gets back to
us. And the worst thing that could happen to us is that parts of
the frame (including the modeline) might get obscured. But this is
something I plan to do anyway when shrinking a frame below the
minimum size to accomodate all of its windows.
WDYT?
martin
next prev parent reply other threads:[~2013-12-13 10:12 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <<8dee88e8-6b12-4822-9586-e013328f2ddc@default>
[not found] ` <<529CCE7F.3070400@gmx.at>
[not found] ` <<52A08780.9020405@gmx.at>
[not found] ` <<3df21358-48ca-4150-9f0e-aa2dbf78cbcb@default>
[not found] ` <<360e0ca4-7e4a-4f11-8157-c8f69e4ce913@default>
[not found] ` <<52A188D8.60608@gmx.at>
[not found] ` <<83txem1i7m.fsf@gnu.org>
2013-12-06 14:43 ` bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code Drew Adams
2013-12-06 14:56 ` martin rudalics
2013-12-06 15:29 ` Drew Adams
2013-12-06 16:20 ` martin rudalics
2013-12-06 16:43 ` Drew Adams
2013-12-06 17:22 ` martin rudalics
2013-12-06 19:04 ` Drew Adams
2013-12-07 9:46 ` martin rudalics
2013-12-07 20:34 ` Drew Adams
2013-12-08 9:57 ` martin rudalics
2013-12-08 17:31 ` Drew Adams
2013-12-08 17:54 ` martin rudalics
2013-12-09 17:14 ` Eli Zaretskii
2013-12-09 18:37 ` martin rudalics
2013-12-10 3:53 ` Eli Zaretskii
2013-12-10 7:52 ` martin rudalics
2013-12-10 14:51 ` Drew Adams
2013-12-10 10:31 ` martin rudalics
2013-12-10 10:49 ` martin rudalics
2013-12-10 14:50 ` Drew Adams
2013-12-10 15:36 ` martin rudalics
2013-12-12 4:27 ` Drew Adams
2013-12-12 10:17 ` martin rudalics
2013-12-12 16:29 ` Drew Adams
2013-12-12 18:10 ` martin rudalics
2013-12-12 19:55 ` Drew Adams
2013-12-13 10:13 ` martin rudalics
2013-12-13 10:52 ` Eli Zaretskii
2013-12-13 16:00 ` Drew Adams
2013-12-13 17:24 ` martin rudalics
2013-12-13 18:05 ` Drew Adams
2013-12-13 18:23 ` martin rudalics
2013-12-12 16:38 ` Eli Zaretskii
2013-12-12 18:10 ` martin rudalics
2013-12-12 18:47 ` Eli Zaretskii
2013-12-13 10:12 ` martin rudalics [this message]
2013-12-13 10:51 ` Eli Zaretskii
2013-12-14 11:22 ` martin rudalics
2013-12-14 12:04 ` Eli Zaretskii
2013-12-14 13:45 ` martin rudalics
2013-12-14 14:09 ` Eli Zaretskii
2013-12-14 17:17 ` martin rudalics
2013-12-14 17:19 ` Eli Zaretskii
2013-12-14 17:23 ` martin rudalics
2013-12-16 10:12 ` martin rudalics
2013-12-16 15:06 ` Drew Adams
2013-12-15 0:43 ` Drew Adams
2014-02-10 4:07 ` Lars Ingebrigtsen
2014-02-10 4:29 ` Drew Adams
2013-12-10 15:31 ` martin rudalics
2013-12-10 16:41 ` Eli Zaretskii
2013-12-10 16:51 ` martin rudalics
2013-12-10 18:04 ` Eli Zaretskii
2013-12-10 18:57 ` martin rudalics
2013-12-06 18:22 ` Eli Zaretskii
2013-12-06 18:57 ` martin rudalics
2013-12-06 19:15 ` Eli Zaretskii
2013-12-07 9:46 ` martin rudalics
2013-12-07 11:15 ` Eli Zaretskii
2013-12-07 12:25 ` martin rudalics
2013-12-06 21:32 ` Stefan Monnier
2013-12-02 15:51 Drew Adams
2013-12-02 15:58 ` Drew Adams
2013-12-02 18:16 ` martin rudalics
2013-12-02 19:06 ` Drew Adams
2013-12-05 14:02 ` martin rudalics
2013-12-05 16:33 ` Drew Adams
2013-12-06 5:23 ` Drew Adams
2013-12-06 8:20 ` martin rudalics
2013-12-06 8:45 ` Eli Zaretskii
2013-12-06 14:32 ` martin rudalics
2013-12-06 14:13 ` Drew Adams
2013-12-06 14:32 ` martin rudalics
2013-12-06 14:44 ` Drew Adams
2013-12-06 0:11 ` Juanma Barranquero
2013-12-06 0:18 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52AADD97.5060801@gmx.at \
--to=rudalics@gmx.at \
--cc=16028@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.