Einhugur Plugin releases

To say that someone’s business decision is nonsense is, well, nonsense. None of us knows the financials of a private company. So I have to take Bjorn at his word because I do not have any information to contradict him. He knows his business better than any of us ever will.

What I do know is that the 3rd party market for Xojo is tiny. It’s very hard, if not impossible, for anyone selling libraries, controls, source code, etc to make a living doing it. I can’t think of a single developer doing so that doesn’t have a full time job or that doesn’t do consulting to pay the bills.

If you want to bitch about the market not doing better, perhaps you should look at Xojo Inc. and address what they are NOT doing to promote and encourage 3rd party products. I look around at Xamarin, Visual Studio, even LiveCode and see companies that are actively promoting their 3rd party market. You all know me. I’m as much a Xojo promoter as anyone. But except for allowing 3rd party product in their store (which they take a cut of sales), Tweeting about products, and a 3rd party products page what does Xojo do for 3rd party products? Not much.

As Bjorn said, the plugin SDK is immature. They give zero guidance for cross platform native controls. You’d think for a company that must have gone through this exercise a few times that they’d tell us how to do it. Nope. Bjorn and Christian are pretty much the only plugin developers that have figured out how to do native controls. So the failure is Xojo’s. Plus, I’m sure if we really got into the details there are probably a number of things in the SDK that aren’t fully fleshed out.

Anyway, rant over. I’ve received similar ‘advice’ over the years. If I had taken half of it I’d be bankrupt and working for someone else. Instead, I have three full-time developers that I keep busy on Xojo consulting projects. When we have time we work on our 3rd party products. First for ourselves and second for everyone else. That’s what keeps us in business.

@Björn: Isn’t this like a hen/egg problem? You say you don’t earn enough money. But how do you think you could earn more money if your flagship products aren’t even Retina compatible? Customers notice this and simply delete my software.

Personally I’ve always thought Bjorn underpriced his add ons
Companies I used to work for / with paid several hundred per developer for grid controls in VB
Never mind anything else they used
Bjorn only asks 199 for ALL of his

Not really
As far as I understand it the grid controls have to be completely rewritten - not just retinized.
I asked Bjorn about this for something I wrote 8 years ago which is undergoing a bit of a face lift.
It used the data grid.

I’m a developer and a customer. Here I’m a customer and I see “no retina”. The rest frankly doesn’t interest me.

Bjorn’s made a business choice - and that’s his choice and his alone to make.
There are those who don’t like the choice which is to discontinue a product they use.
It happens.

Please don’t misquote me. The “nonsense” part was his explanation about us expecting a new version to be build on 17 year old technology.

If he doesn’t want to make a grid then that is his right. I at no point called his business decision “nonsense”.

I can agree that Einhugur collection of control are under priced. Especially compared with vendors’ price list.

Actually, this discussion clearly shows the need that Xojo Inc take its responsibility and ship modern controls with Xojo.

As it is now Xojo Inc direct us to third part vendors who apparently don’t make the money enough to put more time in it and provide Xojo developers with modern controls.

For a business this is the core weakness with Xojo. Too depended on “one-man-developer-shops”. Suppose the top five ojo vendors would shut down their business. What would it mean for the average Xojo developer?

Of course, we can all build our own customized controls. But for those who running a business, who will pay for it?

And his renewal price is amazing ( almost nothing ). A developer gets a lot for what Bjorn asks for his work.

[quote=226670:@Markus Winter]Please don’t misquote me. The “nonsense” part was his explanation about us expecting a new version to be build on 17 year old technology.

Let’s continue with your original quote then:

Here you say EXACTLY what he should have been doing. I’m calling nonsense on this part of your response.

Yes, it would be nice if he had a newer version of StyleGrid and DataGrid. He doesn’t and it doesn’t matter what the excuse is. For reasons not known to us his business decided to not update them. Perhaps the plugin SDK isn’t up to the task. Perhaps Cocoa is just too big a PITA. Doesn’t matter. To make a claim on what he should have been doing is silly.

I suggest that if you are so sure it could have been done in 3 years (and still stay in business) then I will mark it on my calendar and contact you in 3 years to see if you have come up with a grid replacement.

No. What this shows is that the plugin SDK isn’t well good enough for complex controls. I can’t think of anything more complex than a grid.

