Another marathon coding weekend

Shortly after Xojo Inc will release their 2016r1 version then we will be pushing out DateControl 6.1 which has a number of fixes and tweaks some of which help users using the new drop down calendar mode on broader range of OS X versions. We have had this version in open beta stage for a while so its pretty solid version.

But I got in another marathon coding weekend, when alone in deep snow at remote location. In this session some really nice things got done on the DateControl, so we have 6.2 lined up as well which might come out only days after 6.1 comes out.

Basically the project was to make similar drop down mode for Linux as we did for the Mac. Problem with that is that Xojo uses GTK 2, and proper Popover support did not come until GTK 3. So to make this nice and smooth a lot of coding and tricks had to be pulled out. And after completing it where I thought I had found perfection on Ubuntu then when testing it on Raspberry PI basically nothing worked due to mostly far simpler UI theme that Raspberry PI uses. So I went again and redid the whole thing and at 5 am in the night it was nice running same code base on Ubuntu and Raspberry PI:

Running on Ubuntu after the later tweak.
Running on Ubuntu after the later tweak.
Running on Raspberry PI after the later tweak.
Running on Raspberry PI after the later tweak.

One part of the big problem of going to Raspberry in the first try was that the simple theme on Raspberry PI then borderless popup windows have no shadow like they have on Ubuntu, so there was no difference on the dropped down window vs the parent window, it just blended in and it was impossible to see it was drop down unless it went bellow edge of the window.  Then in the 2nd try I came up with rendering the border manually around the drop down window using the Theme colors .

6.2 will have other improvements as well such as better disabled state for new OS X drop down modes as well as of course for the new Linux drop down mode. Improved drawing of the checkbox when used on Raspberry PI and other tweaks.

Updates to last post:

  • The PDF Plugin got successfully completed and has been published.
  • The situation with the snow is getting a lot better.

PDF Plugin progresses

As many have seen on our alpha releases then our PDF plugin is has been progressing fast in the past days.

I had both technical and mental setbacks on it, realising that the libharu that we use under the hood has some serious drawbacks. Libharu has TrueType embedding to be able to support UTF 8, but issue there is that it can basically only embed .ttf TrueType fonts, not OpenType or any other TrueType format, which limits it very much. In theory it should be able to open also bundled TrueTypes but I was not able to open the bundled ones in the Mac system folder.

I feared that this and the encoding mess of the stock font system in PDF would make it so hard for users to use that it would be best to cancel the project.  And there is little or no hope that Libharu is going to get better with this as Libharu seems to have no development or maintainers right now so hoping for it to improve the TrueType embedding is a no go.  And I have no knowledge to do what would be needed to update Libharu to support OpenType and the missing true type format and complete the unicode support.

But after sleeping on it and giving it careful thought then I came up with the plan to add automatic detection of encodings and let it be able to use the PDF stock fonts as much as possible, making it far easier for the user to use even if its not UTF8 with the stock fonts. Then it will figure out what your text needs, and adjust encodings to make it work, so if your document has Icelandic letters then it will figure that out and set up correct encodings, same if it has Japanese then it will set that up automatically. This idea seems to be working for most parts, so there should be some of this to see in the upcoming a5 version.

I would really like feedback on the a5 when it comes, to see if  users think this is good enough solution. Since if it is not then we might as well cancel this plugin before going much further.

Small update to older posts

I just wanted to update some older posts since, I previously advised against Orange PI’s, but everything has changed now.

Armbian has saved the day big time on this one. My Orange PI has gone from unusable to really great. What happened is that Armbian has added support for the Orange PI H3 based machines which are basically all the newer models. I cannot say enough good things about Armbian and the crew behind it.

There are still small quirks but nothing that is showstopper for me and things are getting tweaked and fixed almost daily lately.

Armbians support for Orange PI so much of a game changer that I have 3 more machines from Orange PI on the way.

Other things worth updating from previous posts is that it just keeps snowing !!

The snow keeps getting deeper


Change of environment and less access to equipment can be good thing for a coder from time to time.

In mid December then I found my self stuck in snow for several days away from home with not so much amount of equipment with me, not enough to do 64 bit ports of our plugins for all platforms for example.


To make matters worse then temperature was about -20 C.

So since the plan was in upset state and it was clear that 64 bit ports and ARM had to wait for a few days then much of the ground work for the new things that has been pushed out lately was done instead, BarcodePlugin, ZipArchives , etc.

Lesson from it is that sometimes its not a bad thing for coders to look outside of their normal tasks and not always be stuck in maintenance mode. Programmers should allocate time for new things even if most of what you do in that time might never get used. And its good to look outside, go different places, whatever it takes to brake your cycle and get inspired.

Switch to clang on Linux and update to Orange PI and Banana PI reviews

I just wanted to touch a bit on it why were are updating our plugins to use CLang on Linux systems.

