[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes 2009-07-15/16 in branch?
From: |
YAMAMOTO Mitsuharu |
Subject: |
Re: Changes 2009-07-15/16 in branch? |
Date: |
Sat, 25 Jul 2009 10:15:34 +0900 |
User-agent: |
Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (Shijō) APEL/10.6 Emacs/22.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) |
>>>>> On Fri, 24 Jul 2009 10:34:55 -0400, Adrian Robert <address@hidden> 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
address@hidden
- Re: Changes 2009-07-15/16 in branch?, (continued)
- Re: Changes 2009-07-15/16 in branch?, YAMAMOTO Mitsuharu, 2009/07/27
- Re: Changes 2009-07-15/16 in branch?, Richard Stallman, 2009/07/28
- Re: Changes 2009-07-15/16 in branch?, Stefan Monnier, 2009/07/24
- Re: Changes 2009-07-15/16 in branch?, YAMAMOTO Mitsuharu, 2009/07/28
- Re: Changes 2009-07-15/16 in branch?, Chong Yidong, 2009/07/28
- Re: Changes 2009-07-15/16 in branch?, YAMAMOTO Mitsuharu, 2009/07/28
- Re: Changes 2009-07-15/16 in branch?, YAMAMOTO Mitsuharu, 2009/07/29
- Re: Changes 2009-07-15/16 in branch?, YAMAMOTO Mitsuharu, 2009/07/28
Re: Changes 2009-07-15/16 in branch?, Adrian Robert, 2009/07/24
- Re: Changes 2009-07-15/16 in branch?,
YAMAMOTO Mitsuharu <=
- Re: Changes 2009-07-15/16 in branch?, Richard Stallman, 2009/07/25
- Re: Changes 2009-07-15/16 in branch?, Adrian Robert, 2009/07/25
- Re: Changes 2009-07-15/16 in branch?, Richard Stallman, 2009/07/26
- Re: Changes 2009-07-15/16 in branch?, Adrian Robert, 2009/07/26
- Re: Changes 2009-07-15/16 in branch?, Richard Stallman, 2009/07/29
- Re: Changes 2009-07-15/16 in branch?, Harald Hanche-Olsen, 2009/07/29
- Re: Changes 2009-07-15/16 in branch?, Stefan Monnier, 2009/07/29
- Re: Changes 2009-07-15/16 in branch?, David Kastrup, 2009/07/30
- Re: Changes 2009-07-15/16 in branch?, Harald Hanche-Olsen, 2009/07/30
Re: Changes 2009-07-15/16 in branch?, Harald Hanche-Olsen, 2009/07/28