We can agree to disagree on the exact problem. What we do know is that we have right now isn’t good enough to satisfy 3rd party developers nor users. I would think Xojo is dissatisfied with the status quo too. So the real question is how to fix it?

Before I start I want to say Bjorn is great and his products are too…

I used StyleGrid for YEARS in a big commercial app that is used by thousands and thousands of people all over the world. We support Mac, Windows and Linux. 3 years ago I talked to Bjorn about the status of a cocoa build of StyleGrid. He told me that he is going to try, but that the project is so huge and old that he can’t promise anything. He eventually did release a Cocoa build but I believe it had issues at the time (I don’t know the status of it now since I stopped using it a while ago).

Anyway, then and there I decided I couldn’t afford to wait to see what would happen. So instead of being upset and complaining, I started converting my grids to the Xojo ListBox. At first it looked almost impossible, but I took a deep breath and with a lot of work and patience I converted everything step by step. Along the way I had to heavily subclass the ListBox to get it to do the things I needed it to do. But in the end everything turned out fine and I have been using the ListBox for 2 years now (going from using the StyleGrid for about 7 years).

With that being said, Bjorn is great! He always answers emails quickly, and he releases bug fixes quickly. When we needed help, he was there. When he couldn’t help, he was honest (like how he is honest with the StyleGrid status).

If StyleGrid isn’t working for you in its current state, please move to the ListBox or another control. It may look impossible, but once you get started you will see it is possible.

lets stop this ranting please… the discussion came to a dead end… I am sitting between these positions. On one hand I understand frustration of missing Controls, on the other hand I understand Björns position. I wouldn’t do either investing my time without getting something back.

Somewhere I hope Xojo will bring up a decent set of basic controls at least for Windows and Mac OS X.

[b]Picture Effects 9.0 has been released.

New in 9.0[/b]
Added 64 bit compile support for Windows targets.
Added 64 bit compile support for Linux targets.
Added ARM compile support for Linux.
Fixed color issues in PageCurl effect on Cocoa compiles.
All global methods have been moved into modules but set with global attribute there.
Matrix class was renamed to ConvolutionMatrix.
PictureEffectsChannel constants have been moved to the ImageChannelMixer class.
RotationMethod constants have been moved to the RotateEffect class.
GrayScaleType constants have been moved to the GrayscaleEffect class.
RankOrderMethod constants have moved to RankOrderModule.
Slightly reduced internal segment count of the plugin.
The EnsurePictureBits and EnsurePictureCompatible functions have been moved into PictureEffectsUtilities module.
PictureEffectsConsole and the new upcoming PictureEffectsRaw will now be separate download with separate release dates.

PictureEffects is a Xojo plugin to do image processing. Most of the effects in it can use multiple CPU cores to speed up the processing, allowing use of up to 8 CPU cores at once.

more info at www.einhugur.com

First I agree that Einhugur provides a LOT of value for the price, even without the grid controls.

I can understand why those who had come to depend on them are upset… but given how small and how price sensitive the Xojo add-on market is, I think their expectations are unrealistic.

My own 3rd party listbox control, as it is written in RB/Xojo, has needed very few changes over the last 5 years to keep it working, and I expect/hope that will continue to be the case…

But If Xojo suddenly made very major changes to the built-in listbox behavior that broke it (or deprecated and removed it), given the sales, I would likely have to say the same thing as Björn.

For some reason people seem to think that general purpose listboxes and grid controls are relatively simple things…

I think anybody who has done significant work with the Xojo listbox comes to understand 2 things:

  1. It is very complicated to create a good, GENERAL PURPOSE, X-PLATFORM and FLEXIBLE grid type control no matter what.

  2. The Xojo listbox, while a complicated beast, is a very reasonable starting point for many situations. If you are willing to learn it and put in the work, you can make it do almost anything with less work than starting from scratch.

  • Karen

I’d like to give my most important project the LLVM treatment but it’s got lots of StyleGrids :frowning:

I guess I should be grateful I saw this thread before renewing.

CalendarControl 6.5 has been released.

New in 6.5:
[i]* Added 64 bit compile support for Mac targets.

  • Added 64 bit compile support for Windows targets.
  • Added 64 bit compile support for Linux targets.
  • Added ARM compile support for Raspberry PI.
  • Slightly re-touched the look and feel on Windows and Linux systems.
  • Added OSXDrawWeekBars property to turn Optionally turn off drawing the week bars on OS X. (Request ID 0000008 in the Einhugur bug base) (Note when upgrading existing projects then this property gets set to false by Xojo so if you want it on which is the default when dragging new control on the window then you need to turn it on in the property browser).
  • Did some El Capitan tweaks and fixes in look and feel.[/i]