Over the years its always been a issue of which runtime libraries users have had on their Linux installation, getting it to match what Xojo uses and then what a plugin might use.

  • Xojo uses CLang on Linux systems, so using same will reduce the issue of matching runtime libraries. Thus making it easier for you to deploy your applications successfully.
  • Mysterious crashes on deep nested C++ exceptions and other runtime abnormalities all seem to go away. We had for example the new Barcode plugin for some months just waiting because of issues that could not be explained on some Linux systems, but going Clang to match Xojo the host of the plugin fixed that.

Now I want to update my review of the Orange PI and Banana PI since I have had them for some months now. And yes this is a warning to all potential buyers of such.

Orange PI:

DO NOT BUY !!! (Thats the short version of it)

Basically nothing works ! the images they provide crash a lot, it will not load USB stick, WIFI works sometimes, huge display detection issues, the maker does nothing to fix driver issues, but pushes out more and more hardware even if previous sets cannot be used due to broken or non existent drivers.

(Sadly Armbian does not seem to be ready for this CPU yet but I hope it will come soon, then the Orange PI will be salvageable – see bellow how it salvaged Banana PI M2)

Banana PI:


I sort of loved the M2 for a while, but then the circuit under the power connector got loose. Then I read I could use the mini USB port to power it also which works…..but then 2 USB ports mysteriously die. I also found out at late stage that the Ethernet does not work on their system images.

Pretty much same situation here as with Orange PI software and drives seriously lacking.

Some updates on this one:

I found that side by the power connector there were two holes in the board marked CN2, using multimeter I was able to measure that those pins are same pins as in the broken power connector I had. With a little soldering I made a patch from the power connector to the CN2 pins and the power issue was solved making ALL USB ports work again by not having to use the USB OTG port to power it.

Then I got my self Armbian, from the page, and after fiddling a bit with it then all the issues I had with the Banana PI M2 have vanished. This is far better than what the Banana PI team is supplying.

Network works decently both WIFI and Wired. USB sticks work. And I get display for first time at full resolution.

To get things up the way I wanted I had to:

First get up user interface:

apt-get -y install xorg lightdm xfce4 tango-icon-theme gnome-icon-theme


Add GUI to the network setup:

sudo apt-get install wicd

Make USB sticks mount and fix the trash can not showing on desktop:

sudo apt-get install thunar-volman
sudo apt-get install gvfs
sudo apt-get install policykit-1

Add a web browser:

sudo apt-get install epiphany-browser


I waited on this one for months with great hopes as if I was waiting for the holy grail. There are only two normal USB ports, so if you have keyboard and a mouse then there is no place for USB stick. SATA port is more or less fake since it uses way slow USB bridge. It will only scan for Wifi if I have wired net connected also.

I have not given up on this one, I still hope they will post better system image where some things are fixed. But my hopes are low given their ability and track record to support their devices.

Why on earth they make loads of system Images with Various of Linux types is beyond me when they all are bad instead of focusing making one good at least.

The right case for Raspberry PI

I have had some trouble getting happy with cases for the Raspberries. One falls apart, one does to have hole to take out the SD card, but today I had chance to 3D print, so I tested printing this case here:



It has a VESA mount to fasten it on back of a TV, but I am not going to do that so I selected the smallest VESA mount so it would not take much space.

I am not able to really try it yet since I don’t know where to get suitable screws for it. Though I did find one out of 4 screws I need to screw the board down so that leaves 3 missing there and 4 different ones of some sort to close the case.

The case seems to be really nice, it has good access to the memory card and if getting screws then it won’t have the fall apart problem that I have with some other cases.

I encourage everyone if they get chance to access 3D printer to experiment there are a lot of drawings out there for really nice cases. And if you know how to use 123D Design then its really easy to customise them.

Here are examples of some of the other cases I have tested.


This one is plain and access to the memory card is good but it falls apart very easily.


This one is made of heavy metal (yes it is amazingly heavy). I thought this one would be really awesome, it has a fan at back that you can optionally connect. But it has no hole to access the memory card !. And it takes me about 30 min to tear this case apart and get it back together. Making this case not suitable for most cases, except maybe for servers that just need to run 24/7 without changes like Own cloud server for example. The case does have hole for cobbler cable, a good solution too since it sort of is slimmer and the case lid seals around it so it does not need to be as wide as the connector.


This one is good, its for Banana PI though and not Raspberry PI. It has good access to the memory card, does not fall apart, and has hole for the cobbler cable.

The day has come ! Xojo has released Xojo 2015r3 with 64bit compile on MacOS X, Linux and Windows, as well as adding Raspberry PI ARM target

This is great day in history of Xojo and for most Xojo developers.


Of course its not perfect and some would say its no good because of lack of debugging, to big compile sizes and because there might be bugs.

Having been playing with it throughout the alpha and beta process then for me then I am actually impressed, there are a lot fewer issues than I expected and overall things have just been a lot smoother than could have hoped for.

