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. 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. 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. 50000 lines, other purpose, same coding style). 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?

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. 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. Dr Jansen, See my responses below. On Sun, Dec 13, 2015 at 7:46 AM, 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: 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. GNUstep uses the native theming capabilities of Windows itself to blend in. The WinUXTheme delegates to Windows to draw the widgets so they look entirely native. Nothing major is missing.

The buttons, the menus and everything are done this way. 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. As long as they generate nib files you can. The trick here is that Cocotron doesn't support XIB files either. They use the nibs which are converted during the build process and read those. Just like Cocotron, GNUstep can read the nib files, but we can't directly read the XIBs. You will need to manually convert those using the ibtool on your mac.

I am currently working on native xib support in GNUstep so that no compilation of the xibs is needed. 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.

50000 lines, other purpose, same coding style). Yes, you can expect the same. There are a number of apps on the market currently using GNUstep. See for an example of one such app. 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? GNUstep has the capability to read and display PDFs on both Linux and Windows.

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. Yes, GNUstep provides complete support for RTF.

I believe it would be much more work to implement the capabilities you need for RTF support into The Cocotron. 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? It is possible to build an app using a 'standalone' process. This means that once compilation is done all of the relevant.DLLs will be copied into place.

This still allows you to replace them. GNUstep doesn't like anything statically so it's entirely possible to upgrade an individual DLL within the application directory. 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? You may expect the same with GNUstep.

The best way to go about it is to provide patches back to us or to sign a copyright assignment for your changes and commit them on a branch in the SVN repo for review and inclusion. Anything else to obey with? Not that I am aware of. If you have additional questions please let us know. Am um 14:53 schrieb Gregory Casamento: Dr JansenSee my responses below.

On Sun, Dec 13, 2015 at 7:46 AM, 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: 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.

GNUstep uses the native theming capabilities of Windows itself to blend in. The WinUXTheme delegates to Windows to draw the widgets so they look entirely native. Nothing major is missing. The buttonsthe menus and everything are done this way.

This is perfect for me, and I will be ready to fix minor things and contribute my patches to the GNUstep project. 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. As long as they generate nib files you can. The trick here is that Cocotron doesn't support XIB files either. They use the nibs which are converted during the build process and read those. Just like Cocotron, GNUstep can read the nib files, but we can't directly read the XIBs.

Cocotron For Mac Pro

You will need to manually convert those using the ibtool on your mac. I am currently working on native xib support in GNUstep so that no compilation of the xibs is needed.

Sorry, I meant it in the way of utilizing the compiled XIB files. My Mac applications do it, my Windows-Cocotron application does it, and I am perfectly happy once my Windows-GNUstep application would do it as well.

So, I don't need native xib support in GNUstep, I would always ship my application with the compiled XIB files. 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.

50000 lines, other purpose, same coding style). Yes, you can expect the same. There are a number of apps on the market currently using GNUstep.

See for an example of one such app. 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? GNUstep has the capability to read and display PDFs on both Linux and Windows. What about PDF generation using -NSView dataWithPDFInsideRect:?

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. Yes, GNUstep provides complete support for RTF.

I believe it would be much more work to implement the capabilities you need for RTF support into The Cocotron. That was my hope, and as said above I definitely will give it a try.

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? It is possible to build an app using a 'standalone' process. This means that once compilation is done all of the relevant.DLLs will be copied into place. This still allows you to replace them.

GNUstep doesn't like anything statically so it's entirely possible to upgrade an individual DLL within the application directory. Please can you point me to instructions how to set up a build environment, ideally directed to Mac developers who want to cross build for other platforms. I build my Windows-Cocotron application from within the same Xcode project as the Mac counterpart, I only select the other target. I guess, I need to set up a GNUstep build environment on a Windows machine and I would drag-in my sources from my local SVN repository. Can I use LLVM/clang together with the Objective-C runtime of David Chisnall on Windows? Is LLDB working with this on Windows?

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? You may expect the same with GNUstep. The best way to go about it is to provide patches back to us or to sign a copyright assignment for your changes and commit them on a branch in the SVN repo for review and inclusion. When I run into issues, then let's talk about the best way of resolving it. Anything else to obey with? Not that I am aware of. If you have additional questions please let us know.

Best regards Rolf Discuss-gnustep mailing list. 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. 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. 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: 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. 50000 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. 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. 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 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? If your changes are of general use and quality, we will be happy to improve GNUstep itself, send in the patches! Cheers, Riccardo Discuss-gnustep mailing list.

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. 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.

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.

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. 50000 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.

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. The formatted text is kept within my application.

Interoperation of formatted text with other applications is not necessary. Well, now saying this, my Mac application use PDF export of the documents view in order to let third parties view and present the nicely formatted contents (containing the formatted text) in Acrobat Reader (or Preview). It also allows drag & drop of any graphics format including PDF into its views and PDF snippets out of it to the desktop. What a pain need to evaluate this. 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? If your changes are of general use and quality, we will be happy to improve GNUstep itself, send in the patches! 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? 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. 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? 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.