Web application with wxWidgets?

[Carsten A. Arnholm]

Hi,

Maybe this is too naive, but:

I have been using wxWidgets for a couple of years to create portable
desktop applications. It works great. I like the way things are
organized and it is well documented and logical. And it works.

Recently, at work, where we don't use wxWidgets (yet) I have been on a
project developing a web application using ASP.NET, which is a new and
"rather different experience" compared to wxWidgets.

Since wxWidgets is targeting multiple platforms, has it ever been
considered if it could target a web browser as "just another platform"?
Obviously, it would be a severly limited platform, but anyway.

Maybe a subset of wxWidgets could be defined so if you used only that
subset, an application could be compiled either as an ordinary desktop
application or as a web app?

Has such an idea ever been tried or discussed? If not, why not?

Carsten Arnholm

[Ori Lahav]

Hello Carsten,
Web application, not matter in which language is written, will work on any
platform (e.g. browser). What makes a website "non-multi-platform" is when
it's maker don't write HTML according to the W3C standart, which will
usually work only in browsers which are non-standart (e.g. IE 6/7). Another
possible cause may be if the maker uses a new standart, and then it will
work only in the newer browsers (Firefox, IE 7) and not in the older (IE 6).
So, as long as you write (the HTML) according the web standart, it will be
multi platform by all means.

For your question, wxWidgets is a desktop application library. Its
completely different from a web application, and thus, can't be used to
develop web application. Anyway, I highly recommend you using PHP (+MySQL).
Open source, used by most websites around the world, and supported by
(almost) every server you can find.

Good luck,
Ori.

Post by Carsten A. Arnholm
Hi,
I have been using wxWidgets for a couple of years to create portable
desktop applications. It works great. I like the way things are organized
and it is well documented and logical. And it works.
Recently, at work, where we don't use wxWidgets (yet) I have been on a
project developing a web application using ASP.NET, which is a new and
"rather different experience" compared to wxWidgets.
Since wxWidgets is targeting multiple platforms, has it ever been
considered if it could target a web browser as "just another platform"?
Obviously, it would be a severly limited platform, but anyway.
Maybe a subset of wxWidgets could be defined so if you used only that
subset, an application could be compiled either as an ordinary desktop
application or as a web app?
Has such an idea ever been tried or discussed? If not, why not?
Carsten Arnholm
_______________________________________________
wx-users mailing list
http://lists.wxwidgets.org/mailman/listinfo/wx-users

[Carsten A. Arnholm]

Post by Ori Lahav
Hello Carsten,
Web application, not matter in which language is written, will work on
any platform (e.g. browser). What makes a website "non-multi-platform"
is when it's maker don't write HTML according to the W3C standart, which
will usually work only in browsers which are non-standart (e.g. IE 6/7).
Another possible cause may be if the maker uses a new standart, and then
it will work only in the newer browsers (Firefox, IE 7) and not in the
older (IE 6).
So, as long as you write (the HTML) according the web standart, it will
be multi platform by all means.

Well, the whole point of my question, or at least a big part of it, is
that I don't want to (or really don't understand why I have to) do any
HTML at all. I don't need to understand the concept of video memory or
the difference between Win32 and GTK when I write a desktop application
with wxWidgets, because wxWidgets provides the suitable abstractions.
Any business with HTML towards W3C etc. would be part of that
abstraction. Having to relate to individual browsers as an application
developer reminds me of times long gone when we had to deal with
individual terminal models in desktop applications.

Post by Ori Lahav
For your question, wxWidgets is a desktop application library. Its
completely different from a web application,

It is maybe different today, but does it need to be? All you do in GUI
development for desktops and web apps is define layouts and insert
controls etc. I am thinking that for example a wxWidgets XRC should be a
good starting point for some module to generate HTML, while keeping the
same programming model on the application.

Post by Ori Lahav
and thus, can't be used to
develop web application. Anyway, I highly recommend you using PHP
(+MySQL). Open source, used by most websites around the world, and
supported by (almost) every server you can find.

Thanks for the advice, but that was not my question. I know there are
many ways of attacking this and I am using one of them. I just wanted to
hear if someone with wxWidgets experience had considered making some
kind of "wxWidgets webkit" that would allow someone like me to do web
apps without having to learn a totally new language and framework,
because it seems like waste to have to do that just to get some controls
working in a web browser.

Best regards
Carsten Arnholm

[Riccardo Cohen]

