QHTML for MOZART2 (on Windows)

[andre rifaut]

I'm "porting" the QHTML sources found at https://github.com/mozart/mozart2-stdlib/blob/master/wp/qhtml/
for MOZART2 on bare Windows (i.e. without any additional and just using mozart2-2.0.0-alpha.0+build.3777.4c64bf5-x86-windows.zip)

I'm not a Mozart hacker, but Peter told me to inform hackers and users.

I have some strange bugs (see below), i.e. I think, they are not caused by the new implementation of Mozart2,
but could be old bugs not detected in the original QHTML source, or due to new versions of Windows, Firefox, ...

Does anybody know if the porting of QHTML to MOZART2 has been done somewhere ? We could join our efforts.

Currently, I do not have access to the sources of the two *.class found in https://github.com/mozart/mozart2-stdlib/tree/master/wp/qhtml/html
I tried to decompile with Java decompilers, but that does not work. (I'm not a hacker.)

I any case I will share the results of my "porting".

Thanks.

André Rifaut

PS:
Just an example of bug in https://github.com/mozart/mozart2-stdlib/blob/master/wp/qhtml/LiteWebServer.oz
"class WebServer" the method "meth start" (near lines 63-70):

               URI={Reverse
                    {List.takeWhile
                     {Reverse {Get {Get Req $ _} _}}
                     fun{$ C} C\=&/ end}}

is no longuer valid because the computed URI is equal to "class.class" due to the fact that I GET from the internet browser (Firefox) the string "/OzLink/class.class" instead of (I guess) the string "/OzLink.class"

[stewart mackenzie]

André, I don't fully understand what you are doing here.

Did you use git to clone the mozart2-stdlib repository? Did you get
the *.class via the browser?

If you used the browser, it seems you are doing this a bit backwards.
You'll need to use git to clone the repository locally. Then compile
the mozart2 project, once done run QHTML locally without the browser
playing silly buggers with URIs, this should run smoothly.

Regardless if you are going to be changing QHTML sources and
committing them upstream then you will need to learn how git and
github works. Read the http://mozart.github.io/collaboration-process
to get a better understanding of how to contribute to the mozart2 code
base.

Ping the list if you need Git support, but there is plenty of docs online.

I do not know of other people porting QHTML.

Kind regards
Stewart

[stewart mackenzie]

As you are officially entering the deep dark realms of oz hackery, you
will need to create a github account. Once that's done, I suggest you
subscribe to the https://github.com/mozart/mozart2-stdlib and
https://github.com/mozart/mozart2 accounts by clicking on the "watch"
icon. This gives you full access to all the issues and comments
associated with them.

If you have any technical issues/bugs etc they should be filed under
the "issues" section of https://github.com/mozart/mozart2-stdlib. This
allows us to keep a track of the issues at hand and answer your
questions directly. Be sure to follow these directions:
http://mozart.github.io/report-a-bug/

More general conversations should be pointed to this mailing list.

Kind regards
Stewart

[stewart mackenzie]

I'm replying on this thread as you changed the subject title on the
last email. (Try not to change the name of the subject title as it
breaks the email threading.)

This is what you said:

"Hi,

7zip cannot open those 2 *.class files (there is no *.jar file). I was
upset with that and with the fact that no java decompiler could do
anything.

But with Notepad you can see a lot of interesting strings, in
particular the name of the source, a lot of pathnames with the string
"java".
I do not know if this is usual for *.class files compiled from *.java ...

Thanks

André Rifaut "

Okay those are java applets. They are completely defunct, dead... do
java applets even run in modern browsers these days? You'll need to
replace this technology ideally with something more up to date,
something like angularjs.org. (Unless someone can suggest something
better - Sebastien did some really cool work on making Scala run in
the browser, he would have sharp knowledge in this domain) Have a read
up on http://docs.angularjs.org/guide/overview.

Kind regards
Stewart

[stewart mackenzie]

So let me get this straight, QHTML allows you to write a program in oz
using a syntax similar to QTk and deploy the application to the
browser? This allows you to interact with your oz program with the
browser? Then forget AngularJS!

If that's the case I suggest you compile the QTk(QHTML) like syntax to
something Closure Compiler
(https://developers.google.com/closure/compiler/) can understand, this
then compiles down to something much faster browsers will understand.
Closure gives you a spread of features, dead code optimization, battle
hardened code, solid cross browser support. Don't waste your time
hacking on cross browser issues, you'll go mad. Use GUI elements in
Google Library (https://developers.google.com/closure/library/) This
is to be used with Closure Closure.

I suggest you take this approach.

Clojurescript did it: https://github.com/clojure/clojurescript
Scalajs did it:
http://skillsmatter.com/podcast/home/scala-js-write-in-scala-for-the-browser-4567

Kind regards
Stewart

[andre rifaut]

I got a mail from Donatien that advised us to decompile with jad.
I did it and I saw the code.
I guess the applet is blocked due to the use of: "import netscape.javascript.JSObject;"
Because I found this recent bug: https://bugzilla.mozilla.org/show_bug.cgi?id=839967#10
The comment #10 by Leszek 2013-03-08 03:48:30 PST says:

"
So i thought of a workaround. I just fire method created in iframe from a method created in main html. In my main html i have something like <script type="text/javascript"> jsStaticMethod = function() { jsIFrameCreatedMethod(); } </script> And from applet i call jsStaticMethod... and it works....
"

In the post just above this one, Steward Mackenzie is right when saying:"Don't waste your time hacking on cross browser issues, you'll go mad."

I'll try something this week-end.

[andre rifaut]

Status:
1) most examples are running (examples that were in the qhtml folder of the mozart2-stdlib-master)
2) tested to run only for Firefox on Windows
3) No specific installation. Just unzip the official mozart2-2.0.0-alpha.0+build.3777.4c64bf5-x86-windows.zip (on github) and unzip the qhtml version containing the qhtml folder of mozart2-stdlib-master that I modified.

