Re: Changes 2009-07-15/16 in branch?
YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
2009-07-25 01:15:34 GMT
>>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert <adrian.b.robert <at> 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
> 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.
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
>> 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."
> "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
> 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.
mituharu <at> math.s.chiba-u.ac.jp