Post by Carsten A. Arnholm
Well, the whole point of my question, or at least a big part of it, is
that I don't want to (or really don't understand why I have to) do any
HTML at all. I don't need to understand the concept of video memory or
the difference between Win32 and GTK when I write a desktop application
with wxWidgets, because wxWidgets provides the suitable abstractions.
Any business with HTML towards W3C etc. would be part of that
abstraction. Having to relate to individual browsers as an application
developer reminds me of times long gone when we had to deal with
individual terminal models in desktop applications.

Let me give my modest opinion about this.

There are 2 important points to consider:

1) web applications are disconnected. The fondamental structure of HTTP
is that the browser is "disconnected" after each request (even if you
think about "keepalive", you are still functionnaly disconneted. It also
implies that the server may be far, and slow sometimes.

2) web application can only be run by a web browser which functions are
limited. Html was the first display mechanism, and now css, Flash and
other common plugins are a very frequent alternative. But you do not
master the client technology, it is not the local native windowing system.

Now you can still think about design a web application like a desktop
application, in term of dialogs, alerts, etc. There is no problem about
this, but when comes the time of storing the data and transmitting to
the client, the underlying structure is completely different.

In other words, when a user do an action on the interface, a desktop
application would react usually by getting some object from memory
storage, and display it on a dialog that is also in memory. While a web
application (even in flash) will systematically start a request to the
server, and eventually open a dialog, that is sent from the server if
HTML, or in memory with flash.

I think that you can (with a lot of work) create a flash code generator
from softwares like DialogBlocks and other IDE, and your web application
may look like a wxwidgets application. But really I'd never do this,
because the underlying structures, mechanism and logics would not fit
the web context.

It's only my opinion.

[Carsten A. Arnholm]

Post by Riccardo Cohen
Let me give my modest opinion about this.

Thank you for replying.

Post by Riccardo Cohen
1) web applications are disconnected. The fondamental structure of HTTP
is that the browser is "disconnected" after each request (even if you
think about "keepalive", you are still functionnaly disconneted. It also
implies that the server may be far, and slow sometimes.

It is a problem or special feature of web applications, I understand.
But assuming it is a problem that could be overcome, it is precisely a
good reason why an abstraction layer like wxWidgets might hide these
things better, to make life easier for web application developers.

Post by Riccardo Cohen
2) web application can only be run by a web browser which functions are
limited. Html was the first display mechanism, and now css, Flash and
other common plugins are a very frequent alternative. But you do not
master the client technology, it is not the local native windowing system.

Understood. It is a different animal with some limitations. Although I
would prefer a desktop application for most purposes, there are some
cases where a web app makes sense. For such cases, I would still prefer
to use the same abstractions that I am used to from desktop application
development.

Post by Riccardo Cohen
Now you can still think about design a web application like a desktop
application, in term of dialogs, alerts, etc. There is no problem about
this, but when comes the time of storing the data and transmitting to
the client, the underlying structure is completely different.

If we assumed that a wxWeb port existed allowing me to write limited
wxWidgets web apps that would have some peculiarities for the reasons
you explain, it would still be tempting to me, as the alternative is to
learn and use a different language and/or framework, a very costly process.

Thanks for your thoughts.

[Rüdiger Ranft]

Post by Carsten A. Arnholm

Post by Riccardo Cohen
Now you can still think about design a web application like a desktop
application, in term of dialogs, alerts, etc. There is no problem
about this, but when comes the time of storing the data and
transmitting to the client, the underlying structure is completely
different.

If we assumed that a wxWeb port existed allowing me to write limited
wxWidgets web apps that would have some peculiarities for the reasons
you explain, it would still be tempting to me, as the alternative is to
learn and use a different language and/or framework, a very costly process.
Thanks for your thoughts.

The most importent thing to take into account is how much and which kind
of interaction between the user and the programm are needed. If the
interaction is only a dialog-centric way, I would recommend to seperate
the application logic entirely from the presentation logic, and also
make the presentation logic very dumb[1]. Also you can use tools like
wxXmlResource to describe the layout of the dialogs and generate the GUI
and web pages by this resources.

The biggest drawback of a web application is that you can't send changes
in your application to the user[2], because there is no connection
after a page is loaded by the user.

Bye
Rudi
[1]http://www.objectmentor.com/resources/articles/TheHumbleDialogBox.pdf
[2]Ok, you can use Tools like AJAX and poll some interface of your app

