[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep vs. The Cocotron for Mac to Windows porting
From: |
Dr. Rolf Jansen |
Subject: |
Re: GNUstep vs. The Cocotron for Mac to Windows porting |
Date: |
Sun, 13 Dec 2015 16:16:29 -0200 |
Gregory,
Thank you very much for taking your time to respond to my questions. I
definitely need to give GNUstep a try, and I guess, the Christmas holidays are
a perfect time to start with this. I added some comments/questions within the
lines below:
> Am 13.12.2015 um 14:53 schrieb Gregory Casamento <greg.casamento@gmail.com>:
>
> Dr Jansen,
>
> See my responses below....
>
> On Sun, Dec 13, 2015 at 7:46 AM, Dr. Rolf Jansen <rj@obsigna.com> 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.
This is perfect for me, and I will be ready to fix minor things and contribute
my patches to the GNUstep project.
>> 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.
>
> 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.
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.
>> 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).
>
> Yes, you can expect the same. There are a number of apps on the
> market currently using GNUstep. See http://www.testplant.com for an
> example of one such app.
>
>> 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?
>
> GNUstep has the capability to read and display PDFs on both Linux and Windows.
What about PDF generation using -[NSView dataWithPDFInsideRect:]?
>> 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.
>
> 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.
>> 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?
>
> 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