We’re finding lots of inconsistencies between the IDE and what actually diplays in any browser.
I understand that when you put an icon on the screen for a weblistbox that that is not WYSIWYG
But there are a number of other things that don’t even come out close to what the ID shows.
Simple basic question. When I see the IDE acting differently than any web browser is that a bug? Or is that the limits of the Xojo IDE/by design and not a bug?
try to tell feedback it’s a bug, and most important join a small project to the ticket to see the problem in real
if they can’t make it better, they will close it “by design”
It should be. Why dont you post an image with the differences?
No. It is WYSWTBWCG (What you see was the best we could get).
So the consensus here seems to be that everyone believes that it is supposed to be WYSIWYG, but there seems to be an undercurrent that it comes up short.
Could somebody from Xojo please comment whether or not it is supposed to be WYSIWYG? If it is supposed to be WYSIWYG I’ll be happy to file bug reports. Hopefully they will not be closed as feature requests.
But if it is not supposed to be WYSIWYG I don’t want to waste my time or Xojos time.
It’s as close as we can get it without using an actual browser to render it. We tried it and it was too slow.
Greg are you saying that I should report bugs that show up in the IDE and are not WYSIWYG or I should not ?
P.S. Have you tried the Browser on an m1?
You can, but the cases still might be closed if the appearance depends on some code running in a browser’s JavaScript engine.
Remember, the whole point was to be able to drop a new theme into your project and have the IDE approximate that too.
Are you saying: “Go ahead and report a bug, but we will close it if we cant fix it”?
Im not throwing rocks at you. I understand there are constraints. But …wow.
Contrary to Web 1.00 which was emulating as closely as possible a desktop app, Web 2.00 designs an HTML environment, where the place of things can change depending on the size of the browser, as well as the browser itself.
To answer your question, no, the IDE cannot be WISIWYG when it comes to Web 2.00, because that is not the way web sites work.
Wow. Outta context and brought up to like 50 thousand feet…
It is not impossible to be WYSIWYG just because it is Web (see the Offline Bootstrap Studio that uses the same CSS framework Xojo uses for example) but it is probably very hard to make within the Xojo IDE. You would need some kind of dynamic view where you can go in all kind of modes (desktop/table/mobile/…) if responsiveness is supported (not sure if Xojo already does) and, as Greg pointed out, would require some kind of HTML renderer.
From what I understand from his post, they tried it with a real browser (that is exactly what I do with my library in another tool) but it does need a very fast transpiler to work live. I think the way Xojo works it would need to recompile with every change and speed would then indeed become an issue. I can only speculate why it was to slow as I have no insight in what they tried.
Not sure how realistic Xojo shows custom made components, but I think the ‘near WYSIWYG’ Xojo has is probably close enough to get the general layout overview for most people.
Not so. It can be but a design choice was made to not use a browser component. Ergo the term ‘approximation’ was used. Seeing as aporoximation ‘closeness of fit’ is subjective, how can we all agree what is a bug then ?
– we can’t
Xojo’s IDE not being a browser, it is extremely difficult to do WISIWYG when Web is concerned.
Furthermore, the user has large control over the final result. He can chose fonts, font size and zoom level. To make it even worse, each browser has its way to show HTML.
It makes it quasi impossible to guess what the real world result will be. The only way to test such iterations is from a browser as noted by Alain, which when it comes to Xojo is by running the program.
lol
welcome to the jungle!
i say this since xojo 2018…
Regardless, the browser can (and does) run JavaScript code that also modifies the appearance which we cannot emulate in the IDE, so it’s meant to be a close approximation only.
A browser control is slower than the actual implementation?
I highly doubt that.
Sure, if you’re using jQuery or a self written JS compilation, then I can imagine. But if you’re using a modern front-end frame work, then even with bootstrap, it could be lightning fast.
We’ve done something similar and it is super responsive and fast.
Then how did Xojo do it in 1.0?