I will post the modified qhtml folder after some cleaning.

[andre rifaut]

1) Porting Qtk towards Qhtml does that means sticking to Tk widget set or moving to html5 widget set (if any such set)?
2) If html5 has no widget set, what widget set do I have to implement in html5?
3) If i have to stick Qtk (and Tk), then we have the following question:*Porting Qtk towards Qhtml is this as difficult as porting Tk towards Html5?"

As seen in the preceding messages I modified the original Qhtml so that it can be run on Mozart2
Then I made some tests that are ok (see preceding messages).
(I had also a look to the "mozart way" of defining tests suites -- see mailing list "Mozart Users", but may be not appropriate for applications based on an external component such as a browser.)

To test what I have done, instead of creating "dummy" samples, I'm currently porting "Micromondes" (see pvr website) and its user interface.

However I have to create widgets that are missing even in the original Qhtml implementation, such as CANVAS which are quite powerful in Tk. If I understood well, you can insert widgets into canvas. This might be done with a "svg" canvas, but not with an html5 canvas.

As Qtk is bringing Tk to Mozart, do I have to stick to the Qtk widget set (which is the tk widget set), i.e. do I have to simulate/implement the Tk widgets in html5?

But this seems very difficult as can be seen on the tcl/tk wiki: (see hereafter two quotes)

http://wiki.tcl.tk/487
Updated 2013-11-20 14:11:38 by niklauschen
Tk in the Web Browser
Tk applications run on the desktop, not in the browser. Strategically this means Tk apps will become less prevalent if most applications move to web-based software.
Tk is not universally available for the browser, so programs written in Tk can only really work on the desktop.

http://wiki.tcl.tk/4580
Porting a Tk GUI to A Web Browser
Updated 2013-10-16 06:52:19 by pooryorick
In comp.lang.tcl, I asked: "Does anyone here have any thoughts or pointers into the Wiki, or to papers that might help us port our current Tcl-Tk GUIs to a browser without re-coding in Java?"

