bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#14233: 24.3; Don't constrain frame size to character multiples


From: martin rudalics
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Thu, 25 Apr 2013 09:29:05 +0200

>> A function that would tell me in a platform independent way the pixel
>> offset of the frame's root window from the top edge of the frame's
>> "client rectangle" (sorry for the Windows parlance).
>
> Using MS Windows narrows your world view.  If you used Emacs for Gtk+
> you would know that the toolbar can be on any edge (top, bottom, left
> or right).  So getting just top edge offset is not enough.  You need
> all four offsets.

If you had a broader world view, you would have noticed that the Gtk+
toolbar is not part of the client rectangle (the rectangle passed to
change_frame_size), so your point is moot in this context.  What I
wanted are the much simpler macros

#define FRAME_MENU_BAR_HEIGHT(f) (f)->menu_bar_height

#define FRAME_TOOL_BAR_HEIGHT(f) (f)->tool_bar_height

#define FRAME_TOP_MARGIN_HEIGHT(F)                              \
  (FRAME_MENU_BAR_HEIGHT (F) + FRAME_TOOL_BAR_HEIGHT (F))

where tool_bar_height would count (in pixels) things like
`tool-bar-button-margin', `tool-bar-button-relief' and
`tool-bar-border', wherever applicable, together with the actual toolbar
and menubar heights (in particular, when these have been wrapped).

If you want for tiled/user specified/maximized/fullscreen mode on Gtk+
change_frame_size to subtract the Gtk+ toolbar size from that of the
screen, then we'd have to first include this size in that of the
rectangle passed to change_frame_size.  This would, however, constitute
a considerable change in the design of the frame/window interface and
would be better done in a separate project.

martin





reply via email to

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