More info at www.einhugur.com

[b]JSON Parser 1.5 is out.

New in 1.5:[/b]

  • Added 64 bit compile support for Mac targets.
  • Added 64 bit compile support for Windows targets.
  • Added 64 bit compile support for Linux targets.
  • Added ARM compile support for Linux targets.

More info at www.einhugur.com

e-CryptIt Engine Partial Release 7 is out on our beta zone.

Partial release 7 adds Linux 64bit build and ARM Linux build.

The Partial release contains the classes we are taking with us to 64 bit. Other classes we will likely separate into different Legacy encoders plugin which will contain things that don’t make much sense any more on modern operating systems like AppleSingle, BinHex, etc, which will not be ported to 64 bit for obvious reasons.

It contains so far 13 out of 22 internal plugins of the full e-CryptIt Engine plugin.

Classes in those first 10 plugins:
AES_CBC, AEC_ECB, TwofishECB, TwofishCBC, TwofishCFB1, Blowfish_ECB, Blowfish_CBC, Serpent, eCrypt Encryption
SHA, SHA1, SHA3, SHA_256, SHA_384, SHA_512, MD5, RIPEMD_128, RIPEMD_160
CRC16, CRC32, Adler32,
ZCompression, ZStream, ZStreamWriter, ZStreamReader,
Base64Stream, UUCoderStream, EinhugurBase64Module, eCrypt Encoding

All the classes are 64 bit compatible on Mac, Windows and Linux as well as Linux ARM compatible.

We just auto generated the documentation, for the partial release to show the syntax. Please refer to the documentation with the full e-CryptIt Engine for those classes.

No syntax has been changed, except the AES classes can now optionally also operate on MemoryBlock, and most of the Hashing algorithms can now optionally use MemoryBlocks.

To access our Beta zone go to:


(Please note the beta zone may be slow and or have timeout issues, the host is having some issues)

TreeView 6.5.2 is out

  • Fixed bug [0000014]: DrawBackground event does not work correctly on CustomNodes on MacOS X.

JSON Parser 1.5.4 beta is out on our beta downloads

  • Changed Linux 32bit, 64bit and ARM to Clang compile. (users who have Linux library version issues with their distros probably should try this, as i it works out well then we will be switching a lot more plugins to Clang).

More info on www.einhugur.com

[b]BarcodePlugin 1.0, PictureEffectsRaw 1.0, GraphicsFormats 5.6 and TypeLib 7.6 are out

BarcodePlugin 1.0:[/b]

This is a new plugin to detect barcodes and QR codes.

The plugin supports the following standards:
Aztec, Codebar, Code 39, Code 93, Code 128, Data Matrix, EAN 8, EAN 13, ITF, PDF 417, QR Code, UPC A, UPC E

And the plugin is supported on all platforms.

(Note the example projects need PictureEffectsRaw, GraphicsFormats and TypeLib)

PictureEffectsRaw 1.0:

This is also a new plugin.

This is handy where the plugin needs to run on Enterprise restricted environment such as various of cloud servers, or if you need to interact with other 3rd party plugins that can work on MemoryBlock. Given Xojo picture inaccuracy in Console mode then RawBitmap handling offers superior accuracy per platform and across platforms. PictureEffectsRaw can also be used together with the Einhugur BarcodePlugin to support auto rotation in barcode detection.

GraphicsFormats 5.6: (5.5 was never officially published so this change log is for both of them)

[i]* Changed compiler on Linux 32 bit to Clang.

  • Changed compiler on Linux 64 bit to Clang.
  • Changed the compiler on Linux ARM 32 bit to Clang
  • Added 64 bit compile support for Mac targets.
  • Added 64 bit compile support for Windows targets.
  • Added 64 bit compile support for Linux targets.
  • Added ARM compile support for Linux targets.[/i]

TypeLib 7.6:

[i]* Changed compiler on Linux 32 bit to Clang.

  • Changed compiler on Linux 64 bit to Clang.
  • Changed the compiler on Linux ARM 32 bit to Clang[/i]

More info on www.einhugur.com