Re: Windows and GnuStep

[Andy Satori]

Andrew Ruder wrote:
> On Wed, Feb 01, 2006 at 10:48:26AM -0500, Andy Satori wrote:
> > I've got a few questions and I hope they don't come across wrong.  I 
> > want to clarify something before I begin. Yes, I'm frustrated.
>
> Understandable; software can be frustrating at times.
>
> > [...] Applications which use Foundation (AKA GNUstep-Base) exclusively
> > are portable to nearly any posix compliant OS, as well as Windows
> > (using Cygwin or MingW). [...]
>
> Ok, so it says GNUstep-base is portable to windows.  I'm not sure how
> that applies to -gui (which the rest of this email is about).

But isn't that entire page in refutation of a Cocoa development book, 
and isn't the vast majority, say 99% of Cocoa development about the GUI? 
 I'm sorry, but I failed to make the intuitive leap there, shame on me 
I suppose.


> > And yet, here I am after a month of casually futzing around with various 
> > revisions of the Windows installer, and the end results of those 
> > installers and I have exactly one Application from the GnuStep 
> > Applications page built.  Of course, it wouldn't run without manually 
> > building a missing dependancy, and then manually starting a program that 
> > apparently all GnuStep GUI applications require before running (gdomap 
> > IIRC).
>
> Cool, you found some bugs?  Did you put them on bugs.gnustep.org?  As
> far as I can tell you did not.  Heck, the only other email I ever see
> from you is from November complaining about this same thing.  Correct me
> if I'm wrong...

I'm going to ask a silly question, where pray tell would I have looked 
to find a reference to bugs.gnustep.org (which until I saw this email I 
didn't know existed, I assumed that you had something somewhere, but 
hadn't gone digging for).  It's not linked or referenced in any way on 
the main gnustep.org website, having now been made aware of it's 
presence and gone looking, it's under "Develper's", which, in the realm 
of GnuStep, I, nor the casual user looking to install GnuStep to support 
an application they wish to run (GnuMail.app in my case) are not 
Developers, and it's not likely in the top 5 places we are going to 
look, Think Home Page, Applications, Download, Screenshots, maybe the 
Wiki if we are feeling particular adventurous.

> > For the record, that one app is Gorm, which candidly is only of use to 
> > build user interfaces, and is an excellent project.  ProjectBuilder, 
> > ProjectCenter, GnuMail, AddressBook all however failed, all for 
> > different reasons.
>
> Gorm is a pretty awesome app :).  While -gui works on Windows, any
> application which ventures outside of the OpenStep/GNUstep API would
> automatically lose any portability unless the developer of said
> application took care to keep portability in mind.  Once again, I'm not
> sure how this is in any way about -gui.

After another person took a quick look at things, and got me pointed in 
the right direction, I spent last night trying to get a couple of these 
built, taking off my 'User' hat and putting on my 'Geek' hat, I don't 
generally take my Windows laptop home at night, preferring to work on 
the platform I prefer, OS X, writing OSS software there.

After several hours of tweaking, configuring and further hacking...

Project Center won't build because it makes poor assumptions about 
symlinks and filesystem abilities in it's build process. GnuMail can't 
build because AddressBook can't build, because it's apparently never 
been built on Windows to resolve linking order issues and needs some 
platform specific ifdef's to get around type declaration issue with 
u_int and uint, even built, it doesn't in fact work.  I duplicated the 
results of another user, where I get menu's but no windows.

Since you seem to have a clue about some of these issues, I decided to 
give your own efforts, TalkSoup a quick run.  I've used it on Linux, and 
found it to be an excellent IRC tool.  So, I downloaded NetClasses. 
Guess what, it doesn't use -gui, never got to the GUI part.  It doesn't 
build either (results pasted at the end of this message), no I didn't 
try to debug it the build yet.

It does help explain my point.  No user that is used to the 
./configure;make;make install; world of most OSS apps, even on Windows 
is going to get far.  As a rule, one app that doesn't work, ok.  But 
when one out of many succeeds, while the rest consistantly fail?  You 
aren't going to retain many casual users.

> What? You listen to people on IRC? ;) Just kidding... 

Not to be offensive, but I find that IRC is a much easier method of 
communication.  Email tends to come across entirely too abrupt or direct 
 and frequently generates more anger than results.  I don't really like 
