GNUstep Project Gets New Chief Maintainer 129
stivi writes "OSNews is reporting that Gregory Casamento has accepted the position of GNUstep Maintainer. Adam Fedor, former GNUstep leader writes: 'After over 15 years of being the Chief Maintainer for GNUstep, I've found I have too many other responsibilities to devote as much time to GNUstep as is necessary. I still plan on contributing to GNUstep in the future in a lower capacity.' Gregory has been a prolific developer for GNUstep for the past seven years and is currently the maintainer for Gorm (the graphical interface designer) and the GUI library. I think he will make a great choice to lead GNUstep in the future. New plans for change have been set up already. Thank you Adam for the past, congratulations Gregory to the future."
Direction (Score:4, Insightful)
Re:gnustep (Score:5, Insightful)
Alive (Score:2, Insightful)
Ok I read TFA (Score:3, Insightful)
Comment removed (Score:5, Insightful)
Re:The *big* problem with GNUStep... (Score:3, Insightful)
Its main disadvantage is the same one as all C++ toolkits : the vast majority of people programming are absolute beyond belief raving idiots and will destroy their lives very quickly when they are given as many avenues of complexity as C++ gives them. Of course, this will probably make them feel that they are experts. I've recently realised after working on a few Python projects in groups that the same sadly applies to dynamic languages : most people programming can not be trusted with anything more expressive than Java. They will happily screw that beyond hell as well, but Java tools are good enough to help you out of the mess, and any other languages tools are not. Lets not bring up the pitiful smalltalk refactoring tools that people who have never used them rave about. They were crap because they relied on type inference - and the code you really want to refactor is shit code, ie has no consistent typing. So, worse is better... sigh.
Anyway, away from that semi-relevant rant, Qt itself is pretty well done and only things that I could see as real OpenStep advantages are scope related - it deals with a lot of interapplication stuff that Qt doesn't. I would really not dismiss Qt as an MFC++ or a Win32 wrapper - MFC is so foul it shouldn't be mentioned in the same breath as any vaguely sane toolkit.
Re:Please explain if you know... (Score:3, Insightful)
Much of Mac OS X Cocoa was derived from NeXTSTEP, so there is the possibility of some level of compatibility with Mac OS X. In some ways GNUstep might be considered superior because of simplicity resulting in the lack of integration with Carbon which was done on Mac OS X for partial compatibility with previous Mac OS versions.
Where to begin? (Score:5, Insightful)
I use NeXTStep as proof that Microsoft has set the computer industry back 12 years. NeXTStep used display postscript on both the video display, and for printing. It was fully-preemptive, with a clean, POSIX-compliant system interface. The application framework was extremely advanced, and extremely easy to code for. Using Objective-C as the programming language of choice, NeXTStep had some very advanced programs for the time, such as Lotus Improv, the spreadsheet MS-Excel wishes to become when it grows up.
As it is, MS-Windows still lags behind NeXTStep by a good amount, especially in terms of ease-of-development, ease-of-use, and aesthetics.
Tim Berners-Lee created the World Wide Web on a NeXT.
Anyway, when it became apparent that NeXT was not going to survive, they released a bunch of specifications that together made up the technical documentation for OpenStep, based on NeXTStep. The idea was that OS vendors could implement OpenStep APIs, and application vendors could target a single API for multiple OSs.
GnuStep is an implementation of the OpenStep API, and other programs to recreate the NeXT environment on any Unix-like operating system. Applications written for GnuStep can be recompiled to target OS X with little-to-no work.
Basically, when people say Linux needs an easy-to-use, easy-to-develop-for application environment and desktop, they are talking about GnuStep, whether they know it or not. It's not as flashy as GNOME or KDE, but it's much cleaner, easier to develop for, easier to use, and much more consistent. Where both GNOME and KDE try to be similar to MS-Windows, GnuStep tries to be like NeXTStep, the best application development and user desktop ever created.
Re:The *big* problem with GNUStep... (Score:3, Insightful)
Which is a stuck up way of saying that Java meets the needs of more projects than C++.
One implementations of your best solution would be to hire, exclusively, graduates of the Vulcan Science Academy. Since your solution is predicated on assumptions contrary to fact, it is not in actuality a solution.
While having more competent programmers would, in any world real or imagined, be a good thing, I think you also underestimate the problem of realism in project goals. Your goals and who you hire should be closely interrelated. If you aren't willing to hire people with the skills needed to complete your project with reasonable quality and the time alloted, your project's goals are not realistic.
Hiring expensive talent and using a less "idiot-proof" language is not necessarily more virtuous than hiring median talent and using a more "idiot-proof" language. Nor are these the only two alternative strategies. The point is to have a strategy for a project that is sustainable, effective, and economical.
Re:Alive (Score:3, Insightful)
GJC
Re:gnustep (Score:1, Insightful)
- monolithic main menu bar w/ wasted blank space between the menus and the (optional) information / settings menus for Airport &c.
By putting it there, it's faster to use. The blank space isn't so bad, since you couldn't put anything in a space that shape/position, anyway. Look at anybody using NeXT and see how much time they waste moving their menu around (not to mention acquisition time for the menu items in the first place, since they just float there).
- verbose Mac-style shortcut descriptions w/ arcane symbols instead of concise NeXT-style shortcuts (in NeXTstep, Save is indicated by ``s'' and Save as by ``S'', no Command symbol (it's assumed---Control only as a modifier is reserved for personal shortcuts / Unix-use), Shift by case)
Yeah, ^S is really verbose. (And sadly, Apple keyboards outside of the US have those symbols on the keys, but that's a hardware issue, not a software one.)
- Print, Hide, Services and Quit are no longer top-level menus where they made more sense and were quicker to get at.
I'm not sure what you mean by this. (Are you upset because you think it takes too long to quit a Mac app? How often do you do that?)
- scroll bars on wrong side (this can't be fixed by theming 'cause Carbon apps are responsible for deciding where scroll bars are placed
When you partially drag the window off the right, then left-side scrollbars are more useful. When you partially drag it off the left, then right-side scrollbars are more useful. Result: this is not a deciding factor.
- no Webster.app (this has since been addressed w/ 10.4), Digital Librarian / Shakespeare or Oxford's Book of Quotations --- in NeXTstep this meant one was guaranteed to have Command = _not_ used in an app so it'd be available for looking things up in Websters
As you point out, Mac OS X does have a dictionary service now. If I used it more than once a week, I might wish it had a keyboard shortcut, but I don't. (There's probably a trick to add one.)
- Pantone colour library --- used to be this was licensed w/ the system, now each graphic app which needs it has to pay a license, and one _doesn't_ get them in one's office apps (major negative for adhering to corporate identity programs where such is specced)
I guess this is a downside, but most people really don't care. Mac OS still handles color far better than Windows or Linux.
- vertical menu
This is an advantage
- pop-up main menu --- this is wonderfully fast / efficient / elegant. For me, ``Punch'' in Altsys Virtuoso is pretty much a gesture, right-click, down a bit, then straight over and release
The Mac has a "mile high" main menu. This has been shown to be faster than a context menu, *even when it's on a different screen* (see Tog on Interface).
Then again, Mac developers always have the choice of using either one. If "Punch" is a common operation, developers are welcome to make it a popup menu, too. On NeXT, you can't make a mile-high menubar at all.
- repositionable sub-menus --- no need for inscrutable button bars, and one can make a given command easy to get to as needed (when doing lots of envelopes I tear off the poste.app Services menu, put it in the bottom left corner, then an envelope is merely a selection, mouse move to bottom left, click, shift right to the print menu (also aligned on the bottom edge for this) click away. (takes longer to say / type than to do)
I guess the Mac way is to use Applescript or Automator so you don't have to do the same mindless thing 1000 times by hand.
Or right-click and choose "Icon & Text" -- then your toolbars are no
Re:What GNUStep needs is... (Score:3, Insightful)
2: Take a lesson doesn't mean copy. If I wanted Aqua I'd just buy an Apple.
However a great looking GUI along with a genuinely intuitive user interface, which is API compatible with an Apple Mac is a compelling proposition. In fact I reckon it has more potential than Gnome or KDE. The ability to write a GNUStep app and then just re-build on a Mac (and viceversa) vastly increases the market for both systems.