Any idea of what is the best direction?

[stewart mackenzie]

(sorry I forgot to forward this to the list)

Okay, HTML is just a document layout type markup. It was never
designed for application development.
Though (like the rest of the web) it organically mutated into this.
Though it doesn't and hasn't solved these problems.
That is why we are inundated with all these client side frameworks.

The few that come close to representing "application development" in
the browser are things like http://www.cappuccino-project.org/
Here are some demos: http://www.cappuccino-project.org/learn/demos/LightsOff/
http://www.cappuccino-project.org/learn/demos/FlickrPhoto/
There are whole host of rich client applications - google closure
tools, openlaszlo, anglularJS, enyo, lively kernel etc
you might want to come up with a solution that abstracts out cappuccino?

Now here is an interesting idea!

I just met with the creator of red-lang.org.

There is some interesting technology there.
It could become possible to leverage the red-lang environment (http
servers and other libraries)
and build cross platform solution.
this way you can keep the QTk syntax and swap out the backend to talk
to red instead of TCL.
This then gives us android, linux, macos, windows and later iOS.
One could go a step further and create a DSL in red (its very good at
DSLs) that uses the builtin http server to do things you want for the
browser.
I'll cc the chap once my mate has charged his phone and I can get his
email address.

more answers inline


On Tue, Jan 7, 2014 at 4:48 PM, <andre....@tudor.lu> wrote:
> Thanks for your reply.
>
> I would like to get "clean" ideas of the problem.

Yes I agree clean ideas are better,

> One idea written in a paper (pvr and others) is that one language suffice
> instead of using htm tags, javascript, css rules, ... Indeed, Oz can
> represent all of those langages.
> Another idea is the "declarative description" of your user interface. This
> means a declarative description of the structural components (a button
> inside a cell of a table) of your user interface, a declarative description
> of constraints (geometry, behaviour, reaction to events ?) between
> structural components, (other declarative aspects ?).

I recall reading a paper regarding this, I forgot the name and
actually I wanted to cite it..
It'll be great if you could give me the paper name, I've been wanting
to re-read it

>
> Your remarks are additional good ideas.
>
>> "In other words keep the naming the same as HTML5"
> I agree.
> But, in the Qhtml of Mozart 1.4 they tend to re-implement functionalities of
> Tk, such as td/lr, toplevel, nswe positions and glue, ...
>
>> "HTML5 has a widget set."
> I disagree.

Well is a button not a GUI widget? http://html5doctor.com/element-index/#button

> You pointed to me "enlighment" and I think this is a widget set.
> jQueryUI tries to build a good widget set.
>
>>"Just implement what HTML5 has on offer."
> I agree with you.
>
>> "https://github.com/wmeyer/roads"
> Thanks for pointing me that. I might re-use something from that. But if the
> idea is to use only one language as possible, we have to modify that.
>
>>"This might sound a bit wild..."
> I think you answered me with your preceding remarks.
>
>
>>"... yet easily extendable to support different GUI toolkit backends."
> I agree.
> But the problem is that I have no documentation about the "conceptual
> architecture" of a widget set.
> I think there is some compositional independence between:
> 1) "structural geometry" (something look like a table structure, menu
> structure, button structure, text structure, character structure, ...)
> 2) "geometrical constraints" (glue, nswe, ...)
> 3) interaction (= events and re-actions ?)
> 4) functional aspects (behave like a table, tooltip, ...)
>
> Is it true that Tk deals better than HTML5 for that independent composition
> of 1, 2, 3, and 4 ?

For desktop applications yes I agree Tk it far superior to HTML5. HTML
is just a layout markup language.
But there are other issues with Tk, such as lack of touch support, the
world is moving to mobile devices with native widgets.
Instead of distributing the user interface (as HTML does) why not
distribute oz (which it was designed for) to the native GUI widgets?

> If yes, it would be interesting to architecture the Oz code with that
> compositional independence.

