cancelled

Am I the only one who sees the word "run" bolded? Or the link to the exact page with building instructions: "Instructions on compiling Sigil can be found on the BuildingFromSource wiki page."? It's the very next sentence after the list of libraries required to run Sigil. "libqt4-dev" is not required to run Sigil, but is required to build it. This would be the reason why it's not listed in the libraries required for running, but is listed in the libraries required for building.

Also, none of this text is in the INSTALL.txt file included in the source package you downloaded. That file only has the text from the BuildingFromSource page, since with the source package you'll be... building from source.

I honestly don't know how to make all of this more explicit for new users. I guess I'll have to try.

It's very clear from the README.txt and INSTALL.txt. If someone can't be bothered to review the files included in the zip file I don't know that there's anything that can be done to help that person short of binary packages.

MacPorts progress.
 

But there is a little problem here - MacPorts is not universal by default - which means that MacPorts users usually don't have the ppc version of QT installed.

Now it seems that Sigil v0.1.2 tries to create a universal-binary by default. I had not have the time to look for a No-Universal option yet - so this is not a bug report - it's just an progress info.

Martin

The advantage is that of using the distribution's package system, which means you have a centralized database of installed packages, a centralized way of installing and uninstalling, of querying the version installed, etc.

At the moment you may have a single file (which I just copy in ~/bin, by the way), but later on you may want to install man pages, samples, templates, HTML help pages, command-line helper apps... It's a good practice to use "sudo checkinstall" rather than "sudo make install".

Oh I agree, it's good practice. But currently for Sigil I think there is little point. Of course, no harm would come from using it.

Although in general I have heard that checkinstall instills one very bad practice in users: the distribution of packages created with it, when those packages are meant for the machine where it was first run. People think that the created package is just like those from the repos, and this creates problems.

If you want the build process to create just the architecture type of the machine it is running on, remove this line from the root CMakeLists.txt file:

Thanks - that saves me a lot of searching.

@Valloric

Producing a deb package for Sigil

I send you a zip file including:

1- a rtf file called "Compilation" which is the exact text log of the first two commands. You may note one explicit error at 19%, which seems to have no importance, but who knows?
2- a rtf file called "checkinstall" which is the exact text log of the checkinstall command I used. Please note that I included the four needed dependencies to run the program (but not the last one, libqt4-dev, which is not needed afaik)
3- a deb package which should run fine on 32 bits systems for distros using debs like Debian, all Ubuntus, Mint...

The checkinstall program is also able to produce rpm or slack packages but I have not enough experience with these distros to dare produce it.

My distro is Ubuntu jaunty 32 bits.

Hope this may be of use to you.

Thank you for trying to help roger64, but for security and quality assurance reasons I will not distribute binaries from random people on the internet.

And checkinstall is not meant to be used to produce packages that are to be installed on computers other than the one used to make the package. The deb and rpm packages you normally install from your distribution's package repository are created with a lot more care and precision. It is not an easy or simple process by any means. For more information on creating distributable debs, take a look here. Just creating debs alone is rather complicated. Rpms AFAIK have their own complex procedures.

Those things aside, just providing deb and rpm packages would not be fair to the other Linux users whose distributions do not use them. There are many other package types. Providing some and not others would still leave a lot of people unhappy, and I just don't have the resources or the time to make a dozen different package types.

As I've noted in (several) previous posts, many (major) software projects provide only source archives for Linux. From GCC, GIMP, Inkscape etc. These people have met the same hurdles I have met, and have a lot more manpower available. Their solution is to provide sources, which users can then compile themselves or leave it to the package maintainers to handle for them.

Sigil will do so as well. This is final.

This decision is not the product of laziness, lack of skill or malice. Simply a consequence of Sigil being a one-man-project, and a hobby project at that. That being said, many larger projects still provide only source archives for Linux. I've said this too many times now, and I'm starting to sound like a broken record.

I hope I've made my point clear. If I haven't, well... I gave it my best shot.

I would suggest that those who really must have a binary package for whatever reason might get involved with the community of their preferred distribution and see if they can't get Sigil considered for addition to that distro's repositories or whatever.

You decide. You are the -final- author and boss.

For the sake of objectivity and for the information of our readers, I need to correct a misconception about the technical value of checkinstall built deb packages stemming from our previous posts. This will be my last shot.

To write that "checkinstall is not meant to be used to produce packages that are to be installed on computers other than the one used to make the package" is a misconception.

The situation is just not so one-sided as you wrote it. I explain this:

First, let's put aside please the trust and security reasons. This is another and different question. A most important one, for sure, but another one. Let's speak only here about the technical value of a package made with checkinstall.

Checkinstall can technically be trusted, even for distribution purposes. It's part of the Ubuntu communautary documentation. Look here: https://help.ubuntu.com/community/CheckInstall which speaks of "allowing for easy package removal or distribution".
It has indeed some limitations,
- 32bits or 64 bits version
- same version of same distribution specially when there are dependencies
- same architecture (i386 or Sparc,...) written in the deb package.
If available, I agree that an official package is to be preferred
- available for several architectures
- respect for specific distribution rules (recommended paths, icon menus, patches...)

So, for the above-mentioned reasons, the checkinstall built deb package I sent you can technically be trusted and it will successfully and safely run on all 32 bits i386 computers using Ubuntu jaunty and not only on my computer where it has been compiled and built.

It's somewhat more limited than what I wrote before and I apologize for this, but it's still significant and of much wider use than what you wrote. So, all done for the double misconception I wanted to correct.

To conclude, you wrote that to compile your program is trivial. Well, to create a working deb package with checkinstall including the needed dependencies is just as trivial. It's, to use your own words, “as simple as” replacing :
sudo make install
by
sudo checkinstall -D --requires="libqt4-gui,libqt4-svg,libqt4-webkit,libqt4-xml”
Note: for black magic reasons, no whitespace between package names, only comas. ;)

This was my best shot too. Thank you for giving me the opportunity to understand better checkinstall and for having taken the time to reply. :thanks:

Your random servant.

P.S. Zelda. Still OK like this? Nobody to be hurt?

Hi,

I'm just new to Sigil, and using it for some hours for comparing with various editing and conversion tools supporting .epub. Looks really great and simple. Congratulations.

A simple question, sorry, but I was not able to find it in the forum (using search) or with first-look program options:

- How can I add a cover image? To show as cover, not in text, for all software and hardware .epub readers.

- And, how much must the size for this image? I noted that Sigil does not change or resize the images, so later in viewers they are too small, or too big.

- I have a strange problem: when saving/loading files, I can load again the .epub exported files, but not the original .sgf one (???) Hangs forever loading with high cpu usage, both are about 4,83 MB size.

By the way, I vote also for .RTF and .MOBI (.PRC) input and conversion. Later you can even consider .LRF, if not too tricky, considering the latest Sony news.

Thanks! Regards!

Is there a way in 0.1.2 to make any of the paragraphs have no indent? Also, can the extra space between paragraphs be removed or not added in in the first place?

I have not looked at the tickets so this may already be there. But is there going to also be a CSS editor eventually built in?

MacPorts released
 

Sigil 0.1.2 for MacPost has been released for MacPorts. Please discuss in the MacPorts Thread.

Martin