Interesting discussion...
My thoughts:
FWIW, after developing wxWebKit for several years, I find that while I
see the demand for it regularly, the vast majority of the wx
development community either has no time for it or is interested in
other issues instead. Personally, I think that's a very critical
mistake, because not having a modern, cross-platform, HTML5 compliant
web engine really locks out a lot of modern and upcoming app
categories from being developed using wxWidgets.
I agree, but this is an open-source community project, and that means that what gets done is not based on what would be good for the adoption of the project, but rather what people need enough to put the work in to make it happen -- I'm surprised that a good embeddable HTML renderer isn't on many folks' todo lists, but what can you do? I'm really glad that Kevin's been working on it!
Hopefully critical mass will be achieved soon. For example -- two years ago we had the need for an embedded browser window (more on that later...). We started by trying to use wxWebKit, and even had some time and money to put into fixing bugs and adding features. However, it turned out that we didn't have the resources to get it where we needed it, so we ended up embedding IE on Windows, and WebKit (Safari) on the Mac. That works OK, but there were quite a few platform/browser-version differences that were a pain. We're doing an update this year, and we'll probably take a look at wxWebKit again -- i hope so, it really will be better to have full control by delivering the browser engine, rather than relying on the system browser, and I hope wxWebKit is up to the job now. If it's close, we'll probably provide some patches, which is what I mean my critical mass.
So I was playing with the thought to integrate wxWebKit into my
application, along with some kind of bridge between wxPython and the
wxWebKit UI. Or using wxPython as a frontend for a zope server. I
couldn't come up with a sane plan for it if it was to be powerful
enough.
well, the app a referred to above is what I call a Browser Interface Local Server (BILS) app -- the interface is almost entirely the embedded browser, the server runs locally (in a separate thread in the same app). We did it because we needed both a traditional web app, and a stand-alone desktop version that could be run without a network.
We also wanted the desktop version to be an easy install, and look and feel much like a desktop app -- one click to start it up, icons in the dock/status bar, whatever, etc.
By embedding the browser in a wxPython app, we could choose to do any bit of the UI is either the browser or with straight wxPython.
In this case, there was very little JavaScript, which was due to the requirement that the web version be able to run in a wide variety of older browsers, but you could put do a heavy JS/AJAX app the same way.
As I said above, it worked OK, but would have worked better if we could have had a single embedded web control as out target -- i.e. wxWebKit.
Also, wxPython did not provide any data-driven controls.
Dabo does, though.
I wrote a custom browser plugin to
display the 3d window. I am also able to use this custom plugin to embed
wxPython in it.
I would think you might get a better experience (more desktop-like, anyway) by embedding the browser in wxPython, rather than the other way around. And a good wxWebKit would be helpful for that.
I've contemplated about extending
wxPython/wxWebKit in various ways. However, there were too many things
to do. I can't spend all my time on writing the middleware to create my
application
That's the key problem with the development model -- you need folks to "scratch an itch", but the itch is too big -- we could have spent a few weeks improving wxWebKit, but not more than a month or so -- and it needed more than that -- Mathias was in the same situation, and probably lots of others are, too.
- not themable
I still don't know why people want themability so badly -- it just makes the desktop look cluttered and ugly, what usability is gained?
- no data driven widgets, no connection to server backend
again, Dabo, yes?
However, often today's web uis are much easier to create
and more powerful than the desktop apps.
That's interesting -- one thing that has kept me from going more web oriented is that it seems far more painful to write a web app -- maybe that's changed with the newer JS ui toolkits -- time to re-evaluate, I guess.
"We" will not be doing any such thing. Not every app is well-suited to
running this way, nor is it necessary in many cases. Those of us
writing scientific/engineering programs in particular have much
different needs.
That's been my thought as well, but I'm wondering. In fact, if you do the BILS thing, it really only comes down to UI options -- and I guess those are getting better. It looks like Mathias as integrated OpenGL, for instance, so if you can mix and match JS GUI elements with OpenGL rendering, and put it all in a browser, you could probably get anything you need. If you're running the server locally, then you don't have the data transfer problems (though there may be some need for UI elements to share memory with computational code, I'm not sure how you could do that with a web app approach.
Also, we have an app that allows the user to visually manipulate large data sets on a map. While Google Maps and OpenLayers have shown you can do great stuff with that, they really break down with large data sets, and it's not just the network lag time issue. We ended up using PyOpenGL with some Cython code to make GL calls we need to speed up -- I don't think you can do all that in JavaScript.
I'm oversimplifying a little bit, but the main deal-breaker for me is
that the software needs to be run on the same node (or at least same
filesystem) as the GUI, regardless of whether there is an Internet
connection.
BILS
it's also one
more cross-platform support issue. (My guess is this will be the very
first thing to break.)
I don't see how that would be any more fragile that a wxPython app.
We release semi-nightly builds of our code for
power users and they need to be able to switch back and forth between
versions if necessary - not sure how that would work with webapps
either. (Maybe a different port for each version,
That's not a big deal really. There are a lot of way to accomplish that, and, in fact, that sounds like a really good reason to keep things on the server!
I've also had some bad experiences with code that was so tied in to a
web interface that it was difficult if not impossible to use it any
other way, therefore making it less useful.
that's a code design issue -- the same sure can be said for some GUI apps!
so web apps won't
work unless I were to bundle some kind of standalone web server too. I'd
rather not think about that though.
Why not? it's really not that hard and works well.
What I'm currently doing works great!
A very good reason to keep doing it!
One point even for a simple bundled webserver is that your UI can
benefit from the vast amount of libraries and widgets that are already
existing.
This is key. I think the whole HTML-DOM-manipulating-Javascript stuff is really one huge kludge, but there are an enormous number of people developing stuff for it. One of the hardest decisions is which full-featured fabulous JS toolkit to use. Sometimes you go with the best supported solution, rather than the theoretically best -- or how many of us would be using/supporting Windows?
> if you want to display an icon in the user's taskbar,
you'll have to create a traditional desktop app. However I think a lot
of traditional non-trivial desktop applications would benefit from
incorporating more web technologies. This applies to the users of these
apps as well as their developers.
yup -- and that is another good argument for wxWebKit -- it would let you mix and match wxPython and Web stuff pretty seamlessly.
You're also underestimating the support overhead of deploying onto
thousands of computers running MacOS or multiple Linux variants, none of
which I have access to.
I'm confused, this is usually easier with web apps -- that's one of their main selling points!
people are going to have bizarre
firewalls, messed-up network configurations, and weird restrictions put
in place by the sysadmins.
We have had some of those issues with our BILS app -- though far less than I'd think (thousands of deployments, 2 or 3 problems)
(And I have no idea how this would function
properly on multi-user workstations - different ports again?)
For a BILS app, yes, different ports -- not much code to write, just check if the port is already in use before starting up, give it a different one if it is in use.
-Chris
···
On 11/2/10 4:21 PM, Matthias wrote:
On 11/2/10 4:42 PM, Nat Echols wrote:
On 11/2/10 6:28 PM, Mike Driscoll wrote:
On 11/2/10 7:03 PM, Matthias wrote:
On 11/2/10 7:45 PM, Nat Echols wrote:
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
There's already a precedent with apps like Chrome that users are willing to accept non-native UI if it's fast and works well. wx needs to modernize, but I'm not sure many of the core developers consider that their first priority, and I suspect some potential new and motivated contributors are getting frustrated by the insistence on things like Win 98 and Visual C++ 6 compatibility, not to mention the inability to change API even once a decade or so even when it's broken, for all contributions.
I doubt everybody is using wxPython as a GUI for performance sensitive C++ code.