Hello
Is it normal that there is next to no reaction on feedback cases? I submitted a case over a month ago, it was verified after a couple of minutes. But since then, nothing.
That is normal.
Some cases are reviewed and fixed in a day, others wait months till they get some priority and others wait forever.
Waiting for a fix is not very wise. Xojo never gives any time estimate. If you have not found a workaround yet, posting the case number here would help others assist you.
[quote=286508:@Mathias Maes]Hello
Is it normal that there is next to no reaction on feedback cases? I submitted a case over a month ago, it was verified after a couple of minutes. But since then, nothing.[/quote]
First of all, the Verified status merely means that we have verified the behavior that you described, not that it is actually a bug. We do this as a first line of review so that those who work on IDE bugs don’t end up chasing down something that can’t be reproduced.
Once a bug has been verified, it goes into a queue for the engineers who are working on bugs. Unfortunately we can’t give a timeframe as it depends on a number of factors like how critical a bug is, whether or not it’s can easy fix (or requires a huge refactor) and if someone is already working in that section of the code, to name a few.
Just out of curiosity, what’s the case number?
Oh, and it’s worth noting that just because you don’t see any action on a case does not mean that there haven’t been internal comments.
I’m not really waiting, I was just checking out. I already asked the community, just before creating the case. But it’s a problem that cannot really be fixed without Xojo devs.
[quote=286533:@Greg O’Lone]First of all, the Verified status merely means that we have verified the behavior that you described, not that it is actually a bug. We do this as a first line of review so that those who work on IDE bugs don’t end up chasing down something that can’t be reproduced.
Once a bug has been verified, it goes into a queue for the engineers who are working on bugs. Unfortunately we can’t give a timeframe as it depends on a number of factors like how critical a bug is, whether or not it’s can easy fix (or requires a huge refactor) and if someone is already working in that section of the code, to name a few.
Just out of curiosity, what’s the case number?[/quote]
Case number is 44908.
I understand that you guys are working on a lot of bug/features, it’s more the lack of communication that bugs me.
The case number i created before that was in June last year (39555). And it’s reviewed, but that’s all. If it’s never going to get implemented, just let me know. But leaving customers with no response for over a year. That’s kind of rude.
I was intrigued by the response of Christian, so I checked the top cases. Case 11151 is ranked as 1st, so most people want this.
That case was made in 2010
Reviewed in 2012
Then again in 2015 (by you)
Then the first real answer in April this year:
That is mostly true. You cant call APIs from anything but Java. So while we can compile your code natively, we will have to have a Java layer under the hood that makes the OS API calls.
So, this is 6 years of progress, but we as a community know, next to nothing.
I’m not ranting or anything, just inviting you (and your team) to maybe discuss more what’s happing/needs to happen.
For case 44908: Xojo just embeds the OS provides HTMLViewer. They have no influence on what that one can do. So I bet unless there is an easy switch to enable WebGL, I doubt this case will be fixed.
39555 sounds useful. Having a list of all classes as part of introspection would be handy in some cases.
That’s what I tought, but NW.Js or Electron are also implementing webkit, and embedding WebGL works with at least in NW.JS, haven’t tested Electron
Safari 10 displays his site just fine. So I guess there is something missing in the version that Xojo embeds.
But HTMLViewer in Xojo is not WebKit as in Safari.
The newer WebKit used in Safari is 64-bit only.
You can try it with 64-bit Xojo app and our WKWebViewControlMBS control:
http://www.monkeybreadsoftware.net/control-wkwebviewcontrolmbs.shtml
I can confirm that WebGL seems to work in WKWebViewControlMBS as I see a landscape on your example URL here.
Then Mathias has got his workaround 
This is awesome. Is there a possibility to port WKWebViewControlMBS to Win or even Linux?
WKWebView is a component supplied by OS X
Christians exposed it in his plugin for you to get at
For Windows the plugin would likely have to hard link in a specific version of Web Kit as its not part of Windows
For Linux its probably the same to make sure the dependencies are satisfied
We had to recently do that for Linux & the framework HTMLViewer as using dylibs was too troublesome to make sure installs had all the right dependent libraries
WKWebViewControlMBS is only for Mac.
In 32-bit it uses old webview, in 64-bit, it uses newer WKWebView.