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

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert <adrian.b.robert@gmail.com> said:

> 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.

They would hesitate to remove the code even if it breaks compatibility
unless you explicitly ask it.

>> 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
>> experimental/hackers-only.

> 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)

Whether or not to mark experimental/hackers-only is up to the
maintainers, and I actually asked them about the status of the port
before removing the code.

http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html
http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00630.html

And actually I considered whether I can remove some of the
incompatible features you listed above, say open/save panel.  But it
is too drastic to do so without some replacement code.  Addition of
such code is "too late" and regression-prone, so I restricted myself
to the features that just removal is sufficient.

>>> nsfont_draw(): Would setting the foreground instead of the
>>> background color to the bitmap constitute a corrected
>>> implementation?
>> 
>> 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.

As I said above, I avoided adding replacement code.

>>> 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."
>> (http://lists.gnu.org/archive/html/emacs-devel/2009-07/msg00594.html)

> "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 fundamental features such as alpha-component needs some
consensus among platforms about its specification.  Of course,
platform-specific proof-of-concept code is sometimes useful to call
for discussion, but it doesn't fit with the official release version
as it is.

>> 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
>> incompatibilities.

> 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 I already said, I suspect the port has fundamental design flaw (not
100% sure, so you can possibly refute it).  And design and policy are
too different from mine.

What I would do with Cocoa can be found in my Carbon+AppKit port.

> 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.

I thought RMS is strongly against adding features to proprietary
platforms first.  Of course, it is not applied to inherently
platform-specific features (such as Apple Event handling).  Maybe if
you make the GNUstep port much more stable and usable enough as
"first-class" port, then you can add some features first to the
platform, but I'm not sure.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp