I ought to give compiling it up under Mac OS X a go. Hopefully this weekend.

I am planning to create a MacPort for it so if you find out anything important let me know.

Martin

In what way does it need more porting to the Mac? It needs some mac-specific fixes in the metadata, but the Applicaton itself looks very Mac-like. Native controls, proper menu bar, etc.

I am planning to create a MacPort for it so if you find out anything important let me know.

Martin

In what way does it need more porting to the Mac? It needs some mac-specific fixes in the metadata, but the Applicaton itself looks very Mac-like. Native controls, proper menu bar, etc.

I was just looking at his post an thinking "Is this a good thing or a bad thing?". I can't help but feel that if Sigil can be somehow improved for the Mac, I'd like it in the Sigil source tree myself. I'd certainly want someone to help me out with mac specific issues.

But if krischik wants to create a "MacPort", he can feel free to do so.

It needs some mac-specific fixes in the metadata.

The buttons are not all the same size, I know. Very irritating, isn't it? It looks fine on Windows and Linux, and I need to figure out what's causing this.

I was thinking more of creator code and document icons myself. But they are relatively unimportant in alpha versions.

The buttons are not all the same size, I know. Very irritating, isn't it? It looks fine on Windows and Linux, and I need to figure out what's causing this.

I was thinking more of creator code and document icons myself.

I'm not entirely sure what you mean by this.

In what way does it need more porting to the Mac? It needs some mac-specific fixes in the metadata, but the Applicaton itself looks very Mac-like. Native controls, proper menu bar, etc.

I believe he is talking about MacPort a tool that retrieves, compiles and installs applications. A MacPort is a script that drives the "port" tool. I use MacPorts to install Ruby, Python, Bazzar, Mecurial, Subversion, Git, etc.

BOb

If this thread has turned into Mac specific tweaks, one thing that isn't working is the 'Open With' finder menu option (probably same for configuring Sigil as default app for epub). It won't open the epub in this case.

If this thread has turned into Mac specific tweaks, one thing that isn't working is the 'Open With' finder menu option (probably same for configuring Sigil as default app for epub). It won't open the epub in this case.

I've moved this to another thread.

Anyway, any mac specific issues can and should be raised. I don't have much (any) mac dev experience, or mac experience in general. For instance, I have no idea what an "Open With" finder option is. I can guess at it's function, but that's it.

You will have to provide more details.

Unfortunately I don't really know the specifics of how it works either. It's equivalent to 'open with' in windows. i.e. you right click on an epub, you select 'Open with', and choose Sigil as the target. I assume the OS is passing the application that filename on launch somehow, but I don't know the specifics.

Anyway, not urgent in any way, just something I noticed that's likely Mac specific.

Unfortunately I don't really know the specifics of how it works either. It's equivalent to 'open with' in windows. i.e. you right click on an epub, you select 'Open with', and choose Sigil as the target. I assume the OS is passing the application that filename on launch somehow, but I don't know the specifics.

Anyway, not urgent in any way, just something I noticed that's likely Mac specific.

Doesn't work on Win either. The command just calls up nthe software without opening the file. You have to do that manually! No big deal. I didn't even make an issue with it yet.

I'm not entirely sure what you mean by this.

Mac applications almost all have a 32-bit 'creator code' that identifies the Application to the OS in various ways. Not essential, but usual.

They also contain resources that link documents to the application, indicating that they can open the document and, if unique to the application, providing icons for the documents. Most of this happen in the Info.plist inside the application package Contents folder.

When I get Sigil compiling nicely on my Mac (i.e. when I have some hours to spend, perhaps this weekend), I'll see what I can do in terms of the metadata in the Info.plist. Icon design isn't my string point though. I can do one, but it won't be pretty!

Oooh - that makes more sense. Sorry for being obtuse.

Paul

I believe he is talking about MacPort a tool that retrieves, compiles and installs applications. A MacPort is a script that drives the "port" tool. I use MacPorts to install Ruby, Python, Bazzar, Mecurial, Subversion, Git, etc.

Unfortunately I don't really know the specifics of how it works either. It's equivalent to 'open with' in windows. i.e. you right click on an epub, you select 'Open with', and choose Sigil as the target. I assume the OS is passing the application that filename on launch somehow, but I don't know the specifics.

Anyway, not urgent in any way, just something I noticed that's likely Mac specific.

Doesn't work on Win either. The command just calls up nthe software without opening the file. You have to do that manually! No big deal. I didn't even make an issue with it yet.

Now I know what this is. Sigil doesn't take a file as an argument. I'll try to fix this for 0.1.2.

Mac applications almost all have a 32-bit 'creator code' that identifies the Application to the OS in various ways. Not essential, but usual.

They also contain resources that link documents to the application, indicating that they can open the document and, if unique to the application, providing icons for the documents. Most of this happen in the Info.plist inside the application package Contents folder.

When I get Sigil compiling nicely on my Mac (i.e. when I have some hours to spend, perhaps this weekend), I'll see what I can do in terms of the metadata in the Info.plist. Icon design isn't my string point though. I can do one, but it won't be pretty!

Please do. Any help on this front would be greatly appreciated. Adding information to the Info.plist is possible through CMake. You'll just have to tell me what to add and I'll find a way to add it.

The icons are not a problem: look into the Sigil app on Mac, there is a Sigil.icns file.

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

Now that Sigil is using the new build system, providing universal binaries should be fairly straightforward. You should see this in 0.1.2.

Now that Sigil is using the new build system, providing universal binaries should be fairly straightforward. You should see this in 0.1.2.

Hooray! thanks!

In what way does it need more porting to the Mac? It needs some mac-specific fixes in the metadata, but the Applicaton itself looks very Mac-like. Native controls, proper menu bar, etc.

I thought everybody knows about MacPorts (http://www.macports.org/) - Macports is a distribution for Mac. MacPorts already distributes QT - so a MacPorts distribution of Sigil would not need to bundle the QT libraries.

Martin

As a user, my big request would be to make this a Universal binary. I don't know if there's a specific reason that the original isn't Universal, but G5-and-earlier machines still make up a large portion of the Mac installed base. Universal and 10.4.11 compatibility would make it so *I* could use the program.

MacPorts would sort that out as well as you would compile your own version for the CPU and Operating System you use.

Martin

Hi,

For MacPorts I need a short and long descriptions for tidylib and ZipArchive. That's because I need to make three different ports :-( .

Martin

Hi,

I am currently blocked (http://code.google.com/p/sigil/issues/detail?id=68) - anybody with cmake experience who can help me?

Martin

Hi,

I did get around all the problems after all and Sigil is now available for MacPorts compatible systems.

In the end I needed three portfiles: libtidylib (http://trac.macports.org/browser/trunk/dports/devel/libtidylib/Portfile), libziparchive (http://trac.macports.org/browser/trunk/dports/devel/libziparchive/Portfile) and Sigil (http://trac.macports.org/browser/trunk/dports/editors/sigil/Portfile).

Of course you only have to install the last one - MacPorts takes care of dependencies itself.

See the MacPorts Homepage (http://www.macports.org) for instructions on how to install MacPorts.

Martin

For MacPorts I need a short and long descriptions for tidylib and ZipArchive. That's because I need to make three different ports :-(

Please don't separate ZipArchive and tidyLib from Sigil. These are not the upstream versions and should not be present on user's systems. They are only statically linked in to the main Sigil application.

I cannot provide you with descriptions for these libraries since I didn't write them, I only modified them.

I must say I cannot support the development of a MacPorts version, or its build system. The only build system supported is the provided CMake version. Anything beyond that, and I'm sorry to say but you are on your own.

Please don't separate ZipArchive and tidyLib from Sigil. These are not the upstream versions and should not be present on user's systems. They are only statically linked in to the main Sigil application.

It would be nice to have clear instructions on how to do that - as the sigil make not find the other libs. If the Wiki is wrong - better delete it because once I found the Wiki i stopped looking for other instructions.

I must say I cannot support the development of a MacPorts version, or its build system. The only build system supported is the provided CMake version. Anything beyond that, and I'm sorry to say but you are on your own.

MacPorts does not use it's own build system - MacPorts calls the build system provided by the developer and in the case Sigil that is cmake.

Martin

In the end I needed three portfiles: libtidylib (http://trac.macports.org/browser/trunk/dports/devel/libtidylib/Portfile), libziparchive (http://trac.macports.org/browser/trunk/dports/devel/libziparchive/Portfile) and Sigil (http://trac.macports.org/browser/trunk/dports/editors/sigil/Portfile).

This is a very, very bad idea. What happens when someone uses those two libraries for something other than Sigil? And it breaks because of the changes made to them?

These libraries were never meant to be available on a system level. There will come a time when this will cause great harm to certain users.

It would be nice to have clear instructions on how to do that - as the sigil make not find the other libs. If the Wiki is wrong - better delete it because once I found the Wiki i stopped looking for other instructions.

The wiki instruction are for Linux systems, and they are very clearly labeled as such. They are not general build instructions.

You can find those in the INSTALL.txt file in the repository.

MacPorts does not use it's own build system - MacPorts calls the build system provided by the developer and in the case Sigil that is cmake.

But I'm guessing you used the separate CMakeLists.txt files in each of the subdirectories, which you are not supposed to do.They are only meant to be loaded from the root dir CMakeLists.txt file that will descend to the subfolders and initiate specific builds.

You should learn CMake or follow the (correct) instructions more closely.

Hello,

Don't be upset about my mistakes. See them as a change to learn and improve documentation. I add a few ;) so you know I am not all that serious.

This is a very, very bad idea. What happens when someone uses those two libraries for something other than Sigil? And it breaks because of the changes made to them?

Fine, I guess I have to remove them again :( .

You can find those in the INSTALL.txt file in the repository.

which INSTALL.txt ;) ?


/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1 Darwin martin@macpro Mo Aug 10 16:44:11 standart 0
>gfind . -iname INSTALL.txt
/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1 Darwin martin@macpro Mo Aug 10 16:44:33 standart 0
>


Note that as a maintainer I only use the official release :) .

But I'm guessing you used the separate CMakeLists.txt files in each of the subdirectories, which you are not supposed to do.They are only meant to be loaded from the root dir CMakeLists.txt file that will descend to the subfolders and initiate specific builds.

Ahh, I see you mean that one ;):


/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1 Darwin martin@macpro Mo Aug 10 16:49:47 standart 0
>ls -la
insgesamt 48
drwxr-xr-x 7 root admin 238 6. Aug 02:56 .
drwxr-xr-x 5 root admin 170 10. Aug 16:42 ..
-rw-r--r-- 1 root admin 773 5. Aug 02:18 .hgignore
-rw-r--r-- 1 root admin 619 5. Aug 02:18 CMakeLists.txt
-rw-r--r-- 1 root admin 35821 5. Aug 02:18 COPYING.txt
-rw-r--r-- 1 root admin 1070 6. Aug 02:54 ChangeLog.txt
drwxr-xr-x 5 root admin 170 6. Aug 02:56 src
/Volumes/Work/macports/editors/sigil/work/Sigil_code_0.1.1 Darwin martin@macpro Mo Aug 10 16:49:54 standart 0
>


I have to say .txt is a great extension for a build file. You easily spot when close to COPYING.txt and ChangeLog.txt. ;) . One would never think it is just another piece of documentation ;) .

Now, again please don't be upset - I now it's your fault. The cmake guys should have known better then use .txt for a build script.

So I messed it up and I have to do it again :smack:.

Martin

I have to say .txt is a great extension for a build file. You easily spot when close to COPYING.txt and ChangeLog.txt. ;) . One would never think it is just another piece of documentation ;) .

Now, again please don't be upset - I now it's your fault. The cmake guys should have known better then use .txt for a build script.

Your second paragraph answers your first one: CMakeLists.txt is the name mandated by the CMake build tool. It's not something I can change.

Then again, having "CMake" as part of the name should make anyone at least curious enough to open it if they're using the CMake build system.

Hello,

I implemented Vallorics suggestions for improvement ;) It works a lot better now :) - All I need now is someone to try the build.

Martin

Sigil 0.1.2 has been released for MacPorts. It's only 1.6M in size as opposed to 28.3M for the DMG version.

Have fun

Martin

I see you're listing Sigil as x86_64 compatible for the MacPorts version. I'm not sure that will work out-of-the-box. See this page (http://doc.trolltech.com/4.5/developing-on-mac.html#carbon-or-cocoa) for details.

Basically, to work on x86_64, Qt needs to be compiled against Cocoa, not Carbon. I'm not sure the Qt version on MacPorts supports this. Have you tested this?

EDIT: The 32 bit Carbon version of Sigil should of course work without problems on x86_64 Macs.

Basically, to work on x86_64, Qt needs to be compiled against Cocoa, not Carbon. I'm not sure the Qt version on MacPorts supports this. Have you tested this?

Nope - I Qt itself does not compile - but that is not my task. The guys at MacPorts currently suggest to compile everything universal as well as quite a lot off stuff needs 32bit.

Unless you are into experimental stuff one should stay with 32bit for another month or so.

Martin