[Stef Mientki]

Post by Riccardo Cohen

Post by Carsten A. Arnholm
Well, the whole point of my question, or at least a big part of it,
is that I don't want to (or really don't understand why I have to) do
any HTML at all. I don't need to understand the concept of video
memory or the difference between Win32 and GTK when I write a desktop
application with wxWidgets, because wxWidgets provides the suitable
abstractions. Any business with HTML towards W3C etc. would be part
of that abstraction. Having to relate to individual browsers as an
application developer reminds me of times long gone when we had to
deal with individual terminal models in desktop applications.

Let me give my modest opinion about this.
1) web applications are disconnected. The fondamental structure of
HTTP is that the browser is "disconnected" after each request (even if
you think about "keepalive", you are still functionnaly disconneted.
It also implies that the server may be far, and slow sometimes.
2) web application can only be run by a web browser which functions
are limited. Html was the first display mechanism, and now css, Flash
and other common plugins are a very frequent alternative. But you do
not master the client technology, it is not the local native windowing
system.

Limited ?
Although I've no experience myself with web applications,
I last read an article where was stated, that GUI web applications (
JavaScript) are far superior to desktop applications.
When there's an error in a desktop application, the program crashes,
when an error in a web application occur, it never crashes and the
program still will try to accomplish the tasks that don't has in errors
in it.

To get back to the OP's question, mayb PyJamas is part of the answer.

cheers,
Stef

Post by Riccardo Cohen
Now you can still think about design a web application like a desktop
application, in term of dialogs, alerts, etc. There is no problem
about this, but when comes the time of storing the data and
transmitting to the client, the underlying structure is completely
different.
In other words, when a user do an action on the interface, a desktop
application would react usually by getting some object from memory
storage, and display it on a dialog that is also in memory. While a
web application (even in flash) will systematically start a request to
the server, and eventually open a dialog, that is sent from the server
if HTML, or in memory with flash.
I think that you can (with a lot of work) create a flash code
generator from softwares like DialogBlocks and other IDE, and your web
application may look like a wxwidgets application. But really I'd
never do this, because the underlying structures, mechanism and logics
would not fit the web context.
It's only my opinion.

[Vadim Zeitlin]

Sorry, I didn't want to involve myself in this discussion as it's really
rather OT here until someone is ready to discuss the real technical
problems which would need to be overcame to create a wx port for the web
but some of your assertions are simply ridiculous:

On Tue, 28 Apr 2009 14:41:53 +0200 Stef Mientki <***@ru.nl> wrote:

SM> Limited ?

Yes, there are plenty of things which can't be done in web applications
which can (and often trivially) be done in traditional desktop ones. And
while web applications have made great progress quickly and recently their
flexibility and responsiveness is still nowhere near enough to consider
using them when a locally installed application is available.

The popularity of web applications is a purely political, or social,
phenomenon and really has no base in any technical considerations.


SM> Although I've no experience myself with web applications,
SM> I last read an article where was stated, that GUI web applications (
SM> JavaScript) are far superior to desktop applications.

Yes, when there are zillions of baseless articles stating that web (and
*especially* web 2.0) applications are far superior to desktop ones, people
start believing it, whether this is true or not. I don't dispute that there
is a real power in advertisement.

SM> When there's an error in a desktop application, the program crashes,
SM> when an error in a web application occur, it never crashes and the
SM> program still will try to accomplish the tasks that don't has in errors
SM> in it.

It's trivially easy to make a C++ program which never crashes: just
install a signal handler for all fatal signals or catch all SEH and ignore
them. But the fact that it didn't crash hardly helps you if your data is
lost and you can't do whatever you're trying to do! And, from personal
experience, losing your text typed into a web browser (Trac *cough*)
happens much, much more often than losing anything because of a crashing
desktop application. And even without taking into account the server or
connection problems, a bug in the client-side part of a web app can be
just as fatal as a bug in a traditional desktop application: an infinite
loop is an infinite loop whether it happens in C++ or JavaScript (except
that it runs hundred times slower in the latter ;-)

SM> To get back to the OP's question, mayb PyJamas is part of the answer.

For C++ I'd recommend looking at Wt. This is, AFAIK, the state of the art
for the web applications in C++ currently and it's still far from being
ready for any real projects AFAICS.

Regards,
VZ

[Riccardo Cohen]

