Re: GNUstep and session management

[Gregory John Casamento]

Saso,

--- Sa¹o Kiselkov <diablos@manga.sk> wrote:

> Why bother following the _internal_workings_ of OSX? The important features,
> namely the external interface that apps see (that is, that
> -applicationShouldTerminate: gets invoked before the poweroff occurs and the
> return value correctly controls poweroff) and which users expect (correct
> behavior of the workspace when the app is controlling poweroff) is already in
> the implementation I proposed. My point is: my implementation _DOES_ follow
> the correct OSX app behavior (which in simple terms means "override
> -applicationShouldTerminate: and you can decide about poweroff with it"), but
> I  didn't bother trying to disassemble and backtrace every step OSX made
about
> how to implement the feature, and thus a _dirty_ implementation that relies
on
> bugs in OSX might (will) not work on GNUstep.

GNUstep should make it clear what does and does not constitute the GNUstep
library.  One of our problems is that we continually define the "finished"
state of GNUstep as "whatever is in the current version of Cocoa" which should
NEVER be the case.   GNUstep cannot hope to track 100% w/ Apple, it's just not
possible or pratical in some cases.
 
> Hell, why bother about following bugs or being 1000000% OSX compliant?? It
> behaves as the specification requires it to; finito. If we discuss every
> single feature a year before it finally (if at all) gets in, then no 
> wonder why GNUstep is so terribly behind schedule. Look at KDE. Look at 
> Gnome. Those projects started years after GNUstep and now are years ahead 
> of it and their enlarging their lead.

Lead?  How do you define a lead when it comes to software development, is this
a race?  Please elaborate on how they "lead", at least from the API
perspective.  I realize that they certainly lead from the application
perspective and the mindshare perspective.
 
> What I'm trying to say is: don't worry about peanuts. We have far more
> important and urgent issues which _DO_ require serious and competent 
> decisions ASAP (e.g. printing is absolutely crappy (even output to a PS 
> file yields terrible results), audio support is far from existant, and we 
> don't even have a good IDE or workspace app!).

GWorkspace.app isn't any good??????   Geez.   My usual response to such things
is that if you think it's no good, then by all means write another one which is
better.

As for IDEs, I agree that ProjectCenter is lagging behind.   

As far as Gorm is concerned, I must say that it's far and away better than any
other GUI builder out there at this point.  Glade cannot do many of the things
that Gorm is capable of (custom classes for one thing, palettes for another,
just to name a couple).  I may be a little biased here, though. ;D
 
Printing on GNUstep does currently have room for improvement, but it's being
worked on.   Audio support is there, but it's far from what it should be.

> Sorry I got so into rolling. It is nothing personal. But it's just that
> GNUstep's state has overall not improved much over the years, so it drives me
> mad with saddness...
> (Please don't flame me for that...)

Not flaming, just responding. :)

> --
> Saso

Later, GJC

Gregory John Casamento 
-- CEO/President Open Logic Corp. (A MD Corp.)
## Maintainer of Gorm (IB Equiv.) for GNUstep.