GNUstep vs. The Cocotron for Mac to Windows porting
I am a Mac developer and in the past I successfully used The Cocotron to port, build and distribute one of my bigger GUI application projects for Windows. This one is feature complete now, and I am now looking forward to port one of my next big projects to Windows. I am considering to use GNUstep for this, however, I got some questions: 1. Look & Feel I want my applications look & feel native on Windows, and I am demanding on that. I read, that the WinUXTheme is still under development, and my question is now what exactly does this mean. Do most of the GUI elements work and look nice? Or, perhaps, do only the buttons look nice and the other stuff looks and feels somehow? What is missing? Does it crash any now and then? For my other application, I submitted some contributions to The Cocotron in order to letting it behave and look good on Windows. 2. Interface Builder compatibility Can I use my .xib-files (Deployment target OS X 10.6) without any changes for building Windows applications? With The Cocotron I can. 3. Shared Code Base My other GUI application got apprx. 25000 lines of custom Objective-C and C code, and it is a shared code base for both platforms Mac OS X and Windows. With a little bit of coding discipline, I was able to keep the number of platform specific #ifdef segments low (perhaps 5 small snippets). Can I expect the same with GNUstep for my still to be ported application (apprx. 5 lines, other purpose, same coding style). 4. PDF readiness My application requires reading and flawless display of PDF files, as well as generation of PDF files from its view contents, some of which may become really huge. Does this work with GNUstep on Windows? 5. RTF views and editing Does GNUstep provide complete RTF compatibility, editing and display. Here The Cocotron is lacking, and the application to be ported to Windows does rely heavily on perfect RTF text formatting capabilities. So actually, my concerns may be rephrased to, whether it would be more work for me to implement the missing RTF capabilities into The Cocotron, compared to implement something into GNUstep if not to work around any other shortcomings in GNUstep. 6. License question I read that it is best to ship my application with the GNUstep frameworks in separate .dll files, so end users may replace the frameworks by their customized ones. Is this correct? In addition, I must not prohibit reverse engineering of my application interface to GNUstep. As a matter of fact, my EULA's do not mention anything about reverse engineering, would this be OK, or do I need to positively permit reverse engineering? If I need to change something within GNUstep, then my intention is to commit my changes upstream, and ideally the GNUstep frameworks shipped with my application would be based on the upstream code at the given point in time. This is how, I handled it with The Cocotron. May I expect the same with GNUstep? Do I need to provide the sources in a separate place anyway, or may I simply add a link to the GNUstep SVN repository on a prominent place (e.g. the About panel) of my application? Anything else to obey with? Many thanks for any kind replies. Best regards Dr. Rolf Jansen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep vs. The Cocotron for Mac to Windows porting
Hi Rolf, Dr. Rolf Jansen wrote: I am a Mac developer and in the past I successfully used The Cocotron to port, build and distribute one of my bigger GUI application projects for Windows. This one is feature complete now, and I am now looking forward to port one of my next big projects to Windows. I am considering to use GNUstep for this, however, I got some questions: I do maintain and use a couple of applications under Windows, but only with GNUstep, so I don't know how things compare with Cocotron. 1. Look & Feel I want my applications look & feel native on Windows, and I am demanding on that. I read, that the WinUXTheme is still under development, and my question is now what exactly does this mean. Do most of the GUI elements work and look nice? Or, perhaps, do only the buttons look nice and the other stuff looks and feels somehow? What is missing? Does it crash any now and then? For my other application, I submitted some contributions to The Cocotron in order to letting it behave and look good on Windows. Most elements display well and directly with WinUX, meaning that they theme and blend in WinXP, Win7, Win8 and even Win10. Tested and proven with all of them. Buttons scrollbar and native file dialogs do work (with limitations). There is extra-code that needs soem setup for which I have not released a guide yet, but I will do soon. Caveats? yes, there are. Popupbuttons do not work well for me they have a coupe of issues, the most annoying is that in certain conditions (that is, certain Popupbuttons) do not update in display (but do work) in the first usage. Other, within the same app, do work. There are issues with multi-monitor setup where monitors have different sizes too. You will have issues with document based applications if you don't have empty docs, this is not a problem of the theme itself. I am not aware of other things, but it depends on what your application uses. Look here: http://multixden.blogspot.it/2014/09/improvements-in-gnusteps-native-window.html 3. Shared Code Base My other GUI application got apprx. 25000 lines of custom Objective-C and C code, and it is a shared code base for both platforms Mac OS X and Windows. With a little bit of coding discipline, I was able to keep the number of platform specific #ifdef segments low (perhaps 5 small snippets). Can I expect the same with GNUstep for my still to be ported application (apprx. 5 lines, other purpose, same coding style). I don't know The Cocotron, but I would expect something similar, just perhaps different. In my case, I have one application ported with no changes at all, the other one has changes because networking is different on windows. Other apps might require ifdefs to tweak UI elements. 4. PDF readiness My application requires reading and flawless display of PDF files, as well as generation of PDF files from its view contents, some of which may become really huge. Does this work with GNUstep on Windows? I would say no, I am not aware of native PDF handling on windows. Do you know what The Cocotron uses? On GNUstep you have two kits: PDFKit and PopplerKit which rely on xpdf and poppler libraries. Or you can GSPdf's approach to work with ghostscript. I got none of the above working on windows yet, not because of the GNUstep code, but because of the dependend library/application. I did not try since a long time though, things might have gotten better upstream. 5. RTF views and editing Does GNUstep provide complete RTF compatibility, editing and display. Here The Cocotron is lacking, and the application to be ported to Windows does rely heavily on perfect RTF text formatting capabilities. So actually, my concerns may be rephrased to, whether it would be more work for me to implement the missing RTF capabilities into The Cocotron, compared to implement something into GNUstep if not to work around any other shortcomings in GNUstep. Our RTF support is quite good. We use it internally and it improved a lot in the past years thanks to Fred's invaluable work. Since SimpleWebKit essentially transforms HTML into RichText, support for attributes, images and other details made big strides, I seriously doubt The Cocotron has such quality. I did interchange files with WordPad quite well and did try basic RTF features in read/write from and to Windows apps. We do write RTF files that are usually read quite well, however the RTF produced by latest Word might be problematic, because specs are not clear and MS changed stuff, it is no longer a 1:1 match of the corresponding Word format. The best would be to test some example and use Ink to show them. If I need to change something within GNUstep, then my intention is to commit my changes upstream, and ideally the GNUstep frameworks shipped with my application would be based on the upstream code at the given point in time. This is how, I handled it with The Cocotron. May I expect
Re: GNUstep vs. The Cocotron for Mac to Windows porting
> Am 13.12.2015 um 19:59 schrieb Riccardo Mottola <riccardo.mott...@libero.it > <mailto:riccardo.mott...@libero.it>>: > > Rolf wrote: >> Ricardo wrote: >>> Rolf wrote: >>> >>>> 4. PDF readiness >>>> >>>> My application requires reading and flawless display of PDF files, as well >>>> as generation of PDF files from its view contents, some of which may >>>> become really huge. Does this work with GNUstep on Windows? >>> >>> I would say no, I am not aware of native PDF handling on windows. Do you >>> know what The Cocotron uses? >> >> Cocotron does the whole PDF handling (parsing, reading, writing) by itself, >> using its Quartz2D replacement named Onyx2D. Recently I committed a minor >> fix to the PDF generator. > > Interesting, is this in-house of cocotron or does it has an external library? Onyx2D works completely without external libraries, even the rasterizer is internal code. The internal rasterizer is somewhat slow (a little faster than pixman+cairo) but way slower that Quarz2D, so people who need speed can include the AntiGrain rasterizer as an external library, however, Cocotron works well without any external dependency — it is completely self-contained. > We support most PS functions instead Well, the way from PS to PDF is not that stony, having some hope now. >>> On GNUstep you have two kits: PDFKit and PopplerKit which rely on xpdf and >>> poppler libraries. Or you can GSPdf's approach to work with ghostscript. >>> I got none of the above working on windows yet, not because of the GNUstep >>> code, but because of the dependend library/application. >> >> Well, this sounds not that promising. I have to evaluate this. One option >> might be to switch from a PDF to a SVG workflow. Recently, I wrote a SVG >> generator for a non GUI server application. SVG is less complex than PDF, >> and I guess that I will be able to implement a simple parser and writer in >> my application. > > Actually, perhaps those libraries can be ported. I will try one of these days. > PDFKit needs some revamping, but my efforts to update it to current xpdf were > unsuccessful, apparently they removed some functionality it relied on. > If PDFKit suits you, maybe it is worth improving it as well as corresponding > GS support. Maybe you can try on Linux first. Certainly, I will evaluate the options. I need PDF import for directly displaying it in some views of my application and PDF export of the document view for file exchange with third parties, I don't need PDF manipulation. >>>> Does GNUstep provide complete RTF compatibility, editing and display. … >>> >>> Our RTF support is quite good. … >> >> The formatted text is kept within my application. Interoperation of >> formatted text with other applications is not necessary. > > Formatted text inside your application should really work quite well! That > is, AttributedStrings are quite capable. To exchange stuff between apps I > would rely on that. You can copy a piece of a web page from Vespucci to Ink > and it is quite good. OK, this sounds promising. > Is cocotron mantained actually? Yes, it lost a little bit of inertia over the years, however, definitely yes. > We actually always suspected and even have the proof that they copied stuff > from GNUstep circumventing the license. Well, I recently saw on the list that GNUstep people have a habit to suspect this about other projects, in that case somebody suspected that Microsofts WinObjC might be a stolen clone of GNUstep. When reading this, I browsed the code in the GitHub repository, and at that time I found no indication that they took code from other projects, neither from GNUstep nor from The Cocotron. The Cocotron received many small code contributions from many developers over the years. I cannot speak for everybody, however, I am sure that Christopher Loyd (who is the initiator and maintainer of The Cocotron) would cut off his right hand before he would steal code from other projects. I also contributed some pieces to The Cocotron, and I took nothing from GNUstep. After all the whole repository is online, and you may want to search for yourself for unauthorized copies: https://github.com/cjwl/cocotron <https://github.com/cjwl/cocotron> Best regards Rolf ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: GNUstep vs. The Cocotron for Mac to Windows porting
Hello Ricardo! > Am 13.12.2015 um 17:26 schrieb Riccardo Mottola <riccardo.mott...@libero.it > <mailto:riccardo.mott...@libero.it>>: > > Hi Rolf, > > Dr. Rolf Jansen wrote: >> I am a Mac developer and in the past I successfully used The Cocotron to >> port, build and distribute one of my bigger GUI application projects for >> Windows. This one is feature complete now, and I am now looking forward to >> port one of my next big projects to Windows. I am considering to use GNUstep >> for this, however, I got some questions: > > I do maintain and use a couple of applications under Windows, but only with > GNUstep, so I don't know how things compare with Cocotron. > >> 1. Look & Feel >> >> I want my applications look & feel native on Windows, and I am demanding on >> that. I read, that the WinUXTheme is still under development, and my >> question is now what exactly does this mean. Do most of the GUI elements >> work and look nice? Or, perhaps, do only the buttons look nice and the other >> stuff looks and feels somehow? What is missing? Does it crash any now and >> then? For my other application, I submitted some contributions to The >> Cocotron in order to letting it behave and look good on Windows. > > Most elements display well and directly with WinUX, meaning that they theme > and blend in WinXP, Win7, Win8 and even Win10. Tested and proven with all of > them. Buttons scrollbar and native file dialogs do work (with limitations). > There is extra-code that needs soem setup for which I have not released a > guide yet, but I will do soon. OK, I will keep this in mind in case I run into issues with file dialogs. I use only the plain dialogs without any customizations, so perhaps I won't experience much problems. > Caveats? yes, there are. > Popupbuttons do not work well for me they have a coupe of issues, the most > annoying is that in certain conditions (that is, certain Popupbuttons) do not > update in display (but do work) in the first usage. Other, within the same > app, do work. On Cocotron, I recently fixed the behaviour of Combo Buttons, PopUp Buttons worked and work fine though. > There are issues with multi-monitor setup where monitors have different sizes > too. This is a known issue for pure Mac applications as well. Users expect window positions with respect to the top, while Cocoa usually measures everything in cartesian coordinates (origin at the bottom), so if the screen height changes, then windows seem to be displaced with respect to users expectations, although, the positions are correct with respect to cartesian coordinates. Note, I am a scientist, and as such, I am a big fan of cartesian coordinates, i.e. I happily live with it and I do not fight against it. My applications come with small code snippets that do the correct coordinate conversions on opening/closing windows. I wouldn't touch the frameworks for handling this, because from their point of view, the measurements are correct. > You will have issues with document based applications if you don't have empty > docs, this is not a problem of the theme itself. I know, Windows will close applications without windows, because it does not know where to place the menu bar ;-) > I am not aware of other things, but it depends on what your application uses. > > Look here: > > http://multixden.blogspot.it/2014/09/improvements-in-gnusteps-native-window.html > > <http://multixden.blogspot.it/2014/09/improvements-in-gnusteps-native-window.html> Sounds promising to me. >> 3. Shared Code Base >> >> My other GUI application got apprx. 25000 lines of custom Objective-C and C >> code, and it is a shared code base for both platforms Mac OS X and Windows. >> With a little bit of coding discipline, I was able to keep the number of >> platform specific #ifdef segments low (perhaps 5 small snippets). Can I >> expect the same with GNUstep for my still to be ported application (apprx. >> 5 lines, other purpose, same coding style). > > I don't know The Cocotron, but I would expect something similar, just perhaps > different. In my case, I have one application ported with no changes at all, > the other one has changes because networking is different on windows. Other > apps might require ifdefs to tweak UI elements. Yeah, I guess, this won't be a major issue. >> 4. PDF readiness >> >> My application requires reading and flawless display of PDF files, as well >> as generation of PDF files from its view contents, some of which may become >> really huge. Does this work with GNUstep on Windows? > > I would say no, I am not aware of native PDF handling on windows. Do you know > what
Fwd: Cocotron patch for OpenBSD
This might interest some people. Without looking into the details, I guess he means the Foundation is ported to OpenBSD. Yen-Ju -- Forwarded message -- From: Vladimir Pouzanov farcal...@gmail.com Date: Sun, Apr 19, 2009 at 12:42 AM Subject: Cocotron patch for OpenBSD To: cocotron-...@googlegroups.com Hi all, I'm happy to announce that cocotron has been successfully ported to OpenBSD (also might work on other *BSD, I'll check FreeBSD status next week). The patch is here: http://code.google.com/p/cocotron/issues/detail?id=275 Building native BSD cocotron is done mostly in same way as with native Linux: http://fow.farcaller.net/trac/wiki/Build_GCC http://fow.farcaller.net/trac/wiki/Build_Cocotron BSD patch credit goes to Vladimir Kirillov pro...@hackndev.com. -- Sincerely, Vladimir Farcaller Pouzanov --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Cocotron Developers group. To post to this group, send email to cocotron-...@googlegroups.com To unsubscribe from this group, send email to cocotron-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/cocotron-dev?hl=en -~--~~~~--~~--~--~--- -- Yen-Ju Chen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Am 02.11.2008 um 23:58 schrieb Fred Kiefer: Doing a configure for cross compilation is bound to fail Why? My gcc experience is a bit dated, but in the Mac OS X 10.0 days, gcc could configure for cross-targets almost fine already. What you need is a copy of the foreign (MinGW-)environment, of course. The difficult part is to distinguish between binaries meant to run in the build process (helper tools) and binaries meant to run on the other architecture. But gcc's configure has mechanisms to deal with this in place, even if they might be somewhat buggy (rarely tested). I can't see a reason why GNUstep's configure couldn't do this as well. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 3 Nov., 10:43, Fred Kiefer [EMAIL PROTECTED] wrote: Markus Hitter wrote: Am 02.11.2008 um 23:58 schrieb Fred Kiefer: Doing a configure for cross compilation is bound to fail Why? My gcc experience is a bit dated, but in the Mac OS X 10.0 days, gcc could configure for cross-targets almost fine already. What you need is a copy of the foreign (MinGW-)environment, of course. The difficult part is to distinguish between binaries meant to run in the build process (helper tools) and binaries meant to run on the other architecture. But gcc's configure has mechanisms to deal with this in place, even if they might be somewhat buggy (rarely tested). I can't see a reason why GNUstep's configure couldn't do this as well. The big difference between gcc and GNUstep is that the former doesn't rely heavily on external libraries. So configuring gcc itself for cross compilation isn't that hard. For GNUstep we need to know a lot more about the environment is is compiled in. I would say there are cases which will work and others that wont. We use configure to find out about installed libraries and headers, this might work, but we also try to find out whether some functions are actually provided by those libraries and working. To do so configure needs to build and run short code fragments and the later part just wont work. What is possible is to provide the correct values as configure command line arguments, but then already providing the full config.h file for Windows might be easier. On the other hand, my experience with cross compilation is a bit dated as well and they may be better way to do this now. Fred I am not experienced with Cross-Compiling for Windows but the mySTEP projects has provided a lot of insights about cross-compiling GNUstep on MacOS X. 1. installing a working gcc on OS X isn't simple. Especially if you want to have the linux and glibc headers. The reason is that they have so many assumptions about the underlying system where OS X and Linux differ. It starts with the correct gmake (instead of make) and goes through ./configure packages that check the version of the host gcc, ld, as - where Apple provides version numbers that are outdated from the view of the package. So you need some wrappers that provide faked version numbers. So, simply getting e.g. the glibc headers and doing a ./configure; make install-headers fails. 2. as Fred points out, cross-compiling needs a set of runtime libraries and header files for the target architecture. But we need a copy on the host system. So the SDK must include a full set of Linux, libjpeg, libfftype, libX11 etc. includes and libs compatible to the target machine 3. Fred mentiones some tools that are run at compile-time. These need to run natively on OS X. 4. a Plugin for Xcode is simple. I just have a makefile that processes some environment variables. So I just add a new Shell Script Build Phase to some project target and define the variables and finally call make. 5. There can be archtecure dependent parts in the objc runtime or in some foundation classes (the ARM processor e.g. uses a Mixed-Endian format for double floats. So, swapping Network to Host byte order for external communication needs additional code). But these are quite rare and are easily handled by #ifdef. So in my experience, getting the cross-compilation environment is the complex part. And I still have not solved it for ARM-EABI which is the reason why there is no QuantumSTEP for the Openmoko Freerunner yet (David, I know you are waiting). BR, Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Nicola Pero wrote: Anyway, you have good points that cross-compiling from Xcode might be appealing to some people. :-) It wouldn't be difficult to set up a similar thing for cross-compiling from Apple to Windows using GNUstep. You need to get a MinGW cross-compilation environment running on your Apple, then get the GNUstep libraries in it. Then tell Xcode to use the cross-compilation compiler. :-) I just tried the cross compilation package from Cocotron and it works rather nicely. They provide a script that downloads gcc and binutils plus a few libraries, patches them and compiles them for cross compilation. All that is rather easy on the Mac as you already have a fully functional Unix environment to start with. All I had to do is change the version number of the mpf library as the one they are referencing is no longer available. It would be worhtwhile for somebody with deeper gcc and binutility knowledge to take a look at those patches and see what would be suitable for integration in the standard version. This framework also installs cross compilation target for Xcode and there documentation include a description of build settings that need to be manually adjusted. I failed with that on a very simple test application, but most likely my missing Xcode skills are to blame for that. The Cocotron code itself was really simple to cross compile as everything needed for that was delivered. (This was pretty fast, but then Cocotron is still a lot less code then GNUstep and my Apple laptop is also pretty fast compared to my Linux machine) I am not sure whether that patched gcc and ld would work for GNUstep or if it would be better to use unchanged versions of these programs to cross compile GNUstep. What we definitely need is somebody with Xcode experience to come up with working build settings. For GNUstep cross compilation we will need not only suitable XCode project files, but also pre-prepared config.h files for a MS Windows environment. Doing a configure for cross compilation is bound to fail :-( I keep you posted on my further progress, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Obviously, most people arguing here against Cocotron never tried to play with it... I did during some months, as well as I played with GNUstep on OSX some years ago. One of the points no one talked about is the easiness with which you can distribute a Windows app built with Cocotron: you zip the .app folder, copy and unzip it on another Windows machine and here you are: no need to install anything else: no library, no service, no registry modification! Maybe I'm wrong, as I haven't worked with GNUstep since years, but IIRC for a GNUstep app to work on Windows, you need to install several DLLs and their related resource files, and need to install some services (for DO, etc.). With Cocotron, your app is self- contained, like Mac apps. There is a minor drawback, of course: the Cocotron frameworks (Foundation AppKit) are copied in the .app folder, thus making your binary a little bigger than expected, but this is really a very minor drawback nowadays. And there's no DO, but how many apps do need it? About development, some people seem concerned about the need to compile every time for Windows AND Mac, thus slowing down development. It's not true: you build only the target you want to: Windows OR Mac. You get two separate .app folders. For debugging the Windows target, you can even remote-debug it through Xcode: you install the Windows app on the Windows computer/VM, then start debug it from within Xcode. I admit that in its current state, this solution is not yet satisfying, as the custom gdb is still in experimental state, but as you would say to defend GNUstep: it's just a matter of modifying some C code, just a matter of time ;-) I agree that GNUstep maturity is better that Cocotron, but the Cocotron experience on Windows is much better than what you want to agree with; it should help you to make GNUstep better on Windows, not only in term of API, but also in term of user experience. Cheers, Stéphane ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
One of the points no one talked about is the easiness with which you can distribute a Windows app built with Cocotron: you zip the .app folder, copy and unzip it on another Windows machine and here you are: no need to install anything else: no library, no service, no registry modification! Maybe I'm wrong, as I haven't worked with GNUstep since years, but IIRC for a GNUstep app to work on Windows, you need to install several DLLs and their related resource files, and need to install some services (for DO, etc.). With Cocotron, your app is self-contained, like Mac apps. OK - good point [PS: you can do all that (self-contained Windows app) with GNUstep as well. We worked on it a lot last year. :-) But it's not as streamlined as in Cocotron - yet -, I suppose] I agree that GNUstep maturity is better that Cocotron, but the Cocotron experience on Windows is much better than what you want to agree with; it should help you to make GNUstep better on Windows, not only in term of API, but also in term of user experience. :-) That's a useful suggestion. Btw, sorry for being a bit pushy on the Cocotron guys/project (good luck guys!), it just felt like nobody had even mentioned or considered all the work and effort that we (GNUstep) put into the Windows port in the last few years. ;-) There's a lot you can do with GNUstep on Windows now. A massive lot. Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 31 Oct 2008, at 15:48, Stéphane Corthésy wrote: Obviously, most people arguing here against Cocotron never tried to play with it... I did during some months, as well as I played with GNUstep on OSX some years ago. One of the points no one talked about is the easiness with which you can distribute a Windows app built with Cocotron: you zip the .app folder, copy and unzip it on another Windows machine and here you are: no need to install anything else: no library, no service, no registry modification! Maybe I'm wrong, as I haven't worked with GNUstep since years, but IIRC for a GNUstep app to work on Windows, you need to install several DLLs and their related resource files, and need to install some services (for DO, etc.). With Cocotron, your app is self-contained, like Mac apps. There is a minor drawback, of course: the Cocotron frameworks (Foundation AppKit) are copied in the .app folder, thus making your binary a little bigger than expected, but this is really a very minor drawback nowadays. And there's no DO, but how many apps do need it? GNUstep was changed a few years ago so that you can configure it to have the whole system inside the app folder, and it gets configured that way by default on windows. So you *can* quite easily distribute standalone apps as simple sip archives of the .app folder. Where Cocotron is easier (presumably) is that it puts everything inside the app folder by default, wheras with GNUstep you have to write a couple of lines in your makefile to copy the core stuff into the app folder if you want a standalone app. Probably it would be a good extension for GNUstep-make (assuming Nicola hasn't done it already) to have it do the copy automatically on windows (or have another target such as 'standalone') to build standalone apps. About development, some people seem concerned about the need to compile every time for Windows AND Mac, thus slowing down development. It's not true: you build only the target you want to: Windows OR Mac. You get two separate .app folders. For debugging the Windows target, you can even remote-debug it through Xcode: you install the Windows app on the Windows computer/ VM, then start debug it from within Xcode. I admit that in its current state, this solution is not yet satisfying, as the custom gdb is still in experimental state, but as you would say to defend GNUstep: it's just a matter of modifying some C code, just a matter of time ;-) That sounds good ... I really think it would be nice if someone took the Cocotron XCode environment and adapted it to build GNUstep apps. That would combine the familiarity/ease-of-use for XCode developers from Cocotron with the more complete/robust API/implementaion provided by GNUstep. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 30 Okt., 15:44, Markus Hitter wrote: Am 29.10.2008 um 19:30 schrieb Krishna: How is debugging done? You rarely have to run a debugger natively. Most errors are in the logic of an app, which is (should be) the same on both sides. Debugging is done remotely from Xcode. http://groups.google.com/group/cocotron-dev/browse_thread/thread/1380da1eb8746863# http://cocotron-dev.googlegroups.com/web/xcxdb.png ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Am 29.10.2008 um 19:30 schrieb Krishna: While Xcode integration can be a big plus, having to cross-compile everytime can be painful, no? No. :-) You'll only notice by the doubled compile time, i.e. 2 seconds instead of 1 for typical small changes. Mac developers do this all day already, as it's currently standard to build for Intel 32-bit and PPC, or 32-bit and 64-bit, or all three (resulting in a single universal binary). There's a switch to build native-only, of course. How is debugging done? You rarely have to run a debugger natively. Most errors are in the logic of an app, which is (should be) the same on both sides. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
There's no reason any company porting to Windows should ever choose Cocotron over us. We're more complete. If we had the ability to integrate with Xcode, as Cocotron does If I were a developer developing a Cocoa application on Xcode, and wanting to port it to Windows and/or GNU/Linux/Solaris/*BSD, I don't think I would cross-compile. ;-) I would rather: 1. install a virtual machine software in my Apple. One of those were you can run another OS in a window and can easily pass files from the Apple to the other OS via shared folders etc 2. install Windows (and/or GNU/Linux/Solaris/*BSD/...) in the virtual machine 3. install GNUstep in the virtual machine. For Windows, that just means running an installer. 4. add a GNUmakefile to your Xcode project ... no big deal since you just need to list all of your source code files in the GNUmakefile and you're done 5. copy the source code to the virtual machine via a shared folder or stuff like that 6. move to the virtual machine and type 'make' 7. watch your Objective-C Cocoa code being compiled into native Windows/GNU/Linux/Solaris/BSD/whatever code 8. run immediately the native Windows/GNU/... program on the actual OS you're porting to and see how it works 9. if something's not really looking that good, go back to Xcode, make your changes ... 10. copy the code to the virtual machine, type 'make' again and try again I suppose someone good with Xcode and VMs would probably be able to automate step 10. so that you only need to click a button in Xcode to have the code copied to the VM and recompiled ... and even the program started in the VM I guess (build-and-go) ? :-) I mean, even if you cross-compile, is anyone really going to be developing a Windows application without trying it on Windows ? Obviously you'd install a virtual machine with Windows in it to test your application on Windows. There are so many things to try out - eg, just file names or file paths or how the thing start or how it looks or what it does. But then why cross-compiling at all ? You can just compile in your Windows virtual machine using GNUstep. :-) Advantages over Cocootron's cross-compiling solution: 1. real cross-platform portability. If you're porting to other platforms, why stop to Windows only! Once your code works with GNUstep, GNUstep allows you to run your software on Windows, but also on all Unix OSes such as GNU/Linux (any Linux distribution you want!), Solaris, OpenBSD, etc. :-) 2. you easily can run your native code in a native debugger. You may never need it, but the time you really need it because your Windows port is segfaulting in some weird way, being able to use a debugger is a huge bonus ;-) 3. no cross-compilation is involved; meaning that a big chunk of complications in the linking steps is removed. Linking DLLs on Windows is hard enough if you do it natively on the Windows box itself; you probably don't need the additional complication of cross- compilation. The reduced complexity means if you get in trouble with the DLLs you're more likely to be able to solve the problem. :-) 4. GNUstep is lot more complete in terms of API. A much larger subset of the Cocoa API is available. You don't have to spend time reimplementing APIs that already exist in GNUstep. :-) 5. Massive support - GNUstep is a big project with a large number of people willing to help. You won't be left alone. We're here to help. :-) 6. GNUstep-base (aka GNUstep's implementation of Foundation) is superb. 10 years or so of constant development means it's not only complete, but it's being optimized and reoptimized, tested and retested, written and rewritten a lot of times. It's *fast*. 7. GNUstep is a very long-term project to provide a free, cross- platform, state-of-the-art Objective-C development framework. It's been here for many, many years and is here to stay in the very long-term; no matter what Apple, Microsoft or whoever else decide to do with their OS or languages or development environments, GNUstep will be here to support your future cross-platform Objective-C development needs. It's happened before. ;-) Disadvantages over Cocootron: 1. you do have to learn a bit about GNUmakefiles, and if you add a new source file to Xcode, you will have to add it to your GNUmakefile (that could be automated too though) 2. you do have to get your hands dirty with Windows/GNU/Linux/... - ie, you have to install it and try things out on the platform you're porting to. I personally doubt you can ever do a successful port to a new platform without trying your program out on the platform regularly! Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Am 30.10.2008 um 11:09 schrieb Nicola Pero: There's no reason any company porting to Windows should ever choose Cocotron over us. We're more complete. If we had the ability to integrate with Xcode, as Cocotron does If I were a developer developing a Cocoa application on Xcode, and wanting to port it to Windows and/or GNU/Linux/Solaris/*BSD, I don't think I would cross-compile. ;-) I would rather: 1. install [...] 2. install [...] 3. install [...] 4. add a [...] 5. copy [...] 6. move [...] 7. watch [...] 8. run [...] Yes. Your cross-compiling buddy will be done by the time your virtual machine asks for the installation disk. Advantages over Cocootron's cross-compiling solution: Some reasons are valid, but you forgot there's no reason not to cross- compile GNUstep as well, i.e. to join Cocotron and GNUstep capabilities to the advantage of both. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 30 Oct 2008, at 07:44, Markus Hitter wrote: Am 29.10.2008 um 19:30 schrieb Krishna: While Xcode integration can be a big plus, having to cross-compile everytime can be painful, no? No. :-) You'll only notice by the doubled compile time, i.e. 2 seconds instead of 1 for typical small changes. Mac developers do this all day already, as it's currently standard to build for Intel 32-bit and PPC, or 32-bit and 64-bit, or all three (resulting in a single universal binary). There's a switch to build native-only, of course. Cocotron has a big advantage over GNUstep - it only aims to support Windows. Windows has a stable, static ABI and is a very easy target due to its homogeneity. GNUstep, in contrast, supports various flavours of *NIX on various architectures. I use GNUstep on OpenBSD/PowerPC, Solaris/SPARC64 and FreeBSD/x86. Setting up a cross-compile system for these would be very difficult. I'd need a version of GCC with SPARC, PowerPC and x86 back ends built, and I'd need all of the headers for OpenBSD, Solaris and FreeBSD. Apparently some people use my code on Ubuntu/x86 and Ubuntu/x86-64 as well, so I'd probably need to add these targets too. When we get clang / LLVM support then this will be slightly easier since, unlike GCC, LLVM is built with cross-compiling in mind, but this still won't eliminate the need for copies of all of the headers and libraries for each potential target platform. Cross-compiling any C-family language is painful at the best of times, because the compiler is highly context-dependent. If you're only wanting to support OS X and Windows, then cross- compiling might be a good option. Otherwise, it's likely to be a lot more pain than it's worth. Yes. Your cross-compiling buddy will be done by the time your virtual machine asks for the installation disk. And then he'll have to wait to install his VM before he can test it. The Cocoa and Cocotron APIs may be the same, but shipping some code using two completely independent implementations of the same API without testing it on both is something I can't imagine anyone actually doing if they expected real users. Maybe you could test your Cocotron version using WINE on OS X, but that doesn't sound like a good way of working. How is debugging done? You rarely have to run a debugger natively. Most errors are in the logic of an app, which is (should be) the same on both sides. Spoken like someone who has only ever had to support one CPU architecture. Or someone who has never come across bugs related to minor implementation differences between Cocoa and GNUstep. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
There's no reason any company porting to Windows should ever choose Cocotron over us. We're more complete. If we had the ability to integrate with Xcode, as Cocotron does If I were a developer developing a Cocoa application on Xcode, and wanting to port it to Windows and/or GNU/Linux/Solaris/*BSD, I don't think I would cross-compile. ;-) I would rather: 1. install [...] 2. install [...] 3. install [...] 4. add a [...] 5. copy [...] 6. move [...] 7. watch [...] 8. run [...] Yes. Your cross-compiling buddy will be done by the time your virtual machine asks for the installation disk. Possibly. But then they will need to install a virtual machine anyway to test the Windows port ... and copy the results of the build to the VM ... and then run it ... and to make a change, they need to go back to Xcode ... rebuild ... copy the results of the build to the Windows VM ... then go in the VM and run it ... can't see much difference with the native GNUstep approach I outlined - the only difference is if you compile before or after moving the files over to the Windows VM. ;-) Anyway, I agree that for an Xcode programmer the idea of just having a button in Xcode that cross-compiles to Windows might be attractive. I also agree with you that it would be nice for GNUstep to support that. :-) If anyone's interested in working on cross-compilation from Xcode to GNUstep, I'd be happy to help and provide whatever support on the GNUstep building side that you may need. :-) I personally don't find it interesting enough to take the project myself since - in my view - with virtual machines available, you can compile straight on your target host - cross- compilation is *so* last century in this context. ;-) Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 30 Oct 2008, at 14:10, Nicolas Roard wrote: On Thu, Oct 30, 2008 at 1:56 PM, Truls Becken [EMAIL PROTECTED] wrote: Nicola Pero wrote: Anyway, I agree that for an Xcode programmer the idea of just having a button in Xcode that cross-compiles to Windows might be attractive. I also agree with you that it would be nice for GNUstep to support that. :-) Even more awesome, was your idea of a button in Xcode that sends the code changes to the virtual machine, and triggers a recompile there. This would be easiest to implement as a network protocol, so sending it to a physical computer shouldn't make any difference. Perhaps using distributed objects? It's definitely something you could do -- have a special script in xcode triggered when you use a windows target, with the script basically calling (lots of different possible ways to do this) the gnustep installation in the VM to recompile the program. Frankly I think it's a better approach than doing the cross-compilation, specially considering installing GNUstep on windows is just a matter of running the installer. This is pretty much what I did when I was developing on OS X and deploying on IRIX, but I just had a trivial shell script that ran rsync and then ssh'd to the target machine and ran make. Using a network share is another option. Most desktop VMs have the ability to export a host folder via SMB or similar to the guest. Even better would to have some kind of file changed notification system on the guest used to automatically recompile when files in the share were changed, so it would always be up to date. The biggest challenge probably is syncing the code changes. If commiting to a repository for every cycle is acceptable, it would be easily solved that way. A network drive might be doable (i.e. create a network drive on osx and put your sources here, so they can be accessed both by xcode and by the vm). The only last hurdle is the GNUmakefile generation -- there is no xcode-gnumakefile translator anywhere ? surely it can't be that hard to do -- iirc the xcode stuff is in xml. I take it you've never looked at the XCode project files in a text editor. They're graphs wrapped in XML, with opaque references everywhere, and so difficult to parse that I've had XCode fail on them a few times, and had to recreate them from scratch. XCode does expose most of its model via the scripting interface, however, so it would probably be possible to write an AppleScript that would create a GNUmakefile from the active project. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On Thu, Oct 30, 2008 at 2:17 PM, David Chisnall [EMAIL PROTECTED] wrote: On 30 Oct 2008, at 14:10, Nicolas Roard wrote: On Thu, Oct 30, 2008 at 1:56 PM, Truls Becken [EMAIL PROTECTED] wrote: Nicola Pero wrote: Anyway, I agree that for an Xcode programmer the idea of just having a button in Xcode that cross-compiles to Windows might be attractive. I also agree with you that it would be nice for GNUstep to support that. :-) Even more awesome, was your idea of a button in Xcode that sends the code changes to the virtual machine, and triggers a recompile there. This would be easiest to implement as a network protocol, so sending it to a physical computer shouldn't make any difference. Perhaps using distributed objects? It's definitely something you could do -- have a special script in xcode triggered when you use a windows target, with the script basically calling (lots of different possible ways to do this) the gnustep installation in the VM to recompile the program. Frankly I think it's a better approach than doing the cross-compilation, specially considering installing GNUstep on windows is just a matter of running the installer. This is pretty much what I did when I was developing on OS X and deploying on IRIX, but I just had a trivial shell script that ran rsync and then ssh'd to the target machine and ran make. Using a network share is another option. Most desktop VMs have the ability to export a host folder via SMB or similar to the guest. Even better would to have some kind of file changed notification system on the guest used to automatically recompile when files in the share were changed, so it would always be up to date. yup, rsync is probably the simplest solution in fact, and wouldn't require any development. Just write a tutorial on how to do that on windows, showcase it with a large application (gnumail?) and you'll see people interested... The biggest challenge probably is syncing the code changes. If commiting to a repository for every cycle is acceptable, it would be easily solved that way. A network drive might be doable (i.e. create a network drive on osx and put your sources here, so they can be accessed both by xcode and by the vm). The only last hurdle is the GNUmakefile generation -- there is no xcode-gnumakefile translator anywhere ? surely it can't be that hard to do -- iirc the xcode stuff is in xml. I take it you've never looked at the XCode project files in a text editor. They're graphs wrapped in XML, with opaque references everywhere, and so difficult to parse that I've had XCode fail on them a few times, and had to recreate them from scratch. XCode does expose most of its model via the scripting interface, however, so it would probably be possible to write an AppleScript that would create a GNUmakefile from the active project. Good point -- I forgot they were just serialized graph. An applescript could do the work yes, at worse you can always write the gnumakefile, it's not really difficult and doesn't change that often. Basically, all this is doable, probably very easily done in fact. Anybody willing to write a nice tutorial then ? :) I may work on this next month if nobody wants to do it before. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 30.10.2008, at 14:09, Nicola Pero wrote: Possibly. But then they will need to install a virtual machine anyway to test the Windows port ... Just for clarification: this is *much* less trouble than described. All OSX VMs can expose the local OSX folders to Windows, they even allow calling Windows apps from inside OSX! (eg I think you can configure Parallels to open Word documents using Windows Word if you double click a file). So the workflow is as simple as 'build in Xcode', then run it. No need to install or 'copy' anything to test builds. I suppose you could even perform the 'run' phase from inside Xcode (not sure whether there is something like open-in-parallels path). Additionally the build system of Xcode is quite a bit faster, can distribute the builds and is more convenient (if you are an OSX developer). (personally I still prefer makefiles, but someone used to Xcode won't understand why he should use them ...) BTW: cross builds are done all the time on OSX, even just for MacOS. Eg you can build 10.3 binaries on 10.5, or PPC/FAT binaries. Not to mention iPhone applications - which you can even *debug* and profile remotely using Xcode! I assume this (debug/profile) could also be made possible with Cocotron. But hey, I still like GNUstep make better ;-) And I would *love* to be able to easily build (regular) Windows binaries on MacOS w/o switching to Windows. Greets, Helge -- Helge Hess http://helgehess.eu/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Possibly. But then they will need to install a virtual machine anyway to test the Windows port ... Just for clarification: this is *much* less trouble than described. All OSX VMs can expose the local OSX folders to Windows, Sure - the gnustep-make route is also much less trouble then, since you can type 'make' inside the shared Xcode folder directly without having to copy anything ;-) Additionally the build system of Xcode is quite a bit faster Well, yes, Xcode will certainly have all of GCC and the binutils/ linker chain very optimized if you build for anything Apple; but to cross-compile to Windows, Cocotron use their own compiler and linker - taken from the very same pool of GNU tools that GNUstep uses - so I don't expect you'll see much difference between Cocotron and GNUstep here. ;-) Anyway, you have good points that cross-compiling from Xcode might be appealing to some people. :-) It wouldn't be difficult to set up a similar thing for cross-compiling from Apple to Windows using GNUstep. You need to get a MinGW cross-compilation environment running on your Apple, then get the GNUstep libraries in it. Then tell Xcode to use the cross-compilation compiler. :-) Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Gregory John Casamento wrote: One more thing... It says that they spent two months adding: • Added unicode path support to the NSFileManager class. • Added support for displaying truncated strings. • Added support for drawing unicode strings. (Not very pretty support.) • Fixed some issues with the NSSocket implementation. • Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.) • Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples: - [NSPropertyList dataFromPropertyList:] (for binary property lists) - [NSImage TIFFRepresentation] - [NSFileManager subpathsAtPath:] - [NSWorkspace iconForFile:] - [NSMutableString replaceOccurrencesOfString:withString:option:] • Additionally, Ken posted a few issues/requests to the Cocotron Google Group, and the team responded amazingly fast; they even implemented some functionality that we needed. GNUstep already has all of the above mentioned methods. I'll mentioned this on the blog-page you gave. I think this is not completely true. At least I think that • Added support for displaying truncated strings. is still on the list of the thinks to do :-) But all of this is not the point here. This isn't about my system is more complete then yours, or is it? We all know that GNUstep has more features implemented than Cocotron, it also is the much older project. What I still find fascinating with Cocotron is how it appeals to Cocoa developers that don't want to leave there original development platform and still deliver applications for MS Windows. What Cocotron achieved here is unmatched by GNUstep. We should accept that and try to match this instead of pointing to the shortcomings Cocotron that has plenty. Why wont somebody sit down and uses the Cocotron XCode environment to cross compile GNUstep to Windows? I don't see any problem in using their development environment although it isn't LGPL or GPL. As long as we don't mix the source code we should be on the save side. With that done people wanting to port applications from Cocoa to Windows have a fair choice. And of course I hope they choose GNUstep as it is the project I develop for and which license I prefer. (For this to happen we will still have to work on our UI appearance. Even with a better foundation and more features people are first impressed by the look of an application) And congratulation Cocotron! Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 29 Oct 2008, at 09:01, Fred Kiefer wrote: I think this is not completely true. At least I think that • Added support for displaying truncated strings. is still on the list of the thinks to do :-) I don't even know what this is ... so I can't tell whether we have it or not. However, the other things are clearly features long present in GNUstep. But all of this is not the point here. This isn't about my system is more complete then yours, or is it? We all know that GNUstep has more features implemented than Cocotron, it also is the much older project. What I still find fascinating with Cocotron is how it appeals to Cocoa developers that don't want to leave there original development platform and still deliver applications for MS Windows. What Cocotron achieved here is unmatched by GNUstep. We should accept that and try to match this instead of pointing to the shortcomings Cocotron that has plenty. Why wont somebody sit down and uses the Cocotron XCode environment to cross compile GNUstep to Windows? I don't see any problem in using their development environment although it isn't LGPL or GPL. As long as we don't mix the source code we should be on the save side. With that done people wanting to port applications from Cocoa to Windows have a fair choice. And of course I hope they choose GNUstep as it is the project I develop for and which license I prefer. (For this to happen we will still have to work on our UI appearance. Even with a better foundation and more features people are first impressed by the look of an application) Yes ... well, I'm a long time advocate of theming in GNUstep, but we need someone to actually work on it :-( In any case, perhaps you are referring to other appearance glitches etc, I don't know if GNUstep is any worse or better than Cocotron in that respect on windows (better when I looked, but that was quite a while ago). My feel from reading the blog about this port is, that the issue of completeness is unimportant (GNUstep clearly being much more complete, but a developer only needs the features they want to use, and in a free software project can add minor missing features) and reliability is also unimportant (GNUstep being much more reliable, but a developer only needs bits they want to use to be reliable, and in a free software project can fix minor bugs). It seems that in these areas Cocotron is now 'good enough'. So I agree with your main point ... the only reason I can see for Cocotron being chosen in this case is that a Mac developer was able to simply use XCode to port to windows, and the obvious way to add that capability to GNUstep is to 'steal' that from Cocotron. Presumably we could take the development environment, hack it a little to support generic unix as well as windows, and provide a MacOS installer package to install it on our web site, so that people could build using XCode for GNUstep on windows and unix-style operating systems. Is there any Mac based developer out there who'd like to do that? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Given that the LGPL and the GPL are used by roughly 80% of all open source projects, I'm not sure what the objection to it was. The LGPL allows commercial use of the libraries without the necessity to release the code. So far, the only people I've ever heard complain about the license is the Cocotron project. :) Sorry... instead of commercial use I should have said proprietary software. The LGPL allows you to link the library with proprietary software without requiring that you release the code of said proprietary software. Sorry... just wanted to make myself clear. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: TMC [EMAIL PROTECTED]; Discuss-gnustep@gnu.org Sent: Tuesday, October 28, 2008 8:12:05 PM Subject: Re: Cocotron used for a real-world app TMC, I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Thank you for this information. See GNUstep's success stories page for examples of real world apps GNUstep has been used for: http://wiki.gnustep.org/index.php/Success_Stories That list is not complete and there are a few more on the way. :) File Magnet Uploader is an application that transfers files between a Mac or Windows computer and the iPhone (or iPod Touch). It uses a GUI window to manage transfers, drag-and-drop file transferring, progress bars, and many other AppKit classes. It seems like a fairly modest application. [Cocotron has been discussed before][4]. Its authors do not like GNUstep's license nor GNUstep's approach to installation. Given that the LGPL and the GPL are used by roughly 80% of all open source projects, I'm not sure what the objection to it was. The LGPL allows commercial use of the libraries without the necessity to release the code. So far, the only people I've ever heard complain about the license is the Cocotron project. :) I'm not certain why our approach to installation is a problem. Could you elaborate on this a little? We have, and have had for some time, script which will allow you to build GNUstep with one command. We have gone to great lengths to simplify installation. GNUstep can also be installed so that it is conformant with the FHS for people who insist on it. So, any feedback you might be able to give would be very much appreciated. Its license is MIT and workswith Xcode to re-target a Cocoa app to Windows (and eventually Linux). Our aim is to be a completely independent development environment on top of as many operating systems as possible. Currently GNUstep is allows you to compile applications written for Cocoa on Windows, Linux, *BSD, Solaris, IRIX, etc. I don't see that kind of portability with Cocotron. :) The projects are different on a fundamental level. Whereas Cocotron simply wants to be a means by which people port from Mac OS X to other platforms, GNUstep seeks to be an API, a Development environment, a basis for a Linux desktop, and a means by which people can port their Cocoa based applications. The fact of the matter is that GNUstep's goals are much broader than Cocotron's goals are. Its MIT license means that GNUstep is legally free to incorporate code from Cocotron, but Cocotron is not allowed to use GNUstep code. Nevertheless [using Cocotron code is not feasible][5]: it would break GNUstep's convention of copyright assignment, and would mean integrating code that may rely on Cocotron's specific implementation. Yes, that's true. Copyright assignment is currently required because the copyright of GNUstep is held by the FSF. Personally I am glad that Cocotron is open source, and believe that a friendly rivalry will spur both Cocotron and GNUstep to improve themselves. I agree. :D Thank you for your thoughts. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: TMC [EMAIL PROTECTED] To: Discuss-gnustep@gnu.org Sent: Tuesday, October 28, 2008 5:50:26 PM Subject: Cocotron used for a real-world app I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Glen Aspeslagh, one of the authors of the [File Magnet application][3], posted an overview of the porting process. He contributed code to the Cocotron project, as he states below: * Added Unicode path support to the NSFileManager class. * Added support for displaying truncated strings. * Added support for drawing Unicode strings. (Not very pretty support.) * Fixed some issues with the NSSocket implementation. * Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.) * Since Cocotron is not a complete
Re: Cocotron used for a real-world app
I would very much like to see us concentrate our efforts on both of these things: Theming and cross compilation. GNUstep, as I pointed out in my email, has a much wider set of goals than Cocotron does and is much more complete in all of them. There's no reason any company porting to Windows should ever choose Cocotron over us. We're more complete. If we had the ability to integrate with Xcode, as Cocotron does, as well as theming I don't think we would have this problem. Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. The biggest thing which is missing right now is the menus attached to the main window. GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Fred Kiefer [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; TMC [EMAIL PROTECTED]; Discuss-gnustep@gnu.org Sent: Wednesday, October 29, 2008 5:34:15 AM Subject: Re: Cocotron used for a real-world app On 29 Oct 2008, at 09:01, Fred Kiefer wrote: I think this is not completely true. At least I think that • Added support for displaying truncated strings. is still on the list of the thinks to do :-) I don't even know what this is ... so I can't tell whether we have it or not. However, the other things are clearly features long present in GNUstep. But all of this is not the point here. This isn't about my system is more complete then yours, or is it? We all know that GNUstep has more features implemented than Cocotron, it also is the much older project. What I still find fascinating with Cocotron is how it appeals to Cocoa developers that don't want to leave there original development platform and still deliver applications for MS Windows. What Cocotron achieved here is unmatched by GNUstep. We should accept that and try to match this instead of pointing to the shortcomings Cocotron that has plenty. Why wont somebody sit down and uses the Cocotron XCode environment to cross compile GNUstep to Windows? I don't see any problem in using their development environment although it isn't LGPL or GPL. As long as we don't mix the source code we should be on the save side. With that done people wanting to port applications from Cocoa to Windows have a fair choice. And of course I hope they choose GNUstep as it is the project I develop for and which license I prefer. (For this to happen we will still have to work on our UI appearance. Even with a better foundation and more features people are first impressed by the look of an application) Yes ... well, I'm a long time advocate of theming in GNUstep, but we need someone to actually work on it :-( In any case, perhaps you are referring to other appearance glitches etc, I don't know if GNUstep is any worse or better than Cocotron in that respect on windows (better when I looked, but that was quite a while ago). My feel from reading the blog about this port is, that the issue of completeness is unimportant (GNUstep clearly being much more complete, but a developer only needs the features they want to use, and in a free software project can add minor missing features) and reliability is also unimportant (GNUstep being much more reliable, but a developer only needs bits they want to use to be reliable, and in a free software project can fix minor bugs). It seems that in these areas Cocotron is now 'good enough'. So I agree with your main point ... the only reason I can see for Cocotron being chosen in this case is that a Mac developer was able to simply use XCode to port to windows, and the obvious way to add that capability to GNUstep is to 'steal' that from Cocotron. Presumably we could take the development environment, hack it a little to support generic unix as well as windows, and provide a MacOS installer package to install it on our web site, so that people could build using XCode for GNUstep on windows and unix-style operating systems. Is there any Mac based developer out there who'd like to do that? ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. I agree that allowing for native-appearing GNUstep apps under Windows is a great idea... but I don't think that's doable in the context of a theme. Theming support is essential for GNUstep (obviously), but with Windows, I think we need to really be using native widgets. There are just so many ways that a Windows machine can be customized visually, that a theme will almost always feel out of place (not to mention what we make that GNUstep theme look like: XP or Vista or... something else). I have no idea how this would be done technically, but it's most certainly the best way to give the feel of a truly native application. That, or we throw away native conventions entirely and go the iTunes/ Safari on Windows route. J. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 29 Oct 2008, at 13:56, Jesse Ross wrote: Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. I agree that allowing for native-appearing GNUstep apps under Windows is a great idea... but I don't think that's doable in the context of a theme. Theming support is essential for GNUstep (obviously), but with Windows, I think we need to really be using native widgets. There are just so many ways that a Windows machine can be customized visually, that a theme will almost always feel out of place (not to mention what we make that GNUstep theme look like: XP or Vista or... something else). I have no idea how this would be done technically, but it's most certainly the best way to give the feel of a truly native application. True integration with windows widgets is (line integration with X widgets) almost impossible without essentially throwing away gui/back altogether. My concept of theming (as described in the theme documentation in GNUstep) was to have something a good deal more powerful than conventional themes though, and while it can't be perfect it could do a lot better than you might expect. The idea was to have three levels of operation that a theme bundle could make use of: 1. setting user defaults to change colors and implement limited behavior changes (menu style, window decoration etc) which are already built in to GNUstep. 2. painting gui elements using tiled images (like camealon) 3. new code in the bundle to handle drawing and change class behavior. The first two parts of this should be usable by designers with no coding knowledge, but the third obviously requires programming skills. My thought was that a windows theme would operate largely at the third level, though it could make use of the other stuff. For instance, it could make itsself aware of changes to the ms-windows native theme that happens to be in operation, and update drawing of the gnustep app in response to native theme changes. It might be able to draw test widgets using the native APIs, then grab pixmap information from them and use that pixmap information to draw the gnustep gui elements etc. And of course it could also replace the implementation of particular gnustep user interface element with wrappers for native widgets in any place where that's actually enough of an advantage to justify the work. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 29 Oct 2008, at 13:56, Jesse Ross wrote: Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. I agree that allowing for native-appearing GNUstep apps under Windows is a great idea... but I don't think that's doable in the context of a theme. Theming support is essential for GNUstep (obviously), but with Windows, I think we need to really be using native widgets. There are just so many ways that a Windows machine can be customized visually, that a theme will almost always feel out of place (not to mention what we make that GNUstep theme look like: XP or Vista or... something else). I have no idea how this would be done technically, but it's most certainly the best way to give the feel of a truly native application. True integration with windows widgets is (line integration with X widgets) almost impossible without essentially throwing away gui/back altogether. My concept of theming (as described in the theme documentation in GNUstep) was to have something a good deal more powerful than conventional themes though, and while it can't be perfect it could do a lot better than you might expect. The idea was to have three levels of operation that a theme bundle could make use of: 1. setting user defaults to change colors and implement limited behavior changes (menu style, window decoration etc) which are already built in to GNUstep. 2. painting gui elements using tiled images (like camealon) 3. new code in the bundle to handle drawing and change class behavior. The first two parts of this should be usable by designers with no coding knowledge, but the third obviously requires programming skills. My thought was that a windows theme would operate largely at the third level, though it could make use of the other stuff. For instance, it could make itsself aware of changes to the ms-windows native theme that happens to be in operation, and update drawing of the gnustep app in response to native theme changes. It might be able to draw test widgets using the native APIs, then grab pixmap information from them and use that pixmap information to draw the gnustep gui elements etc. And of course it could also replace the implementation of particular gnustep user interface element with wrappers for native widgets in any place where that's actually enough of an advantage to justify the work. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On Wed, Oct 29, 2008 at 7:26 PM, Jesse Ross [EMAIL PROTECTED] wrote: Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. I agree that allowing for native-appearing GNUstep apps under Windows is a great idea... but I don't think that's doable in the context of a theme. Theming support is essential for GNUstep (obviously), but with Windows, I think we need to really be using native widgets. There are just so many ways that a Windows machine can be customized visually, that a theme will almost always feel out of place (not to mention what we make that GNUstep theme look like: XP or Vista or... something else). I have no idea how this would be done technically, but it's most certainly the best way to give the feel of a truly native application. That, or we throw away native conventions entirely and go the iTunes/Safari on Windows route. Win32 API provides routines for drawing native looking controls. AFAIK, GTK+ uses them to obtain near native look. I have no idea how to wire it for GNUstep though. Cheers, -Krishna -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? - Aksel Peter Jorgensen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On Wed, Oct 29, 2008 at 7:43 PM, Richard Frith-Macdonald [EMAIL PROTECTED] wrote: On 29 Oct 2008, at 13:56, Jesse Ross wrote: Fred, Riccardo, Adam and I have been working on Windows lately and it's now more stable than ever. A good windows theme might help, but actually some of the color schemes we already have work very well indeed. I agree that allowing for native-appearing GNUstep apps under Windows is a great idea... but I don't think that's doable in the context of a theme. Theming support is essential for GNUstep (obviously), but with Windows, I think we need to really be using native widgets. There are just so many ways that a Windows machine can be customized visually, that a theme will almost always feel out of place (not to mention what we make that GNUstep theme look like: XP or Vista or... something else). I have no idea how this would be done technically, but it's most certainly the best way to give the feel of a truly native application. True integration with windows widgets is (line integration with X widgets) almost impossible without essentially throwing away gui/back altogether. My concept of theming (as described in the theme documentation in GNUstep) was to have something a good deal more powerful than conventional themes though, and while it can't be perfect it could do a lot better than you might expect. The idea was to have three levels of operation that a theme bundle could make use of: 1. setting user defaults to change colors and implement limited behavior changes (menu style, window decoration etc) which are already built in to GNUstep. 2. painting gui elements using tiled images (like camealon) 3. new code in the bundle to handle drawing and change class behavior. The first two parts of this should be usable by designers with no coding knowledge, but the third obviously requires programming skills. My thought was that a windows theme would operate largely at the third level, though it could make use of the other stuff. For instance, it could make itsself aware of changes to the ms-windows native theme that happens to be in operation, and update drawing of the gnustep app in response to native theme changes. It might be able to draw test widgets using the native APIs, then grab pixmap information from them and use that pixmap information to draw the gnustep gui elements etc. And of course it could also replace the implementation of particular gnustep user interface element with wrappers for native widgets in any place where that's actually enough of an advantage to justify the work. http://msdn.microsoft.com/en-us/library/ms534865.aspx - Will this help? Cheers, -Krishna -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? - Aksel Peter Jorgensen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On Wed, Oct 29, 2008 at 9:48 PM, Markus Hitter [EMAIL PROTECTED] wrote: Am 29.10.2008 um 14:45 schrieb Gregory John Casamento: There's no reason any company porting to Windows should ever choose Cocotron over us. We're more complete. I humbly disagree, Greg. Very obviously, there _are_ reasons why people choose Cocotron over GNUstep. Just as obviously, these reasons are not to find in the area of stability or completeness. Xcode integration is a big bonus for Mac heads, as one can be an true expert in one development environment only. If you have to learn another one, thats a duplication of a lot of kmowledge and most people would consider this as a waste. Looking at GNUstep installation ... this is 2008 and 999 of 1000 Computer users don't know how to set up a compilation environment. So, installation from source won't cut it for anybody but developer them selfs. Even most developers prefer ready-to-use packages these days. Have you tried Adam's Windows installer(s)? I think it coming along quite well. Cheers, -Krishna -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? - Aksel Peter Jorgensen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On Wed, Oct 29, 2008 at 9:48 PM, Markus Hitter [EMAIL PROTECTED] wrote: Xcode integration is a big bonus for Mac heads, as one can be an true expert in one development environment only. If you have to learn another one, thats a duplication of a lot of kmowledge and most people would consider this as a waste. While Xcode integration can be a big plus, having to cross-compile everytime can be painful, no? How is debugging done? binaries are copied to the target everytime it is recompiled? I have to admit that when I read InstallCDT on their site my interest was piqued. Thought it had go something to do with Eclipse. Turns out to be a cross compiler. The whole thing appears to be very tedious... I understand having something like code completion can be very useful when dealing with a large API like Cocoa so maybe GNUstep can do something about it - a plugin for Eclipse or Netbeans might ease the entry barrier. btw, how do GNUstep developers deal with the tons of classes and methods? Cheers, -Krishna -- Why make things difficult, when it is possible to make them cryptic and totally illogical, with just a little bit more effort? - Aksel Peter Jorgensen ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
Richard Frith-Macdonald wrote: On 29 Oct 2008, at 09:01, Fred Kiefer wrote: I think this is not completely true. At least I think that • Added support for displaying truncated strings. is still on the list of the thinks to do :-) I don't even know what this is ... so I can't tell whether we have it or not. However, the other things are clearly features long present in GNUstep. The truncation I was thinking of gets used by NSTabViewItem to display oversized labels. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
On 30/10/2008, at 2:18 PM, Krishna wrote: hi!, thanks for the pointer on uxtheme API. Do you still have those patches of yours floating around? I'd like to see how it is done. btw, wxWidgets is a wrapper toolkit so it gets default LF for free. These are the original links I posted. One is a patch against gnustep- gui that adds hooks for some drawing methods. The other is a theme engine that implements some of those methods by hacking gnustep-back and uxtheme. I do recall doing more work on it, but I think its gone now. http://carmstrong.fastmail.com.au/gnustep-gui-themeing-20070429-2.diff http://carmstrong.fastmail.com.au/win32theme.tgz Regards Chris Christopher Armstrong [EMAIL PROTECTED] ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Cocotron used for a real-world app
I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Glen Aspeslagh, one of the authors of the [File Magnet application][3], posted an overview of the porting process. He contributed code to the Cocotron project, as he states below: * Added Unicode path support to the NSFileManager class. * Added support for displaying truncated strings. * Added support for drawing Unicode strings. (Not very pretty support.) * Fixed some issues with the NSSocket implementation. * Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.) * Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples: - [NSPropertyList dataFromPropertyList:] // (for binary property lists) - [NSImage TIFFRepresentation] - [NSFileManager subpathsAtPath:] - [NSWorkspace iconForFile:] - [NSMutableString replaceOccurrencesOfString:withString:option:] File Magnet Uploader is an application that transfers files between a Mac or Windows computer and the iPhone (or iPod Touch). It uses a GUI window to manage transfers, drag-and-drop file transferring, progress bars, and many other AppKit classes. [Cocotron has been discussed before][4]. Its authors do not like GNUstep's license nor GNUstep's approach to installation. Its license is MIT and works with Xcode to re-target a Cocoa app to Windows (and eventually Linux). Its MIT license means that GNUstep is legally free to incorporate code from Cocotron, but Cocotron is not allowed to use GNUstep code. Nevertheless [using Cocotron code is not feasible][5]: it would break GNUstep's convention of copyright assignment, and would mean integrating code that may rely on Cocotron's specific implementation. Personally I am glad that Cocotron is open source, and believe that a friendly rivalry will spur both Cocotron and GNUstep to improve themselves. [1]: http://macdaddyworld.com/2008/10/27/adventures-in-cocotron/ [2]: http://www.cocotron.org/Info [3]: http://www.magnetismstudios.com/filemagnet/ [4]: http://www.nabble.com/Cocotron-to8033632.html [5]: http://www.nabble.com/Using-code-from-Cocotron-to10426241.html --Tycho Martin Clendenny -- View this message in context: http://www.nabble.com/Cocotron-used-for-a-real-world-app-tp20216767p20216767.html Sent from the GNUstep - General mailing list archive at Nabble.com. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron used for a real-world app
TMC, I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Thank you for this information. See GNUstep's success stories page for examples of real world apps GNUstep has been used for: http://wiki.gnustep.org/index.php/Success_Stories That list is not complete and there are a few more on the way. :) File Magnet Uploader is an application that transfers files between a Mac or Windows computer and the iPhone (or iPod Touch). It uses a GUI window to manage transfers, drag-and-drop file transferring, progress bars, and many other AppKit classes. It seems like a fairly modest application. [Cocotron has been discussed before][4]. Its authors do not like GNUstep's license nor GNUstep's approach to installation. Given that the LGPL and the GPL are used by roughly 80% of all open source projects, I'm not sure what the objection to it was. The LGPL allows commercial use of the libraries without the necessity to release the code. So far, the only people I've ever heard complain about the license is the Cocotron project. :) I'm not certain why our approach to installation is a problem. Could you elaborate on this a little? We have, and have had for some time, script which will allow you to build GNUstep with one command. We have gone to great lengths to simplify installation. GNUstep can also be installed so that it is conformant with the FHS for people who insist on it. So, any feedback you might be able to give would be very much appreciated. Its license is MIT and workswith Xcode to re-target a Cocoa app to Windows (and eventually Linux). Our aim is to be a completely independent development environment on top of as many operating systems as possible. Currently GNUstep is allows you to compile applications written for Cocoa on Windows, Linux, *BSD, Solaris, IRIX, etc. I don't see that kind of portability with Cocotron. :) The projects are different on a fundamental level. Whereas Cocotron simply wants to be a means by which people port from Mac OS X to other platforms, GNUstep seeks to be an API, a Development environment, a basis for a Linux desktop, and a means by which people can port their Cocoa based applications. The fact of the matter is that GNUstep's goals are much broader than Cocotron's goals are. Its MIT license means that GNUstep is legally free to incorporate code from Cocotron, but Cocotron is not allowed to use GNUstep code. Nevertheless [using Cocotron code is not feasible][5]: it would break GNUstep's convention of copyright assignment, and would mean integrating code that may rely on Cocotron's specific implementation. Yes, that's true. Copyright assignment is currently required because the copyright of GNUstep is held by the FSF. Personally I am glad that Cocotron is open source, and believe that a friendly rivalry will spur both Cocotron and GNUstep to improve themselves. I agree. :D Thank you for your thoughts. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: TMC [EMAIL PROTECTED] To: Discuss-gnustep@gnu.org Sent: Tuesday, October 28, 2008 5:50:26 PM Subject: Cocotron used for a real-world app I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Glen Aspeslagh, one of the authors of the [File Magnet application][3], posted an overview of the porting process. He contributed code to the Cocotron project, as he states below: * Added Unicode path support to the NSFileManager class. * Added support for displaying truncated strings. * Added support for drawing Unicode strings. (Not very pretty support.) * Fixed some issues with the NSSocket implementation. * Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.) * Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples: - [NSPropertyList dataFromPropertyList:] // (for binary property lists) - [NSImage TIFFRepresentation] - [NSFileManager subpathsAtPath:] - [NSWorkspace iconForFile:] - [NSMutableString replaceOccurrencesOfString:withString:option:] File Magnet Uploader is an application that transfers files between a Mac or Windows computer and the iPhone (or iPod Touch). It uses a GUI window to manage transfers, drag-and-drop file transferring, progress bars, and many other AppKit classes. [Cocotron has been discussed before][4]. Its authors do not like GNUstep's license nor GNUstep's approach to installation. Its license is MIT and works with Xcode to re-target a Cocoa app to Windows (and eventually Linux). Its MIT license means that GNUstep
Re: Cocotron used for a real-world app
TMC, One more thing... It says that they spent two months adding: • Added unicode path support to the NSFileManager class. • Added support for displaying truncated strings. • Added support for drawing unicode strings. (Not very pretty support.) • Fixed some issues with the NSSocket implementation. • Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.) • Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples: - [NSPropertyList dataFromPropertyList:] (for binary property lists) - [NSImage TIFFRepresentation] - [NSFileManager subpathsAtPath:] - [NSWorkspace iconForFile:] - [NSMutableString replaceOccurrencesOfString:withString:option:] • Additionally, Ken posted a few issues/requests to the Cocotron Google Group, and the team responded amazingly fast; they even implemented some functionality that we needed. GNUstep already has all of the above mentioned methods. I'll mentioned this on the blog-page you gave. Thanks, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Gregory John Casamento [EMAIL PROTECTED] To: TMC [EMAIL PROTECTED]; Discuss-gnustep@gnu.org Sent: Tuesday, October 28, 2008 8:12:05 PM Subject: Re: Cocotron used for a real-world app TMC, I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Thank you for this information. See GNUstep's success stories page for examples of real world apps GNUstep has been used for: http://wiki.gnustep.org/index.php/Success_Stories That list is not complete and there are a few more on the way. :) File Magnet Uploader is an application that transfers files between a Mac or Windows computer and the iPhone (or iPod Touch). It uses a GUI window to manage transfers, drag-and-drop file transferring, progress bars, and many other AppKit classes. It seems like a fairly modest application. [Cocotron has been discussed before][4]. Its authors do not like GNUstep's license nor GNUstep's approach to installation. Given that the LGPL and the GPL are used by roughly 80% of all open source projects, I'm not sure what the objection to it was. The LGPL allows commercial use of the libraries without the necessity to release the code. So far, the only people I've ever heard complain about the license is the Cocotron project. :) I'm not certain why our approach to installation is a problem. Could you elaborate on this a little? We have, and have had for some time, script which will allow you to build GNUstep with one command. We have gone to great lengths to simplify installation. GNUstep can also be installed so that it is conformant with the FHS for people who insist on it. So, any feedback you might be able to give would be very much appreciated. Its license is MIT and workswith Xcode to re-target a Cocoa app to Windows (and eventually Linux). Our aim is to be a completely independent development environment on top of as many operating systems as possible. Currently GNUstep is allows you to compile applications written for Cocoa on Windows, Linux, *BSD, Solaris, IRIX, etc. I don't see that kind of portability with Cocotron. :) The projects are different on a fundamental level. Whereas Cocotron simply wants to be a means by which people port from Mac OS X to other platforms, GNUstep seeks to be an API, a Development environment, a basis for a Linux desktop, and a means by which people can port their Cocoa based applications. The fact of the matter is that GNUstep's goals are much broader than Cocotron's goals are. Its MIT license means that GNUstep is legally free to incorporate code from Cocotron, but Cocotron is not allowed to use GNUstep code. Nevertheless [using Cocotron code is not feasible][5]: it would break GNUstep's convention of copyright assignment, and would mean integrating code that may rely on Cocotron's specific implementation. Yes, that's true. Copyright assignment is currently required because the copyright of GNUstep is held by the FSF. Personally I am glad that Cocotron is open source, and believe that a friendly rivalry will spur both Cocotron and GNUstep to improve themselves. I agree. :D Thank you for your thoughts. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: TMC [EMAIL PROTECTED] To: Discuss-gnustep@gnu.org Sent: Tuesday, October 28, 2008 5:50:26 PM Subject: Cocotron used for a real-world app I thought GNUstep folks would like to know that [Cocotron][2], another Cocoa / *step implementation, has been used by a Mac software company to [port an app to Windows][1]. Glen Aspeslagh, one
Re: NSPredicate bug (Re: Using code from Cocotron)
Richard, can you help us on this? Yen-Ju Chen wrote: Just confirm that NSPredicate works except the %d. But it is not a big issue and can easily work around. My current idea for this problem is to pre-parse the format string for the va_list case and store the arguments in an NSArray and invoke the init with array method. In the process packaging all the integers and floats up as NSNumber. Do you think this will work? And is there a simple way to implement all the printf details we need? With that in place nextArg would only access the array and the rest of the code could stay as it is now. Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSPredicate bug (Re: Using code from Cocotron)
On 6/11/07, Yen-Ju Chen [EMAIL PROTECTED] wrote: On 6/11/07, Fred Kiefer [EMAIL PROTECTED] wrote: Yen-Ju Chen wrote: On 6/9/07, Fred Kiefer [EMAIL PROTECTED] wrote: There are plenty of other problems with predicates that your tests uncovered. For example we don't support ==, but have =. Which of them should we have? Both? Fixed Also the IN operator will only work for strings, not for a set and an element. Fixed Handling of BETWEEN is completely missing and the parsing of all key words failed at the end of the string. Fixed I tried to fix some of this, but it requires a lot more work. Thanx again. I intentionally pick less-used cases for testing because I believe GNUstep can handle the common ones. One thing I notice is that with '==' (or '=' for GNUstep), you cannot specify the case-insensitive ([c]). Fixed or did I get you wrong and the GNUstep behaviour matched the one from Apple? Apple does not allow '==[c]'. So I have to use 'MATCHES[c]' for case-insensitive, but due to the regex, MATCHES is not implemented in GNUstep. So I have no away to do case-insensitive full string comparison on GNUstep excepting using a combination of 'BEGIN[c]', 'IN[c]' and 'END[c]' for that. It is just less convenient. Maybe for current situation, you can implement MATCHES as simple full string comparison ? It is the same as regex without all the special symbol (*, ?, [, ]). So I have to use 'MATCHES[c]'. But 'MATCHES' use regex, which I think is too much if I only want to do case-insensitive comparison. Regular expressions are still missing in GNUstep. With all these fixes only the tests that include %d and the one with matches still fail. But don't erxpect any further progress here. We need Richard to look at the %d problem. Thanx. I will try again later. Just confirm that NSPredicate works except the %d. But it is not a big issue and can easily work around. Thanx. Yen-Ju Yen-Ju Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSPredicate bug (Re: Using code from Cocotron)
Yen-Ju Chen wrote: On 6/9/07, Fred Kiefer [EMAIL PROTECTED] wrote: There are plenty of other problems with predicates that your tests uncovered. For example we don't support ==, but have =. Which of them should we have? Both? Fixed Also the IN operator will only work for strings, not for a set and an element. Fixed Handling of BETWEEN is completely missing and the parsing of all key words failed at the end of the string. Fixed I tried to fix some of this, but it requires a lot more work. Thanx again. I intentionally pick less-used cases for testing because I believe GNUstep can handle the common ones. One thing I notice is that with '==' (or '=' for GNUstep), you cannot specify the case-insensitive ([c]). Fixed or did I get you wrong and the GNUstep behaviour matched the one from Apple? So I have to use 'MATCHES[c]'. But 'MATCHES' use regex, which I think is too much if I only want to do case-insensitive comparison. Regular expressions are still missing in GNUstep. With all these fixes only the tests that include %d and the one with matches still fail. But don't erxpect any further progress here. We need Richard to look at the %d problem. Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSPredicate bug (Re: Using code from Cocotron)
Yen-Ju Chen wrote: On 5/23/07, Fred Kiefer [EMAIL PROTECTED] wrote: Triggered by this mail, I set down and wrote some code for NSPredicate and NSExpression to make these classes (and their subclasses) at least usable. They are still far away from being complete, but it would be nice if somebody actually tested them. The best thing to do now is write some test code, exercising these classes and integrate that into our test framework. I promise to have a look at the bugs found in that process. I write some simple tests with UnitKit. All tests pass on Mac, but have problem with GNUstep. I think it is due to predicate parsing. The test is attached. Thank you for the test. It took me some time to get it running as the UnitKit in Etoile does not compile properly. You need to install the Framework frist and then you are able to compile the run script. Looks like who ever wrote the makefile for this framework never tested it on a clean system. After hacking in some debug output into NSPredicate it became obvious that simple lines like the following break the parser: p = [NSPredicate predicateWithFormat: @%K == %d, @Record1.Age, 34]; Here we have an integer parameter that needs to be parsed and the code in parseSimpleExpression is not prepared to do so. But this also raises a deeper problem. The nextArg method on GSPredicateScanner expects all the arguments in the varg list to be of type id. When this isn't true the repeated loop over the arguments may produce nonsense. Now this is a problem I cannot resolve myself. Perhaps Richard has an idea here? I remember we had problems with that va_list structure, when I introduced it and I still don't have a glue how this works internally. There are plenty of other problems with predicates that your tests uncovered. For example we don't support ==, but have =. Which of them should we have? Both? Also the IN operator will only work for strings, not for a set and an element. Handling of BETWEEN is completely missing and the parsing of all key words failed at the end of the string. I tried to fix some of this, but it requires a lot more work. Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: NSPredicate bug (Re: Using code from Cocotron)
On 6/9/07, Fred Kiefer [EMAIL PROTECTED] wrote: Yen-Ju Chen wrote: On 5/23/07, Fred Kiefer [EMAIL PROTECTED] wrote: Triggered by this mail, I set down and wrote some code for NSPredicate and NSExpression to make these classes (and their subclasses) at least usable. They are still far away from being complete, but it would be nice if somebody actually tested them. The best thing to do now is write some test code, exercising these classes and integrate that into our test framework. I promise to have a look at the bugs found in that process. I write some simple tests with UnitKit. All tests pass on Mac, but have problem with GNUstep. I think it is due to predicate parsing. The test is attached. Thank you for the test. It took me some time to get it running as the UnitKit in Etoile does not compile properly. You need to install the Framework frist and then you are able to compile the run script. Looks like who ever wrote the makefile for this framework never tested it on a clean system. Thanx. I will take a look of it. It may be easier to rewrite the tests with GNUstep's unit test for the future. After hacking in some debug output into NSPredicate it became obvious that simple lines like the following break the parser: p = [NSPredicate predicateWithFormat: @%K == %d, @Record1.Age, 34]; Here we have an integer parameter that needs to be parsed and the code in parseSimpleExpression is not prepared to do so. But this also raises a deeper problem. The nextArg method on GSPredicateScanner expects all the arguments in the varg list to be of type id. When this isn't true the repeated loop over the arguments may produce nonsense. Now this is a problem I cannot resolve myself. Perhaps Richard has an idea here? I remember we had problems with that va_list structure, when I introduced it and I still don't have a glue how this works internally. There are plenty of other problems with predicates that your tests uncovered. For example we don't support ==, but have =. Which of them should we have? Both? Also the IN operator will only work for strings, not for a set and an element. Handling of BETWEEN is completely missing and the parsing of all key words failed at the end of the string. I tried to fix some of this, but it requires a lot more work. Thanx again. I intentionally pick less-used cases for testing because I believe GNUstep can handle the common ones. One thing I notice is that with '==' (or '=' for GNUstep), you cannot specify the case-insensitive ([c]). So I have to use 'MATCHES[c]'. But 'MATCHES' use regex, which I think is too much if I only want to do case-insensitive comparison. I guess it is something missing from Apple's design of predicate syntax. Yen-Ju Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
NSPredicate bug (Re: Using code from Cocotron)
On 5/23/07, Fred Kiefer [EMAIL PROTECTED] wrote: Triggered by this mail, I set down and wrote some code for NSPredicate and NSExpression to make these classes (and their subclasses) at least usable. They are still far away from being complete, but it would be nice if somebody actually tested them. The best thing to do now is write some test code, exercising these classes and integrate that into our test framework. I promise to have a look at the bugs found in that process. I write some simple tests with UnitKit. All tests pass on Mac, but have problem with GNUstep. I think it is due to predicate parsing. The test is attached. Yen-Ju Cheers, Fred Yen-Ju Chen wrote: Hi, I was looking at GNUstep's NSPredicate implementation and one obvious missing part is the -evaluateWithObject: in NSComparisonPredicate. Then I found Cocotron has more implementation than GNUstep. Since NSPredicate use KVC and I remember GNUstep's implementation of KVC/KVO is not finished (It is listed in SoC 2007 for GNUstep), I look at Cocotron's implementation again and it seems to have implementation to an extent. I wonder what is GNUstep's stand of using Cocotron's code considering they are released under MIT ? While their AppKit might be tied with Windows, Foundation should be fairly portable. Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make GNUstep more complete, why not take this advantage. :) Yen-Ju PredicateTest.tar.gz Description: GNU Zip compressed data ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Using code from Cocotron
Triggered by this mail, I set down and wrote some code for NSPredicate and NSExpression to make these classes (and their subclasses) at least usable. They are still far away from being complete, but it would be nice if somebody actually tested them. The best thing to do now is write some test code, exercising these classes and integrate that into our test framework. I promise to have a look at the bugs found in that process. Cheers, Fred Yen-Ju Chen wrote: Hi, I was looking at GNUstep's NSPredicate implementation and one obvious missing part is the -evaluateWithObject: in NSComparisonPredicate. Then I found Cocotron has more implementation than GNUstep. Since NSPredicate use KVC and I remember GNUstep's implementation of KVC/KVO is not finished (It is listed in SoC 2007 for GNUstep), I look at Cocotron's implementation again and it seems to have implementation to an extent. I wonder what is GNUstep's stand of using Cocotron's code considering they are released under MIT ? While their AppKit might be tied with Windows, Foundation should be fairly portable. Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make GNUstep more complete, why not take this advantage. :) Yen-Ju ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Using code from Cocotron
On May 11, 2007, at 1:44 AM, Richard Frith-Macdonald wrote: Well, as far as I know the license is an issue (I believe BSD is incompatible with the LGLP) How so? The Cocotron license is GPL/LGPL compatible. References: http://cocotron.org/Info/The_MIT_License/ http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses http://lists.debian.org/debian-legal/2007/04/msg00033.html ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Using code from Cocotron
On 12 May 2007, at 07:34, Tim McIntosh wrote: On May 11, 2007, at 1:44 AM, Richard Frith-Macdonald wrote: Well, as far as I know the license is an issue (I believe BSD is incompatible with the LGLP) How so? The Cocotron license is GPL/LGPL compatible. References: http://cocotron.org/Info/The_MIT_License/ Ah ... so cocotron is not BSD ... so the license is not an issue ... so we only have copyright (we approached them about that) and technical issues to prevent direct use. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Using code from Cocotron
On 11 May 2007, at 06:40, Yen-Ju Chen wrote: Hi, I was looking at GNUstep's NSPredicate implementation and one obvious missing part is the -evaluateWithObject: in NSComparisonPredicate. Then I found Cocotron has more implementation than GNUstep. Since NSPredicate use KVC and I remember GNUstep's implementation of KVC/KVO is not finished (It is listed in SoC 2007 for GNUstep), KVC is complete, but IMO is sufficiently underused/tested that it may contain bugs, which is why I'd like to see it reviewed. KVO is not complete, but is not (afaik) used by the NSPredicate stuff. I look at Cocotron's implementation again and it seems to have implementation to an extent. I wonder what is GNUstep's stand of using Cocotron's code considering they are released under MIT ? We can't use the code because they won't assign the copyright to the FSF. in practice we probably couldn't use much (if any) of it simply anyway as we have our own codebase and cocotron stuff would need to be altered to fit in to gnustep. Where it's valuable is that you can look at the cocotron code, see how they do things, and write code using ideas from it where appropriate (or write different code if you think they've gone wrong of course). While their AppKit might be tied with Windows, Foundation should be fairly portable. Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make GNUstep more complete, why not take this advantage. :) Well, as far as I know the license is an issue (I believe BSD is incompatible with the LGLP), and the cocotron people won't assign copyright, so we can't just incorporate the code for license/ copyright reasons. I see at least four reasons why we can't just copy cocotron code: 1. it would need modifying to work 2. copyright 3. license 4. a minor problem ... coding style (needs reformatting etc to ,meet coding standards) What you should do is write new code for GNUstep using ideas from cocotron as appropriate. For that cocotron is obviously a valuable resource. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Using code from Cocotron
Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make We already have it and ours is better. :) -- Gregory Casamento - Original Message From: Yen-Ju Chen [EMAIL PROTECTED] To: Discuss GNUstep discuss-gnustep@gnu.org Sent: Friday, May 11, 2007 1:40:39 AM Subject: Using code from Cocotron Hi, I was looking at GNUstep's NSPredicate implementation and one obvious missing part is the -evaluateWithObject: in NSComparisonPredicate. Then I found Cocotron has more implementation than GNUstep. Since NSPredicate use KVC and I remember GNUstep's implementation of KVC/KVO is not finished (It is listed in SoC 2007 for GNUstep), I look at Cocotron's implementation again and it seems to have implementation to an extent. I wonder what is GNUstep's stand of using Cocotron's code considering they are released under MIT ? While their AppKit might be tied with Windows, Foundation should be fairly portable. Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make GNUstep more complete, why not take this advantage. :) Yen-Ju ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Using code from Cocotron
Hi, I was looking at GNUstep's NSPredicate implementation and one obvious missing part is the -evaluateWithObject: in NSComparisonPredicate. Then I found Cocotron has more implementation than GNUstep. Since NSPredicate use KVC and I remember GNUstep's implementation of KVC/KVO is not finished (It is listed in SoC 2007 for GNUstep), I look at Cocotron's implementation again and it seems to have implementation to an extent. I wonder what is GNUstep's stand of using Cocotron's code considering they are released under MIT ? While their AppKit might be tied with Windows, Foundation should be fairly portable. Something like nib supporting from Cocotron may also be worth to take a look. The point is that if license is not an issue and it will make GNUstep more complete, why not take this advantage. :) Yen-Ju ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: FOSDEM 2007 All developers Meeting (was Re: Cocotron)
On Dec 28, 2006, at 10:19, [EMAIL PROTECTED] wrote: Of couse, having a GNUstep Conference Stream would be very cool :) How? Webcam + skype??? May FOSDEM provide a related infrastructure? Yes, there will be WLAN provided by all. FYI: you can't expect the FOSDEM WLAN to work reliably. Be prepared to have *no* network. Greets, Helge ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 28, 2006, at 19:27, Yen-Ju Chen wrote: Cocotron is under MIT license, which makes it easier for GNUstep to borrow their codes. :) How? GNUstep requires the FSF copyright assignment, so you can't use _any_ of their code. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On 12/31/06, Stefan Bidigaray [EMAIL PROTECTED] wrote: The only think that I don't like about the current implementation is the whole /System, /Local and /Network hierarchies (I'll refer to everything as if it was installed to /). I'm really bad at trying to say what on my mind cause it's a mess up there, but here goes. Why not make the /System hierarchy just be /? This would mean the hierarchy would be something more like: [...] You can do that by modifying GNUstep.conf, e.g. during installation of gnustep-make: CC=gcc41 ./configure --with-system-root=/ --with-local-root=/ --with-network-root=/Network --with-user-config-file='~/Library/.GNUstep.conf' --with-user-dir='~' --with-user-defaults-dir='~/Library/Defaults' --with-config-file=/share/GNUstep.conf As you can see, I install everything in / -- that is, I will end up with /Applications /Library /Network (nostalgia) /Tools /share (which should really be in /Library). And instead of HOME/GNUstep/... I put everything directly in my home directory. Been using this 'set-up' for more than a year, and haven't encountered any problems (aside from moronicly written Makefiles and source code that insist on using hard-coded path names, like Addresses). -- Chris ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
I understand such a configuration is possible but even though this does work, a small issue does come up, which isn't anything big... under GNUstep.sh things are setup such as: //Applications //Library etc... because the file assumes a $GNUSTEP_SYSTEM_ROOT/* and if $GNUSTEP_SYSTEM_ROOT=/ you get that. Also, what I wanted to get through was to set up this type of hierarchy by default as in my opinion it's more intuitive than the current one. In this case, even if you set your GNUstep root directory to be /usr/lib/GNUstep you get something like: /usr/lib/GNUstep/Applications; /usr/lib/GNUstep/Library; /usr/lib/GNUstep/Local; etc... As a side note, I set my hierarchy up similar to yours, except my $GNUSTEP_LOCAL_ROOT=/Local (pretty much like I suggested on the initial post). Stefan On 1/2/07, Chris B. Vetter [EMAIL PROTECTED] wrote: You can do that by modifying GNUstep.conf, e.g. during installation of gnustep-make: CC=gcc41 ./configure --with-system-root=/ --with-local-root=/ --with-network-root=/Network --with-user-config-file='~/Library/.GNUstep.conf' --with-user-dir='~' --with-user-defaults-dir='~/Library/Defaults' --with-config-file=/share/GNUstep.conf As you can see, I install everything in / -- that is, I will end up with /Applications /Library /Network (nostalgia) /Tools /share (which should really be in /Library). And instead of HOME/GNUstep/... I put everything directly in my home directory. Been using this 'set-up' for more than a year, and haven't encountered any problems (aside from moronicly written Makefiles and source code that insist on using hard-coded path names, like Addresses). -- Chris ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Richard Frith-Macdonald schrieb: On 29 Dec 2006, at 01:37, Lars Sonchocky-Helldorf wrote: Am 28.12.2006 um 17:37 schrieb Gregory John Casamento: Nikolaus, They would be wrong. GNUstep not an OS. They might be wrong, but it's not their fault. If we want people to get it right we'll have to explain it to them in a catchy way - even if that might include to rename gnustep-base to gnustep- foundation and gnustep-gui to gnustep-appkit. I actually have no problem at all with the idea of renaming ... in fact, for compatibility it might be nice if we could build them so that they could be used both as libraries and frameworks at the same time, so that cocoa developers could link to them the same way they do on macos. I don't know how to modify makefiles etc to build them that way, but it can't really be all that hard. I think it would be great if -base/-gui could be compiled as NATIVE_LIBRARY. I once took a shot at it, but the BaseAdditions part wrt apple-apple-apple made it very messy. I'm not sure if it could be split due to the interdependencies. Cheers, David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Gregory John Casamento schrieb: Matt, They would still be gnustep-foundation and gnustep-appkit.The idea is to have Foundation and AppKit in the name so that the users/developers can readily associate it with the equivalent libraries from Cocoa. Later, GJC ... oh OK, not sure if this helps much since we still install headers so the search paths for include files still have to take into accout a side by side installation of GNUstep and Cocoa anyway. In anycase, I remember that some Apple users would have liked to see BaseAdditions be built as a NATIVE_LIBRARY for apple-apple-apple. But as I'm not a Mac user, I'll drop out of this thread now. Cheers, David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Directories (Was: Re: Cocotron)
On Dec 30, 2006, at 4:32 PM, Stefan Bidigaray wrote: The only think that I don't like about the current implementation is the whole /System, /Local and /Network hierarchies (I'll refer to everything as if it was installed to /). I'm really bad at trying to say what on my mind cause it's a mess up there, but here goes. Why not make the /System hierarchy just be /? I know it really should be documented better, but with the current GNUstep system (make, etc) you can pretty much put things wherever you want using the GNUstep.conf file. See ./configure --help in gnustep-make and also read the docs on the GNUstep Configuration file here: http://www.gnustep.org/resources/documentation/Developer/Base/ Reference/index.html It really would be nicer though, if there was an option to setup the whole system to common layouts, like ./configure --with-macosx-layout or ./configure --with-fhs-layout (fhs layout still would need some extra changes to get it to work, though). ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Matt, They would still be gnustep-foundation and gnustep-appkit.The idea is to have Foundation and AppKit in the name so that the users/developers can readily associate it with the equivalent libraries from Cocoa. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Matt Rice [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED]; Lars Sonchocky-Helldorf [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]; Richard Frith-Macdonald [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Saturday, December 30, 2006 1:48:47 AM Subject: Re: Cocotron I'm not sure if renaming to AppKit and Foundation is a good thing, (though it'd surely simplify the base/gui makefiles a little which i'd be in favor of) unfortunately it would make it harder to install gnustep along side os x, where if we were compiling things as native-libs (which i believe was the suggestion, or maybe i'm wrong), people have done this in the past to use profiling tools, i've never tried it... maybe someone with some experience using GNUstep alongside osx will chime in. on os x, GNUstep binaries would have to be run with DYLD_FRAMEWORK_PATH set, where normal binaries would have to run without it, in order to find the correct version of appkit... i may still have patches to compile gui and base as native-libs named Foundation/AppKit though, i'll look for them... --- Gregory John Casamento [EMAIL PROTECTED] wrote: Yes, that's what I'm thinking I'm just saying it's best to do this after the next release. :) -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Lars Sonchocky-Helldorf [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Richard Frith-Macdonald [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 11:33:36 PM Subject: Re: Cocotron Am 29.12.2006 um 16:36 schrieb Gregory John Casamento: I believe that renaming is a good idea. It would make it clearer what's what. We'll need, of course, to do it when we have a release which breaks backwards compatibility. How about keeping symlinks for the existing stuff being created to ensure that? Later, GJC regards, Lars -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Lars Sonchocky-Helldorf [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 3:05:31 AM Subject: Re: Cocotron On 29 Dec 2006, at 01:37, Lars Sonchocky-Helldorf wrote: Am 28.12.2006 um 17:37 schrieb Gregory John Casamento: Nikolaus, They would be wrong. GNUstep not an OS. They might be wrong, but it's not their fault. If we want people to get it right we'll have to explain it to them in a catchy way - even if that might include to rename gnustep-base to gnustep- foundation and gnustep-gui to gnustep-appkit. I actually have no problem at all with the idea of renaming ... in fact, for compatibility it might be nice if we could build them so that they could be used both as libraries and frameworks at the same time, so that cocoa developers could link to them the same way they do on macos. I don't know how to modify makefiles etc to build them that way, but it can't really be all that hard. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
They would be wrong. GNUstep not an OS. http://www.gnustep.org/information/aboutGNUstep.html [EMAIL PROTECTED] schrieb: In my experience (from other discussuions about GNUstep and even with my mySTEP project), I think the reasons are manifold. What I have collected is: Another one just appeared in a German Cocoa developer discussion: * GNUstep is an incomplete operating system and not a GUI framework - people simply do not associate GUI with AppKit and Base with Foundation and therefore not GNUstep with Cocoa. I know it, You know it, we all here on this list know it - but people outside don't. That is the key issue to solve... Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Richard Frith-Macdonald schrieb: I actually have no problem at all with the idea of renaming ... in fact, for compatibility it might be nice if we could build them so that they could be used both as libraries and frameworks at the same time, so that cocoa developers could link to them the same way they do on macos. I don't know how to modify makefiles etc to build them that way, but it can't really be all that hard. That is basically the way the mySTEP makefile works. It builds e.g. the AppKit.framework hierarchy (Version/Current etc. incl. all links) through Xcode (but tht can also be done in a Makefile and adds a special Version/Linux-ARM which contains a) a libAppKit.so b) a symbolic link AppKit - libAppKit.so The compiler's CFLAGS gets passed as -L all Frameworks/*.framework/Versions/Current/Linux-ARM so that it finds -lAppKit as libAppKit.so Apple has added special code to gcc to search frameworks in all -F framework paths. I have not yet found a reasonable way to easily emulate this -F flag. -- hns ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Am 28.12.2006 um 17:47 schrieb [EMAIL PROTECTED]: Another one just appeared in a German Cocoa developer discussion: * GNUstep is an incomplete operating system and not a GUI framework - people simply do not associate GUI with AppKit and Base with Foundation and therefore not GNUstep with Cocoa. I know it, You know it, we all here on this list know it - but people outside don't. That is the key issue to solve... For me, I doubt this can be solved by a simple rename of the frameworks. People would still wait for the remaining parts to come. While the public appearance of the gnustep.org improved a lot over the last year, looking at a introduction page like http:// gnustep.org/experience/Startup.html neither the word Cocoa, AppKit, nor Foundation is even mentioned. If GNUstep wants to attract Cocoa developers, what stops one to point to the similarities to Cocoa: Introduction: GNUstep Startup is a compilation of the GNUstep core packages and gives you about the equivalent of what is known as Cocoa on Apple's Mac OS X, but fully cross platform. ... ... GNUstep Base: Like Cocoa's Foundation, the GNUstep Base library is a library of ... GNUstep Gui: Like Cocoa's AppKit, GNUstep Gui is a library of graphical user ... GNUstep Back: Unlike Cocoa, GNUstep comes with it's own graphics back-end to be more flexible about different platforms ... ... Additionally, I think some Xcode integration would be appreciated a lot. A few words about how to switch from Cocoa to GNUstep (find the other frameworks) and perhaps a Xcode template or two (Hello World- sized apps). Any sane developer will prefer to do one project in _one_ IDE, if that's possible. If they use Xcode already, there's not much point in trying to sell them Gorm or ProjectCenter. Not at the beginning, at least. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Cross-compilation/Development tools (was Re: Cocotron)
Markus, You said... Additionally, I think some Xcode integration would be appreciated a lot. A few words about how to switch from Cocoa to GNUstep (find the other frameworks) and perhaps a Xcode template or two (Hello World- sized apps). I agree with this. I believe that the ability to compile from Xcode to another platform using GNUstep is something that should be done. Any sane developer will prefer to do one project in _one_ IDE, if that's possible. If they use Xcode already, there's not much point in trying to sell them Gorm or ProjectCenter. Not at the beginning, at least. Gorm and ProjectCenter are there to provide a way for people to work on projects on Linux, BSD, Windows, or other environments without needing Mac OS X. Since Gorm is able to load and save nibs now, it's possible for a Mac developer to make changes when using GNUstep and bring that back to the Mac or for a developer who doesn't have a Mac to build an application that can be compiled on a Mac. For Mac developers bringing their stuff, they are a convenience. For every other developer who doesn't have a Mac, they are a necessity. That being said, I believe that ProjectCenter needs to incorporate some amount of xcode compatibility into itself. This would allow the developers to load and change Xcode projects from PC. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Markus Hitter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 4:00:01 PM Subject: Re: Cocotron Am 28.12.2006 um 17:47 schrieb [EMAIL PROTECTED]: Another one just appeared in a German Cocoa developer discussion: * GNUstep is an incomplete operating system and not a GUI framework - people simply do not associate GUI with AppKit and Base with Foundation and therefore not GNUstep with Cocoa. I know it, You know it, we all here on this list know it - but people outside don't. That is the key issue to solve... For me, I doubt this can be solved by a simple rename of the frameworks. People would still wait for the remaining parts to come. While the public appearance of the gnustep.org improved a lot over the last year, looking at a introduction page like http:// gnustep.org/experience/Startup.html neither the word Cocoa, AppKit, nor Foundation is even mentioned. If GNUstep wants to attract Cocoa developers, what stops one to point to the similarities to Cocoa: Introduction: GNUstep Startup is a compilation of the GNUstep core packages and gives you about the equivalent of what is known as Cocoa on Apple's Mac OS X, but fully cross platform. ... ... GNUstep Base: Like Cocoa's Foundation, the GNUstep Base library is a library of ... GNUstep Gui: Like Cocoa's AppKit, GNUstep Gui is a library of graphical user ... GNUstep Back: Unlike Cocoa, GNUstep comes with it's own graphics back-end to be more flexible about different platforms ... ... Additionally, I think some Xcode integration would be appreciated a lot. A few words about how to switch from Cocoa to GNUstep (find the other frameworks) and perhaps a Xcode template or two (Hello World- sized apps). Any sane developer will prefer to do one project in _one_ IDE, if that's possible. If they use Xcode already, there's not much point in trying to sell them Gorm or ProjectCenter. Not at the beginning, at least. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Am 29.12.2006 um 16:36 schrieb Gregory John Casamento: I believe that renaming is a good idea. It would make it clearer what's what. We'll need, of course, to do it when we have a release which breaks backwards compatibility. How about keeping symlinks for the existing stuff being created to ensure that? Later, GJC regards, Lars -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Lars Sonchocky-Helldorf [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 3:05:31 AM Subject: Re: Cocotron On 29 Dec 2006, at 01:37, Lars Sonchocky-Helldorf wrote: Am 28.12.2006 um 17:37 schrieb Gregory John Casamento: Nikolaus, They would be wrong. GNUstep not an OS. They might be wrong, but it's not their fault. If we want people to get it right we'll have to explain it to them in a catchy way - even if that might include to rename gnustep-base to gnustep- foundation and gnustep-gui to gnustep-appkit. I actually have no problem at all with the idea of renaming ... in fact, for compatibility it might be nice if we could build them so that they could be used both as libraries and frameworks at the same time, so that cocoa developers could link to them the same way they do on macos. I don't know how to modify makefiles etc to build them that way, but it can't really be all that hard. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Yes, that's what I'm thinking I'm just saying it's best to do this after the next release. :) -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Lars Sonchocky-Helldorf [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Richard Frith-Macdonald [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 11:33:36 PM Subject: Re: Cocotron Am 29.12.2006 um 16:36 schrieb Gregory John Casamento: I believe that renaming is a good idea. It would make it clearer what's what. We'll need, of course, to do it when we have a release which breaks backwards compatibility. How about keeping symlinks for the existing stuff being created to ensure that? Later, GJC regards, Lars -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Richard Frith-Macdonald [EMAIL PROTECTED] To: Lars Sonchocky-Helldorf [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, December 29, 2006 3:05:31 AM Subject: Re: Cocotron On 29 Dec 2006, at 01:37, Lars Sonchocky-Helldorf wrote: Am 28.12.2006 um 17:37 schrieb Gregory John Casamento: Nikolaus, They would be wrong. GNUstep not an OS. They might be wrong, but it's not their fault. If we want people to get it right we'll have to explain it to them in a catchy way - even if that might include to rename gnustep-base to gnustep- foundation and gnustep-gui to gnustep-appkit. I actually have no problem at all with the idea of renaming ... in fact, for compatibility it might be nice if we could build them so that they could be used both as libraries and frameworks at the same time, so that cocoa developers could link to them the same way they do on macos. I don't know how to modify makefiles etc to build them that way, but it can't really be all that hard. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
FOSDEM 2007 All developers Meeting (was Re: Cocotron)
you're right - it is very desirable to discuss this topic with all GSsteppers, althoug we may not be able to do so :( But I see this During FOSDEM we will have a Devroom with 31 seats and a beamer. And, we can add a time slot for such a discussion. The only solution we need is someone who takes care of it (moderator + organizer). session only as a possibility to exchange some ideas which we have to present and discuss further on this mailing list. Of couse, having a GNUstep Conference Stream would be very cool :) How? Webcam + skype??? May FOSDEM provide a related infrastructure? Yes, there will be WLAN provided by all. @Helge: We should start preparing this session...seems to be important :) At the beginning of the next week i can start on this topic. Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Richard Frith-Macdonald schrieb: It's unfortunate that all of these efforts are going on in parallel with GNUstep (libFoundation, Cocotron, AJRFoundation) instead of people getting together and collaborating on one project. I very strongly agree with that ... it always saddens me to see people re-inventing what GNUstep already does and duplicating effort rather than joining in. I wish I know how to persuade people to contribute to a joint effort. Perhaps we should try posting requests for volunteers to all these projects and to any other mailing lists where objc developers might hang out? I guess we would need to figure out *why* (assuming reasons other than simple ignorance) people do their own thing rather than a group effort, and try to address any mistaken impressions of the project in any email we sent out. However, my impression is that unfortunately the reason is often either religious differences over licensing/copyright or simple desire for total control over their own project, and no reasoning will convince people in those cases :-( Even so, it's probably worth a try. In conclusion, GNUstep is a much more mature and complete project than Cocotron is. Yes. We should try to get them on board. In my experience (from other discussuions about GNUstep and even with my mySTEP project), I think the reasons are manifold. What I have collected is: * there is no clear roadmap/release plan (which would indicate project acitivity and agility) * it is unclear who is working on what (sometimes, great individualistically crafted building blocks appear on the surface) * there is no regular call for patches and an organisation that visibly collects and merges them (giving the impression that working on a fork is faster and easier to plan than participating) * it is unclear how to contribute major changes that affect several parts (this also opens risk to fork) * sometimes GNUstep appears to want to be the best and only solution per definition, i.e. is embracing everything (like this discussion shows to some extent) * tied to a license (this argument I personally don't understand - Linux is *very* successful with GPLLGPL) * issues with GNUstep makefile * issues with Window Managers * there is no regular *distribution* to base experience on (would convice people easily that it is worth looking into the latest GNUstep) So, I think the GNUstep project needs a little more discussion about directions and project organization - and needs some active marketing utilities. FOSDEM 2007 will be a good chance to start that. Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Nikolaus, They would be wrong. GNUstep not an OS. http://www.gnustep.org/information/aboutGNUstep.html Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Thursday, December 28, 2006 8:56:28 AM Subject: Re: Cocotron [EMAIL PROTECTED] schrieb: In my experience (from other discussuions about GNUstep and even with my mySTEP project), I think the reasons are manifold. What I have collected is: Another one just appeared in a German Cocoa developer discussion: * GNUstep is an incomplete operating system and not a GUI framework - people simply do not associate GUI with AppKit and Base with Foundation and therefore not GNUstep with Cocoa. Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Yen-Ju, RFM and I wrote the author and his feeling was that it was mainly the license and that he and others felt like GNUstep wasn't meeting the goal that they wanted, which was, as Cocotron demonstrates, to be able to cross-compile apps from OS X to Windows, Linux or others. GNUstep currently has a more complete implementation of the Cocoa APIs and other APIs, such as EOF, than Cocotron does. GNUstep also has a complete development environment which allows developers to develop on GNUstep and port their apps easily to Mac. There are advantages to both projects, and, undoubtedly, things that both can learn from the other. I have no desire, at this moment, to convince the Cocotron guys to join us, I just wanted to understand their motivations and foster an atmosphere of collaboration. Competition is a way of life, and it's healthy. :) Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Yen-Ju Chen [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Thursday, December 28, 2006 1:27:42 PM Subject: Re: Cocotron On 12/28/06, Gregory John Casamento [EMAIL PROTECTED] wrote: Nikolaus, They would be wrong. GNUstep not an OS. http://www.gnustep.org/information/aboutGNUstep.html From a practical point of view, here is my opinions: For GUI/AppKit, there is no way to persuade Cocotron to join because the approach is quite different. And frankly, sometimes it is nice to have two implementation so that we can compare the pros and cons and learn from each other. Cocotron is under MIT license, which makes it easier for GNUstep to borrow their codes. :) And I do believe that GNUstep has less win32 experts than Cocotron. For the Base/Foundation, the priority should be to merge libFoundation first, and see whether mySTEP want to joing/use gnustep-base, and then Cocotron. So in short, there is no need to concern/worry/persuade Cocotron in the near future. That's is my 2 cents. Yen-Ju Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Thursday, December 28, 2006 8:56:28 AM Subject: Re: Cocotron [EMAIL PROTECTED] schrieb: In my experience (from other discussuions about GNUstep and even with my mySTEP project), I think the reasons are manifold. What I have collected is: Another one just appeared in a German Cocoa developer discussion: * GNUstep is an incomplete operating system and not a GUI framework - people simply do not associate GUI with AppKit and Base with Foundation and therefore not GNUstep with Cocoa. Nikolaus ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 28, 2006, at 2:54 PM, Gregory John Casamento wrote: Yen-Ju, RFM and I wrote the author and his feeling was that it was mainly the license and that he and others felt like GNUstep wasn't meeting the goal that they wanted, which was, as Cocotron demonstrates, to be able to cross-compile apps from OS X to Windows, Linux or others. Incidentally, what exactly was their plan for non-Windows OS's? I looked at the code briefly and saw lots of W32 calls embedded everywhere. I guess maybe they could throw the whole thing on top of WINE, at the cost of some performance hit.. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
I'm not sure. That is what their website says, but, like you said... from looking at their code, it doesn't look like they can currently work on non-Windows operating systems. I didn't test this, but I saw the same thing your describing. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Adrian Robert [EMAIL PROTECTED] To: Discuss-GNUStep GNUstep discuss-gnustep@gnu.org Sent: Thursday, December 28, 2006 3:16:44 PM Subject: Re: Cocotron On Dec 28, 2006, at 2:54 PM, Gregory John Casamento wrote: Yen-Ju, RFM and I wrote the author and his feeling was that it was mainly the license and that he and others felt like GNUstep wasn't meeting the goal that they wanted, which was, as Cocotron demonstrates, to be able to cross-compile apps from OS X to Windows, Linux or others. Incidentally, what exactly was their plan for non-Windows OS's? I looked at the code briefly and saw lots of W32 calls embedded everywhere. I guess maybe they could throw the whole thing on top of WINE, at the cost of some performance hit.. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
FOSDEM participation (was: Re: Cocotron)
Am 27.12.2006 um 01:06 schrieb Helge Hess: On Dec 27, 2006, at 24:56, Oliver Langer wrote: i read the whole thread just a couple of seconds ago and want to refer to the Discussion at FOSDEM only. The idea behind is to discuss what to do with all the utility packages which have been developed for or based on GNUstep in the past. We may also take the time to present/name some of them. I suppose this is everything in GNUstep which is not Foundation/ AppKit. eg Renaissance, gnustep-base extensions (eg MIME, XML), GDL, ... @Helge: We should start preparing this session...seems to be important :) At the beginning of the next week i can start on this topic. I'm away for holidays till Jan 7th :-) And honestly I won't have a lot of time in January either. I'm already quite happy if we get the FOSDEM somewhat organized ... So far there seems to be amazingly little feedback and I wonder who of the GNUstep team is actually going to visit FOSDEM :-/ If nothing outstanding happens I will join in this year again. Last time I checked the Wiki was missing the attendee table, which was the most important part of the Wiki page. Come on, copying from 2006 it took me just two minutes. Now you even don't need to add yourself, I did that for you. Greets, Helge regards, Lars ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Gregory, On Sunday 24 December 2006 04:15, Helge Hess wrote: On Dec 24, 2006, at 03:00, Gregory John Casamento wrote: Now that I'm Chief Maintainer [...] I'm concentrating my efforts on focusing the project on the goal I stated above. GNUstep is an crossplatform development environment and API only. [...] It is not a desktop, nor is it going to be an OS clone. May I ask you to CC the important statements about the project direction to the list? I'm following the discussion and did not find your letter with the things you stated above. I'm sure Helge makes a fair job quoting you, but still it would be easier - and more fair to you - to get it from you directly. While I'm totally agree with API only course there was another thing (also brought by Helge Hess) where I agree less: From: Helge Hess [EMAIL PROTECTED] On Dec 24, 2006, at 24:35, Gregory John Casamento wrote: The projects libFoundation, Cocotron and AJRFoundation are re- implementations of Foundation/AppKit. There is no reason, aside from obstinance or ego which should cause so many projects with similar or identical goals to develop things in parallel. It is, purely and simply, an egregious waste of time and effort. Well understood, but not reasonable at all. I understand your disappointment, but it can't be just ego. Something must have not worked in GNUstep for them. I think it's worth to understand what it was. Thank you, Tima ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Am 25.12.2006 um 15:41 schrieb Fred Kiefer: I do fully agree in them not seeing the need for yet another GNUstep clone, but this is really just our view of it. If we write about cocotron that way, we will never reach it's programmers. What we should try to do is understand how they think about their project themselves. See what is good about it and try to learn from it. Very good point. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Am 26.12.2006 um 09:26 schrieb Tima Vaisburd: Gregory, On Sunday 24 December 2006 04:15, Helge Hess wrote: On Dec 24, 2006, at 03:00, Gregory John Casamento wrote: Now that I'm Chief Maintainer [...] I'm concentrating my efforts on focusing the project on the goal I stated above. GNUstep is an crossplatform development environment and API only. [...] It is not a desktop, nor is it going to be an OS clone. May I ask you to CC the important statements about the project direction to the list? I'm following the discussion and did not find your letter with the things you stated above. Look here: http://digg.com/programming/ GNUstep_does_what_Apple_can_t_Extend_Cocoa_to_Linux_Windows regards, Lars ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On 26 Dec 2006, at 10:22, Renaud Molla wrote: First of all, I join the cocotron thread after several posts and may say things already said in previous messages. I tried the cocotron textedit example, and to be true, i first thought this was an hoax since I downloaded it and it worked as is. So i changed the NIB with Interface Builder to check this was really true, addes a Label and A button, and it worked, so i guess claims that they're experiencing nib reading problems can't be totally true. What stroke me (positively) is that their example worked after unzipping, nothing more to do. The application integrates well within the OS look and feel, i mean, I'm a mac os x user and really like the top menu bar and the floating menu concept of openstep, but to most windows or other APIs (gtk/kde/etc...) with menus right below the title bar, the menus are rather reluctant. (what a pity however). I think it really is straightforward to see that cocotron and gnustep do not share the same goals. They must have common subprojects in order to comply with the OpenStep specifications, but it is clear that the end user/deployment philosophy is not the same. I think that is partly true ... only partly, because I think a large part of the issue is simply that GNUstep unfortunately does not have any mswindows experienced programmers. Where I think you are right about philosophy is actually something I've noticed common to all the non-gnustep variations I've seen... GNUstep tries to produce libraries which are fully MacOS-X compatible, and the emphasis of development is on 'fully' with completeness and correctness of the implementation being a major focus. The various Cocoa-clone projects seem to be much less devoted to correctness/completeness of the library implementation, but instead focus on producing a usable subset of roughly correct code, which can be 1. Easily used by Cocoa programmers (eg uses the MacOS-X development tools) 2. Easy for end-users to install/run on a particular target system. This gives GNUstep developers a strange view of alternative projects ... their codebase seems to be woefully incomplate/immature/ buggy from our point of view, and we therefore tend to be dismissive. In part we have developed this attitude because people always complain about missing features ... but there will always be missing features for people to complain about. However, the perception of new users actually wanting to try out the software is the opposite of ours ... because (in the case of cocoa developers) they can work with the Cocoa development tools they are used to, and because there are smoothly working demo applications, the alternative projects can appear better than GNUstep. I imagine that, once they start writing applications with a non- GNUstep framework they will be frustrated by the lack of completeness and immaturity ... but by then they have bought in to the software psychologically ... and are likely to fix bugs and implement missing features/classes. This is exactly what GNUstep lacks ... we need to lower the entry barrier and make things look easy so that people will start using GNUstep ... once they have started developing with it they are more likely to contribute. And while it's a radical departure, I think it's probably now more important to lower the usability barrier than it is to fix bugs and add missing features. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Actually, after a second look the nib does contain the connections. I'm not sure why I didn't see them at first. From looking at the decoding logic, there are keys missing in classes such as NSCell and others. The nib decoding isn't complete and the encoding is not present. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Renaud Molla [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Tuesday, December 26, 2006 5:22:01 AM Subject: Re: Cocotron First of all, I join the cocotron thread after several posts and may say things already said in previous messages. I tried the cocotron textedit example, and to be true, i first thought this was an hoax since I downloaded it and it worked as is. So i changed the NIB with Interface Builder to check this was really true, addes a Label and A button, and it worked, so i guess claims that they're experiencing nib reading problems can't be totally true. What stroke me (positively) is that their example worked after unzipping, nothing more to do. The application integrates well within the OS look and feel, i mean, I'm a mac os x user and really like the top menu bar and the floating menu concept of openstep, but to most windows or other APIs (gtk/kde/etc...) with menus right below the title bar, the menus are rather reluctant. (what a pity however). I think it really is straightforward to see that cocotron and gnustep do not share the same goals. They must have common subprojects in order to comply with the OpenStep specifications, but it is clear that the end user/deployment philosophy is not the same. Renaud. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
// // Sorry for Richard Frith-Macdonald that may read this message twice, // I replied to him but didn't post the message to the mailing list. // I agree with you, depending on one's knowledge of computers/systems (and many other things), the focus when comparing systems may be very different. Unexperienced users may find themselves lost with 'exotic' screen arrangement (menus, scrollbars ;-), etc. ) and consider something is crap when compared to other things because they can't compare using other means because they don't have the knowledge to do so. However, software developers (should) try to view their product with the end user point of view, therefore, no matter how elegant the backend design can be, if it was to be classified as garbage by the users, this design would simply be discarded. So in the end, this leads to the use of other APIs like Qt to develop cross platforms products. On Dec 26, 2006, at 12:37 PM, Richard Frith-Macdonald wrote: On 26 Dec 2006, at 10:22, Renaud Molla wrote: First of all, I join the cocotron thread after several posts and may say things already said in previous messages. I tried the cocotron textedit example, and to be true, i first thought this was an hoax since I downloaded it and it worked as is. So i changed the NIB with Interface Builder to check this was really true, addes a Label and A button, and it worked, so i guess claims that they're experiencing nib reading problems can't be totally true. What stroke me (positively) is that their example worked after unzipping, nothing more to do. The application integrates well within the OS look and feel, i mean, I'm a mac os x user and really like the top menu bar and the floating menu concept of openstep, but to most windows or other APIs (gtk/kde/etc...) with menus right below the title bar, the menus are rather reluctant. (what a pity however). I think it really is straightforward to see that cocotron and gnustep do not share the same goals. They must have common subprojects in order to comply with the OpenStep specifications, but it is clear that the end user/deployment philosophy is not the same. I think that is partly true ... only partly, because I think a large part of the issue is simply that GNUstep unfortunately does not have any mswindows experienced programmers. Where I think you are right about philosophy is actually something I've noticed common to all the non-gnustep variations I've seen... GNUstep tries to produce libraries which are fully MacOS-X compatible, and the emphasis of development is on 'fully' with completeness and correctness of the implementation being a major focus. The various Cocoa-clone projects seem to be much less devoted to correctness/completeness of the library implementation, but instead focus on producing a usable subset of roughly correct code, which can be 1. Easily used by Cocoa programmers (eg uses the MacOS-X development tools) 2. Easy for end-users to install/run on a particular target system. This gives GNUstep developers a strange view of alternative projects ... their codebase seems to be woefully incomplate/ immature/buggy from our point of view, and we therefore tend to be dismissive. In part we have developed this attitude because people always complain about missing features ... but there will always be missing features for people to complain about. However, the perception of new users actually wanting to try out the software is the opposite of ours ... because (in the case of cocoa developers) they can work with the Cocoa development tools they are used to, and because there are smoothly working demo applications, the alternative projects can appear better than GNUstep. I imagine that, once they start writing applications with a non- GNUstep framework they will be frustrated by the lack of completeness and immaturity ... but by then they have bought in to the software psychologically ... and are likely to fix bugs and implement missing features/classes. This is exactly what GNUstep lacks ... we need to lower the entry barrier and make things look easy so that people will start using GNUstep ... once they have started developing with it they are more likely to contribute. And while it's a radical departure, I think it's probably now more important to lower the usability barrier than it is to fix bugs and add missing features. -- - Orange vous informe que cet e-mail a ete controle par l'anti-virus mail.Aucun virus connu a ce jour par nos services n'a ete detecte. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Lacking encoding, perhaps. Lacking key elements of nib decoding doesn't make sense at all.Their example may work, but I have a feeling that many, more complex apps, won't. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Renaud Molla [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Tuesday, December 26, 2006 10:52:25 AM Subject: Re: Cocotron These lacks seem somewhat logical within their goal that seems to be enabling cross compilations from Mac OS X to Windows, and the use of OS X tools to create software. On Dec 26, 2006, at 4:47 PM, Gregory John Casamento wrote: Actually, after a second look the nib does contain the connections. I'm not sure why I didn't see them at first. From looking at the decoding logic, there are keys missing in classes such as NSCell and others. The nib decoding isn't complete and the encoding is not present. GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Renaud Molla [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Tuesday, December 26, 2006 5:22:01 AM Subject: Re: Cocotron First of all, I join the cocotron thread after several posts and may say things already said in previous messages. I tried the cocotron textedit example, and to be true, i first thought this was an hoax since I downloaded it and it worked as is. So i changed the NIB with Interface Builder to check this was really true, addes a Label and A button, and it worked, so i guess claims that they're experiencing nib reading problems can't be totally true. What stroke me (positively) is that their example worked after unzipping, nothing more to do. The application integrates well within the OS look and feel, i mean, I'm a mac os x user and really like the top menu bar and the floating menu concept of openstep, but to most windows or other APIs (gtk/kde/etc...) with menus right below the title bar, the menus are rather reluctant. (what a pity however). I think it really is straightforward to see that cocotron and gnustep do not share the same goals. They must have common subprojects in order to comply with the OpenStep specifications, but it is clear that the end user/deployment philosophy is not the same. Renaud. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep -- - Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
That's true, i didn't notice you found other things missing apart from encoding. Renaud. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Tuesday 26 December 2006 03:24, Lars Sonchocky-Helldorf wrote: Am 26.12.2006 um 09:26 schrieb Tima Vaisburd: Gregory, [...] May I ask you to CC the important statements about the project direction to the list? Look here: http://digg.com/programming/ GNUstep_does_what_Apple_can_t_Extend_Cocoa_to_Linux_Windows I can't follow this link, did you mean http://heronsperch.blogspot.com/2006/12/what-gnustep-is-and-is-not.html and http://heronsperch.blogspot.com/2006/12/plans-for-change.html ? I could find the information, thank you, I was more talking about a courtesy to a potential reader - it seems more appropriate to include mailing list in replies to mailiing list messages. Thanks again, Tima ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Gregory, On 24.12.2006, at 03:00, Gregory John Casamento wrote: snip the goal I stated above. GNUstep is an crossplatform development environment and API only. It is not a desktop, nor is it going to be an OS clone. I'd say clean up www.gnustep.org then, as it (still) says: GNUstep is ... ...a desktop. You can read that in the main introduction: http://www.gnustep.org/information/aboutGNUstep.html ;-) Anyway, please would you explain why you think that programmers should/will use GNUstep as their primary API for GUI applications if there is no native environment for GNUstep apps? Do you really believe GNUstep GUI apps will - one day (...) - be perfectly integrated into Windows, X11 and maybe OS X so that the users by then won't able to tell the difference between a GNUstep GUI app and an application written using the native technologies of their platform/ desktop environment? I hope you have a good plan here, because not even NeXT succeeded in this respect, nor Trolltech (with Qt) or other similar projects. But if GNUstep won't provide this level of integration, why should anybody use gnustep-gui then? I'm really curious how you see this as new chief maintainer of GNUstep and also Gorm. cheers, -Phil ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Oliver, I'm wondering if there's any way... since I may not be able to make it there physically, for me to participate in the discussion via telephone. This is something that I would very much like to participate actively in instead of hearing and commenting on what happened after the fact. Does anyone know of a service that can be used for teleconferencing that's relatively cheap? Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Oliver Langer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Helge Hess [EMAIL PROTECTED]; GNUstep Discussion discuss-gnustep@gnu.org Sent: Tuesday, December 26, 2006 6:56:32 PM Subject: Re: Cocotron Hi @all, i read the whole thread just a couple of seconds ago and want to refer to the Discussion at FOSDEM only. The idea behind is to discuss what to do with all the utility packages which have been developed for or based on GNUstep in the past. We may also take the time to present/name some of them. @Helge: We should start preparing this session...seems to be important :) At the beginning of the next week i can start on this topic. @Gregory: You are right! In case we run this session definitely have to document it - i can do this then. Regards, Oliver Am 24.12.2006 um 17:56 schrieb Gregory John Casamento: Helge, I'll write some other mail and then stop posting :-) I would be very happy to discuss those things on FOSDEM, this is much more efficient and less error prone (misunderstandings happen to easily ;-). Lets find out there what can be done to reduce duplication of efforts. The problem with Discussing it at FOSDEM is that I, and many others, may not be at FOSDEM. If you guys do end up discussing this there, please post a followup to the list. Thanks, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Hi Gregory, you're right - it is very desirable to discuss this topic with all GSsteppers, althoug we may not be able to do so :( But I see this session only as a possibility to exchange some ideas which we have to present and discuss further on this mailing list. Of couse, having a GNUstep Conference Stream would be very cool :) How? Webcam + skype??? May FOSDEM provide a related infrastructure? Best regards, Oliver Am 27.12.2006 um 01:07 schrieb Gregory John Casamento: Oliver, I'm wondering if there's any way... since I may not be able to make it there physically, for me to participate in the discussion via telephone. This is something that I would very much like to participate actively in instead of hearing and commenting on what happened after the fact. Does anyone know of a service that can be used for teleconferencing that's relatively cheap? Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Oliver Langer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Helge Hess [EMAIL PROTECTED]; GNUstep Discussion discuss-gnustep@gnu.org Sent: Tuesday, December 26, 2006 6:56:32 PM Subject: Re: Cocotron Hi @all, i read the whole thread just a couple of seconds ago and want to refer to the Discussion at FOSDEM only. The idea behind is to discuss what to do with all the utility packages which have been developed for or based on GNUstep in the past. We may also take the time to present/name some of them. @Helge: We should start preparing this session...seems to be important :) At the beginning of the next week i can start on this topic. @Gregory: You are right! In case we run this session definitely have to document it - i can do this then. Regards, Oliver Am 24.12.2006 um 17:56 schrieb Gregory John Casamento: Helge, I'll write some other mail and then stop posting :-) I would be very happy to discuss those things on FOSDEM, this is much more efficient and less error prone (misunderstandings happen to easily ;-). Lets find out there what can be done to reduce duplication of efforts. The problem with Discussing it at FOSDEM is that I, and many others, may not be at FOSDEM. If you guys do end up discussing this there, please post a followup to the list. Thanks, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Sorry to join this discussion so late, I had other things to do the last few days :-) Let my state first that I don't like the way most posters on this mailing list are addressing the subject. I do fully agree in them not seeing the need for yet another GNUstep clone, but this is really just our view of it. If we write about cocotron that way, we will never reach it's programmers. What we should try to do is understand how they think about their project themselves. See what is good about it and try to learn from it. Only after having done that step should we go out and ask them why they don't join GNUstep. Doing so in a long mail that lists what we like about their project and their code, is something different than sending out mails that list what GNUstep does a lot better. Sure GNUstep is more complete in almost any regard, at least I hope so having spend so much time on it :-) Still it is very impressive to see how much the developers of cocotron have achieved in rather little time. If I understand their comments correctly there are just two main developers. But if they keep up the current speed they will overtake GNUstep in a year or two. So what do I find great in this project? Some of these points have already been listed by others and you may have other items to add. - Framework support for MS Windows. This is something that should go back into the main line of the GNU binary utilities and thereby help GNUstep as well. - Basic CoreGraphics library. it really makes live easier for people porting over from MacOSX. - Cross-compilation from XCode. This is no must for GNUstep, but again it makes live easier. - Aiming for MacOS 10.4, where GNUstep is still lagging behind. - Grouping class files that belong together in sub directories. - Clean code without all the backwards compatible stuff we sometimes need in GNUstep. - Consistent coding style. OK, this is much easier to achieve when the coding gets done by just two people in one year. Still, I find it makes code so much easier to read. - Their blog (http://www.cocotron.org/blog/) is much more fun then the GNUstep ones :-) I would expect that even when we all agree, to take over most of these points from cocotron (which I don't expect based on the previous discussion), still the cocotron people will keep up their own separate project. Fine for me. I think the LGPL is important and copyright assignment to the FSF is too. If somebody disagrees here, there is nothing to be done. What we should try to reach anyway is a mutually agreed statement about the similarities and differences between GNUstep, cocotron, mySTEP and libFoundation that should be placed on all different web sites. That will make it easier for users to choose which framework they want to build on. Of course, I hope it will be GNUstep most of the time. Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Fred, No one is putting down Cocotron. My earlier assessment wasn't meant as a negative, only to represent what I had found in Cocotron in comparison to GNUstep after a quick review. You are right in the sense that there are things we can learn from Cocotron. They have done some pretty interesting things. That being said... we are simply wondering why, when GNUstep is the most visible of all Cocoa clones, someone would go through so much trouble to duplicate our efforts. It's a very understandable question. As far as understanding how they think, Richard and I have been talking to them. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Discussion discuss-gnustep@gnu.org; Helge Hess [EMAIL PROTECTED] Sent: Monday, December 25, 2006 9:41:47 AM Subject: Re: Cocotron Sorry to join this discussion so late, I had other things to do the last few days :-) Let my state first that I don't like the way most posters on this mailing list are addressing the subject. I do fully agree in them not seeing the need for yet another GNUstep clone, but this is really just our view of it. If we write about cocotron that way, we will never reach it's programmers. What we should try to do is understand how they think about their project themselves. See what is good about it and try to learn from it. Only after having done that step should we go out and ask them why they don't join GNUstep. Doing so in a long mail that lists what we like about their project and their code, is something different than sending out mails that list what GNUstep does a lot better. Sure GNUstep is more complete in almost any regard, at least I hope so having spend so much time on it :-) Still it is very impressive to see how much the developers of cocotron have achieved in rather little time. If I understand their comments correctly there are just two main developers. But if they keep up the current speed they will overtake GNUstep in a year or two. So what do I find great in this project? Some of these points have already been listed by others and you may have other items to add. - Framework support for MS Windows. This is something that should go back into the main line of the GNU binary utilities and thereby help GNUstep as well. - Basic CoreGraphics library. it really makes live easier for people porting over from MacOSX. - Cross-compilation from XCode. This is no must for GNUstep, but again it makes live easier. - Aiming for MacOS 10.4, where GNUstep is still lagging behind. - Grouping class files that belong together in sub directories. - Clean code without all the backwards compatible stuff we sometimes need in GNUstep. - Consistent coding style. OK, this is much easier to achieve when the coding gets done by just two people in one year. Still, I find it makes code so much easier to read. - Their blog (http://www.cocotron.org/blog/) is much more fun then the GNUstep ones :-) I would expect that even when we all agree, to take over most of these points from cocotron (which I don't expect based on the previous discussion), still the cocotron people will keep up their own separate project. Fine for me. I think the LGPL is important and copyright assignment to the FSF is too. If somebody disagrees here, there is nothing to be done. What we should try to reach anyway is a mutually agreed statement about the similarities and differences between GNUstep, cocotron, mySTEP and libFoundation that should be placed on all different web sites. That will make it easier for users to choose which framework they want to build on. Of course, I hope it will be GNUstep most of the time. Cheers, Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 1:17 AM, Richard Frith-Macdonald wrote: (though it could well be that their windows gui looks/behaves better than GNUstep's) Has anyone out there been able to run their test app under Windows -- if so, how? I tried running TextEditor.exe and just got something like This application has caused and error and must be shut down, under Windows 2000. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On 24 Dec 2006, at 02:00, Helge Hess wrote: On Dec 24, 2006, at 02:00, Yen-Ju Chen wrote: But I don't understand the difficulty of merging libFoundation and GNUstep-base. Well, then just do it! :-) It doesn't make a lot of sense to argue about it, if its trivial, just demonstrate it :-) Fair comment ... though (unless you have already done so) I think you would need to assign copyright to the FSF before it would be worth addressing technical issues. In the past I have often posted the issues we encountered, but some of the problematic areas are: a) KVC support b) FHS support c) release policies (aka no stable releases promoted) d) various minors e) packaging SOPE/OGo works perfectly fine on libFoundation *and* Cocoa, but it doesn't work with GNUstep. Now its quite some research work to find out why and fix it. Sure, but people will help if you want to do it ... however we need someone on the SOPE/OGo side, who understands how it all works and what the problems are, to list issues in enough detail to make it a reasonable way to spend time. For instance, pointing out what (if anything) is wrong with KVC support in GNUstep-base, rather than just saying that the area is problematic. I believe it can also support the extension in libFoundation if someone asks. Neither SOPE nor OGo depend on libFoundation. In fact both work just fine on Cocoa. Because you took the effort to port/develop for cocoa. I haven't spent much time looking at SOPE/OGo, but what time I did spend on it was enough to notice some #ifdef options etc to cope with the different systems. But if license is the issue, there is almost nothing people can do. I'm fine with LGPL, this was never a point for me. I don't know whether it was a strong point for Ovidiu when he started libFoundation, but I don't think so. I believe Ovidiu objected to assigning copyright to the FSF more than licensing. At least, that was what I understood from my few email conversations with him. As for the place to install (/usr/loca/lib or GNUstep/System/ Libraries), gnustep-base works on both ways with right settings. Even if this is the case (nobody seems to use it!) I've tried it out, just to check it works ... but of course I'm familiar/happy with the normal layout, so I don't do it routinely. In practice you are probably correct hat nobody uses it (though I'm often surprised by what the silent users of the software turn out to be doing). producing packages which install it properly also takes some more days(/weeks). Yes, good packaging is very time consuming. I certainly can't write gnustep-make packages which install my software into /usr/local out of the box? I probably need to manually move gnustep-base and do all the right settings etc? As a rough guess I think it would take about 2...4 weeks to get a (deployable) port. Its the typical 90/10 rule that the last 10% take 90% the time. We don't need a prototype showing SOPE/OGo running on gstep-base, but a solid solution meeting basic QA expectations. How about spending the couple of days to get a prototype, then publicise it and let other people find the rough edges and smooth them out? Actually I do think that gstep-base is slowly improving (adding FHS etc), but I suppose the issue is that the core developers have a different viewpoint on it (ie they don't think that proper FHS support or Unix/Linux integration is crucial etc). Well, only Nicola works on gnustep-make generally (you are probably the second most expert person on gnustep-make after him) and you know how busy he is on other things. If you have tracked the mailing lists, you should be aware that all the core developers are in favor of having FHS compliant installation available as an option. So, since you are probably the person best placed to do it, and since you know we would be happy to accept such a contribution, why not have a chat with Nicola (to avoid any clash if you are both working on the same thing) and just add it? Anyways. If someone wants to do the port, you are very welcome and of course you will get assistence. I still consider it a goal to move to gstep-base, but at the current pace this will take some additional 3 years. Probably we have moved to Mono till then ;- As I've said, I'm interested in helping/doing this ... but I've got a lot of other stuff I want to do too, so I need pointing in the right direction to work in small, managable chunks. I imagine that, if you could do make package stuff (ie install everything in the places you want it) and point me to specific issues in the base library, I can address the base library issues. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
--- Helge Hess [EMAIL PROTECTED] wrote: On Dec 23, 2006, at 20:32, Richard Frith-Macdonald wrote: I very strongly agree with that ... it always saddens me to see people re-inventing what GNUstep already does and duplicating effort rather than joining in. I can't follow that, it sounds like everyone is re-inventing GNUstep all the time. Which isn't the case. There is just one new project which popped up, and apparently also has a focus which GNUstep just doesn't have (Windows deployment). In fact a two or so years ago I suggested to work together which was rejected by GNUstep. Replace libFoundation with gnustep-base, gnustep- web with SOPE-appserver, SOPE-imap with GNUmail, etc. Eliminate DUPs. Fact is that GNUstep also won't let go for better alternatives due to individual, personal reasons ... IMHO GNUstep at least appears to be much more religious/uncooperative here than any other people in the same sector. Possibly because more people with vastly diverging expectations are involved. just figured i would post a link to the thread i believe you are referring to here http://lists.gnu.org/archive/html/discuss-gnustep/2004-03/msg8.html it seems to be an offshoot of a thread started on GSWHackers and the archive for that list doesn't go back to 2004 from what i read, there was some personal differences and what not, but a large problem was the copyright assignment issue there was some discussion at the end about a kits.gnustep.org for non-FSF assigned copyright since this thread theres been a project on gna created for non-assigned code (albeit currently empty) https://gna.org/projects/gnustep-nonfsf/ anyhow if people are adamant about maintaining their FSF copyright assigned code or their own copyrighted code a change of venue won't really achieve much besides a change of venue... as much as i hate to say it GNUstep's catch all tendancy doesn't seem to be helping resolve these issues, and this has little if anything to do with cocotron, but i'm not sure what is hindering you from replacing SOPE-imap with GNUMail/Pantomime, and i'm not actually sure if GNUMail is even copyright assigned to the FSF it doesn't say Copyright (c) ... Free Software Foundation anywhere... so i'm wondering if project cohesion is reducing collaboration in this case, because GSWeb and SOPE-appserver cannot get along is that hindering progress replacing libFoundation with gnustep-base, it seems possible, definitely the more people involved the complicated communication becomes, because of the different stakeholders and their individual objectives... or alternately if GSWeb and GNUstep core were separate, you might have issues with the GSWeb and still be able to maintain a 'healthy relationship' with core. i should point out i'm not pointing any fingers at GSWeb specifically it seems to be an instance of a larger problem, similar issues come up with those wanting it to be a desktop and those wanting a set of core libraries now i'm not sure if/how much any of this cohesion is caused by project accessibility, is GSWeb and core under the GNUstep project umbrella because we as the umbrella haven't done a good enough job making outside projects using GNUstep core easily accessible? so if we could make the GNUstep umbrella a separate project entirely, which could have some specific objectives a few come to mind like help secure permanent hosting if needed for free software projects using the GNUstep core make easily accessible projects which fall under the GNUstep umbrella maintain a neutral stance regarding competing software projects though promoting collaboration so with something like this in place, maybe we could collaborate more, by being able to keep disagreements and religious issues isolated to their respective projects, and prevent them reflecting upon GNUstep as a whole and hindering potential for further collaboration... anyhow... I think it basically comes down to the fact that the work is being done by volunteers. Which prefer doing their own stuff in their free time. Eg why would I bother about code formatted in that ridiculous GNU coding style in my freetime! (just kidding ;-) However, my impression is that unfortunately the reason is often either religious differences over licensing/copyright This was fun :-) Given that *GNU*step itself only exists because of this :-) Anyways, Oliver Langer wanted to run a session on precisely this topic on FOSDEM :-) So I suppose we should defer discussion till then. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 10:49, Matt Rice wrote: just figured i would post a link to the thread i believe you are referring to here http://lists.gnu.org/archive/html/discuss-gnustep/2004-03/ msg8.html Yes, I guess so. I think it turned into a big flamewar which we don't want to repeat ;-) But after all its quite a good demonstration on why we have duplicates. Eg why would Cocotron adopt gnustep-gui if they already have a version which works much better *for them*. I wonder whether it would be a good approach to let them be the Cocoa for Windows if thats their focus and concentrate on Linux. Maybe try to make them use gnustep-base. but a large problem was the copyright assignment issue Thats right, copyright assignment is a huge blocker. It almost forgot about this one, but it was mentioned several times now. (BTW: in fact I have done the copyright assignment for GNUstep) Hm, yes. Thats probably a huge issue for people coming from Cocoa. They already have a problem with just the license, and _then_ they are also supposed to assign copyright. You really need to provide a very good value in return to make that worthwhile. i'm not sure what is hindering you from replacing SOPE-imap with GNUMail/Pantomime, and i'm not actually sure if GNUMail is even copyright assigned to the FSF it doesn't say Copyright (c) ... Free Software Foundation anywhere... What hinders me is that this means a lot of work :-) Obviously the copyright-assignment is only an issue for GNUstep (can't work with developers who do not want to assign it to the FSF), not the other way around. so i'm wondering if project cohesion is reducing collaboration in this case, because GSWeb and SOPE-appserver cannot get along is that hindering progress replacing libFoundation with gnustep-base, Its not hindering the gnustep-base port at all. or alternately if GSWeb and GNUstep core were separate, you might have issues with the GSWeb and still be able to maintain a 'healthy relationship' with core. I think I do have a healthy relationship with core :-) The current issue is that work needs to be done and nobody can force anyone in doing that work. My current opinion wrt GNUstep is that I would like to use gnustep- make / gnustep-base and just don't care about / blend out the remaining stuff. Everything else in GNUstep is useless _for me_ and I don't see that this will change. If GNUstep would be just the parts I need, it would be perfect :-) i should point out i'm not pointing any fingers at GSWeb specifically it seems to be an instance of a larger problem, similar issues come up with those wanting it to be a desktop and those wanting a set of core libraries Probably you are on the right track here. GNUstep is a LOT of stuff, it acts like some kind of wrapper project for everything people come up with. Which obviously leads to duplicates with other projects working with other Foundations (mostly Cocoa of course). now i'm not sure if/how much any of this cohesion is caused by project accessibility, is GSWeb and core under the GNUstep project umbrella because we as the umbrella haven't done a good enough job making outside projects using GNUstep core easily accessible? so if we could make the GNUstep umbrella a separate project entirely, which could have some specific objectives a few come to mind like help secure permanent hosting if needed for free software projects using the GNUstep core make easily accessible projects which fall under the GNUstep umbrella maintain a neutral stance regarding competing software projects though promoting collaboration so with something like this in place, maybe we could collaborate more, by being able to keep disagreements and religious issues isolated to their respective projects, and prevent them reflecting upon GNUstep as a whole and hindering potential for further collaboration... All that sounds quite reasonable and to the point to me. Greets, Helge ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 03:00, Gregory John Casamento wrote: I can't follow that, it sounds like everyone is re-inventing GNUstep all the time. Which isn't the case. There is just one new project which popped up, and apparently also has a focus which GNUstep just doesn't have (Windows deployment). GNUstep is all about deploying on as many operating systems as possible, so I'm not certain what you're referring to. GNUstep's focus, as I have recently laid out, is that of a cross-platform API which is usable on everything from Linux to Windows. The fact that Windows isn't the only operating system that GNUstep is available on shouldn't be an issue. I'm not that much into developing-AppKit, but IMHO its a huge difference whether you write AppKit just for Windows or whether you also target X11 given that the two are vastly different. Personally I would probably approach that by writing two entirely different AppKit libraries instead of creating one huge monster abstracting away the APIs inside yet another API ... (aka backends ;-) The OpenStep idea is to have a common API, not being fixed on a common implementation. Helge, could you please point out the email you sent in the list archives proposing this? Matt send the link. I don't think its worth to resurrect the discussion, it turned into a huge mess. Matt's points are quite good, IMHO. Now that I'm Chief Maintainer I'd like to take a look at what was proposed so that it can be considered. I'm concentrating my efforts on focusing the project on the goal I stated above. GNUstep is an crossplatform development environment and API only. Well, even that is too broad. What is the API covered? Is it just Cocoa? What happens with all the enhancements currently hosted by GNUstep. It is not a desktop, nor is it going to be an OS clone. I'm not entirely sure how its possible to separate a GUI library from the desktop environment. But since I'm not into GUI that much, I don't care either :-) I'm wondering if you can summarize the vastly diverging expectations you're talking about as well. One of the problems I have seen on this project is that people are far too eager to start bashing GNUstep instead of actually trying to help or to do anything about the problems which are challenging this community. I'm here to change all of that. Yes, I'm very interested to find out what will happen with GNUstep under your new leadership :-) Anyways, Oliver Langer wanted to run a session on precisely this topic on FOSDEM :-) So I suppose we should defer discussion till then. I would prefer to discuss it here and now so that I can help to address any issues as soon as possible. It already starts to get too much work to follow/answer that thread for little return. I'll write some other mail and then stop posting :-) I would be very happy to discuss those things on FOSDEM, this is much more efficient and less error prone (misunderstandings happen to easily ;-). Lets find out there what can be done to reduce duplication of efforts. Thanks, Helge ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Helge Hess wrote: Even if this is the case (nobody seems to use it!) producing packages which install it properly also takes some more days(/weeks). I certainly can't write gnustep-make packages which install my software into /usr/local out of the box? I probably need to manually move gnustep-base and do all the right settings etc? As a rough guess I think it would take about 2...4 weeks to get a (deployable) port. Its the typical 90/10 rule that the last 10% take 90% the time. We don't need a prototype showing SOPE/OGo running on gstep-base, but a solid solution meeting basic QA expectations. Actually I do think that gstep-base is slowly improving (adding FHS etc), but I suppose the issue is that the core developers have a different viewpoint on it (ie they don't think that proper FHS support or Unix/Linux integration is crucial etc). Anyways. If someone wants to do the port, you are very welcome and of course you will get assistence. I still consider it a goal to move to gstep-base, but at the current pace this will take some additional 3 years. Probably we have moved to Mono till then ;- Greets, Helge Interresting that I was able to build a self-contained installable binary application package of an app which uses additional libraries and massively depends on run-time loading of bundles just using vanilla GNUstep and all that in one day. I haven't tested it on many platforms though, but just in case you want to give it a try, here it is: http://netdev.netlab.sk/NetMage.tar.bz2 - -- Saso -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFjnAzakxhuWWzY78RA4OVAJ9HBhxwqzdftd7W2FnS1MmYWRvUeACgl0Pl XysVOBz2csUzFxGO5yljmHw= =WDLT -END PGP SIGNATURE- ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 03:39, Gregory John Casamento wrote: I understand why libFoundation exists. My point, quite simply, is that gnustep-base does so much more than libFoundation at this point, there's little need for libFoundation at all. For new users there is no point in using libFoundation, I completely agree with that. However, I don't need 98% of that does so much more. If it doesn't get into the way, well, OK then be it. The major thing which would be a gain for us is Unicode support. BTW: lF isn't really being developed anymore, its just kept in shape. It just works and does all we need in our limited scope. Its no waste of time for us because fixing gstep-base to match our requirements is still quite a big effort, while keeping libFoundation is a matter of a few days per year at most. Would you mind documenting what fixes/changes you feel are necessary to gstep-base to make it more palatable for your project? I suppose the things to be done are basically (in order): - get OGo compile and _run_ with gnustep-base (Note: w/o breaking Cocoa compat) - get OGo to run with no major performance drawbacks - make everything working in an FHS context - do packaging Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 13:18, Sašo Kiselkov wrote: Interresting that I was able to build a self-contained installable binary application package of an app which uses additional libraries and massively depends on run-time loading of bundles just using vanilla GNUstep and all that in one day. I'm not sure why this is interesting in the context :-) Its a good demo on what is possible with GNUstep, but doesn't bring us any further in our setup. Greets, Helge -- Helge Hess http://docs.opengroupware.org/Members/helge/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Helge Hess wrote: On Dec 24, 2006, at 13:18, Sašo Kiselkov wrote: Interresting that I was able to build a self-contained installable binary application package of an app which uses additional libraries and massively depends on run-time loading of bundles just using vanilla GNUstep and all that in one day. I'm not sure why this is interesting in the context :-) Its a good demo on what is possible with GNUstep, but doesn't bring us any further in our setup. Greets, Helge --Helge Hess http://docs.opengroupware.org/Members/helge/ I was merely countering your claims that GNUstep is unusable for any kind of ready-packaged working commercial product. It usable, and even quite well. I build all my Windows tools using gnustep-base and I've had little hassle in getting it work - merely involved copying the dependant DLLs into the tool's directory. - -- Saso -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFjpwvakxhuWWzY78RAx8+AJ9EdEPDzO8pp7J/eGRasZbQjiSm6QCfcONg MHcYKcjsj67DGxTyw1DXE8w= =U25W -END PGP SIGNATURE- ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On Dec 24, 2006, at 7:15 AM, Helge Hess wrote: I'm not that much into developing-AppKit, but IMHO its a huge difference whether you write AppKit just for Windows or whether you also target X11 given that the two are vastly different. Personally I would probably approach that by writing two entirely different AppKit libraries instead of creating one huge monster abstracting away the APIs inside yet another API ... (aka backends ;-) The OpenStep idea is to have a common API, not being fixed on a common implementation. Hi, The gui / backend division makes a lot of sense because (1) most of the code in gui is and would always be drawing layer independent, and (2) NeXT / Apple have always split things along similar lines. (Also, compare the size of code in gui and back. We could also compare size of GUI/back to Cocotron WinAppKit but can't yet because functionality is so much less there.) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Helge, I'll write some other mail and then stop posting :-) I would be very happy to discuss those things on FOSDEM, this is much more efficient and less error prone (misunderstandings happen to easily ;-). Lets find out there what can be done to reduce duplication of efforts. The problem with Discussing it at FOSDEM is that I, and many others, may not be at FOSDEM. If you guys do end up discussing this there, please post a followup to the list. Thanks, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Cocotron
http://www.cocotron.org/Info/ Greets, Helge ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
Helge, A quick analysis shows the following things: 1) They are missing many Cocoa classes 2) They do not use native widgets, they draw thier own, like we do. 3) Much of the nib decoding logic which is currently present in GNUstep is not in Cocotron. That is to say... there are many cases that the Cocotron code cannot handle properly when unarchiving Cocoa nibs. There are other problems along these lines as well, such as some classes are missing keys which are needed to function properly. 4) Cocoa compatible keyed nib encoding is entirely missing 5) The only way you can build it is by using Xcode on a mac and cross compiling it for other platforms, this is a major drawback. 6) Printing appears to be non-functional, or, at least severely restricted... more so than GNUstep's printing functionality currently is. 7) The TextEditor example is completely bogus. None of the connections in the nib are actually made... none of the menus work. All it does is bring up a window with an NSTextField in it and look halfway nice. Other than that the example is non-functional. I'm quite sure there's more, but the above is just from looking at it for about 10 minutes. :) There are, however, a few things that can be learned from the project... particularly how the code is organized. I like the idea of having class clusters in thier own directories/subprojects, it seems like the right thing to do. The only reason that Cocotron looks good under Windows, I suspect, is because it was themed that way. It likely looks precisely the same under Linux. It's unfortunate that all of these efforts are going on in parallel with GNUstep (libFoundation, Cocotron, AJRFoundation) instead of people getting together and collaborating on one project. In conclusion, GNUstep is a much more mature and complete project than Cocotron is. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Helge Hess [EMAIL PROTECTED] To: GNUstep Discussion discuss-gnustep@gnu.org Sent: Saturday, December 23, 2006 7:55:40 AM Subject: Cocotron http://www.cocotron.org/Info/ Greets, Helge ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
I believe that this might also stem from a fundamental misunderstanding of GNUstep's goals. Many people, erroneously, believe that GNUstep's goal is to clone the OPENSTEP 4.2/Mach OS. This is not the case. GNUstep is, and always has been, a cross-platform API. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Andrew Sveikauskas [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Saturday, December 23, 2006 11:27:00 AM Subject: Re: Cocotron On 2006-12-23 07:55:40 -0500 Helge Hess [EMAIL PROTECTED] wrote: http://www.cocotron.org/Info/ My reading of this page seems to be: We have rewritten a lot of OpenStep things from scratch. We are missing Cocoa-specific things like NIBs and NSStream, and a lot of OpenStep stuff too. We do not want to work with GNUstep because we have 'different goals'. AFAIK, gnustep-base has come a lot closer to their goals than they have. A lot of functionaliy on their TODO list, to be precise. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
On 23 Dec 2006, at 19:14, Gregory John Casamento wrote: Helge, A quick analysis shows the following things: 1) They are missing many Cocoa classes 2) They do not use native widgets, they draw thier own, like we do. 3) Much of the nib decoding logic which is currently present in GNUstep is not in Cocotron. That is to say... there are many cases that the Cocotron code cannot handle properly when unarchiving Cocoa nibs. There are other problems along these lines as well, such as some classes are missing keys which are needed to function properly. 4) Cocoa compatible keyed nib encoding is entirely missing 5) The only way you can build it is by using Xcode on a mac and cross compiling it for other platforms, this is a major drawback. 6) Printing appears to be non-functional, or, at least severely restricted... more so than GNUstep's printing functionality currently is. 7) The TextEditor example is completely bogus. None of the connections in the nib are actually made... none of the menus work. All it does is bring up a window with an NSTextField in it and look halfway nice. Other than that the example is non-functional. On the foundation side, much is missing too ... distributed objects, xml parsing, streams, url handling etc and also large chunks of functionality of a few classes I looked at. I'm quite sure there's more, but the above is just from looking at it for about 10 minutes. :) There are, however, a few things that can be learned from the project... particularly how the code is organized. I like the idea of having class clusters in thier own directories/subprojects, it seems like the right thing to do. I rather liked that too. The only reason that Cocotron looks good under Windows, I suspect, is because it was themed that way. It likely looks precisely the same under Linux. It's unfortunate that all of these efforts are going on in parallel with GNUstep (libFoundation, Cocotron, AJRFoundation) instead of people getting together and collaborating on one project. I very strongly agree with that ... it always saddens me to see people re-inventing what GNUstep already does and duplicating effort rather than joining in. I wish I know how to persuade people to contribute to a joint effort. Perhaps we should try posting requests for volunteers to all these projects and to any other mailing lists where objc developers might hang out? I guess we would need to figure out *why* (assuming reasons other than simple ignorance) people do their own thing rather than a group effort, and try to address any mistaken impressions of the project in any email we sent out. However, my impression is that unfortunately the reason is often either religious differences over licensing/copyright or simple desire for total control over their own project, and no reasoning will convince people in those cases :-( Even so, it's probably worth a try. In conclusion, GNUstep is a much more mature and complete project than Cocotron is. Yes. We should try to get them on board. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Cocotron
I would like to see some hard numbers on what your friend is claiming to see, so that we can nail down where GNUstep needs improvement, if there's a problem. I also would like to try Cocotron myself to test this out. Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer - Original Message From: Banlu Kemiyatorn [EMAIL PROTECTED] To: Richard Frith-Macdonald [EMAIL PROTECTED] Cc: Gregory John Casamento [EMAIL PROTECTED]; GNUstep Discussion discuss-gnustep@gnu.org; Helge Hess [EMAIL PROTECTED] Sent: Saturday, December 23, 2006 3:38:45 PM Subject: Re: Cocotron Richard Frith-Macdonald wrote: On 23 Dec 2006, at 19:14, Gregory John Casamento wrote: Helge, A quick analysis shows the following things: 1) They are missing many Cocoa classes 2) They do not use native widgets, they draw thier own, like we do. 3) Much of the nib decoding logic which is currently present in GNUstep is not in Cocotron. That is to say... there are many cases that the Cocotron code cannot handle properly when unarchiving Cocoa nibs. There are other problems along these lines as well, such as some classes are missing keys which are needed to function properly. 4) Cocoa compatible keyed nib encoding is entirely missing 5) The only way you can build it is by using Xcode on a mac and cross compiling it for other platforms, this is a major drawback. 6) Printing appears to be non-functional, or, at least severely restricted... more so than GNUstep's printing functionality currently is. 7) The TextEditor example is completely bogus. None of the connections in the nib are actually made... none of the menus work. All it does is bring up a window with an NSTextField in it and look halfway nice. Other than that the example is non-functional. On the foundation side, much is missing too ... distributed objects, xml parsing, streams, url handling etc and also large chunks of functionality of a few classes I looked at. Well, I was grinning for controllers. I'm quite sure there's more, but the above is just from looking at it for about 10 minutes. :) There are, however, a few things that can be learned from the project... particularly how the code is organized. I like the idea of having class clusters in thier own directories/subprojects, it seems like the right thing to do. I rather liked that too. too++; The only reason that Cocotron looks good under Windows, I suspect, is because it was themed that way. It likely looks precisely the same under Linux. It's unfortunate that all of these efforts are going on in parallel with GNUstep (libFoundation, Cocotron, AJRFoundation) instead of people getting together and collaborating on one project. I very strongly agree with that ... it always saddens me to see people re-inventing what GNUstep already does and duplicating effort rather than joining in. I wish I know how to persuade people to contribute to a joint effort. Perhaps we should try posting requests for volunteers to all these projects and to any other mailing lists where objc developers might hang out? I guess we would need to figure out *why* (assuming reasons other than simple ignorance) people do their own thing rather than a group effort, and try to address any mistaken impressions of the project in any email we sent out. However, my impression is that unfortunately the reason is often either religious differences over licensing/copyright or simple desire for total control over their own project, and no reasoning will convince people in those cases :-( Even so, it's probably worth a try. In my opinion, I think their code looks very clean and may be it's a good source to point out the new gnustep developer to check before diving into GNUstep or as a reference. So I think it's not a very duplicating effort and it should strenghten the overall OpenStep standard and drive the market. This kind of project really open more opportunity to us! My friend claims its win32 GDI backend much more responsive than GNUstep's. May be we could just ste^Wborrow their CoreGraphics subproject so we don't have to maintain a backend ourselves. -- Banlu Kemiyatorn Senior Janitor Game Square Interactive Co., Ltd. -- ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