using email for anything that could be construed as negative or taken 
wrong for that very reason, that's why you generally only see me use 
this email when I hit my limits, I will pursue other avenues if they are 
available.  For example, this very conversation has apparently come 
across as an attack upon GnuSTep and OSS, when in fact, I'm seriously 
trying to understand assertion that GnuStep is anything more than a 
partially implemented version of the OpenStep spec that more or less 
works on Linux and Unix like systems.  MY point was that despite what 
has been represented to myself and others in other venues, Windows is 
_not_ an equal peer at this time, and it should not be represented as 
such on the gnustep.org website, nor by it's proponents.

> > "There are tested and released tar/gz packages of all GNUstep source at 
> > ftp://ftp.gnustep.org/pub. It is also important to point out here that 
> > getting source from CVS is not advisable for the average user. Quite 
> > often there are issues with CVS versions of projects (in general, not 
> > just with GNUstep) since they are in development. There might be some 
> > experimental code or some code which might not work at all, again this 
> > is true with all projects, not just GNUstep. In general it is 
> > recommended that end users make use of the packages provided on the ftp 
> > site, which are considered to be official releases. These are generally 
> > better tested and more stable than what might be in CVS at any given 
> > point in time."
>
> Do you really think the official stance could possibly be to use CVS?
> In general, it is nearly impossible to suggest CVS as an advisable
> option because at any given time the CVS could be horribly broken.  If
> people on IRC suggested CVS (which I'm sure they did) it was probably
> only due to the fact that they were using CVS and could assert that it
> was in a buildable/usable condition at that *particular* time.

I would agree, however, this doesn't change the core issue.  If neither 
the 'snapshot' nor the 'CVS' trunks contain stable, usable code, then 
it's hard to expect users to be able to draw conclusions different from 
the one that is being so eloquently refuted.

> > So which advice should a user or potential user follow?  I shall not 
> > point out that Item 7 on that same page then goes on to explain that 
> > older versions from CVS were the issue.  When the current "stable" 
> > version don't build, and the CVS tree is the only potentially viable 
> > option, and when those build, but don't actually work, what conclusions 
> > do you really expect?.
>
> bugs.gnustep.org bugs.gnustep.org bugs.gnustep.org?  If you had build
> problems on the stable release, there would undoubtedly have been
> someone that could have helped you.  

Unfortunately, as I mentioned above.  At that point, I wasn't in 
'Developer' land, I was just a user, installing a binary base and then 
trying to install a couple of applications.  At at the time I was 
testing the viability of existing applications.

> > Now, all of this said, I will grant that things are better, under
> > Linux.  I did get more things built on the Suse 9 box, though, that
> > was Ok gentlemen, without icons in most applications, and having to
> > make some other manual modifications to the system to get GnuStep apps
> > to properly register themselves.
>
> I have used GNUstep on several distros without these problems.  But once
> again, bugs.gnustep.org, only a quick surf away...

If you know about it.  It wasn't mentioned in the brochure.

> > In short, I simply do not see how GnuStep, in it's current state, is 
> > usable for anyone but the most hard core, die hard users.
>
> As pointed out above, GNUstep *is* used in commercial applications
> successfully.
>
> > Windows users are deemed to be clueless gits that aren't worth the time 
> > nor effort.
>
> Wrong.  Here's why open source developers don't support windows: no
> open source developers use it.  Now, that is a rather broad statement,
> but I'm pretty sure that most of the Windows work on GNUstep is done by
> people who would otherwise be using a unix-like environment.  So until
> these supposed "windows developers" start showing up and submitting bugs
> and fixing things, things will continue plodding along at there
> continuous but somewhat slow pace towards things working.

In case you didn't catch the inferencs above.  If it wasn't for work 
related issues, _I_ wouldn't be using Windows either.  I'm a Mac user by 
preference, and Linux by preference over Windows,  I'd even go back to 
OS/2 by preference over Windows.  Unfortunately those aren't options, 
and thus I looked to GnuStep to bring some comfort level, particularly 
as I have been led to believe by GnuStep supporters to believe that it 
was viable (particularly a couple that really want Geoff and I to port 
our Cocoa# / ObjectiveC to Mono bridge to GnuStep, which was the 
secondary reason for this adventure).

> Why should *we* convince *your company* that GNUstep isn't a dead end.
> Believe it or not, nobody (as far as I know) is making money directly
> off of working on GNUstep (some are indirectly, I know).  Believe it or
> not, people have to put all this code together; it doesn't just pop out
> of thin air.  We all have jobs, we all have other things to do, we all
> have other interests, and while I do not directly contribute to GNUstep
> most of the time, I understand all of this.  If something is broke,
> submit a bug, fix it yourself, or continue waiting for it to be fixed,
> but ranting and complaining isn't going to get you anywhere.

This wasn't intended as a rant, nor a complaint, it was always intended 
as questions to get opinions about what the communities thoughts on the 
status of the Windows implementation where, and to confirm that my 
experiences with GnuStep are more or less the norm, or if I'm doing 
something blatantly wrong. I apologize if it came across wrong, that was 
never the desire.

> I swear, half the world thinks that open source software grows on a tree
> somewhere in East Africa.

Now before you go there, let me give you my background:

I've been programming professionally for 15 years.
I've been maintaining a MUD based upon OSS drivers for 10 of those 
years, I've ported it to 3 hardware platforms and 4 operating systems 
(OS/2, BeOS, Windows and now Mac OS X).
I've been maintaining a Windows port of TinyFugue since 1995.
I'm the sole contributor the the PostgreSQL for Mac project.
I'm 1/3 of the group that got Mono for the Mac off the ground (as much 
of that work was arguing with Lupus and Miguel to get things fixed as it 
was in code contributions)
I'm one of the people working to make Cocoa# and the C# to ObjectiveC 
bridge work.

