The Async framework for image processing is out but what is next.

Its been a while since posting here, I wanted to put out a post since the Async feature in PictureEffectsRaw finally came out and so far its been great success.

So what is next ?  Many are waiting for GTK3 version of the TreeView so TreeView is getting most of the time those days.

Milestone 2 has been reached with the TreeView for GTK3 so far, so a lot has been done. Where Milestone 1 was to get it to compile and Milestone 2 to get it to actually run on GTK3.

Left to do is to make all Theme objects draw correctly on GTK3 so under GTK3 things like scrollbar and checkboxes and other such are not drawing but the control in whole though working.

Users who are desperate to test their apps under GTK3 can get Alpha versions if they wish.

Theme parts left to handle in some what for milestone 3:
Frame theme part – done
Expanders in native mode – done
Checkboxes
– done
Scrollbar
Headers

Asynchronous image processing coming soon in PictureEffectsRaw

I just wanted to post here a little bit on what has been in the works for our Image Processing framework for Xojo.

Basically in the coming versions of PictureEffectsRaw we will start to add asynchronous methods to every single class. This will probably happen gradually, adding few effect classes per release.

So here is what this means for your code: (Time line on left showing old style synchronous mode, time line in the middle showing asynchronous mode with complete hook and time line on right showing asynchronous mode without complete hook)

Asynchronous image processing

All three modes will be supported.

Long time no post

I have not posted anything here for a while but thought it would be good to talk about Gtk3 in Xojo 2017r2.

Xojo 2017r2 is out and it now uses Gtk3 on Linux instead of Gtk2.

This means that any plugin that uses Gtk2 in any way will not work on Xojo 2017r2 when compiling for Linux.

In terms of Einhugur Plugins then this means all control plugins, all plugins that deal with Pictures and possibly others.

In the coming weeks and months we will be pushing out updates to get Gtk3 on board then probably we will have 2 lines, Gtk2 and Gtk3 so that we can also support older versions than 2017r2.
One of the challenges with Gtk3 is that not all things work the same like for example Gtk3 theme for Ubuntu draws nothing at all for a WindowSplitter, while Gtk2 theme running on exactly same Ubuntu will draw some glyph for the splitter.

We will be pushing out few updates non Gtk3 related updates before we start pushing out Gtk3 compatible plugins, like for example minor update for the ExcelWriter plugin which was officially released at the Xojo Conference in Berlin. (That plugin has been very well seen by our users). Column alignment will come in the TreeView control before we start pushing out Gtk3 updates and there will be other minor releases of some plugins.

Update with progress so far (Dec 2017):

  • TypeLib (8.1) updated to support Gtk3
  • TypeLibF (2.2) tested to work with Gtk3 no changes needed. (2.2)
  • PictureEffectsRaw (2.5) tested to work with Gtk3 no changes needed but needs TypeLib 8.1 or 8.2 with GTK 3 support.
  • ExcelWriter Plugin (1.2) tested to work with Gtk3 no changes needed but needs TypeLib 8.1 or 8.2 with GTK 3 support.
  • e-CryptIt Engine (13.1.4) partially tested to work with Gtk3 no changes needed but needs TypeLib 8.1 or 8.2 with GTK 3 support. (other parts of the plugin are expected to work unchanged as well)
  • WindowSplitter (9.0) updated to support Gtk3
  • CalendarControl (7.0) updated to support Gtk3
  • PDF Plugin (1.3.2) tested to work with Gtk3 no changes needed but needs TypeLib 8.1 or 8.2 with GTK 3 support.
  • DateControl (7.0) updated to support Gtk3.
  • TimeControl (6.5) updated to support Gtk3.
  • PictureButton (4.0) updated to support Gtk3.

We need our users help else important plugin showstopper plugin related bugs in Xojo are not looked at

We really need users to sign onto plugin showstoppers in the Xojo bug base because of their awful system to weight the bugs then if only the plugin author signs them then the issue will not get any attention.

This one here causes Plugin control experience on Linux to be less than good, basically Linux Them drawing will randomly not work because Xojo leaves the graphics port in some bad state if focus was obtained with SetFocus: 43559
Update: we don’t really care about 43559 any more having found ways to clean up the graphics state our selfs to get things to work right.

This one here causes plugin controls in IDE design mode to draw Picture way to big and out of bounds when using Image sets, giving Xojo really bad impression to new users right away in design mode. Event Xojo’s own Bevel button can reproduce this issue.
43174 – Controls that use image sets always show the 2x image regardless of whether the IDE is on a 1x or 2x screen

