On 2008/05/23, at 20:56, Vebjorn Ljosa wrote: > > Seiji Zenitani <[EMAIL PROTECTED]> writes: > >> I was excited to see your code. It excellently works when I set the >> fullscreen parameter to 'fullboth or nil. >> >> However, it is not fully compatible with the Linux/GTK port. Is it >> possible to show the menu bar when the fullscreen parameter is >> fullwidth or fullheight? > > First of all, I see now that the way my code handles the menu bar is > flawed. It was somewhat flawed before (hiding the menu bar for one > frame hid it for all frames), but with my patch it's much worse: for > instance, setting the frame parameter to 'fullboth and then directly > to > 'fullwidth makes the menubar disappear permanently. The difficulty is > that SystemUIMode works on a per-application basis rather than a > per-frame basis. I think we will need to call SystemUIMode every > time a > frame receives focus. Do you know in which function this happens? > I will look at it, but I won't have much time for the next week.
It's true that the menu bar is per-application basis, not per-frame basis. Furthermore, it will not be user-friendly if the "focus" changes the menu bar visibility everytime. To me, the best way is to compromise like this; 1) If Emacs has one or more full-screen frame, it hides the menu bar. 2) If Emacs do not have frame, it shows the menu bar. Along with your comments, I will carefully observe how the X/GTK port deals with the GTK menu bar next next weekend (I'm on a trip now). Also, the fullscreen code is big enough now, and so it can be separated from mac-function patch. Thanks, Seiji > Second, the question of what the various fullscreen modes should > entail > wrt. menu bars, window decorations, and frame size. Here is what > the X > port (with or without GTK) does: > * With proper window manager support: > - Does not touch the menu bar, but leaves that an orthogonal > decision (according to the frame parameter menu-bar-lines) > - Removes window decorations only in 'fullboth. > - Ignores set-frame-height and/or set-frame-width while in > fullscreen mode. > - Restores original frame size and position properly. > * Without proper window manager support (e.g., with Xquartz): > - Does not touch the menu bar, but leaves that an orthogonal > decision (according to the frame parameter menu-bar-lines) > - Does not remove window decorations > - Heeds set-frame-height and set-frame-width even in full-screen > mode > - Does not change frame size at all when leaving full-screen mode > > In order to match the first wrt. the menu bar, we should do the > following: > * If mac-autohide-menubar-on-maximize is false: > - Obey the menu-bar-lines frame parameter, whether in full-screen > mode or not. (This is un-mac-like when not in full-screen, but > that's ok, as menu-bar-lines is 1 by default.) > * If mac-autohide-menubar-on-maximize is true: > - Outside full-screen mode, obey the menu-bar-lines frame parameter > (either showing it completely or hiding it completely, never > autohide). > - In full-screen mode, either hide the menu bar completely (if > menu-bar-lines is 0) or autohide it (if menu-bar-lines is 1). > We should also change the code so that set-frame-height and/or > set-frame-width are ignored in fullscreen mode. Not sure how to do > this. > > Some technical questions: > > * Why is some information (frame size and position before fullscreen) > stored in a separate struct, pointed to from a property of the Mac > window, rather than as frame parameters? > > * What is the right way to modify a frame parameter from C code? > > * Is it ok to call a Lisp function from the C code that is triggered > by > setting a certain frame parameter call? > > * Why is the code for setting frame parameters written in C instead of > Lisp? Is it because some if it may be called from event handlers? > > As an aside, I wish Emacs's fullscreen mode were different in many > ways > (allow frames to be resized (only programmatically), but with a > backdrop > that keeps other windows from view; remember these positions for next > time a frame enters fullscreen mode; etc.). I think, however, that I > should introduce such changes in behavior to the upstream Emacs, and > that Carbon Emacs Package should attempt to match the upstream Emacs > as > closely as possible. > --~--~---------~--~----~------------~-------~--~----~ Carbon Emacs User Group http://groups.google.com/group/carbon-emacs?hl=en -~----------~----~----~----~------~----~------~--~---