With that said then how they continue is going to be critical of course as it is true that 64 bit without debugging is a bit of a teaser and not development tool to rely on. Same goes for compile sizes, many stopped using Windows builds when the ICU libraries added a lot to the build size, and they were only 20-30 mb addition. But if project was to jump from 15 to 200 mb then we would see programmers jumping board pretty fast. I am confident that next release will continue on the right path and impress us.

To me the impressing bits of 2015r3 are easily enough to make me confident that the next release will target some of that and make it both impressing and solid. Its been long time since my confidence level has been this high for a Xojo release and future roadmap.

Einhugur Plugins on Xojo 2015r3 compiling 64 bit and for Raspberry PI

We have been very active for the past months updating on the alpha and beta lists of Xojo to make sure we would have as much of plugins as we could on day one for our users.

In the comming days we will be packaging plugins that are 100% ready and displaying them here on the web with pictures and everything.

In the mean time we would like to invite you to our cloud drive to grab a copy of them in current state so you can start developing for 64bit and Raspberry PI. Note that most of them are in ready release state already.

Click here to download from the Einhugur Cloud  (Note link this only shows unpublished plugins) 

For published plugins that have been updated you can go to the following links.

Published full versions

Published demo versions

Einhugur loves Raspberry PI and Electronics !


Since we love Raspberry PI and electronics then we have opened zone with step by step Wiring PI and sensor guides that are oriented for Xojo developement on Raspberry PI. All the guides are free of charge for everyone.

Click here to go to Einhugur wiring and sensor guides for Raspberry PI

Next set to boards to test and develop Xojo ARM plugins arrive

Banana PI M2 and Orange PI 2

Next set of boards to develop and test arrived, this time it was Banana PI M2 and Orange PI 2.

I had seen reviews on the web on the hardware, that soldering on the Orange PI was crude, but I found both boards to be flawless in every way as far as manufacturing goes.

At first look then both of the boards solve what annoys me the most on the Raspberry PI, the power connector. On the Raspberry PI the power connector tends to be sensitive to movement when fiddling with the board so it tends to reboot. Thats not the case with the Banana PI and Orange PI where the connector is not sensitive at all, its a different kind than Raspberry uses.

Both Banana PI and Orange PI have huge issues with detecting the display, going through DVI adapter is very bad for example. Resolution is hard coded and you cannot change it without going through a lot of trouble changing the boot, which I have not figured out how to do. Default resolution is 1280 x 720 which many displays have problem displaying.

(I imagine on some displays it will manage to Auto detect 1920 x 1080 but I have not had that luck, from reading on the web then most seem to disable display auto detection and manually enter their display sync parameters, but I have not able to figure out how so far.)

Now if you get the display to work then both machines are really great. I only got it at the 1280 x 720 which is all right for me for now since I work on them remotely through SSH anyhow.

I got the built in wireless to work on both of them without too much pain.

The Banana PI’s Raspian installation is not much changed from the Raspberry PI version of it, everything in sudo raspi-config seems to work fine and it even has some new options there.

Orange PI seems to have forked a bit further away, there is not as much in their sudo raspi-config tool. But the OS comes very rich of features.

And at last a simple benchmark where the test case was to build the Einhugur GraphicsFormats plugin for ARM. (ALL machines used same type of Class 10 memory card, and building was done over SSH on all of them)

  • Raspberry PI 2 finished in 10 min and 45 seconds
  • Banana PI M2 finished in 6 min and 28 seconds
  • Orange PI 2 finished in 6 min and 15 seconds

Note the Orange PI did not produce 100% binary compatible result, I am guessing that it has different version of some library, it should not affect the speed test even if it will affect the usability for me.

Banana PI and Raspberry PI produced 100% same result.

This is of course just one type of benchmark and perhaps does not reflect well the higher clocked CPU in the Orange PI as much of compiling is just disk IO.

Hopefully we can soon attempt multi core image processing test with the PictureEffects plugin.

First Raspberry PI 2 boards arrive


First Raspberry PI 2 boards arrive.

As Xojo Inc has published then Xojo 2015r3 will be supporting Raspberry PI ARM compiles. So of course we are gearing up to support plugins for the Raspberry PI compiles.

The first shipment arrived, which contained two regular Raspberry PI 2 boards. I had in the past old generation one which had been bought from Icelandic supplier, but it crashed all the time due to weak power supply, that supplier still has weak power supplies, so I went different route this time and ordered them from China, getting 2,5 A power supply instead of 1 A.

Machines will now be set up and then we can expect some of the plugins to get ported to Raspberry PI.

I am still waiting for some Banana PI boards and one Orange PI board to have complete test line.

(Cost for two boards + 2 cases, 3 memory cards, 2 power supplies, 2 wireless adapters, cooling plates, and 2x relays, shipping and import taxes was roughly same as one system in Iceland, but then again prices in Iceland are known to be insane. It took 16 days to get them here)

Einhugur technical blog that involves Xojo and Einhugur Xojo plugin related topics