Agreed!

> In the current implementation of Qtk and Qhtml it seems that, for instance,
> the file for menu (QTkMenu.oz and QHTMLMenu.oz) contains all four aspects.
> Sometimes this is worse: table has no specific file, but its implementation
> is (split ?) the code of other files (base ? , other widgets ?).
>
> What appears to me is that Mozart is quite "naked" because there is no
> libraries for http servers, for UI, for system "scripting", DB, Ontologies,
> tests, ... How to solve this problem efficiently, i.e. by collecting more
> and more libraries without loosing them when upgrading ?

I don't think future libraries will be lost. Oz syntax and semantics
are rock solid. Libraries will last quite a long time - (famous last
words)

> Thanks a lot for your mail.
>
> André Rifaut
>
> PS:
> I began with Unix, X11 (postscript) and SPARC workstations (I'm old) . That
> was a widget set with management of constraints + events/actions +
> postscript as pure text-based description of code and data.

This is a wonderful learning experience so I'll try my best to help.

Stewart

>
>
>
>
> From: stewart mackenzie <seto...@gmail.com>
> To: andre rifaut <andre....@tudor.lu>,
> Date: 07/01/2014 10:54
> Subject: Re: [mozart-hackers] Re: QHTML for MOZART2 (on Windows)
> ________________________________
>
>
>
> andre rifaut <andre....@tudor.lu> wrote:
>>
>>
>>*1) Porting Qtk towards Qhtml does that means sticking to Tk widget set

>>or
>>moving to html5 widget set (if any such set)?
>

> I've looked at a unified user interface widget naming set, but each
> widget set can be dramatically different from the next.
> My personal thoughts are to just keep the API the same as the widget
> set you're using. That way you can rely on the documentation
> associated with the toolkit in use.
>
> In other words keep the naming the same as HTML5

>
>>2) If html5 has no widget
>>set,
>>what widget set do I have to implement in html5?
>

> HTML5 has a widget set. buttons, grids textboxes etc Just implement
> what HTML5 has on offer.
>
> Your might want to take a look at wmeyer's roads application
> https://github.com/wmeyer/roads

>
>>3) If i have to stick
>>Qtk
>>(and Tk), then we have the following question:*Porting Qtk towards
>>Qhtml is

>>this as difficult as porting Tk towards Html5?*"
>
> This might sound a bit wild... but how about implementing a language
> similar to TCL.
> It's goal is to provide good interaction with mozart2 yet easily
> extendable to support different GUI toolkit backends. (It would most
> likely support an HTTP server in the case of HTML5)
>
> In this case I would try to make it such that there are generic names
> for each of the different GUI toolkit entities. I would work to
> achieve as broad a user experience as possible given all the supported
> backends.
> This means more powerful GUI toolkits would not have all their
> features expressed as weaker GUI toolkits don't encompass that
> feature.
> Then I'd create one documentation set that works across all supported
> backends.
>
> What do you think?
>
> Kind regards
> Stewart
>

[stewart mackenzie]

I suppose what I'm trying to hint at is that HTML is good at making
websites but not good at making web applications.
One has to add on a whole bunch of other stuff to make it into a web
application. Even then it looks pretty hacky.
Even though cappuccino looks nice and has a decent art assets.
Interacting with the browser just isn't as good as native desktop GUI
toolkits.

Read up about the motivations for cappuccino:
http://www.cappuccino-project.org/learn/

You'll probably be able to easily leverage the geometric constraints
and geometric structuring with this:
http://www.cappuccino-project.org/learn/automatic-layout.html

Now the cappuccino guys have resorted to using interface builder (an
Apple company development environment) to visually build the
interface.
It would be interesting to be able to build that interface with QTk
styled markup instead.

Probably cappuccino is a good way to do what you want. It also
completely abstracts away the DOM which isn't pleasant to work with.

If you want desktop styled applications in the browser using
cappuccino will probably lighten much of your work.