Needless to say I know all about where OSS comes from, It comes from 
scratching an itch.  I also know that unsuccessful OSS projects have no 
guidance or plan.  Successful one's do.  Sometimes, it takes someone 
saying things that others don't want to hear.  Think about where X would 
be if Havoc Pennington didn't say the things he did.

In short, the whole issue is that right now, the website is portraying 
that the status of GnuStep is one thing.  Even your own opinion is one 
that raises questions, being as NetClasses doesn't appear to use -gui in 
any way, and yet it suffers the same problems as the other failed builds.

The question is, how should that be fixed?  should the website be 
adjusted?  should there be a concentrated effort to fix the Windows 
port? ( I can set up a Windows box that could be used a test mule for 
the GS devs ). These are not accusations, they are questions.  I am an 
OSS dev and user, I have too many projects on my plate as it is, I 
cannot personally extend myself into yet another OSS project much beyond 
contributing a box.

Perhaps you understand a little better now, perhaps not.  Either way, I 
tried.


> Just as frustrated,
> Andy

NetClasses-1.05 make output:

Making all in Source...
make[1]: Entering directory `/home/arsatori/netclasses-1.05/Source'
Making build-headers for framework netclasses...
 Creating netclasses.framework/Headers...
 Creating derived_src...
 Creating netclasses.framework/Resources...
Making all for framework netclasses...
 Compiling file NetBase.m ...
NetBase.m: In function `-[NetApplication 
receivedEvent:type:extra:forMode:]':
NetBase.m:320: error: `ET_RDESC' undeclared (first use in this function)
NetBase.m:320: error: (Each undeclared identifier is reported only once
NetBase.m:320: error: for each function it appears in.)
NetBase.m:330: error: `ET_WDESC' undeclared (first use in this function)
NetBase.m:338: error: `ET_EDESC' undeclared (first use in this function)
NetBase.m: In function `-[NetApplication connectObject:]':
NetBase.m:390: error: `ET_EDESC' undeclared (first use in this function)
NetBase.m:393: error: `ET_RDESC' undeclared (first use in this function)
NetBase.m: In function `-[NetApplication disconnectObject:]':
NetBase.m:416: error: `ET_WDESC' undeclared (first use in this function)
NetBase.m:423: error: `ET_RDESC' undeclared (first use in this function)
NetBase.m:426: error: `ET_EDESC' undeclared (first use in this function)
NetBase.m: In function `-[NetApplication transportNeedsToWrite:]':
NetBase.m:462: error: `ET_WDESC' undeclared (first use in this function)
make[2]: *** [shared_obj/NetBase.o] Error 1
make[1]: *** [netclasses.all.framework.variables] Error 2
make[1]: Leaving directory `/home/arsatori/netclasses-1.05/Source'
make: *** [internal-all] Error 2