Feedback is welcome

[pthom]

Constructive feedback and ideas are welcome.
Did you learn something with the manual, did it help you?

[floooh]

This is a wonderful project :)

Are you interested in some PRs which would improve the "web experience"? I have a few things in mind, although one would be quite radical:

1. This would be a minor fix, but currently I get a popup warning when clicking on the buttons which open a link in the browser. It should be possible to avoid that (see here: https://floooh.github.io/visual6502remix/, open "Help -> About" and click on any of the links. This uses the window.open() JS functions which seems to open the link in a new tab without a popup warning, and also seems to work across domains (see here: https://github.com/floooh/v6502r/blob/e67641d454abe1d3dd5051a2538d7721b4d84b4e/src/util.c#L96-L99). This is the popup warning I'm currently getting btw:

2. This would be the "radical change", but by using sokol_app.h + sokol_gfx.h instead of SDL, the size of the WASM blob could most likely be cut at least in half (see the ImGui demos on this page): https://floooh.github.io/sokol-html5/. I would at least like to tinker around with that idea in a fork to see how big the size savings would be, but of course it's up to you if you want to accept such a relatively big change.

3. Another thing I noticed is that the web server you are serving from doesn't seem to be configured for serving WASM, which leads to the WASM blob being loaded somewhat non-efficiently, and it also seems to served uncompressed (see the download size in the next screenshot):

Also, for some reason the WASM seems to be loaded twice (not sure yet why that is):

The easiest way to fix this would be to serve from github-pages (this sets the correct MIME type and also serves WASM blobs compressed), but of course that's also up to you if you even want that :)

Cheers :)
-Floh.

[pthom]

This is a wonderful project :)

Are you interested in some PRs which would improve the "web experience"? I have a few things in mind, although one would be quite radical:

Thanks you very much for your interest and your kind words. Of course I am interested in PRs!

1. This would be a minor fix, but currently I get a popup warning when clicking on the buttons which open a link in the browser.

If you find a better solution, I am interested. However the code is already using window.open
The url opener code is in src/utilities/HyperlinkHelper.cpp:

#if defined(__EMSCRIPTEN__)
        std::string js_command = "window.open(\"" + url + "\");";
            emscripten_run_script(js_command.c_str());
...

2. This would be the "radical change", but by using sokol_app.h + sokol_gfx.h instead of SDL, the size
   of the WASM blob could most likely be cut at least in half

Please do try, I am interested! Especially, since you are the author of sokol. I did not know about your project, but it seems quite interesting!

Some advices on how you could handle this: this project is based on another project I recently published (Hello ImGui), which supports several backends (sdl, glfw, and qt for the moment).

external/hello_imgui/src/hello_imgui/internal/backend_impls is where the backend implementations are stored. AbstractRunner is the base class, RunnerSdlOpenGl3, RunnerGlfwOpenGl3 and RunnerQt are different available backends. RunnerEmscripten is just a specialization for RunnerSdlOpenGl3 (but if sokol proves better this might change :-). RunnerFactory will autodetect the backend based on the cmake options.

On point of attention although. In the manual, I am able to display image as OpenGl Textures (see external/hello_imgui/src/hello_imgui/internal/image_gl.cpp). Would this still be possible with sokol?

3. Another thing I noticed is that the web server you are serving from doesn't seem to be configured
   for serving WASM, which leads to the WASM blob being loaded somewhat non-efficiently,
   and it also seems to served uncompressed (see the download size in the next screenshot):

I will try to put it on github pages. Actually I did not even take time to think of the better server, I just rsynced to one of my servers. As do not use anything special on the server, any server can do the job -)

BTW there is another web issue which I will need to address, concerning the copy and paste. Due to security reasons, the code cannot access the system clipboard. I will need to investigate if there is a workaround (for example, with an external div + textarea that would popup onto the app).

Cheers,

Pascal

[floooh]

However the code is already using window.open

Ah, I remember what's the problem. The code must be run from inside an input event handler (this is a typical restriction on the web unfortunately). E.g. I call this function from the sokol_app.h event handler function, which is called from inside emscripten's event handler functions, which in turn is called from the Javascript input event handlers:

https://github.com/floooh/v6502r/blob/e67641d454abe1d3dd5051a2538d7721b4d84b4e/src/ui.cc#L192-L196

Now that I remember that, this was also one problem (among several) for copy/paste:

BTW there is another web issue which I will need to address, concerning the copy and paste. Due to security reasons, the code cannot access the system clipboard. I will need to investigate if there is a workaround (for example, with an external div + textarea that would popup onto the app).

Yeah I had a lot of fun with copy/paste too ;) I have a somewhat working version here:

https://floooh.github.io/visual6502remix/

Open the integrated assembly editor via View -> Assembler, and then you can copy/paste text in and out via the usual hotkeys (Ctrl/Cmd + X/C/V).

The copy/paste code must again be executed from inside input event handlers (same as opening a browser tab):

https://github.com/floooh/v6502r/blob/e67641d454abe1d3dd5051a2538d7721b4d84b4e/src/ui.cc#L266-L278

