|
From: | Jason Clouse |
Subject: | Re: NSToolbar (was Re: Portability/Compatability between GNUstep<---> Cocoa...) |
Date: | Tue, 13 Jan 2004 21:07:26 -0500 |
The problem with NSToolbar (and, in general, other bad changes) ultimately lies in the interface (ie. the API, not the UI). It can't be well implemented.
I was fully aware of that. But the purpose of implementing these things is PURELY for portability. If nobody here ever used it in an original application, I wouldn't care. In attempting to promote the project, I've consistently found that portability is the clincher for people. Making that as straightforward and effortless as possible is of the utmost importance.
New code bloats the library, adds new complexity to the code,
Slightly. But Alex's PortabilityKit fixes this.
3. Better alternatives. By adding "less-than-perfect" stuff now, we hamper the development of better stuff (either as part of the library, or as independent libraries). By adding NSToolbar, we make it harder to get a better designed GSToolbar done.
How? If NSToolbar is truly inferior, people will be jumping at the chance to come up with something better. Nature abhors a vacuum, somebody will think of something. All you have to do is write a good GSToolbar, and put the NSToolbar in the PortabilityKit. Besides: "the Perfect is the enemy of the Good."
You know what would *really* be cool is if we made GSToolbar portable in the opposite direction and split it off into its own framework as well (along with other redesigns of Apple classes) . That would allow GNUstep applications to use the better solution and be instantly portable to OS X. It might even encourage Apple developers to use the better solution if it's marketed and promoted heavily enough.
[Prev in Thread] | Current Thread | [Next in Thread] |