[Top][All Lists]

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

Re: Changes 2009-07-15/16 in branch?

From: Adrian Robert
Subject: Re: Changes 2009-07-15/16 in branch?
Date: Fri, 24 Jul 2009 10:34:55 -0400

On Jul 23, 2009, at 8:46 AM, YAMAMOTO Mitsuharu wrote:

 It's essential to make these changes in the release branch so users
 may not use the incompatible formats by accident and introduce
 compatibility problems when they are removed in some future version.
 Upcoming version is the first one for the NS port.  Effectiveness is
 much lowered if such changes are deferred to the later versions.

 I've warned about such incompatibility issues that I think
 indispensable for the first official release version, but the author
 has not tried to address them (not just for this one!).

There are others working on the port, but speaking for myself, my time has been limited and I've prioritized fixing bugs (as I've mentioned before). I've advocated for and assisted others with standardization / cleanup efforts.

 Even if by any chance there's overlooked code as you say, it's only
 in the NS-specific part and relatively minor compared with total
 unstableness of the port itself.  Removing incompatible features at
 this timing is much more important unless the port is marked

Then let's mark it such, as there are many more features of this sort that should be removed by your criteria (some of which were unfortunately adopted by the Carbon port following Emacs.app in the Sourceforge days, but were never subjected to the same scrutiny):

- modifier key customization (standard methods exist)
- services integration (no counterpart on other platforms)
- applescript integration (use DBUS instead)
- font panel (unneeded, incompatible)
- nonstandard antialiasing controls (standard methods exist)
- nonstandard way of hiding/showing toolbar (unneeded, incompatible)
- open/save panels (unneeded, incompatible)
- about panel (unneeded)

All of these things belong in distributions, or in add-on packages such as:


ns_color_to_lisp(): The function could be simplified now that you
have eliminated a special case.

I know the changes are not optimal.  But I wanted to keep them quite
straightforward so as to avoid regression.

OK, then at least a cleaned-up version could have gone into the trunk.

nsfont_draw(): Would setting the foreground instead of the
background color to the bitmap constitute a corrected

I don't know if I understand your intention correctly from the above
sentence.  But if you believe you understand stippling correctly this
time, maybe you can make the change into the trunk.

I gathered that you understood it better than I so I was wondering if there was some reason to just remove code when fixing it would have been as easy.

ns-set-background-alpha: The implementation you just removed was
superior to that for (set-frame-parameter nil 'alpha ##): it does
not alter the alpha of the titlebar, scrollbars, modeline, or text.
This makes it usable, instead of a curiosity.  It also provides
access via an interactive function.  The correct fix would be to
improve the (set- frame-parameter) version, not remove this while no
alternative exists for users.

I knew their difference.  I removed it because it belongs to "NS-only
implementation for features that are not inherently specific to NS."

"Inherently specific" is an ambiguous call, and I don't think it's a reasonable litmus test. But if the Cocoa APIs provide alpha capabilities beyond what is available on X11 and W32, it is inherent in some sense. The right thing would be to fix the frame-parameter implementation (at least on NS), but failing that the other option should be left in for users.

I think it's really bad for the "first-class" port to have such
features because they may be superseded in a platform-independent way
by some future versions and that introduces unnecessary

It seems there are several problems listed in the email you cite that either do not impact or actually hurt users; why not work on these (on the trunk), or on fixing bugs?

As far as the superseded / platform independent argument, as I've said before, many features first appeared on X11 or GTK without counterparts on other platforms. This continues to happen now. It's a double-standard to police the NS port so stringently without considering implementing the counterparts.

reply via email to

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