Re: Question about NSMenuView

[Matt Rice]

On Fri, Jan 16, 2009 at 8:39 AM, Richard Frith-Macdonald
<richard@tiptree.demon.co.uk> wrote:
>
> On 16 Jan 2009, at 13:20, Matt Rice wrote:
>
>> i'll just go back to refraining from "interfering" aka "contributing",
>> because I only do this because it is a) fun
>> and b) if I find it useful maybe others will
>> arguing over stuff just makes it no fun, and when I lose said
>> argument, nobody can find it useful because nobody can find it..
>> now if this were just a few things, but most of the stuff I do for
>> gnustep ends up rejected by their maintainers,
>> if my view of gnustep and that of its maintainers don't align there is
>> no point in my contributing this little patch since i'm still stuck
>> maintaining a ton of other patches
>> so no, I don't really care if the remaining stuff goes in personally,
>> at this point it benefits me none, i've already got my patch...
>> and taking one off of the queue isn't going to make any noticable
>> impact to it OTOH I do hope people find it useful
>> maybe if you guys went distributed version control I would bother....
>
> Well, why is it that your view and that of the maintainers doesn't align?
>
> It could be that your aim is just to produce something that works for you

exactly, and gnustep just plain doesn't work for me, I was under the
impression that
gnustep wanted to be useful to me as opposed to me being useful for it,
and worked twords that until that impression was proven false.

> ... in which case there's always going to be a problem, but if you are
> interested in code that matches the MacOS-X behavior and doesn't break
> behaviors for other people, there should be no difficulty convincing
> maintainers.

I'm all for backwards compatibility, but never inhibiting progress due
to breakage of brokeness

> Of course, maintainers tend to be a bit conservative (trying to ensure that
> changes don't break things, except perhaps if they are changes to improve
> MacOS-X compatibility and the things  they break can be fixed to use the
> MacOS-X behavior), so they need to be able to understand patches, which
> means that they need small and/or simple patches.

yeah, Mac OS X is really pretty far from where I want to go, and I
find it ironic
that given the design in the paper here http://virtualschool.edu/cox/pub/PSIR/
we're basically left with few interchangable components, and 2 massive
libraries,
and when some useful component is developed it is inevitably added to
one of the 2 libraries..

but yes, it frustrates me because of the amount of work which has been
and is being put into gnustep.
so add on top of that that not only am I locked into using this whole
monstrous library thing,
but on top of that it comes with this whole damned environment which
is unique to itself,
and resistant to change..

from my end its like you use gnustep at your work and anything but
maintaining the status quo just means time you
could be doing something else on your stuff that uses gnustep,
while my interests couldnt be much further implementing a more free
software friendly
version of openstep where people are free to contribute some random
implementation of some class which may not be compatible with others,
akin to something like CPAN, I dare say its the only way to implement
OPENSTEP while tracking Mac OS changes without turning all the classes
into some weird hybrid combination incompatible with all known
versions but itself.

backwards compatibility becomes less of an issue because you can
selectively upgrade or exchange components
so yeah, i'd like to take inspiration from openstep and bring it back
to the roots of objective-c.

there are quite a few openstep implementations and gnustep forks in
existence some of which have failed some were created because of
licensing issues, but mostly one man shows, and why do they keep
forking it in the first place maybe they too aim to have something
which works for them and gnustep doesn't work for them either.....

but the whole backwards compatibility thing because its been that way
for 10 years attitude just inhibits experimentation with new ideas,
and the centralization of it all just encourages forking... worried
about attracting new developers, try and keep the ones that you've got
first...

>  Remember, they may not be
> as clever as you (and are almost certainly less familiar with the patched
> code than you), and probably don't have the spare time to sort out complex
> patches.

thats why I write test cases which show or reproduce the behaviour,
if someone doesn't understand something I think it's not unreasonable
for them to ask
I rarely send a patch without one..


> Is it really so dreadful/dispiriting to be asked to break patches down into
> smaller, readily digestible versions?

It is when you have to argue through each and every patch only to get nowhere.
while merging in upstream changes and keeping 'rejected patches'
separated from changes to go upstream,
yeah it is a PITA.