I've been thinking to give GUI development a try lately and am torn with the choice of between wxPython and Mono.
Judging from what I've seen out there, wxPython people seem to use the WebKit trick to produce nice (doesn't have to be beautiful) UI.
How hard is it to do the following in each of the platform:
1) Custom Control
2) Use HTML rendering
I don't quite understand how far the HTML rendering works via WebKit in wxPython (i.e.: does it support separate CSS/JS files? how's the JS support? do we need to write extra wxPython code to run the JS? how hard it is to integrate between JS events and wxPython widgets? what are the usual strategy of integrating WebKit with wxPython?)
Mind to share your thought on this subject? I specifically pick either wxPython or Mono, not Java Swing for no reason.
PS: I'm aware of certain limitation of cross-platform UI (as in: it won't be 100% native) and I could care less of such things.
wxPython has wxWebkit available via the new WebView widget, but WebKit is only available on Mac and Linux right now. WebView uses a different rendering engine on Windows called Trident from IE (see http://wxpython.org/CHANGES.html). So you'll want to keep that in mind.
Either way, we're talking about browser engines that display HTML, CSS, etc. They should, theoretically, display whatever those engines support. You'll have to look up their specifications to be sure and also make sure to check if the port supports everything. As I understand it, they should definitely support the usual HTML and CSS and I would assume normal javascript. If I were you, I'd just create a simple window in wxPython and then load the web page you've created and see how it works.
I don't know how the javascript communicates with wxPython or if it even does. You'll want to ask on their mailing list for that kind of information.
Related
I'm probably way out of the loop, but it seems weird to use a native look GUI library and then - if you're not using wxGTK - shoehorn in a text renderer from a different GUI library. What's the deal here?
I think I understand your point. Using GTK (and Pango Cairo) on Windows, by telling wxWidgets to use internally GTK seems duplicating window managers.
It's just a matter of taste. GTK in Windows does call Windows API to do windowing. But some users like the GTK-way for windows, menus, and other controls instead of the native Windows-way, and wxWidgets provides this feature (in addition, of course, of the native usage, keeping native look&feel).
Anyhow, GTK on Linux calls internaly X11 or Wayland for handling windows and menus. Do you also call this "duplicating"?
The question seems to stem from a mistaken assumption, so it's hard to answer it, let me rather explain how things really are instead:
Cairo-based wxGraphicsContext can be optionally used under MSW because this allows to produce exactly the same graphics output under all platforms, which can be important for some kinds of applications. However it is not used by default, you need to explicitly request it, and if you don't you'd be using GDI+ or Direct2D, both of which are perfectly native libraries.
I am working on enterprise-level business applications, and now is the time to start thinking about the non-desktop experience.
We have a common component code-base that is using dojo, and are trying to get as much code re-use as possible.
I am really struggling to determine if I should re-use the same code base, or have separate code bases for desktop and mobile.
A big factor in my decision making is the viabliity of dojox/mobile.
It seems pretty cool, and uses the dojo infrastructure which is a huge win, but the fact that it is in dojox scares me a little.
Some questions:
Is dojox/mobile something that can be relied on long term?
Is it a smart idea to try to swap out dijit components for dojox/mobile components depending on what has.js can tell me?
Will dojox/mobile be a part of dojo2.0?
I would add that in Dojo 2.0 the plan is to converge as much as possible the desktop (dijit) and the mobile (dojox/mobile) widgets which should help in your use-case. See: http://mail.dojotoolkit.org/pipermail/dojo-contributors/2013-June/029041.html
You can rely on dojox/mobile. DojoX will indeed disappear from the Dojo Toolkit in 2.0, but most matured (and probably maintained) modules will be pushed to the dijit/dojo library. I quote the reference guide:
In the future (Dojo 2.0), the DojoX package and namespace will
removed. Sub-Packages and modules will be either integrated into the
Dojo Core, Dijit or separated as their own stand-alone package. For
the 1.X code stream though, in order to ensure backwards
compatibility, all these packages are contained within the dojox
namespace and package.
If we look at the explanation of Mature, we can read the following:
This package or module is considered mature and is being actively
developed and maintained by committers within the Dojo Toolkit. It is
expected that it will persist into the foreseeable future.
Source
And if you look at the link above, you will notice that dojox/mobile is categorized as mature.
Another reason you can rely on it is that IBM (which can be considered a pretty big company and committer to the Dojo toolkit) also relies on dojox/mobile for their mobile product called IBM Worklight. If they rely on it, then there's no reason you couldn't.
I don't think it will be easy to start from the same code base and swap out dijits for dojox/mobile components. Usually mobile app development requires an entire different strategy than web applications. You will probably have to split certain things into multiple views and some dijits may not have a mobile alternative.
You can probably re-use most of your utilities and business logic, but I think you will have to start from scratch again if you want to write your view(s). But I'm not really an advanced mobile developer.
I have a desktop app based on HTML/JS that needs WebKit to function at a reasonable speed. Normally, I would live with IE behaving badly, but its JS engine is just too slow.
I would normally go to Appcelerator for this, but it seems they have discontinued their desktop SDK and left it for the "community"...
This needs to function on Windows PCs, or I would just use Fluid (http://fluidapp.com)...
Is there a simple Webkit wrapper that I can use, or should I build one really quick in something like Qt. I haven't used Qt in a while, so I'd have to look at it again and make sure WebKit is implemented in it...
While it is somewhat node.js-oriented, AppJS may offer what you're looking for. If it doesn't already support other scripting languages, it might at least provide a good example to start from.
Update: in the time that's passed since my original answer, it seems node-webkit fills a similar role but has gathered and maintained more momentum than AppJS. It's a little more focused, in that it doesn't attempt to provide much additional "framework" on top of simply exposing the node.js API to the window's JS context.
There's also https://github.com/atom/atom-shell, which I just learned of and may be similar.
One other thing to note is that (presumably with either, but at least with node-webkit), you MUST be cautious of any XSS-like vulnerability in your app that an attacker could exploit to gain complete access to the user's native machine. So if you are simply needing to package an offline web app in a downloadable desktop distribution, you may wish to research more PhoneGap-like solutions (e.g. Mac OS X as PhoneGap platform) or a plain web view wrapper (like mentioned in the OP) that do not expose an entire OS-level native API — as node.js does — into the JavaScript environment.
Has anyone done some extensive automation with Selenium and a Dojo-heavy web app? I'm looking for any issues or problem that you might have run into or issues related directly to the combination of Selenium and Dojo.
I've used Selenium extensively with a bunch of different web apps, including a few on Dojo. You should be fine. One practice I would recommend is to make sure all the components you'll be testing (both UI controls you'll be driving, as well as text components you'll be reading for testing) have ID tags set. Selenium has a bunch of elegant selectors to get at the elements you need, but selection by ID is still the best. The other methods can be more brittle.
I've had some challenging experiences with Selenium RC not being as compatible with my code as Selenium IDE, to the point that I stopped using Selenium RC. And in case you are not super familiar with Selenium, you should be aware that it doesn't natively support some (IMO) pretty fundamental features like flow control and includes; but there are user extensions to the framework that allow this. I'd also recommend taking a look at Watir which I now generally prefer over Selenium because it exposes the full power/flexibility of a first class language (Ruby).
I'm working on a Dojo-heavy app right now, and am making a number of tests with Selenium IDE. I've ran into a few issues with certain Dojo elements, such as drop down menus and tabbed components. I've learned to appreciate XPath, and have been experimenting with how clickAt and waitForElementPosition commands, which seem to help accommodate for some of Dojo's features.
Dojo specifics - very brief
The Dojo itself differs in some approaches from other heavy-DOM and extensively impressive frameworks (like ExtJS, jQuery, YUI).
The general Dojo specific it workaround the limitations by using Flash (YUI does as well) or Silverlight.
Here is a couple scenarious when Dojo can use Fash:
the browser is not HTML5 and javascript need local storage. Then Dojo will use "Flash Cookie" Flash Local Shared Objects (package dojox.storage)
need support of cross domain https calls.
The general tricks that can turn your testing into something difficult:
browser messages, like "do you wish to allow this site..."
nested frames can make the selection of the node difficult
javascript timeout/intervals they might work with different speed in Selenium then in real browser. Yes they can.
The biggest issue I encountered was the fact that dojo menus, and pop-up UI elements in general, are absolutely positioned as children of the body element and are not children of the element that creates them.
This can impact how you write Selenium CSS Selector and, in my case, made it a bit more challenging to automatically crop a screenshot that includes a menu and its dropdown.
Selenium should be fine with dojo because it's rendered in Firefox and not on it's own. Just make sure dojo is available when testing ( i.e. don't connect to google's cdn if your test environment doesn't have an internet connection ). But that's a problem you'd have with any external resource
I have no experience, but did see http://www.ibm.com/developerworks/opensource/library/os-webautoselenium/index.html discussing how to use Selenium with dojo
If you need to test in an SSL environment and you use Selenium RC's trustAllSslCertificates + proxy, you must make sure all of your JS files are hosted on the same domain. I've seen problems recently with using CDNs to load JS and image files when testing under recent Firefox versions and selenium rc
I am planning to design an application XUL & XPCOM for proprietary system. So i have decided to use C/C++ but how can I start the development as a beginner in this field
I cannot find a good guide to start around. It will be good if you can give some links
and books. I also would like to know how to prevent the user from modifying the code specially in the view part because the logic can be done in XPCOM.
XUL explorer is a tool that lets you drag and drop XUL. It's good for mocking up an interface or starting to learn about the various elements you can use.
xulrunner is Mozilla's binary that allows you to run XUL/XPCOM/javascript applications.
The Mozilla Developer Center is your friend.
If you use IRC, check out #xulrunner on irc.mozilla.org . They are fairly tolerant of some questions from beginners.
I don't think there's going to be away around allowing the user to see (or potentially modify) the actually XUL interface. There are some paths for trying to secure JavaScript in some way (some surface level, like obscuring, minifying, but then some possible secure loading methods). XPCOM can be written in C++ or JavaScript, to name a few, if you put more of your code in XPCOM it should be more secure, I think.
A fun start for seeing what you can do in XUL is to check out the XUL Periodic Table.
Preventing the user from modifying your code is futile, as they will always be able to do this.
You could of course ship a modified build of xulrunner (containing some required XPCOM as well) which only loads jars signed by some key, but they could trivially hack around that by modifying the binary or the image in memory.
So don't bother trying to stop people modifying your code - you can't - unless you're on a trusted platform such as a games console - and even then it's not guaranteed.
This helped me to create my first XPCOM.