blogEiffelVision within a browser

Posted August 8th, 2012 by Ian King
in

With the release of Gtk+ 3.4 comes the availability of a usable html5 backend, this gives the possibility for EiffelVision applications to be displayed remotely in a html5 capable browser such as Firefox.


image.png


To make use of this the easiest way currently is to use Ubuntu 12.04 and then follow the instructions given here to update the system with the broadway html5 backend.

There is also the option of compiling Gtk+ 3.4 manually with the --enable-broadway-backend option but it is usually best to find preconfigured packages for your system.

https://launchpad.net/~malizor/+archive/gtk-broadway

Enabling 'broadway' html5 gtk+ backend

To enable the broadway html5 backend, a GDK_BACKEND environment variable needs to be set to 'broadway', you also need to turn off overlay scrollbars by setting another environment variable LIBOVERLAY_SCROLLBARS to '0' otherwise the implementation will crash if scrollbars are created.

When gtk+ 3.4 is installed correctly with the broadway backend compiled in, you have the following options to control the port

http://developer.gnome.org/gtk3/stable/gtk-broadway.html

Enabling EiffelVision to use Gtk+3.4

Currently the default gtk version that EiffelVision employs is 2.4 and above. To set EiffelVision to use version 3.4 a 'vision_implementation' variable needs to be set to 'gtk34' in your projects ecf. This can be added via EiffelStudio's Project Settings under Target / Advanced / Variables. This needs to be done before the project is compiled to avoid using the default gtk 2 implementation.

You will also need to use the repository version of EiffelVision/Base/WEL inorder to get the latest version. This is available at https://svn.eiffel.com/eiffelstudio/trunk/Src/library/ via svn checkout. Your ISE_LIBRARY environment variable needs to be updated to reflect the new location of the library directory.

Limitations

Currently the EiffelVision gtk 3.4 backend is experimental but a lot of things are now working. There are certain issues with showing standard dialogs causing infinite looping and certain EV_DRAWABLE routines may cause segmentation violations but these are currently being fixed. You are currently limited to one launchable instance but this is something we hope to improve upon in the future.

Comments

WEL?

peter_gummer's picture
Submitted by Peter Gummer on Thu, 08/09/2012 - 14:30.

Hi Ian, why does GTK depend on WEL?

I'm not totally clear about the meaning of this: "You will also need to use the repository version of EiffelVision/Base/WEL". Basically you're just telling us to check out the latest of all of the libraries and point ISE_LIBRARY at them, right?

Peter

GTK does not depend on WEL, but ...

Jocelyn Fiat's picture
Submitted by Jocelyn Fiat on Fri, 08/10/2012 - 08:25.

GTK does not depend on WEL, but vision2 does

If you build you vision2 application, you might want to compile and run it on Windows as well, using the same code.

I guess this is what Ian meant, get the latest code of vision2/base and wel, so that you can build your vision2 application, and with the same code if you compile on a linux (following the requirements for gtk3, broadway, ...), then you will be able to display your application in a web browser.

I guess, one might also need to use the latest EiffelStudio 7.2, but I am not sure, I let Ian precise.

Hi Peter, Yes, this is

Submitted by Ian King on Tue, 08/14/2012 - 16:52.

Hi Peter,

Yes, this is currently a limitation with our configuration system that all referenced ecf's need to be accounted for. Checking out the libraries and pointing ISE_LIBRARY at the checkout location will do the trick too, it's just that Vision2/Base/WEL is the bare minimum needed.

You should be able to compile with Eiffel71 with the checked out libraries.

Thanks for your input, Ian.

Can't compile vision2 example

colin-adams's picture
Submitted by colin adams on Sat, 08/25/2012 - 12:36.

I downloaded ES 7.1 for linux 64 bit, and tried compiling examples from example/vision2.

