Building Sigil on Haiku

[User_Z]

DiapDealer

He was engaged in the design of the Sigil installation package.

When designing attributes and mime-types of an application, you need a program icon. The source codes have icons in png format. I think svg would be a more suitable format, with subsequent conversion to Haiku hvif format.
Do you have an icon file in svg format?

Many more questions will arise in the process of work, I hope for your help and support.
Thank.

[KevinH]

Sigil does not have an SVG version for the program icon. Instead we use png icons and the Sigil icon is available in many sizes: 16x16, 32x32, 48x48, 128x128, 256x256, and 512x512.

I believe in the macOS icon set there is a 1024x1024 version of the icon as well.

[DiapDealer]

Not to mention that the existing "make install" process takes care of installing icons and applications files that will work with standard linux XDG desktops to populate menus and such.

It should be trivial for someone to modify the cmake files to install these files in locations where Haiku expects them to be.

I have no problem helping with compilation issues, but I'm not really interested in learning how to package applications for Haiku (or any other distro for that matter). That's someone else's job.

Happy to help package maintainers if there's something about the Sigil build process that makes it impossible (or very difficult) to package, but I'm not a distro package maintainer. Nor do I desire to be.

[User_Z]

After some torment, I got such an icon in svg format:

[User_Z]

Hi.

While I stopped at this option...

[KevinH]

What is the license attached to this artwork? Is it compliant with the GPL 3 and if so may we consider this a contribution to Sigil.

Thank you,

KevinH

Originally Posted by User_Z

Hi.

While I stopped at this option...

[User_Z]

I think yes.
I took your file from the source code \src\Resource_Files\icon\app_icon_512.png as a basis.
Then, almost the whole day, he edited all this in various graphic editors. I am not a professional but an amateur. And here is the result.

[User_Z]

Hi.

KevinH, DiapDealer

Now, after the installation for Sigil, the following folder system is formed:

sigil/
       /bin/sigil-script
       /lib/sigil/sigil
                  libsigilgumbo.so
       /share/applications/sigil.desktop
             /pixmaps/sigil-haiku-icon.hvif
             /sigil/<all the rest>

Given that the Haiku file system is different from others, I would like to simplify the Sigil folder structure a little.
For example, like this:

sigil/
       /bin/Sigil
       /lib/libsigilgumbo.so
       /share/<all the rest>

or like this:

sigil/
       /bin/Sigil
            libsigilgumbo.so
       /share/<all the rest>

But when I change the record structure in CMakeLists.txt and execute the "make install" command, Sigil does not start and gives the error "libsigilgumbo.so library was not found".

If I understand correctly, the path to the library is set in the file /src/Resource_Files/plugin_launchers/python/wrapper.py

    def get_gumbo_path(self):
        if sys.platform.startswith('darwin'):
            lib_dir = unipath.abspath(os.path.join(self.appdir,"..","lib"))
            lib_name = 'libsigilgumbo.dylib'
        elif sys.platform.startswith('win'):
            lib_dir = unipath.abspath(self.appdir)
            lib_name = 'sigilgumbo.dll'
        else:
            lib_dir = unipath.abspath(self.appdir)
            lib_name = 'libsigilgumbo.so'
        return os.path.join(lib_dir, lib_name)

Changing the file path in this function does not lead to anything.

How can I do that?

[DiapDealer]

That Python file is strictly for the plugin framework. It has nothing to do with how the Sigil binary finds libsigilgumbo. You want to focus on the bash launch script for Sigil. There's cmake options (compile time) and environment variables (runtime) that can be used to relocate Sigil's various components. They're all documented in the Linux build documentation.

The short answer is that you can't just move stuff wherever you want. And you won't be able to move anything without using the provided script to launch Sigil. Directly executing the Sigil binary will get you nowhere.

The launch script is designed to look for libsigilgumbo in the same directory as the Sigil binary. Adjust the launch script and/or $LD_LIBRARY_PATH (if such a thing exists on Haiku) if you wish to change it.

Just note that changing these things could break some third-party plugin functionality if not done thoughtfully.

[eschwartz]

Aside: I've wanted for a while to reduce the reliance on shellscripts for this. For example rpath is a much better way for the main binary to find a vendored libhunspell, and libsigilgumbo is already namespaced so it could just be plopped in /usr/lib if nothing else already required a private libdir.

[DiapDealer]

Originally Posted by eschwartz

Aside: I've wanted for a while to reduce the reliance on shellscripts for this. For example rpath is a much better way for the main binary to find a vendored libhunspell, and libsigilgumbo is already namespaced so it could just be plopped in /usr/lib if nothing else already required a private libdir.

I'm not opposed. But it'll have to wait. Bigger fish right now. The two libs in question are only a problem because we wanted the python plugin framework to also be able to utilize them. Otherwise, we'd just go back to statically linking them (unless the system libs are being used) and there'd be no need to namespace or use the launch script (unless someone wanted to override the default behavior).

It's important to me for there to be a ton of flexible (and relatively simple) installation/launch options (both pre- and post-compile) for *nix. I'm not in love with the launch script myself--truth be told. But it works well enough and provides a lot of flexibility, whereas rpath can be difficult to overcome for the average user if customization or general tweaking is required.

[User_Z]

Hi.

Thanks to our joint efforts in the main Haiku repository, the pcre version 8.43 library package has been updated. Now the libpcre16 and libpcre32 libraries are included in the package.

[User_Z]

Another good day and another good news.

At the last stage of porting Sigil, a well-known man in the Haiku community with the nickname 3dEyes joined the work. He remade almost everything. Sigil now works with Python 3.7 and all system libraries and dictionaries in the 32-bit and 64-bit versions of the operating system.

Sigil can be installed from the Haiku repository using the HaikuDepot program. Spellchecking dictionaries for different languages ​​(hunspell/myspell) are also available for installation there.

The work is not over yet. It is necessary to finish some points and check the functionality. It is especially important to test the functionality. In my work, I do not use all the features of the editor, so I invite all interested to join this test.

Congratulations to the entire Sigil community !!!
Now you can safely change the line in the "About" section to "Multi-platform: runs on Windows, Mac, Linux and Haiku".

[DiapDealer]

Very cool! Thanks for reporting back.

Do you know if the system hunspell library is available to plugins or not? That might be something to look at. There's a test plugin in the docs directory of the Sigil source (make sure you use the version found in the source at the same tag-level you built) that can be installed/run to test the various pieces of the plugin framework.

I know that Tkinter is not available on Haiku, so plugins that rely on Tkinter for gui features are not going to work, but I had plugins that used PyQt5 working. That test plugin will report which features of the plugin system is working and which are failing. Most will be down to making sure certain python modules are installed, but a few features (including libhunspell) may need some tweaking.

[DiapDealer]

You might also want to check that your preferences are being saved from session to session. I looked through 3dEyes' patchset and didn't see the patch I had apply to overcome the fact that QStandardPaths::(App)DataLocation returns "None" on Haiku.

I reported the problem/fix here.