I have continued (and maybe finished?) making the full-screen functionality in Carbon Emacs compatible with the X port. For those who didn't read the previous thread: Per Seiji's suggestion, the patch disposes of the mac-toggle-max-window command and instead ties the full-screen mode to the frame parameter 'fullscreen, like the X port:
The new version differs from my previous attempt in the following ways:
* Properly restores the original size of the window and the menu bar when leaving full-screen mode. (This would sometimes break in my previous patch, e.g., when the frame parameter went nil -> 'fullboth -> 'fullheight -> nil.)
* Keeps the menu bar and title bar in 'fullwidth and 'fullheight mode.
* Cleaner and shorter code; uses the frame parameter 'fullscreen-saved-state to store the original frame position and size.
* Turns off the menu bar only for frames on the main display. (Thanks, David!)
* Turns off the menu bar only for frames in 'fullboth mode (so you can now have multiple frames, some in 'fullboth mode and some not, without problems).
Seiji, I know you suggested hiding the menu bar for all frames when one frame is in full-screen mode, but try the current patch. I think you will like the way it handles the menu bar, which is consistent both with the GTK port of Emacs and with various Mac applications.
It excellently works on my laptop. I am happy if someone examines it on an external display, too. I will try to re-organize the relevant patches this weekend.
On Tuesday, June 03, 2008, at 11:26AM, "Vebjorn Ljosa" <vebj...@ljosa.com> wrote:
>I have continued (and maybe finished?) making the full-screen >functionality in Carbon Emacs compatible with the X port. For those who >didn't read the previous thread: Per Seiji's suggestion, the patch >disposes of the mac-toggle-max-window command and instead ties the >full-screen mode to the frame parameter 'fullscreen, like the X port:
>The new version differs from my previous attempt in the following ways:
> * Properly restores the original size of the window and the menu bar > when leaving full-screen mode. (This would sometimes break in my > previous patch, e.g., when the frame parameter went nil -> 'fullboth > -> 'fullheight -> nil.)
> * Keeps the menu bar and title bar in 'fullwidth and 'fullheight mode.
> * Cleaner and shorter code; uses the frame parameter > 'fullscreen-saved-state to store the original frame position and > size.
> * Turns off the menu bar only for frames on the main display. (Thanks, > David!)
> * Turns off the menu bar only for frames in 'fullboth mode (so you can > now have multiple frames, some in 'fullboth mode and some not, > without problems).
>Seiji, I know you suggested hiding the menu bar for all frames when one >frame is in full-screen mode, but try the current patch. I think you >will like the way it handles the menu bar, which is consistent both with >the GTK port of Emacs and with various Mac applications.
> It excellently works on my laptop. > I am happy if someone examines it on an external display, too. > I will try to re-organize the relevant patches this weekend.
I've re-organized the patches in the svn trunk. BTW, who are the authors? Does the fullscreen patch also contain Joel and David's code?
> On Tuesday, June 03, 2008, at 11:26AM, "Vebjorn Ljosa" <vebj...@ljosa.com > > wrote:
>> I have continued (and maybe finished?) making the full-screen >> functionality in Carbon Emacs compatible with the X port. For >> those who >> didn't read the previous thread: Per Seiji's suggestion, the patch >> disposes of the mac-toggle-max-window command and instead ties the >> full-screen mode to the frame parameter 'fullscreen, like the X port:
>> The new version differs from my previous attempt in the following >> ways:
>> * Properly restores the original size of the window and the menu bar >> when leaving full-screen mode. (This would sometimes break in my >> previous patch, e.g., when the frame parameter went nil -> 'fullboth >> -> 'fullheight -> nil.)
>> * Keeps the menu bar and title bar in 'fullwidth and 'fullheight >> mode.
>> * Cleaner and shorter code; uses the frame parameter >> 'fullscreen-saved-state to store the original frame position and >> size.
>> * Turns off the menu bar only for frames on the main display. >> (Thanks, >> David!)
>> * Turns off the menu bar only for frames in 'fullboth mode (so you >> can >> now have multiple frames, some in 'fullboth mode and some not, >> without problems).
>> Seiji, I know you suggested hiding the menu bar for all frames when >> one >> frame is in full-screen mode, but try the current patch. I think you >> will like the way it handles the menu bar, which is consistent both >> with >> the GTK port of Emacs and with various Mac applications.
Seiji Zenitani <zenit...@mac.com> writes: > I've re-organized the patches in the svn trunk.
Great, thanks!
> BTW, who are the authors? > Does the fullscreen patch also contain > Joel and David's code?
Yes, absolutely. The code that finds the display ID of a mac window is unchanged. (Not sure whether it originated with Joel or David.) And Joel or David had already figured out how to use the Mac's Window Manager API to achieve the desired effects; my mac_fullscreen_hook builds on that previous work.
I tested the latest fullscreen code on an external display. My display configuration is described in the attached file; a wider sub screen (an external display) is located on the left side of the main screen.
Everything is file on the main screen, however, there is a glitch on the sub screen. For example, when I set the fullscreen frame parameter to 'fullwidth on a sub screen, the frame shows up both on the main screen and on the sub screen, as shown in the PDF file. The width of the frame seems to be correct: it's same as the width of the sub screen.
>> I've re-organized the patches in the svn trunk.
> Great, thanks!
>> BTW, who are the authors? >> Does the fullscreen patch also contain >> Joel and David's code?
> Yes, absolutely. The code that finds the display ID of a mac window > is > unchanged. (Not sure whether it originated with Joel or David.) And > Joel or David had already figured out how to use the Mac's Window > Manager API to achieve the desired effects; my mac_fullscreen_hook > builds on that previous work.
Thanks. I will acknowledge the three authors in the relevant documents.
I've been having trouble with the old version of the patch when changing font settings. If you change the font (e.g., with M-x set- frame-font, or with the font panel), the frame resizes, and it is not full-screen any longer.
I haven't installed the new patch yet. It would be interesting to see if things work better with that.
> I tested the latest fullscreen code on an external display. > My display configuration is described in the attached file; > a wider sub screen (an external display) is > located on the left side of the main screen.
> Everything is file on the main screen, > however, there is a glitch on the sub screen. > For example, when I set the fullscreen frame parameter > to 'fullwidth on a sub screen, > the frame shows up both on the main screen > and on the sub screen, as shown in the PDF file. > The width of the frame seems to be correct: > it's same as the width of the sub screen.
>>> I've re-organized the patches in the svn trunk.
>> Great, thanks!
>>> BTW, who are the authors? >>> Does the fullscreen patch also contain >>> Joel and David's code?
>> Yes, absolutely. The code that finds the display ID of a mac window >> is >> unchanged. (Not sure whether it originated with Joel or David.) And >> Joel or David had already figured out how to use the Mac's Window >> Manager API to achieve the desired effects; my mac_fullscreen_hook >> builds on that previous work.
> Thanks. > I will acknowledge the three authors in the relevant documents.
Seiji Zenitani <zenit...@gmail.com> writes: > I tested the latest fullscreen code on an external display. My > display configuration is described in the attached file; a wider sub > screen (an external display) is located on the left side of the main > screen.
> Everything is file on the main screen, however, there is a glitch on > the sub screen. For example, when I set the fullscreen frame > parameter to 'fullwidth on a sub screen, the frame shows up both on > the main screen and on the sub screen, as shown in the PDF file. The > width of the frame seems to be correct: it's same as the width of the > sub screen.
The background for this bug is that the origin of the display on a Mac is in the top-left corner of the main display. In your setup, the main display is on the right, so a window on your external display will have negative X-coordinates. X11, however, does not use negative coordinates. Instead, a negative sign indicates that the coordinate is relative to the right or bottom edge of the display (rather than the left or top). There is code in macterm.c (e.g., x_calc_absolute_position) that simulates the X11 behavior.
The bug was present even before my patch, but didn't happen right away (because mac-toggle-max-window changed the position without telling Emacs). It would also be encountered by anyone setting the frame parameter 'left, even if they didn't use the fullscreen feature at all.
The right way to fix this is probably to translate between two coordinate spaces. Internally to Emacs, the origin should be in the top-left corner of the minimum bounding rectangle of the union of the displays. The Mac-specific code will have to translate to and from the Mac coordinates (with the origin in the top-left corner of the main display).
David Reitter <david.reit...@gmail.com> writes: > I've been having trouble with the old version of the patch when > changing font settings. If you change the font (e.g., with M-x set- > frame-font, or with the font panel), the frame resizes, and it is not > full-screen any longer.
> I haven't installed the new patch yet. It would be interesting to see > if things work better with that.
David,
I had noticed that problem, too (and my patch did not address it). I tried right now to call fullscreen_hook from x_set_font (see patch below), and it seems to work. I think it's a little ugly, however. It would be better to intercept the lower-level code that actually changes the size (in pixels) of the Mac window, but I couldn't find it in the time I have available today. What do you think?
> I had noticed that problem, too (and my patch did not address it). I > tried right now to call fullscreen_hook from x_set_font (see patch > below), and it seems to work. I think it's a little ugly, however. > It would be better to intercept the lower-level code that actually > changes the size (in pixels) of the Mac window, but I couldn't find it > in the time I have available today. What do you think?
Yes, it should be called from wherever changes to the frame size are made, but I guess one can go with your solution for now.
This should be submitted to emacs-devel for review and inclusion in Emacs 23.
Do you have any thoughts about making this work well with the Cocoa port?
>> I had noticed that problem, too (and my patch did not address it). I >> tried right now to call fullscreen_hook from x_set_font (see patch >> below), and it seems to work. I think it's a little ugly, however. >> It would be better to intercept the lower-level code that actually >> changes the size (in pixels) of the Mac window, but I couldn't find it >> in the time I have available today. What do you think?
> Yes, it should be called from wherever changes to the frame size are made, > but I guess one can go with your solution for now.
> This should be submitted to emacs-devel for review and inclusion in Emacs > 23.
I'm experiencing some difficulties with the fullscreen patch (2008-06-02) on the non-main display, which is arranged to be to the right and some 300 pixels above the main screen. When I "fullscreen" a frame on the second screen, it is moved down to y=0. It should be at y=-300.
Also, the width is not correct (it is a little too narrow) on the main screen.
Last, I can move the whole frame manually away when in full-screen mode. This shouldn't be.
I didn't see any such problems with the previous patch.
Also, I notice that the frame is smaller than the full screen size, which is ugly (and not really "full screen"). This is when I use a Lucida Grande 14pt font rather than the default Monaco one.
> I'm experiencing some difficulties with the fullscreen patch > (2008-06-02) on the non-main display, which is arranged to be to the > right and some 300 pixels above the main screen. > When I "fullscreen" a frame on the second screen, it is moved down > to y=0. It should be at y=-300.
> Also, the width is not correct (it is a little too narrow) on the > main screen.
> Last, I can move the whole frame manually away when in full-screen > mode. This shouldn't be.
> I didn't see any such problems with the previous patch.
On Monday, July 07, 2008, at 11:34AM, "David Reitter" <david.reit...@gmail.com> wrote: >Hi Vebjorn + Seiji,
>any news regarding the issues below?
>Also, I notice that the frame is smaller than the full screen size, >which is ugly (and not really "full screen"). >This is when I use a Lucida Grande 14pt font rather than the default >Monaco one.
>- David
>On 3 Jul 2008, at 18:29, David Reitter wrote:
>> Vebjorn,
>> I'm experiencing some difficulties with the fullscreen patch >> (2008-06-02) on the non-main display, which is arranged to be to the >> right and some 300 pixels above the main screen. >> When I "fullscreen" a frame on the second screen, it is moved down >> to y=0. It should be at y=-300.
>> Also, the width is not correct (it is a little too narrow) on the >> main screen.
>> Last, I can move the whole frame manually away when in full-screen >> mode. This shouldn't be.
>> I didn't see any such problems with the previous patch.
> I'm experiencing some difficulties with the fullscreen patch > (2008-06-02) on the non-main display, which is arranged to be to the > right and some 300 pixels above the main screen. > When I "fullscreen" a frame on the second screen, it is moved down to > y=0. It should be at y=-300.
This is the negative-coordinate problem that Seiji encountered. It was also present with the previous fullscreen patch (and also without it). I describe in Message-ID <nq5bq2afnyl....@gm3b6-dd5.broad.mit.edu> (from 2008-06-09) how it can be fixed, but I don't have the time available right now.
> Also, the width is not correct (it is a little too narrow) on the main > screen.
I modified x_set_window_size to avoid this. The attached patch is relative to the current SVN version. Can you please test it?
> Last, I can move the whole frame manually away when in full-screen > mode. This shouldn't be.
I don't understand this. Do you mean that the window keeps its title bar so you can drag it? That should not happen in 'fullboth mode (but should happen in 'fullwidth and 'fullheight mode).
> This is the negative-coordinate problem that Seiji encountered. It > was > also present with the previous fullscreen patch (and also without it). > I describe in Message-ID <nq5bq2afnyl....@gm3b6-dd5.broad.mit.edu> > (from > 2008-06-09) how it can be fixed, but I don't have the time available > right now.
OK, if you could look into it at some point, that'd be good.
> I modified x_set_window_size to avoid this. The attached patch is > relative to the current SVN version. Can you please test it?
Will get back to you.
>> Last, I can move the whole frame manually away when in full-screen >> mode. This shouldn't be.
> I don't understand this. Do you mean that the window keeps its title > bar so you can drag it? That should not happen in 'fullboth mode (but > should happen in 'fullwidth and 'fullheight mode).
No, not the title bar, but the tool bar stays (and it should). The tool bar is draggable (at least in 10.5). So that should be disabled somehow.
|
