Re: Question about NSMenuView

[Matt Rice]

On Fri, Jan 16, 2009 at 12:02 AM, Fred Kiefer <fredkiefer@gmx.de> wrote:
> Matt Rice wrote:
>> I would probably have tried subclassing GSWindowDecorationView (like
>> in the NiftyTitleBar bundle) and added a
>> NSTableView without the scroll bars/headers containing strangely
>> configured NSPopUpButtonCell's e.g
>> pullsDown/usesItemFromMenu/preferredEdge, though I don't recall the
>> specifics of if its easy to change a GSWindowDecorationView's size and
>> whatnot
>>
>> there is an attachment here which has a bunch of weirdly configured
>> NSPopUpButtons,
>> http://www.nabble.com/NSPopUpButton-icon-buttons-patch...-td477205.html
>>
>> Pretty sure that NSMenuView would still require some patching to get
>> what you want though from NSPopUpButtonCell
>> not the whole patch was integrated portions were rejected
>
> Hi Matt,
>
> I clearly see this as a trick to get the last outstanding changes to
> popup buttons in. For some reasons I cannot remember we refrained from
> including all the changes you proposed at that time and now you try to
> sneak them in under the cover of enabling in-window menus. Nice try, but
> I noticed :-)
>

sorry if i find my patch useful, no trick intended, just replying
because my name was brought up

decided to chime in on how i would go about it, the link to the patch
was actually for the example application
since most of the patch is already applied last february, it could be
partially useful
and IIRC only minimal changes would be required

you don't think if i post something on a public list which you are
known to read in a thread you've already replied in I wouldn't think
you would notice,
damn i'm just not very sneaky

the original author asked a question, I responded with an answer of
how I would go about it, since he didn't seem to get any other
answers.......

> If you really want to get the remaining stuff in, I would propose you
> write a new patch (or better one for each feature) that could then be
> discussed on this list. I really don't remember what was the problem at
> that time.

at this point I don't even care..... if i've written some code and you
guys find it useful use it,
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....

anyhow here's the damn patch and a test case,
run the testcase, click buttons
apply patch1
run the testcase, click buttons
revert patch1, apply patch2
run the testcase click buttons

then exclaim that there is no way this could be remotely useful for
menus windows
complain that the patch is ugly, and think about how there's no
non-ugly way to implement it
short of redesigning NSMenuView and friends (which can pretty much be
blamed on apple IMHO),
and keep using your ugly assed pull-downs, isn't going to do me any
good except fix a 5 year old bug in one of my programs that has never
been reported.

anyhow 2 patches, one fixes the easy case the other the ugly case.
the foo2.diff fixes foo1.diff to work with -usesItemFromMenu:YES
IIRC you considered the first one ugly, and we never got to the ugliest one...

if I had my druthers i'd remove the NSPopUpButton/NSMenuView cross
pollination entirely as it just turns NSMenuView into a crossroads of
horizontal/vertical/pop up buttons/pull down buttons, but its fully
exposed API which afaik has only ever been used to internally
implement AppKit... be much simpler as a button with a window
containing a matrix

anyhow apologies for not being nice, having a long memory and a low
bullshit tolerance,
but I don't think you should hold contributions to a higher standard
than the code it modifies...

commence discussion...

> PS: As for the in-window menu, does anybody still have Michael's code?
> It really would be nice to have a solution here and I am going to work
> on the window decoration anyway, to get this better integrated with themes.
>

afaik he ever released it