GitCola works on Haiku too

Good day,

Well, before going further with Manuskript, I was trying to replicate the C++ Wrapper with another software to verify its validity as a multipurpose solution. It turns out that as my Python knowledge is low, as well as my Haiku knowlegde is also low, I wasn’t able to get the wrapper working with GitCola (yet).

Nonetheless, it is another software, written in Python and Qt that also works on Haiku:
screenshot1 screenshot2 screenshot3 screenshot4 screenshot5 screenshot6

I still need to study more about Python, the Python C API and Haiku in order to get the wrapper usable in any case.
For GitCola, besides, I should learn how to use Git too.

Nonetheless, GitCola works with Python 2.7 as well as 3.7.

I’ll keep researching and studying in order to get the wrapper usable in any situation.



I already wondered in the other thread, but what exactly is the wrapper needed for? If it is written with Python and Qt5 it should work without the need for this wrapper already.

Good day @phw,

The wrapper is just some C++ code that executes the python app in order to give the Python app better integration in the Haiku Desktop:

  • like its own icon,
  • file type association
  • file type icon
  • double click launch from the tracker
  • double click on file launches the app and opens file
  • appearance in the app list in the deskbar
  • packaging as hpkg, and hopefully through haikuports

Those sort of things. Actually, my “other” interest is learn to hopefully code native python Haiku soft… ehem… … … … someday :rofl::rofl:


I see. Actually you can do these things also without a wrapper using just the normal Python launch script provided by the application. Icon and file type associations can be set in a resource file and added as a file system attribute to the launch script. The deskbar symlink can be set with addAppDeskbarSymlink.

See e.g.

The relevant part in the recipe is the below:

mv $prefix/bin/picard $appsDir/Picard

settype -t application/x-vnd.Be-elfexecutable $appsDir/Picard

rc $sourceDir/build/picard.rdef
resattr -o $appsDir/Picard $sourceDir/build/picard.rsrc
mimeset -f $appsDir/Picard
addAppDeskbarSymlink $appsDir/Picard

The launch script itself is getting installed at $appsDir/Picard and is just this small Python file. The only thing that is a bit of a hack here is the call to settype -t application/x-vnd.Be-elfexecutable, because obviously the launch script is just a Python script and not a Be ELF executable. But it is needed for some reason.

What I’m not sure about your feature list is the file type icon, as I have never done that. But this probably involves installing a file for the mime database and likely can also be done.


Yep, this would work, but this provides no way to customize the icon of the running program (it gets the standard executable icon) and the name (Python) in the Deskbar, AFAIK.

Nope, name and icon work just fine:


From a user perspective I can see no difference between a Python and a C++ program from the desktop.

Good day @phw,

Why didn’t you said that before??? #&@!?%#!!!

I have to check that out… if true, I’ve been spending time with C++ that I should have been spending on Python

ay ay ay ay caraaaaaaamba…

Anyway… the moment I have some free slot to assign to Haiku will check it.


1 Like

Ha, sorry :smiley: Actually my knowledge of Haiku is rather limited. I just assumed I would miss something essential, even though I wondered why my app and others in HaikuDepot work without such a wrapper. Actually I have just stolen this packaging procedure from some other PyQt based app, just forgot which one.

1 Like

Python program may have problem with BApplication signature.

1 Like

I’m not too familiar with using BApplication directly. What’s the implication of this?

Wrong BApplication signature can cause wrong grouping in Deskbar list and problems with file associations.

1 Like

In this case it should be fine. Qt5 in Haiku will set the signature on the BApplication by reading it from the executed file. In the example of Picard above this will then work fine. The signature is set on the launch script from the resource file, Qt5 reads this and initializes the BApplication from it.

So this should all work fine if PyQt 5 is being used. If the Python application would initialize BApplication itself (e.g. using some Python bindings to libbe) it would need to ensure itself to set the proper signature I guess.

1 Like

This loooooks very nice!!!