After setting vision_implementation to gtk34, these examples fail (they compile OK if I don't set this variable) with 5 errors. Here are the ones from the accelerator example:


Description Location Position 2 VDRD(2): Redeclaration has non-conforming signature. EV_WIDGET_IMP.widget_imp_at_pointer_position (implementation_gtk) Error code: VDRD(2)

Type error: redeclaration has non-conforming signature. What to do: make sure that redeclaration uses signature (number and 

 types of arguments and result) conforming to that of the original.

Class: EV_WIDGET_IMP Redefined feature: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_GTK_WIDGET_IMP Precursor: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_DOCKABLE_SOURCE_I 2 VDRD(2): Redeclaration has non-conforming signature. EV_WIDGET_IMP.widget_imp_at_pointer_position (implementation_gtk) Error code: VDRD(2)

Type error: redeclaration has non-conforming signature. What to do: make sure that redeclaration uses signature (number and 

 types of arguments and result) conforming to that of the original.

Class: EV_WIDGET_IMP Redefined feature: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_GTK_WIDGET_IMP Precursor: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_DOCKABLE_SOURCE_I 2 VDRD(2): Redeclaration has non-conforming signature. EV_MULTI_COLUMN_LIST_ROW_IMP.parent_imp (implementation_gtk) Error code: VDRD(2)

Type error: redeclaration has non-conforming signature. What to do: make sure that redeclaration uses signature (number and 

 types of arguments and result) conforming to that of the original.

Class: EV_MULTI_COLUMN_LIST_ROW_IMP Redefined feature: parent_imp: [detachable] EV_MULTI_COLUMN_LIST_IMP From: EV_MULTI_COLUMN_LIST_ROW_IMP Precursor: parent_imp: [detachable] EV_MULTI_COLUMN_LIST_IMP From: EV_MULTI_COLUMN_LIST_ROW_I 2 VDRD(2): Redeclaration has non-conforming signature. EV_TOOL_BAR_BUTTON_IMP.widget_imp_at_pointer_position (implementation_gtk) Error code: VDRD(2)

Type error: redeclaration has non-conforming signature. What to do: make sure that redeclaration uses signature (number and 

 types of arguments and result) conforming to that of the original.

Class: EV_TOOL_BAR_BUTTON_IMP Redefined feature: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_GTK_WIDGET_IMP Precursor: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_DOCKABLE_SOURCE_I 2 VDRD(2): Redeclaration has non-conforming signature. EV_TOOL_BAR_BUTTON_IMP.widget_imp_at_pointer_position (implementation_gtk) Error code: VDRD(2)

Type error: redeclaration has non-conforming signature. What to do: make sure that redeclaration uses signature (number and 

 types of arguments and result) conforming to that of the original.

Class: EV_TOOL_BAR_BUTTON_IMP Redefined feature: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_GTK_WIDGET_IMP Precursor: widget_imp_at_pointer_position: [detachable] EV_WIDGET_IMP From: EV_DOCKABLE_SOURCE_I 2 Obsolete Class: Type relies on obsolete class. Use of class EV_CURSOR: [090630] Use EV_POINTER_STYLE instead EV_POINTER_STYLE (interface) Warning code: Obsolete Class

Warning: type relies on obsolete class. What to do: update to new class at your earliest convenience. The 

 class is still available but may be removed in the future.

Class: EV_POINTER_STYLE Obsolete class: EV_CURSOR Obsolete message: [090630] Use EV_POINTER_STYLE instead 2 Obsolete Class: Type relies on obsolete class. Use of class EV_CURSOR: [090630] Use EV_POINTER_STYLE instead EV_POINTER_STYLE_IMP (implementation_gtk34) Warning code: Obsolete Class

Warning: type relies on obsolete class. What to do: update to new class at your earliest convenience. The 

 class is still available but may be removed in the future.

Class: EV_POINTER_STYLE_IMP Feature: init_from_cursor Obsolete class: EV_CURSOR Obsolete message: [090630] Use EV_POINTER_STYLE instead 2 Obsolete Class: Type relies on obsolete class. Use of class EV_CURSOR: [090630] Use EV_POINTER_STYLE instead EV_POINTER_STYLE_IMP (implementation_gtk) Warning code: Obsolete Class

Warning: type relies on obsolete class. What to do: update to new class at your earliest convenience. The 

 class is still available but may be removed in the future.

Class: EV_POINTER_STYLE_IMP Feature: init_from_cursor Obsolete class: EV_CURSOR Obsolete message: [090630] Use EV_POINTER_STYLE instead

Oops!

colin-adams's picture
Submitted by colin adams on Sat, 08/25/2012 - 13:32.

I just noticed the bit about have to get the repository version of WEL.

Same errors

colin-adams's picture
Submitted by colin adams on Sun, 08/26/2012 - 10:17.

But I get the same errors when using the subversion version of the library.

gtk3_eiffel.o

colin-adams's picture
Submitted by colin adams on Sun, 08/26/2012 - 10:28.

Removing the precomp clause from the ecf worked wonders.

But I still get one error when the C-code is compiled:

gcc: error: /home/colin/library/vision2/spec/linux-x86-64/lib/gtk3_eiffel.o: No such file or directory

Compiling Clib in gtk34

Jocelyn Fiat's picture
Submitted by Jocelyn Fiat on Mon, 08/27/2012 - 06:36.

Go to vision2/implementation/gtk34/Clib folder ... and run "finish_freezing -library" or $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin/finish_freezing -library

It works on Fedora 17 too ...

colin-adams's picture
Submitted by colin adams on Tue, 09/11/2012 - 14:46.

Thanks. I've got it to work now on Fedora 17. GTK3 is NOT compiled with broadway support on F17, but it was simple to download the rpm, add the flag to the .spec file, and recompile.

Now to the point of my trying this. I wondered what would happen if multiple users point their browser at the same port. When I tried to run the gauges example on port 8080, it worked fine, but when I closed the tab (I'm using Chrome), the application ended:

GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed

That didn't surprise me at all. It's the identical behaviour as for the x11 backend when the main window is closed.

So what is the point of being able to run in the browser? Wouldn't we need to run a separate copy of the executable on a separate port for each possible client? That is hardly scalable.

Thanks

Submitted by Ian King on Tue, 09/11/2012 - 21:06.

Hi Colin,

Thanks for the update regarding Fedora 17. To answer your question regarding scalability, currently we are limited to one processor per display so it won't be all that scalable but could be useful in limited scenarios, say 10-20 users without putting too much load on the system. We hope to have a front end ready that will perform the process/port propagation automatically with some kind of session management mechanism in the not too distant future.

Ian

What about Windows?

colin-adams's picture
Submitted by colin adams on Fri, 09/14/2012 - 08:37.

I assume that nothing will happen any time soon for the win32 api. But what about a gtk34 implementation on Windows?

It seems that gtk+ on Windows

Jocelyn Fiat's picture
Submitted by Jocelyn Fiat on Tue, 09/25/2012 - 07:49.

It seems that gtk+ on Windows might allow this as well, or maybe using a modified gtk+ I googled quickly and found a (french blog) post http://www.tarnyko.net/?q=node/10 so it might be possible, I haven't searched deeper but maybe one can find better answers from those sites:

I wasn't doubting that gtk+

colin-adams's picture
Submitted by colin adams on Tue, 09/25/2012 - 09:31.

I wasn't doubting that gtk+ 3.4 would work with broadway on Windows (it hadn't occurred to me that it might not - perhaps it should have done). But it would need a Vision2 implementation targeting gtk+ 3.4 on Windows. I understood that there isn't one at present. Am I wrong about that?

Syndicate content