Other news is that the new ExcelWriter plugin that will be coming soon is progressing well and there are no big problems expected. Its release date is not decided yet but we might post some pre-releases on our Beta zone.

Coming soon…

We will be pushing out a decent ExcelExporter plugin for Xojo soon.

For many years we have had the Excel Exporter classes that wrote to old XML Excel file format which has little to no support any more. This format never even was Excel’s main format but was more of created for interoperability back then.

And of course over the years there have been countless requests for a decent exporter that can write out to fully native and up to date xlsx Excel files.

The new Plugin will put the old Excel exporter classes from us to rest.

The new plugin writes fully native xlsx files.  

If it will be in December 2016 or January 2017 I do not know but current status of the project is that basic features work on Mac 32 bit and 64 bit as well as Windows 32 bit and 64 bit. Linux remains to be done and more complex features will then be slowly added to all of the platforms.

Feature set will be far more bigger than we ever had on the old Excel Exporter classes.


Other than that then updating more controls and fine tuning for the Windows changes in Xojo 2016r4 has most of the focus.

Buying software vs renting software.

I my self somehow don’t like the idea of renting software. I think part of the reason is that if I do rent then I would feel I would have to use it all the time to justify the rent. While if I purchase then I just go for it and feel good that I have it and I don’t worry about how often I use it. This is of course mostly mentality issue since in some cases renting can be more economic for people.

Having looked around then I am not alone, people are enraging all of the the web about Adobe’s model to only rent out most of their software now. When looking around I found that how people feel about it has empowered companies to actually invest and try to make real alternatives. Which is of course good. So policies to only rent their software seems to create new competitors on the market that will fill the gap in the market as well as push the consumer to look for those new competitors.

I know I did this my self and ended up very happy when I found Affinity Photo and bought their software, which is in my opinion very viable competitor to Photoshop.

 

My feeling that going exclusive for software renting is huge marketing risk. What do others think ?

Comming soon……

We don’t usually post what is about to come but recently when releasing the QRCode Generator then we got many questions on if we would also supply BarCode generator.

I can now confirm that BarCode generator is coming.

Prototype of the Barcode Generator running:

BarCode

It is at this moment unclear which standards we will release in first version. But Code128 and Code93 I can confirm already working.

BarCodes can be generated to Picture object or to SVG vector file.

Now as easter egg….. since the prototype has been done in pure Xojo then we did a fork of the prototype and a iOS module was born.

BarCodeiOS

So this will be first time we supply any kind of Xojo code for iOS also.

The desktop version will most likely be in Plugin (added to our existing BarCode Plugin while the iOS version will come as Xojo module)

Q: Does this mean that everything or most things from us will come for iOS.

A: No I’m afraid not. Most is done in complex C code and will never come for iOS while Xojo does not support some sort of Plugin mechanism for iOS compiles.

Update 11. Aug:

EAN8 and EAN13 been added to confirmed ones that we will support.

EAN13 Barcode generated with Einhugur Barcode module
EAN13 Barcode generated with Einhugur Barcode module

To know when to toss your items or code when things have gone bad.

Yesterday I was working on new GPIO guide, and I was doing the wiring, nothing was working and I had tried 7 chips for the experiment, none of them behaved same and none of them behaved anywhere close to what I expected. Then I burnt my finger when touching the chip and I realized that something was very wrong.

The breadboard power supply had started to put out 11.8 V instead of the expected 5V.

So having been running on over voltage all resistors hot, all chips behaving wrong and overly hot then what do you do ?

I was frustrated and was at first going to try to measure every single piece and then decide what to toss and what not. But luckily day after I had come to my senses. I think its built into us to try to preserve. What does it cost, the time to evaluate every component vs tossing them. And what does it cost to potentially have component in later experiment that might not behave as expected. So i tossed it all, chips, transistors, resistors, LED’s, everything.

I think same lesson also often applies for code, we are to conservative on old code, to patch it even if it makes little sense instead of tossing it and make room for new and better code.

Whats been happening (May – June 2016) ?

There has been a bit of silence lately from us on the Plugin front, apart from one small update of TypeLib.

For those that have been wondering about it then things have been moving nicely internally.  So around or before mid June we will be updating our PDF Plugin for Xojo to version 1.1,

The update will enable compression to make your generated PDF’s a lot smaller. The PDF Plugin update will also have some other new nice features. Along with the PDF Plugin update then there will be updated to the e-CryptIt Engine (a small update to support the PDF Plugin) and another update to TypeLib (also small update to support the PDF Plugin)

On the Electronic GPIO front a lot has been happening:

And some minor updates to older guides.

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