wild idea ...
Stef Mientki
a friend of my came with a very wild idea ....
... why not use the webkit from QT in wxPython ?
The idea started when reading about the new PySide,
which has better (= more free) license than PyQT.
Technical the idea is as follows :
- create a standalone QT application, containing a frameless webkit
- create a hole in the main wx-application
- launch the QT application from the wx-application
- position and size the QT application so it fits the hole
- make a communication channel between the two applications (through pipes)
Would this be realizable ?
cheers,
Stef
Kevin Ollivier
In theory it should be possible, but I kind of doubt you could get it reliable enough that the two frames would never get out of sync at least temporarily (if the system got bogged down, for example). Also, when you drop down a wx menu, it won't display over the QT webview because it will need to be "in front of" the wx app. Even if you could somehow get all this to work, though, would it really be worth it? You have to distribute both toolkits, and your app must load them both into memory for the life of the app, meaning in all senses it needs (a lot?) more resources than a simply wx or qt app would. I think it would just make a statement that wx developers have to jump through a lot of hoops in order to get access to modern controls. If you need QT to develop modern apps in wx, it says a lot about where QT is at, and where wx is headed.
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. QT will get those developers (and users) instead, because quite simply you can't use a toolkit if it doesn't have the controls you need, no matter how much more native the app looks. :( 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.
Sorry for the little rant, it's just that I'd really like to solve your problem the right way, but I can't really do it alone and I'm very concerned about the future of wx if, as a community, it doesn't step up and solve problems like this...
Regards,
Kevin
> cheers,
> Stef
>
> --
> To unsubscribe, send email to wxPython-user...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-users?hl=en
Matthias
<kevin...@theolliviers.com>:
I was going to post my opinion on this topic at a later stage when my
current project is more advanced, so I could show more examples. However,
since the issues discussed in this topic came up frequently in the past
few weeks, I've decided to give my input rather now than later.
I've started developing a quite ambitious project some time ago. I want to
create a tool to collaboratively work together. I chose wxPython for the
client UI. The underlying server was custom created with the ZODB as its
backend. shot1.jpg and shot2.jpg from the attachment show the first very
simple prototype. As you can see it uses only agw components (these shots
actually predate wx.lib.agw). There's AUI, RibbonBar,
CustomTreeCtrl/HyperTreeCtrl, ThumbnailCtrl and stc. I've contributed a
dozen of patches against agw during this time, because there were always
bugs that had to be fixed before things worked (which is not Andrea's or
anybody else's fault!). The native controls provided by wx did not provide
the user experience and the visuals I was imagining.
Time went by and I refactored the whole thing a bit, the result can be
seen in shot3.jpg. The main difference you can see there is the theming. I
was prototyping a css engine for wxPython widgets, but abandoned the
attempt after a while. The new version also featured better property
editors; the biggest changes were on the server side however.
At this time I was seriously looking porting my whole application to the
web. I was doing some research, found things like Plone and concluded they
could not be tailored to me needs. The server backend was delicious, but
the UI was horrible if you want a desktop experience.
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. Also,
wxPython did not provide any data-driven controls. Everything had to be
tediously coded by hand. I had to code a data model, editors for the
different types, drag and drop etc. All the web frameworks I was looking
at had this already in place.
Sooo... I had to "abuse" wxPython by using agw, I had no good way to style
it (consequence of abuse), agw had to be patched a lot, there were no data
driven controls and also no integration with a server backend. I wasn't
keen to reimplement all the things that webapps already had. So I took
another very hard look at porting my application to the web. And low and
behold, I found two good solutions: ExtJS and grok.
ExtJS is a javascript GUI library, here's their version of the wxPython
demo: http://dev.sencha.com/deploy/ext-3.3.0/examples/ . If you checkout
the example pages and the code used to create them, you can see it's quite
powerful. It doesn't have all the components that wxPython has yet, but
it's close enough for me. 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. This is useful for e.g. the custom wxPython controls shown in
shot4.jpg and shot5.jpg. They will probably be ported to pure javascript
later.
Grok ( http://grok.zope.org ) is the server backend. It has lots of nice
features, but I think this is not so interesting here as I want to focus
on the UI/client side of things.
Finally, coming back to the topic. 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, I need to spend the time on creating the application itself.
Don't get me wrong, wxPython has helped me tremendously in the last few
years, but this time it just doesn't seem up to the task anymore. A
summary of the showstopper things:
- wxPython is based on native widgets. Native widgets often look ugly and
are often not powerful enough. Native widgets often provide a worse user
experience than many web-based widgets, even taking the "familiary factor"
into account. If the web uis were that bad, they'd not be used by
virtually everybody.
- not themable
- no data driven widgets, no connection to server backend
- the "advanced" things needed a lot of bug tracking and patching
- smaller things like drag and drop are just not flexible enough
- there's no good canvas like thing for custom controls
Some of these things are easy to fix - though they will take a lot of
work. Other things are much harder to "fix" as they were never part of the
wxWidgets philosophy. I always thought web uis were not powerful enough
for my purposes so I was looking to integrate the web into my desktop app.
However, often today's web uis are much easier to create and more powerful
than the desktop apps. So I am going to embed the small parts of my
application that require native code into the web instead. This is much
easier. And finally this is the reason why I didn't invest more time into
wxWebKit or agw. Of course there are other aspects like you can find web
coders much easier than wxPython coders.
wxPython has still it's uses of course, but for this specific project it's
not powerful enough and fixing it is more work than I can accomplish.
Apologies for the long rant and to all people who had to download the big
attachment over a slow connection (I tried to compress the images as much
as possible).
-Matthias
Stef Mientki
On 02-11-2010 21:44, Kevin Ollivier wrote:
> Hi Stef,
>
> On Nov 2, 2010, at 12:36 PM, Stef Mientki wrote:
>
>> hello,
>>
>> a friend of my came with a very wild idea ....
>> ... why not use the webkit from QT in wxPython ?
>>
>> The idea started when reading about the new PySide,
>> which has better (= more free) license than PyQT.
>>
>> Technical the idea is as follows :
>> - create a standalone QT application, containing a frameless webkit
>> - create a hole in the main wx-application
>> - launch the QT application from the wx-application
>> - position and size the QT application so it fits the hole
>> - make a communication channel between the two applications (through pipes)
>>
>> Would this be realizable ?
> In theory it should be possible, but I kind of doubt you could get it reliable enough that the two frames would never get out of sync at least temporarily (if the system got bogged down, for example).
Ok pipes works terrible on windows, but I think my friend intends to use some remote control (that's
far beyond my knowledge)
> Also, when you drop down a wx menu, it won't display over the QT webview because it will need to be "in front of" the wx app.
I don't think that should be a problem, the menu is from the wxPython application that gets focus,
so it should come on top.
> Even if you could somehow get all this to work, though, would it really be worth it? You have to distribute both toolkits, and your app must load them both into memory for the life of the app, meaning in all senses it needs (a lot?) more resources than a simply wx or qt app would. I think it would just make a statement that wx developers have to jump through a lot of hoops in order to get access to modern controls. If you need QT to develop modern apps in wx, it says a lot about where QT is at, and where wx is headed.
;-)
> 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 assume that writing a component like wx.Webkit (binding) is much too difficult for many of us,
probably you are one of the few that's able to that !
> QT will get those developers (and users) instead, because quite simply you can't use a toolkit if it doesn't have the controls you need, no matter how much more native the app looks. :( 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.
as discussed before (it may take a year of 5 or 10) we'll all go to webbased programs, that runs on
every machine at any location.
> 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.
>
> Sorry for the little rant, it's just that I'd really like to solve your problem the right way,
don't feel sorry, I'm not having a real problem, I just miss a real good browser in wxPython
(although IE8 functions quiet well)
> but I can't really do it alone and I'm very concerned about the future of wx if, as a community, it doesn't step up and solve problems like this...
Hope you'll find a few people, that are capable of helping you getting wxWebkit running.
cheers,
Stef
Nat Echols
as discussed before (it may take a year of 5 or 10) we'll all go to webbased programs, that runs onevery machine at any location.
Matthias
Just out of curiosity, can you tell some specific needs that would
conflict with using a webapp?
-Matthias
Nat Echols
Just out of curiosity, can you tell some specific needs that would conflict with using a webapp?
C M
> 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.
Kevin, can I ask what kind of "upcoming app categories" you have in mind?
As far as not getting enough developers involved with wxWebkit...
<uniformed speculation>
Is it clear enough to those who have the ability to help (wxWidgets
C++ programmers) which help areas they can help with? In looking at
the wxWebkit web page, there is this line:
"but we need your help! We could really use dependency packages for various
compilers, reports of build failures, and in general help testing
and improving
wxWebKit."
I wonder if you could get more help if you made the request not so
much for "general help" but for help that was more specific and broken
into manageable chunks, and with some kind of action plan that would
allow the person to move forward. (Or are the developers you need
those who already know quite what needs be done?)
An analogous situation would be: if Robin put out a call for 5 new
(fairly simple) widgets and described them, I bet it would galvanize
the wxPython community to try their hands at making at least a few of
them. They would then probably soon be attached to this mailing list,
there would be discussion and requests for improvements by Robin, and
then he might put them into the next release. With something like
wxWebkit, it strikes me as much more challenging to make improvements,
but maybe if you or someone helping out could make a list of missing
"chunks" that a person could get involved with, that would help. (I
guess Google SOC works about this way).
You do have the TODO part of the site, but those items perhaps seem to
be too broad and unapproachable for some people?
</uniformed speculation>
> 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,
For wxPython "modernizing", what, besides wxWebkit, do you have in mind?
Thanks,
Che
Mike Driscoll
--
-----------------
Mike Driscoll
Blog: http://blog.pythonlibrary.org
Matthias
> I'm with Nat. I have one program currently that downloads updated
> information when a network is available, but it has to continue to run
> even
> if the network goes down. I'll be working on a second program that does
> something quite similar within the next 6 months, 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. What I'm currently doing works great!
Bundling a simple web server is not a problem at all. E.g. grok uses the
python standalone paster web server ( http://pypi.python.org/pypi/Paste )
by default. You just import the package and off you go. It doesn't have to
be a full apache install every time.
In fact, deploying my grok application was surprisingly easy. I am
developing on a windows system and deployed onto my new dedicated ubuntu
server a few weeks ago. I just pulled the source, pushed the build button,
hit run and it ran. Which I found quite surprising, I was already prepared
to fix issues like wrong path separators. The output looks exactly the
same on both platforms, so it's actually less platform hassle.
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.
There are many more benefits, but enumerating those is a bit too much and
their usefulness varies on the usecase.
Whether your application is suited to a webapp is an individual choice of
course. E.g. 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.
-Matthias
Nat Echols
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.
Mark
> anybody else's fault!). The native controls provided by wx did not provide
> the user experience and the visuals I was imagining.
> Time went by and I refactored the whole thing a bit, the result can be
> seen in shot3.jpg. The main difference you can see there is the theming. I
> was prototyping a css engine for wxPython widgets, but abandoned the
> attempt after a while.
lot of code to do so. Before AGW I would not have been able to use
wxPython as I won't get into C++. However the AGW code is simple and
straightforward allowing a non programmer such as myself to very
quickly put together apps and get them looking the way I want.
As for making a 'webapp' - are you installing a browser for them?? Are
you sure you have the programming skills to make patches to all your
components? This is my greatest concern when delivering an app.
Mark
Matthias
>> bugs that had to be fixed before things worked (which is not Andrea's
>> or anybody else's fault!). The native controls provided by wx did not
>> provide the user experience and the visuals I was imagining.
>> Time went by and I refactored the whole thing a bit, the result can be
>> seen in shot3.jpg. The main difference you can see there is the
>> theming. I was prototyping a css engine for wxPython widgets, but
>> abandoned the attempt after a while.
>
> I've had no trouble theming my app using AGW and have contributed a
> lot of code to do so. Before AGW I would not have been able to use
> wxPython as I won't get into C++. However the AGW code is simple and
> straightforward allowing a non programmer such as myself to very
> quickly put together apps and get them looking the way I want.
Most of the agw components cannot be themed fully without changing lots of
code. Depending on the look of your theme the parts you can not theme can
look quite irritating. I don't say it's not fixable, I just say it takes a
lot of work. And still then, it won't be able to beat css, because
wxWidgets was never designed to allow for this amount of flexibility. The
designer of a custom widget has to anticipate all the stylings a future
user might want to apply.
Do you have any screenshots you can show which show a fully custom theme?
I agree with your view on agw in general. Without agw I also wouldn't have
used wxPython for so long. They solve quite a few usability and visual
problems. However, they still don't solve any problems with data models.
> As for making a 'webapp' - are you installing a browser for them?? Are
> you sure you have the programming skills to make patches to all your
> components? This is my greatest concern when delivering an app.
Right now I do not install any browser. The user is just prompted to
install a plugin which can execute arbitrary (signed) code, including
(wx)python code. The plugin works with IE, FF, Safari, Chrome and Opera.
The idea is to get rid of the plugin altogether in the long run. The only
real stumbling block here is the C++ code I need to run. So this won't
happen in the foreseeable future. Maybe there'll be some kind of
standalone browser later if really needed.
And yes, I have the skills to make patches to all of my components, be it
C++, python or one of the other languages used. Actually it makes things
more maintainable for me, because I can point any web designer/programmer
at the client side of things. Before this would've always taken a
programmer proficient in python and wxPython. Moreover, I can move a lot
of things over to external libraries, e.g. I don't have to write and
maintain a lazy loading CustomTreeCtrl anymore.
-Matthias
Matthias
You can still share memory between your "client" and "server" if you use a
local webserver with a plugin. There don't have to be speed compromises
there. You can just keep everything in the browser plugin as well, if you
want to. Or you can lazily synchronize the data with your server. The
XML-RPC things are already web-like. Now writing a gui in javascript can
actually be easier than writing one in wxPython depending on the
components you are using and the data you are entering. Do you happen to
have a screenshot?
One a different note, maybe a webapp architecture could improve your
user's experience. With the current system it sounds like e.g. you cannot
login from home to test a thing or two, because you don't have the files
available on your local filesystem. People working on the same things also
cannot share/watch each others work easily and collaboration is harder.
Users cannot annotate arbitrary things easily. Building interrelations and
catalogizing/searching things is a lot easier with many web frameworks.
You don't have to build custom data storage/versioning/backup solutions.
You cannot just change a few lines in the html/js/css, hit reload and see
the changes immediately. I could go on more, but finally it's also a
matter of opinion how highly you value some of these points.
Finally, I don't want to convince you to create a webapp out of your
application :) I doubt everybody is using wxPython as a GUI for
performance sensitive C++ code.
> 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. No matter how well an application works on the test systems
> that
> you personally set up, once it gets into the hands of enough users,
> people
> *will* find creative ways to break it. (This is true with wxPython too,
> of
> course; even users who never touch the GUI manage to completely foul up
> installations.) Even if the web browsers always work - which they won't
> -
> people are going to have bizarre firewalls, messed-up network
> configurations, and weird restrictions put in place by the sysadmins.
> (And
> I have no idea how this would function properly on multi-user
> workstations -
> different ports again?)
In my experience the deployment issues are less serious than commonly
anticipated. However, I don't have to deploy to all kinds of linux
machines. I'd estimate the chances of wxPython related packages not being
up-to-date or just completely broken just as high as somebody configuring
the firewall to block connections to localhost (or localhost not being
present).
On a multi-user workstation you can probably make the user login and then
display the pages depending on the http session/a cookie. Just like when
you log into some page on the web which serves more than one user. This
requires your app to be installed once for all the users on the machine.
You could also start a proxy webserver from your browser's plugin and let
them negotiate a port. Or you just put a single server on the lan and make
the clients cache stuff. There might be better ways, I don't have this
problem as in my case the server is not on the same machine.
-Matthias
Kevin Ollivier
On Nov 2, 2010, at 6:23 PM, C M wrote:
> First, Stef, thanks for generating some interesting material.
>
>> 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.
>
> Kevin, can I ask what kind of "upcoming app categories" you have in mind?
Mostly more hybrid web / desktop UI applications. I guess you could call that "modern" too, but I think it is still a rather new concept in practice.
I think that argument would fit better if the issue was that there were a lot of wx developers using, but not contributing back, to wxWebKit. However, almost every single app user I know of using wxWebKit is using wxPython, not wxWidgets C++. And I think the simple fact of the matter is that compiling it is a pain. (Not something I can do much about, its size and complexity are largely set by the main WebKit project.) I think once a user gets the idea of "this works, but I can see a few tweaks I can make", then I think they'll be more open to the work of compiling.
The basic underlying issue I see is that people like to see a working sample before they invest too much in something, and since there are no wxWidgets C++ binaries for Win or Mac, I can't build a wxWebKit dylib for a "stock" wx that users can play with like I can with wxPython. Users are looking at 1+ hours from "get the code" to "try a hello world sample". So I think most potential C++ users and contributors find the need to compile such a large codebase onerous and just move on. (And yes, "where is a binary version" is perhaps *the* FAQ I get from C++ users.) I actually think this lack of binaries is harming wxWidgets itself on the C++ side considerably, but when I bring it up the response I get is "if we can't build binaries for every possible wx configuration, we shouldn't build binaries for any of them". ;-) Funny how Linux distro users and wxPython users get along fine with one-binary-for-all, but anyway...
>> 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,
>
> For wxPython "modernizing", what, besides wxWebkit, do you have in mind?
Mac particularly is a good example where the platform has added all sorts of nice UI controls that native apps can use, but wx apps can't without a lot of painful hacks. There's also just the fact that wxWidgets C++ does not adopt modern coding libraries that ease maintenance because some old compiler can't compile it, etc. and it just makes contributing harder for people who are now used to using these tools in other projects. As an analogy, imagine wxPython requiring all Python code to be Python 1.5 compatible or at least have explicit version checks before all code for versions newer than 1.5.
There's a lot more, but I don't have a lot of time to discuss these issues right now. If I had more time like that, I'd be pushing out a new wxWebKit Win / Mac binary... :(
Regards,
Kevin
> Thanks,
> Che
Christopher Barker
My thoughts:
On 11/2/10 4:21 PM, Matthias wrote:
>> 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.
On 11/2/10 4:42 PM, Nat Echols wrote:
> "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!
On 11/2/10 6:28 PM, Mike Driscoll wrote:
> 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!
On 11/2/10 7:03 PM, Matthias wrote:
> 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.
On 11/2/10 7:45 PM, Nat Echols wrote:
> 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
--
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
Nat Echols
On 11/2/10 7:45 PM, Nat Echols wrote:I'm confused, this is usually easier with web apps -- that's one of their main selling points!
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.
Matthias
There are many more advantages than just putting server and client in
different spatial locations. You can benefit from a whole server stack for
example. It's about being able to use many external resources (code,
algorithms, interfaces) instead of having to code many things yourself.
Although with some application redesign you might be able to split your
server and client in different spatial locations, too. Just cache the
currently edited data on the client for example.
-Matthias
Matthias
<Chris....@noaa.gov>:
>> Also, wxPython did not provide any data-driven controls.
>
> Dabo does, though.
I looked at the dabo source very closely. It wasn't good enough for my
purposes.
>> 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 started like that. But there's no point in making a single wxPython
frame with a huge wxWebKit window in it. You can just use a browser then.
>> - 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?
I need theming because it can a) improve usability and b) make my
application stand out. Usability is heavily dependent on visuals. So if I
can change the visuals to my liking I can change the usability to my
liking.
Finally, you can just create a theme that looks like your desktop if you
really can't part with it :)
>> - no data driven widgets, no connection to server backend
>
> again, Dabo, yes?
No, it might make for a starting point of a very long journey though :)
>> 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.
Writing webapps can be easier. You can benefit from server stacks with
databases and content management systems. On the UI side I'd say that
ExtJS is not harder than wxPython, maybe even simpler.
> On 11/2/10 4:42 PM, Nat Echols wrote:
>> "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.
You can do that with a browser plugin. Browser plugins can have javascript
apis, too.
> 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.
No, but you could just run a browser plugin which executes your OpenGL
code (or python interpreter). Finally, I think in the not so far future
there will be simple 3d apis for browsers:
http://en.wikipedia.org/wiki/WebGL . Firefox 4 and IE9 will also support
hardware accelerated drawing.
> On 11/2/10 7:03 PM, Matthias wrote:
>> 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?
I think the HTML-DOM-manipulating-Javascript stuff is great. It's really
flexible. If you could to the same with wxPython it would solve quite a
few problems for me. E.g. you can create windows out of drawing primitives
and images and don't have to draw to wx.DCs. The DOM is not that much
different from FloatCanvas(2) really.
Windows is underrated in my opinion :)
> > 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.
But why would you want to use wxPython if the web stuff gives you all the
functionality and more (except that it's a nice thing and has a great
community :))? I really like wxPython, it's a pity I cannot put it to use
for my current project.
-Matthias
Christopher Barker
> But the webapp - including the entire backend - would be running locally
> on each computer.
OK, in that case, distribution is just like a desktop app -- but it's
not harder, either.
> Isn't the reason for the supposed ease of webapps
> that you have a single centrally administered server/cluster, or at
> least one per site, instead of individual installations?
Usually, yes, that's the idea -- and if you can do it that way there are
major benefits.
The advantage of a BILS app is that most if the UI can be
browser/html/javascript. In out case, that was an advantage because we
needed that anyway, and would rather not write/maintain/document two
UIs. In that app, a web interface was a good match anyway:
fill out some forms
get some reports.
pretty simple stuff.
I think Mattias is arguing that the state of web app development tool is
now better than desktop tools, and you're likely to want a little
web-connected stuff anyway, so why not just use the web tools for
everything you can?
I'm not sure -- for interactive apps that work with lots of data, I
don't think the Web UIs are there yet -- and may never be. I think both
of us are doing that kind of thing, and it's pretty common in scientific
software.
Matthias
<Chris....@noaa.gov>:
> I'm not sure -- for interactive apps that work with lots of data, I
> don't think the Web UIs are there yet -- and may never be. I think both
> of us are doing that kind of thing, and it's pretty common in scientific
> software.
I'm not sure, the amounts of data I deal with are in the GB range. With
full data history it can easily get into the TB range. With better client
side storage via a plugin (html5 has some, but it's more suited to smaller
data) and a decent connection (probably 100 MBit or 1 GBit LAN in your
case) it's doable in my opinion. Computers can't load/store data faster
than 100MByte/s even on local hard disks.
It might even speed things up depending on your use cases. Say you have
your data on a central server and 10 idle clients. You can enter a build
job into the system where the clients fetches the data, applies some
algorithm and sends the updated data back to the server. If this takes 1
minute it would probably have taken you close to 10 minutes if you ran it
just locally.
-Matthias
Matthias
Of course a distributed file system would be able to do this, too.
-Matthias
Al Mansur
> --
> To unsubscribe, send email to wxPython-
> users+un...@googlegroups.com
> or visit http://groups.google.com/group/wxPython-users?hl=en
[alm>] I'm not so sure about that. Current generation disk drives have
sustained transfer rates of over 130MB/s which with 3G or 6G SAS/SATA
equates to 1.3Gb/s. And you get almost all of that SAS/SATA bandwidth for
yourself while I think you'll be lucky to get half of the network's
bandwidth. You'll need a fast processor system to make this happen, of
course.
Al
Mark
I can't post screens of my project, but take another look at AGW under
the demo - as I've updated code I've tried to make the demo look
better as well. I've completely modified the colors of everything
(except TODO scrollbars ) in my app easily. You should be able to see
that custom renderers are available for cases where you don't just
want to change the color of the selection bar or notebook tab, but
want to gradient it or something. Its all quite simple and the more
people theming the better it will be.
Heres me theming the menu bar.
self.menuBar = FM.FlatMenuBar(self, wx.ID_ANY, 32, 1,
options=0)
self.menuBar.SetBackgroundColour(wx.Colour(211,227,247))
self.menuBar.GetRenderer().SetMenuBarHighlightColour(wx.WHITE)
Mark
Matthias
Yes, you can theme certain things to a certain degree. I did that e.g. in
the shot3.jpg attachment to my earlier mail. This involved custom
renderers, e.g. for the list header. Even native widgets (at least on
Windows) can be themed ok. However, it's not comparable to css theming.
The layout and features of the design are all hardcoded.
So in the end I guess it's YMMV. If current theming and available controls
are good enough for you and don't need more than it, it's great that
wxPython/agw does it all for you!
Btw, I've found no easy way to theme the scrollbars as they are provided
by the native widgets. And at least under win32 you can't change their
appearance. It might be possible to replace them with custom drawn
scrollbars somehow, but I haven't walked down that road.
-Matthias
pyGrant
I would love to see wxWebkit working on Linux, Mac, and Windows. And
I certainly agree with Kevin that a sophisticated, cross-platform web
renderer is an important part of a modern GUI toolkit. Fortunately, I
have successfully gotten the Dojo Javascript/SVG toolkit working on
all three platforms: on Linux using the elegant trick from
http://wiki.wxpython.org/wxGTKWebKit (which works on Ubuntu, Fedora
and openSUSE), on Mac using the native webkit control, and on Windows
the IE6-based control. It is the latter that I would most like to
change over to a proper wxWebKit control for obvious reasons. If you
want to see a complex browser widget working inside a wxPython
application, check out http://www.sofastatistics.com and do some
Javascript/SVG charting or display some complex nested HTML tables
with css background images etc. It all works and the relevant Python
code is pretty easy to follow - esp in the full_html.py module.
All the best, Grant
On Nov 3, 9:44 am, Kevin Ollivier <kevin-li...@theolliviers.com>
wrote:
Andrea Gavana
On 2 November 2010 23:21, Matthias wrote:
> I've started developing a quite ambitious project some time ago. I want to
> create a tool to collaboratively work together. I chose wxPython for the
> client UI. The underlying server was custom created with the ZODB as its
> backend. shot1.jpg and shot2.jpg from the attachment show the first very
> simple prototype. As you can see it uses only agw components (these shots
> actually predate wx.lib.agw). There's AUI, RibbonBar,
> CustomTreeCtrl/HyperTreeCtrl, ThumbnailCtrl and stc. I've contributed a
> dozen of patches against agw during this time, because there were always
> bugs that had to be fixed before things worked (which is not Andrea's or
> anybody else's fault!). The native controls provided by wx did not provide
> the user experience and the visuals I was imagining.
I applaud the way your were able to bend AGW to suit your needs. The
screenshots look impressive, and at last I was able to see some sample
images of your project!
I tend to side with Nat when it comes to web applications: for my
specific purposes (again, scientific/engineering tools), they are a
no-no and egoistically I wish they would be dead, so that developers
could spend their time improving desktop apps instead. But we live in
an imperfect world.
Other than that, I follow very closely the wxWidgets/wxPython mailing
lists (although I am very often short of time since my rotation job
started), and I feel Kevin's pain when it comes to
wxWidgets/wxPython's future. The development pace is slowed down by
the obsession with backward-compatibility; I surely hope Kevin was
joking when it mentioned Windows 98 support in wxWidgets. If this is
not the case, we should ask ourselves: is Microsoft still supporting
Windows 98? I guess the answer is "no". It's a dead platform, let's
move on.
In the past I had mixed feelings about (or I was even against) theming
support in wx; now I think that not supporting theming on
"native-looking" grounds, or not supporting more advanced/exotic
controls because one platform doesn't have them, is a very lousy
excuse at best. AGW, although it offers some more generic widgets, is
unfortunately not the answer. Chrome doesn't look native on any
platform I know of, but I use it every day and I can't possibly
overstate how much more productive one can be because of its speed and
clean interface. I can't obviously whine too much about these issues,
as I have contributed nothing to wxWidgets development (on the C++
side, I mean). But I guess it's high time for wxWidgets developers to
start and look for unexplored and wild territories of new widgets, new
implementations, modern platforms. Being conservative is not always
the answer: breaking the rules - in a positive way - is what will put
wxWidgets/wxPython on top of the UI programming Everest (even at the
cost of momentarily angering other wx users like me because of
backward-incompatible changes or API breakages).
Just my 2c.
Andrea.
"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/
==> Never *EVER* use RemovalGroup for your house removal. You'll
regret it forever.
http://thedoomedcity.blogspot.com/2010/03/removal-group-nightmare.html <==
Kevin Ollivier
I wish; see Vadim's Apr 6, 2:43pm reply to this thread:
Though Vadim does hope that by wx 3.2 we can finally drop support for them. ;-) Of course, that's probably at least 2 years away, and even then, he probably will need to be convinced that "no one will complain", which is a pretty unreasonable standard to adhere to. In the meantime, there are even new wx C++ APIs which we cannot use in wx code or samples because they aren't supported under VC6, which kind of hinders their adoption...
> In the past I had mixed feelings about (or I was even against) theming
> support in wx; now I think that not supporting theming on
> "native-looking" grounds, or not supporting more advanced/exotic
> controls because one platform doesn't have them, is a very lousy
> excuse at best. AGW, although it offers some more generic widgets, is
> unfortunately not the answer. Chrome doesn't look native on any
> platform I know of, but I use it every day and I can't possibly
> overstate how much more productive one can be because of its speed and
> clean interface.
Yes, the key is not that the widget looks native, but that it's intuitive and meets the user's needs well. I'd say if anything, Chrome's design highlights the benefit of a minimalist interface more so than it does the advantage of owner-drawn. It could have been performant and more native at the same time, and I don't think people would have minded, but I suspect Chrome did it the way they did to reduce the coding burden with the Chrome OS project, etc. :) In any case, IMHO the real take away is that functionality trumps form.
The important thing to remember though, when arguing the benefit of owner-drawn, is that many native controls have a lot of auxiliary functionality only used by subsets of users. (And thus not necessarily obvious to the average developer.) Accessibility is one obvious example, but there's also things like drag and drop behaviors, clipboard support, IME (Chinese / Japanese / Korean / Arabic / etc.) etc. These behaviors may be different from platform to platform, and when you go full owner-drawn, you need to manually code in all those behaviors if you wish your control to meet the needs of all the users that the native control does. I've had to deal with some of this with wxWebKit, and wxWidgets does not offer APIs for a lot of these things (particularly IME handling and accessibility) and so in the wxWidgets world owner-drawn UIs end up second rate from a behavioral point of view.
> I can't obviously whine too much about these issues,
> as I have contributed nothing to wxWidgets development (on the C++
> side, I mean). But I guess it's high time for wxWidgets developers to
> start and look for unexplored and wild territories of new widgets, new
> implementations, modern platforms. Being conservative is not always
> the answer: breaking the rules - in a positive way - is what will put
> wxWidgets/wxPython on top of the UI programming Everest (even at the
> cost of momentarily angering other wx users like me because of
> backward-incompatible changes or API breakages).
Amen to that!
Regards,
Kevin
> Just my 2c.
>
> Andrea.
>
> "Imagination Is The Only Weapon In The War Against Reality."
> http://xoomer.alice.it/infinity77/
>
> ==> Never *EVER* use RemovalGroup for your house removal. You'll
> regret it forever.
> http://thedoomedcity.blogspot.com/2010/03/removal-group-nightmare.html <==
>
Stef Mientki
First of all, I hope Kevin finds some co-workers, so we finally get hold of the real wxWebkit.
Most of us agree, that almost all applications will move to the web in the future,
but we differ in how fast this movement will.
It surprises me heavily that a few people still prefer (think the need) desktop applications above
web-applications.
Not that they prefer desktop application, but the reason why, they prefer desktop applications.
I'm coming from an age, where scientific computing could only be done on mainframes, and I still can
remember how we had to fight each day to get as many processors as we could for the next night.
So I find independency from networks, servers, other persons a great good, and this is the only
reason I can legitimate desktop applications (and your own desktop computer can fail too ;-)
As others already mentioned, large datasets and speed is not an issue at all, think of distributed /
cloud computing / gaming and realize that you can easily heir computer power, 1000 times faster than
your own desktop (e.g. Amazone Elastic).
Now back to the "wild idea".
My friend (in fact he's my son Robbert) brought up the idea and realized it.
It works very well and thanks to webkit, bloody fast.
Looking back, after you find the right keywords for the QT-environment, it's even fairly simple to
build.
We made a small movie, showing the embedding in real practice:
http://www.student.tue.nl/W/r.mientki/demo_qtwebkit.html (22MB, 5.5 minutes)
cheers,
Stef Mientki
On 02-11-2010 20:36, Stef Mientki wrote:
> hello,
>
> a friend of my came with a very wild idea ....
> ... why not use the webkit from QT in wxPython ?
>
> The idea started when reading about the new PySide,
> which has better (= more free) license than PyQT.
>
> Technical the idea is as follows :
> - create a standalone QT application, containing a frameless webkit
> - create a hole in the main wx-application
> - launch the QT application from the wx-application
> - position and size the QT application so it fits the hole
> - make a communication channel between the two applications (through pipes)
>
> Would this be realizable ?
>
> cheers,
> Stef
Micah Nordland
--
Hi, I will kill all ads in google gmail.
They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!
Stef Mientki
> very cool. I once thought about making a web brower in wxpython, but I wanted it to be open, and
> not be just ms windows.
for windows we've other solutions (IE, PuntHoofd),
it was th� goal to make a multi-platform as free as possible solution.
Therefor we used:
- embedding through a hole, which is complete multi-platform, in contrast to docking
- communication through execnet, which is completely multiplatform, instead of pipes or other
asynchronuous communication
- the use of PySide bindings, better future perspective and licensing than PyQT
The only thing we couldn't solve multi platform is focusing,
but we expect that won't be any trouble for a specialist on another platform.
> Maybe upload this video to Youtube, as it took a long time to load on my computer.
thanks for the hint, but I don't know how to convert a flash movie (with interactive controls) to
YouTube.
(btw I've the slowest available internet connection available in my country: 20 seconds ;-)
cheers,
Stef
> --
> Hi, I will kill all ads in google gmail.
> They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!
pyGrant
I'm not sure I always understood what I was seeing but that was a very
cool demonstration. It looks like you're pushing some boundaries in
interesting ways.
Your comment about internet speed is quite relevant to this general
discussion - it explains why desktop applications have a lot of life
left in them. I have pretty good broadband but huge numbers of
people, and entire nations, do not. In 10 years time maybe that will
be lots better and I might have to change from making SOFA Statistics
a desktop application. But by then a lot of things will be very
different and I might as well wait and see.
All the best, Grant
Stef Mientki
On 16-11-2010 20:48, pyGrant wrote:
> Hi Stef,
>
> I'm not sure I always understood what I was seeing but that was a very
> cool demonstration. It looks like you're pushing some boundaries in
> interesting ways.
>
Yep, but it's necessary ...
although Python is a very beautiful language,
coming from Delphi,
I'm missing a few things,
e.g. an wysiwyg html editor.
> Your comment about internet speed is quite relevant to this general
> discussion - it explains why desktop applications have a lot of life
> left in them. I have pretty good broadband but huge numbers of
> people, and entire nations, do not. In 10 years time maybe that will
> be lots better and I might have to change from making SOFA Statistics
> a desktop application. But by then a lot of things will be very
> different and I might as well wait and see.
Yes sorry, I often forget that a lot of people have much worse internet.
But here comes another very nice feature of Python,
as it runs on servers, it's easy to run a web-application on your own computer, without the need for
an internet.
In some cases on windows it's even more easy,
you can run your webapplications directly in MSHTML,
that's completely without a local server.
The included python server serves most of the rest of the situations,
and when that's not enough, on windows it's quit easy to install an Apache server.
So we're getting to a new point here,
"it's better to develop your applications as a web-applications,
because the can run both on the web and on your local desktop without an internet connection." ;-)
cheers,
Stef
Micah Nordland
Micah Nordland
Stef Mientki
> well, it still took, a while. Nothing else, ever takes that long to load on my computer.
cheers,
Stef
>
> --
> Hi, I will kill all ads in google gmail.
> They will all be dead and gone for all my emails to you. HA HA bye bye ads I just massacred you!!!