Post by Stef Mientki
Limited ?
Although I've no experience myself with web applications,
I last read an article where was stated, that GUI web applications (
JavaScript) are far superior to desktop applications.
When there's an error in a desktop application, the program crashes,
when an error in a web application occur, it never crashes and the
program still will try to accomplish the tasks that don't has in errors
in it.

thanks for this information.

Yes, scripting languages (and flash also) have the ability to avoid
crashing, but this does not mean superiority for me. And I find that
many "not crashing" technologies lead to a real messy code, and poor
debugging possibilities. About Javascript let me tell you that when
there is an error, the program simply stops without error !

I've been coding and debugging web applications with flash and
javascript. It's, at first sight, rather easy to use, but I miss the
solid basis of a reliable C++ library, and I always fear that in some
situation it won't work. Flash and Javascript are basically enhancement
or alternative to HTML, and in that sens they are superior to html only.

On the contrary, wxWidgets is a set of coherent tools that include not
only listbox, buttons and other dialog items, but also event loop, multi
threading, internal storage (hash tables, arrays, lists..), drag and
drop, pasteboard, etc. All these piece of elements cannot be in a web
application since it is too heavy and needs too much resource for a web
app. You would really need to write a wxWidgets plugin for IE/Firefox,
and invent a new bytecode compilation to transmit the program to the
client !.

[Bob Paddock]

I've been coding and debugging web applications with flash and javascript.
It's, at first sight, rather easy to use, but I miss the solid basis of a
reliable C++ library, and I always fear that in some situation it won't
work.

Take a look at the language haXe: http://haxe.org/
*haXe* (pronounced as *hex*) is an *open source* programming language.

