Eric, Before we determine how best to deal with the UI side of IUP browser interface, I think we need to get the basic framework for the browser IUP driver working. Antonio didn't think this was a big deal when I brought up the concept the first time around.
* Determine screen size, DPI, default font, ... * Work out callbacks. Some may be handled by the client and others off loaded to the server. Between HTML, CSS and JavaScript I think a desktop compatible UI could be assembled and be a worthwhile effort on our part. The other direction might be HTML5. John On Fri, 2017-01-20 at 05:52 -0800, Eric Wing wrote: > > On 1/19/17, John Spikowski <supp...@scriptbasic.org> wrote: > > > > > > Eric, > > > > I'm not interested in using Emscripten of IUP C code to work on the > > web. Try to translate a simple "Hello World" in C to JavaScript > > using > > Emscripten and you will be blown away how much support code is > > generated. > > > > My goal is building a 'HTML' IUP driver and use a popular > > JavaScript > > framework to produce the UI. > > > > John > Yes, I’ve tried Emscripten before. And I agree with you that there is > quite a bit of bloat. (But I also am really picky and frustrated how > slow and bloated software has become and things that are big to me > are > small to other people.) > > This is an SDL program I wrote in pure C and then ported to the > browser using Emscripten. Use Firefox or maybe Safari (I’m having > problems with Chrome) > http://playcontrol.net/tempdownload/BlurrrBinaries/FlappyBlurrrEM/Fla > ppyBlurrr.html > > > However, a few points to consider: > > - Most web frameworks are pretty bloated too. There is some > obfuscation of this fact because they dynamically download extra > framework code on-demand sometimes, which sometimes masks the true > extent of how much data they actually downloaded. > > - Web browser cache hides most of the return visit reloading > > - Content data like images and videos can quickly dominate over your > code data. So if you have a rich media site, the code size is a > rounding error in the total size of your web site. > > > (If you don’t know much about ASM.js or Web Assembly, I highly > recommend this talk, “The Birth & Death of JavaScript”. It’s both > entertaining and informative. > https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javas > cript) > > > - Web assembly is where the browsers are going. ASM.js was intended > as > the prototype/proof-of-concept. And now all the web browser makers > seem to have agreed to support Web Assembly as the standardized > successor to asm.js. Once all the major browsers roll out support, > expect an explosion of apps written from all languages (C, Python, > Lua, Ruby, Swift, Go, etc.) being compiled for the web browser. > > - Everyone will just get used to it and accept the bloat, kind > of as > they do now with the big giant bloated web frameworks being used to > create desktop apps, like Node WebKit, Electron, React, which are > like > 100MB just for Hello World. My above Flappy Blurrr Emscripten example > was 10-15MB which is still a magnitude less than that and most of > that > is due to the data from the images and audio files, and not the code. > > - Web assembly might have a tighter byte code format than what ASM.js > has to do now (which is pure text JavaScript). Some of the code bloat > could be reduced. > > > > > Anyway, as to alternatives to Emscripten, I don’t think I understand > your idea. I’m trying to figure out how you envision this, but I keep > falling short. Can you explain to me the technical details of how > this > works, because in my head, I can only see two ways to make IUP work > in > the web browser. > > 1) Emscripten-like technique that can compile IUP’s C source base > (along with your app’s C source base) to JavaScript (or Web Assembly) > > 2) Re-implement all of IUP in JavaScript. Your app must also be > written in JavaScript. This has the major downside that you can’t > easily compile a native app (Windows, GTK, etc.) any more. > > > So for example, take this very basic IUP program: > Ihandle* lbl = IupLabel("Hello,world!"); > Ihandle* btn = IupButton(“OK”, ""); > IupSetCallback(btn, "ACTION", (Icallback)DoSomethingCallback); > Ihandle* vb = IupVbox(lbl, NULL); > Ihandle* dlg=IupDialog(vb); > IupShow(dlg); > > It actually depends on quite a significant amount of IUP core > procedural C logic to do work. In addition to creating the native > widgets for Label, Button, and Dialog, there is a bunch of layout > code > computed in IUP’s core C base to figure out where to place the label > and button in the dialog. While HTML may have some static layout > capabilities to do relative layout, the first problem is that IUP’s > implementation is dynamically computed. The code is re-running > things, > like to see if the size of each of the individual widgets has > changed, > or if the widget has special properties set that may affect its > layout > position. I am having trouble seeing how to detect. express and > convert this more general, procedural, (and Turing Complete?) layout > algorithm into something that can be expressed as static, declarative > HTML. > > > Next, the button action itself I’m not certain of. So in an IUP > program like above, I have my DoSomethingCallback implemented in C. > Again, how can express/convert the full power of that arbitrary C > function procedural implementation to do the same thing in static, > declarative HTML? > > > > Or maybe I’m misunderstanding your statement entirely: “My goal is > building a 'HTML' IUP driver and use a popular JavaScript framework > to > produce the UI.” > > Maybe I’m over-emphasizing what you actually want to do with HTML? > But > the reason I’m doing that is because, otherwise, this is kind of what > Emscrpiten already does: > > Emscripten takes C code and converts it into JavaScript and HTML, > creating a runnable website. > > > > So the only remaining nuance I see is that maybe you want to > emphasize > that you want Emscripten’s Javascript output to generate 3rd party > JavaScript API calls instead of the baseline official standardized > APIs that all these libraries are built on top of. > > I personally would be hesitant to do that since “the popular” > Javascript framework seems to change every 6 months in the browser > world. (We want the IUP implementation to last a long time and be > stable.) And in the end, it doesn’t make the code size any smaller > because you need Emscripten to convert code, and then you must add > the > 3rd party library Javascript implementation on top of it. And there > may be redundancy in what IUP’s base can already do (like layout) and > the 3rd party library can do, which means duplication bloat. > > However, I’m not strongly opposed to the idea of using a 3rd-party > JavaScript framework either. This is actually an implementation > detail > that is much finer detail than what I was originally describing. I > was > just trying to explain how the overall architecture works. The > specific JavaScript backend implementation isn’t terribly critical in > terms of the big picture of just getting IUP to work in the browser. > (Caveat: I’m saying this as somebody who doesn’t really know web > programming and differences between all the third party libraries, so > I could be underestimating the design impact.) > > And we could theoretically create sub-variants of Emscripten backends > of IUP. So maybe one is based on pure baseline, official, > standardized > APIs, and another uses JQuery, and another uses Electron, and another > uses React. There could be compiler instructions (#ifdefs) to select > which JS backend to compile in. > > > But anyway, I’m interested in understanding better your approach. > > Thanks, > Eric > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
