> On 27 Nov 2019, at 10:48, Johannes Brakensiek <johan...@brakensiek.info> > wrote: > > On 26 Nov 2019, at 23:43, Fred Kiefer wrote: > > That could be said about all backward-compatibility. A follow up question > is, does it hold us back enough to justify breaking compatibility? It seems > some people think yes, and others think no. We're at a stalemate, where no > progress can be expected to take place. For things to move forward, either > one side has to give in, or both sides can compromise and agree to a middle > ground. > > You described the dilemma very well. (And I also want to thank David and Ivan > to their excellent contributions to this thread.) Some people are very > conservative in this group. But others have a bit too much wishful thinking. > I myself would not mind too much loosing gcc but loosing active developers > and packagers. Sadly for some this doesn’t seem to be an argument. > > I think for those who have to do the decision (who’s that anyways, the active > contributors?) this probably will be good reason („argument“ ;)) as this is a > community of people working non-profit who seem to have strong feelings > regarding some options. > > What I want to tell (being quite new to this community and not having these > strong bindings) is there are some reasons that are mainly considered outside > of this mailing list which should be important here as well, imho. > > To name a few (just referring to what I’ve read, not meant as a personal > insult at all): > > the GNUstep project is largely considered dead > the only bigger free software project relying on GNUstep which seems to be of > greater relevance and extension is SOGo, which relies on Foundation and > GNUstep web, but not on AppKit (any of the devs active here?) > German companies that used GNUstep told me they already switched to using > Foundation and GNUsteb web only as users did not accept the AppKit interface > anymore > So, if people like the SOGo devs would say they need GCC because they are > relying on it and Foundation/GNUstep web, I’d say it would be a very > reasonable decision to keep Foundation and GNUstep web compatible to GCC. > > But if there are no bigger projects depending on a GCC AppKit it should be a > first class aim of the project to develop it to a state that others would > consider picking it up and using it for their projects - imo. Yes, that’s > investing into future and it comes at the cost and risk of not being > successful, of course. But please bear in mind that probably there are a lot > more devs (here just being a few of them trying to give them a voice) that > evaluate which platform to use for their apps and probably pass by and choose > Qt or a web based platform. > > I think that’s a pity as GNUstep AppKit could be highly attractive for Cocoa > ObjC devs wanting to port their apps to Linux and a free environment (and > maybe don’t want switch to Swift yet). If you don’t want that target audience > it’s your decision, but I’d be interested to know who’s your target audience > then? Of course you can do it just for yourself, but I think it’s unlikely > others will join then. > > Johannes >
Thats a very good summary. For me Foundation is what I use. But thats mainly because I do background server apps and tasks for Telecom Infrastructure. So I don't care about AppKit much right now. I care about a good and stable Objective-C development environment. On the other hand I would _LOVE_ to see a OS X like desktop with AppKit and I would spend time working on it. Given the other desktops under Linux have not much success because of the way they do certain things, I think there is a big need. Something like what ElementaryOS does but with GNUStep and running on the major distributions (Debian/Ubuntu/Fedora/Redhat/Centos) could change the world. This is a long shot. But we have to ask ourselfs what is our strategy for the future. Apple with Catalina is going in such a horrible direction that I'm moving away from it. My code can't run under Catalina because they have still not implemented SCTP protocol and its a mandatory for my work. And now the open source SCTP kernel driver can no longer work because they moved such stuff to userspace which kills a lot of mandatory features. So rewrite driver from scratch, just for MacOS whereas any other decent platform (Linux, FreeBSD) has it built in is an overkill. And their Wallet garden approach is breaking lots of openSource apps etc. For example you can no logner write to /. So if your open source code uses /opt/something, youe dead as you can't create /opt etc etc. (but anyway, thats a rant for another day). As far as Gnustep /App Kit goes, if the pillars below always fall apart, then its wasted time for any developer to work on it. I think the key issues is that a lot of folks wanted to try GnuStep and fail because they could not get to some degree of success quickly. Everything is "old fashioned", doesnt compile etc etc. If we get this right, we can go far. The GNUStep make system which is used is to build stuff is maybe very powerful but hinders newcomers to come and just try it out. It takes experts to understand how it works and what to do if it doesn't. The main issue is it depends on a lot of environment variables. So if you try it and it works and you log out and log in and it suddenly doesn't, newcomes will get lost very quickly. I had such experiences in the early days due to PKG_CONFIG_PATH not being set. And boy, does that drive you mad. I was many times not far away from throwing away all the make infrastructure and just build my own static library out of the .m files. (this was mainly libobjc2 issues and base). So for Gnustep / Appkit to have a future, we should have: a) a EASY to use entry. Run on any version of Ubuntu, Debian, CentOS, Redhat etc with just a simple setup. ./configure;make;make install should handle all the magic to get up and running from a tar.gz. Or much better a apt-get install gnustep. New developers are not interested to understand how gnustep works. They are interested to bring their apps to Linux and run it there. They will be busy already making their code work on another platform (which in reallity should only be very few ifdefs to work around a few calls which are not (yet) implemented. b) a good development environment. Yes Xcode would be cool but I think rebuilding something like this is a HUGE amount of work. But adopting something else instead of just a command line make would already be quite useful. I was looking at IDE's under Linux and there are many neat ones out there. But none of them really appealed to me for ObjC development. The closest one I liked was CodeLite. Others where very powerful editors (include VisualStudioCode) but not being to build and run from an IDE just declassifies it to a smart Editor. What are you using to write your ObjC code?
