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

[Anders Lindgren]

Hi,

> Meanwhile please install your changes.

Done!

> Now the only remaining issue we must fix before the release is that of
> the non-shrinking echo area when toggling off the tool bar

I wasn't aware of this problem. Can you point me to where it's described.

 

> and the fact
> that a frame keeps shrinking when turning off/on the tool bar.  I'll
> look into that but if you have any ideas ...

I though this was by design. On NextStep, the toolbar is excluded from `frame-pixel-height', so it makes sense that frame size change when enabled and disabled. Besides, it's height typically isn't a multiple of the text size, so the frame would need to be resized slightly anyway (unless `frame-resize-pixelwise' is set).

There are other things that we would need to fix:

* Symbols in the fringe are inverted. I saw a patch for this on the emacs-dev mailing list a few weeks ago but I haven't tried it out.

* When the cursor is rendered in the fringe, it's only drawn incorrectly. (This problem might be related to the previous.)

What is the time frame for the Emacs 25 release? I would be happy to work on this, but with my family situation, work will progress very, very slowly.

> I'll give you some feedback when I'm back there.  One problem with
> NSTRACE I have is that it clutters output with ns_update_window_begin
> and ns_defined_color entries.  I now started to comment them out one by
> one.  Maybe you could devise a method to display these optionally only.

I have thought about that as well. Currently, the package provides the macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now, unfortunately they only silence the current function, not functions that may be called by it (which is something that we would want). Hopefully, I will be able to categorize the functions in such a way that the default setting would silence some of the more frequently called functions.

/ Anders

On Thu, Oct 22, 2015 at 5:35 PM, martin rudalics <rudalics@gmx.at> wrote:

> I have never used GNUStep, maybe I should try it out so that my patch work
> there. Are there build instructions for this somewhere?

Don't bother.  Hardly anyone but me regularly builds on GNUStep.  And I
can't use it anyway - too many other problems.

> Anyway, I think the problem you are seeing is due to the fact that I have
> replaced the code in "zoom" with custom code that simply resizes the frame.
> On OS X there is nothing special happening when maximizing the frame -- the
> outer frame (one pixel thick) is still there, no buttons should change
> state etc.

I suppose so.  Maybe I find a way to splice in some code tailored for
GNUStep.  But it will have low priority.

> One thing we should try is to check is the old zoom system would work
> better in GNUStep after all (this is the first of the three different zoom
> version in the code).
>
> Also, it would be interesting to see the NSTRACE output of a session where
> we go "fullwidth" and then "maximized" and compare it with what happens
> under OS X -- if it still is a problem after changing the zoom method.

I'll give you some feedback when I'm back there.  One problem with
NSTRACE I have is that it clutters output with ns_update_window_begin
and ns_defined_color entries.  I now started to comment them out one by
one.  Maybe you could devise a method to display these optionally only.

> When it comes to the double tool bar, I have unfortunately no idea what the
> problem is.

It's a bad interaction between GNUStep and the window manager.  Maybe I
can find out more.

Meanwhile please install your changes.

martin