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

[Anders Lindgren <andlind@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5915 bytes --]