The underlying JS code also uses a textarea HTML helper element. This was the only clipboard-handling method I could reliably get to work across all browsers (there's a newer more straightforward API, but IFIR this wasn't supported in Safari.

I'll try to tinker around with it in a few days (hopefully) :)

PS: one thing that I couldn't get working is seamless clipboard support with ImGui's clipboard functions unfortunately, IFIR the problem was that pasting on the web is strictly event based. You can't simply "read" the system clipboard in the browser, instead you need to listen to a pasted-event from that textarea, and read the pasted data from the event. I couldn't find a good way to hook this up to ImGui's SetClipboardText() / GetClipboardText() functions.

PPS: forgot a link to the emscripten clipboard handling code in sokol_app.h:

https://github.com/floooh/sokol/blob/3b92290cef6793614e2a24738feab2a811d3282c/sokol_app.h#L2375-L2436

[iKlsR]

@floooh Is your imgui highdpi example the best we can expect for font rendering in the browser? Maybe some of that could be applied here as well.

[pthom]

A somewhat related info: I have developed an environment in which one can instantly write and test mini ImGui apps, without installing any development environment. It is available here.

[floooh]

Is your imgui highdpi example the best we can expect for font rendering in the browser?

Unfortunately the imgui-highdpi demo only looks good on an actual highdpi display, on lowdpi that TTF font doesn't look so great because it's missing subpixel hinting (or rather the ImGui text rendering doesn't use subpixel hinting, using FreeType instead apparently yields slightly better results, but that's a big dependency).

This is what the imgui-highdpi sample looks like on my lowdpi (1080p) monitor:

...and this is the "normal" ImGui demo with the default font on a lowdpi monitor:

The "lowdpi" sample shows different problems though if it is running on a highdpi monitor with an "odd" upscaling factor (like 1.5x, which isn't unusual on non-Mac machines).

There some more info in this twitter subthread, including some feedback from the ImGui author himself:

https://twitter.com/pervognsen/status/1280072599196692481

[pthom]

Update: I have added some code navigation features :

Hierarchical index of the demos

Hierarchical index of imgui.h code sections

Those indexes are searchable.
Example: search for code sections related to docking

And you can search for more information about anything with a right click

A short demo video (1'40") of this features: https://www.youtube.com/watch?v=5jHilwGNSmA&feature=youtu.be

[pthom]

Cross link to the corresponding topic inside imgui repo: ocornut/imgui#3342

[pthom]

Hello @floooh ,

I have some more info for you. This is more for information: in this summer period, I hope you are enjoying some deserved holidays!

Wasm mime type:

Another thing I noticed is that the web server you are serving from doesn't seem to be configured
f> or serving WASM, which leads to the WASM blob being loaded somewhat non-efficiently,
and it also seems to served uncompressed (see the download size in the next screenshot):

The manual is now online on github pages at https://pthom.github.io/imgui_manual_online/manual/imgui_manual.html
Hopefuly the downloads will now be faster.

I created a small website at https://pthom.github.io/imgui_manual_online. It looks atrocious, but, well... I'm not a designer. May be an empty page would have been better :-)

Size of the wasm blob / port to sokol

I do not know if you still plan to port this app to sokol, but just in case, here is some information about the size of the blobs that are linked to the app. Below are the size in kilobytes:

➜  src git:(master) ✗ du -sk imgui_manual.*|sort -n
4	imgui_manual.html
476	imgui_manual.js
1832	imgui_manual.wasm
3288	imgui_manual.data

Once gzipped, they are reduced to this (and hope github pages is able to transmit them in a compressed way):

➜  src git:(master) ✗ du -sk imgui_manual.*|sort -n
4	imgui_manual.html.gz
104	imgui_manual.js.gz
560	imgui_manual.wasm.gz
1028	imgui_manual.data.gz

The reason for which the data blob is so big is that the app bundles the code for imgui (about 2.4 MB): here is a list of the bundled assets folders:

➜  src git:(master) ✗ for d in $(find assets -type d); do du -sk $d; done | sort -n
32	assets/code/imgui_manual/source_parse/tests
36	assets/code/fplus
40	assets/code/imgui_markdown
96	assets/fonts
120	assets/code/ImGuiColorTextEdit
132	assets/code/imgui_manual/source_parse
136	assets/code/hello_imgui
356	assets/code/imgui_manual
2384	assets/code/imgui
3072	assets/code
3168	assets

Copy-paste / open url:

Many thanks for the links to your code. It seems you had a lot fun, that is true ;-)

[pthom]

An experimental online playground for ImGui based on this manual: Playground + demo

[pthom]

@floooh : I added support for clipboard copy in this commit by taking inspiration from your suggestions and from the sokol code.

I can copy to the system clipboard, but I can not paste from the system clipboard (it was kinda working, but unreliably depending on the browser / os). However, in the case of this project, pasting is less important.

Btw, I checked out sokol and fips : quite impressive :-)

I wish I had known about fips when I worked on my own implementation of multiplatform compilation (including mobile devices + emscripten) for hello-imgui. This would probably have saved me a lot of time.

[pthom]

@floooh : I made some investigations about the possible use of sokol. You can see a live test and a report in this related issue