While most of the other languages are bound to their own platform (Java to
the JVM, C# to .Net, ActionScript to the Flash Player), *haXe* is a
*multiplatform
language*.

It means that you can use haXe to target the following platforms :

- *Javascript* : You can compile a haXe program to a single .js file. You
can access the typed browser DOM APIs with *autocompletion* support, and
all the dependencies are resolved at compilation time.
- *Flash* : You can compile a haXe program to a .swf file. haXe can
compile for Flash Players 6 to 10, with either "old" Flash<8 API or newest
AS3/Flash9+ API. haXe offers very good*performance* and *language
features* to develop Flash content.
- *PHP* : You can compile a haXe program to .php files. This enable you
to use a high level strictly-typed language such as haXe while keeping full
compatibility with your existing server platform and libraries.
- *NekoVM* : You can compile a haXe program to NekoVM bytecode. This can
be used for *server-side* programming such as dynamic webpages (using
mod_neko for Apache) and also for*commandline* or *desktop* applications,
since the NekoVM can be embedded and extended with some other DLL.
- *C++* : Currently in testing, with the right build of haXe from Hugh
Sanderson, you can now output your haXe applications to pure C++ source
code, complete with makefiles

[Julian Smart]

Hi Carsten,

Post by Carsten A. Arnholm
I have been using wxWidgets for a couple of years to create portable
desktop applications. It works great. I like the way things are
organized and it is well documented and logical. And it works.
Recently, at work, where we don't use wxWidgets (yet) I have been on a
project developing a web application using ASP.NET, which is a new and
"rather different experience" compared to wxWidgets.
Since wxWidgets is targeting multiple platforms, has it ever been
considered if it could target a web browser as "just another
platform"? Obviously, it would be a severly limited platform, but anyway.
Maybe a subset of wxWidgets could be defined so if you used only that
subset, an application could be compiled either as an ordinary desktop
application or as a web app?
Has such an idea ever been tried or discussed? If not, why not?

It's definitely been discussed and even tried - there was a GSoC project
called wxWeb, but alas it was an ambitious goal for a Summer project and
it didn't succeed.

I would love to see something like this revived. Whether the wxWidgets
API really lends itself to practical web apps is an open question but
I'm sure with some ingenuity it could be achieved. I recently saw
standard apps being remotely accessed across a home broadband connection
from a Windows Server - if that can be done with only a slightly
noticeable lag, then I would have thought with specific toolkit
knowledge a port could be more efficient than that. One challenge will
be to route UI requests to the specific application, especially if the
server app handles more than one application within a single process
space. Perhaps a Flash front end could be used to create windows and
send back user input, with as much rendering as possible being done locally.

Or maybe it could be achieved much more generically using an embedded
VNC widget, but this is likely to be slower than exploiting specific
toolkit API knowledge.

Anyone fancy having another go? Perhaps we should offer a wxPrize for it...

Regards,

Julian

[Carsten A. Arnholm]

Post by Julian Smart
Hi Carsten,
Has such an idea ever been tried or discussed? If not, why not?
It's definitely been discussed and even tried - there was a GSoC project
called wxWeb, but alas it was an ambitious goal for a Summer project and
it didn't succeed.
I would love to see something like this revived. Whether the wxWidgets
API really lends itself to practical web apps is an open question but
I'm sure with some ingenuity it could be achieved. I recently saw
standard apps being remotely accessed across a home broadband connection
from a Windows Server - if that can be done with only a slightly
noticeable lag, then I would have thought with specific toolkit
knowledge a port could be more efficient than that. One challenge will
be to route UI requests to the specific application, especially if the
server app handles more than one application within a single process
space. Perhaps a Flash front end could be used to create windows and
send back user input, with as much rendering as possible being done locally.
Or maybe it could be achieved much more generically using an embedded
VNC widget, but this is likely to be slower than exploiting specific
toolkit API knowledge.
Anyone fancy having another go? Perhaps we should offer a wxPrize for it...
Regards,
Julian

Many thanks for the informative reply Julian, much appreciated. It is
interesting to hear that it has been attempted. That is an indication it
might be possible.

I guess the VNC approach is different than what I had in mind, which was
more along the lines of Wt as someone mentioned
http://www.webtoolkit.eu/wt

The kind of web application I have been working with is mostly using a
rather simple gui, that is tables (i.e. wxListCtrl equivalent), tree
controls (~wxTreeCtrl), tabs (~wxNoteBook), combo boxes (~wxChoice) and
text controls (~wxTextCtrl) and some buttons (~wxButton) and checkboxes
(~wxCheckBox). Then obviously there are layout issues, where wxSizers
would shine.

It would be really nice if wxWeb was revived along these lines of
thought. I am not sure if I am competent enough to be a driving force,
but it seems to me if it worked, it could help close the gap between web
app development and desktop app development.

With something like this, I would have an easier task convincing my
employer to use wxWidgets, because we have both desktop and web apps,
and developers work on several projects.

Carsten Arnholm

[Milan Babuskov]

Post by Julian Smart
I would love to see something like this revived. Whether the wxWidgets
API really lends itself to practical web apps is an open question but
I'm sure with some ingenuity it could be achieved.

There are many layers that need to be transformed.

- sizers could easily be implemented in HTML

- some common controls are provided by HTML (buttons, radio buttons,
checkboxes, etc.), others (like wxTreeCtrl) could be implemented via
JavaScript

- event handlers could be transformed to JavaScript event handlers. It
would be easiest if language is JavaScript to begin with (maybe wxJS
could help there). Something like jQuery could be very useful to
abstract browser differences and most of JavaScript altogether

[Carsten A. Arnholm]

Post by Milan Babuskov

Post by Julian Smart
I would love to see something like this revived. Whether the wxWidgets
API really lends itself to practical web apps is an open question but
I'm sure with some ingenuity it could be achieved.

There are many layers that need to be transformed.
- sizers could easily be implemented in HTML
- some common controls are provided by HTML (buttons, radio buttons,
checkboxes, etc.), others (like wxTreeCtrl) could be implemented via
JavaScript
- event handlers could be transformed to JavaScript event handlers. It
would be easiest if language is JavaScript to begin with (maybe wxJS
could help there). Something like jQuery could be very useful to
abstract browser differences and most of JavaScript altogether

Great response. This was the kind of thinking I was hoping for.

[Bob Paddock]

Post by Julian Smart
Perhaps a Flash front end

Gag. Please don't ruin wxWidgets with something like that. Some paranoid
admins that I have to deal with go around removing flash players in the name
of security, and Flash players do have many security risks. Come in on a
Monday morning to find Firefox gone, Flash gone etc... With IE6 from 2005
installed,
no security risks there...

More importantly to the wxCommunity Flash also does not play well at all to
people with certain disabilities, see section508.
http://www.section508.gov/

could be used to create windows and send back user input, with as much

rendering as possible being done locally.

Like this: http://www.flapjax-lang.org/ ? <http://www.flapjax-lang.org/>

Or maybe it could be achieved much more generically using an embedded VNC
widget

There are several samples of embedded VNC widgets around.

Anyone fancy having another go? Perhaps we should offer a wxPrize for it...