I need to add some multi-touch gestures to google earth plugin, and I want your opinion on witch way I can do that.
I work with a Dell XPS 18, running on Windows 8.1.
I found a way, using the RawInput API (here), but it's a very low level solution, so do you have another idea?
Thanks!
This is not an easy problem. The good/bad news is that you have found the correct API to use. The problem is that you can't simply "add multi-touch" to the plugin. The plugin runs in a web browser. The web browser doesn't have a concept of pinch-zoom or pan-tilt.
What you have to do is embed the plugin in your own custom program, and then intercept the raw inputs in that program. From there you will have to all the translations, and manipulate the GE camera appropriately (or, in some cases, just pass the events directly to the plugin.)
Again, this problem is not easy to solve.
A reasonable starting point (using WinForms / C#) is:
https://code.google.com/p/winforms-geplugin-control-library/
I would suggest trying to rewrite this library using WPF (maybe this already exists?) .NET 4.5 has gesture support built into WPF. (.NET 4.0 might have some stuff as well, not sure.)
Related
I would like to ask the SO community for the following information:
- Is it possible to compile WebKit for Windows8-Metro Environment, either in the form of a WinRT component or just as a linked library in a C++/XAML application?
- Which are the main steps to achieve this goal?
- Which are the possible things that would make this not possible or very difficult?
- Is it an endeavour someone is working on just now?
- Is it possible to gather interested people so they work on this?
I think you will not be able to just "compile" Webkit for WinRT/Metro Style. Metro Style applications are restricted in the kind of API calls they can make, for example there is no GDI/GDI+/MFC for WinRT. WebKit has several building modes that you can use, you can either build it using QT as rendering engine, or using GTK, or plain GDI, but on all those cases, when you create new builds for Windows OSes you will be using GDI at the very end.
Nevertheless, you could modify Webkit source code and add a new rendering engine that uses WinRT new APIs. You could probably become famous if you do.
As a side note, even when there is a "Windows Store" version of Chrome, by looking at the source code of Chromium it seems to me that this version is just a simple app launcher that communicates with the "normal" desktop version using an IPC channel. It does not appear to be a real Windows Store build of the whole source code.
I am not sure if the WinRT environment will allow this, but there is a project called Awesomium that is a wrapper around Google Chrome and Google Chrome is based on WebKit I think. It also has a .NET wrapper, so you can embedd it onto your .NET app.
I never tried using it, neither I know about if this library is applicable with WinRT, but at least it is a start.
Awesomium
Awesomium .NET samples
DownMakerWPF, an application embedding it to display markdown.
WinRT is a combination of managed and native code, so, you have a chance to port WebKit, but remember - native code have some sandbox restrictions.
Also you can choose XNA instead.
I am a web developer. I don't know how to build native Windows applications. I recently built a Mac desktop application (using MacRuby) which is a WebKit wrapper around one of my web applications. I'd like to do the same thing for Windows (preferably in Ruby, but whatever is easiest).
Since this is not the core of the application, I'd rather not spend a lot of time trying to build and maintain it. I just need a Windows application that can:
Open a specific website on application launch using an embedded WebKit WebView
Trigger Growl notifications via JavaScript (with some sort of named bridge)
What is the easiest, fastest, cleanest way to do this?
Update: So far I've come across some frameworks like Qt and Awesomium. I don't know how these frameworks compare to other options available, so if you have any opinions or advice, I would appreciate it.
Check out http://appjs.org/ it's built with NodeJS at its core! And it uses chromium webkit at it's core :D
Well, this is a very old question, but if you are still interested...
I'd recommend Qt. There are some very good books available with a lot of boilerplate code and wizard-type tools. You will be able to find example code demonstrating the embedded Webkit that you can modify to suit your needs. It is free and redistribution is free (last I knew). You won't have to know anything about native Windows development, nor even use any native Windows dev tools.
Good luck!
Some articles point to Windows 8 development being HTML-based instead of primarily using native code like C or C++ (as it has been until now) or .NET (as now, or even more so as it would have been in Longhorn, but never was.)
Is this true? Will the core APIs be accessible from Javascript then? What is the primary API / framework for Windows 8?
This is worth asking. When Windows 8 was demonstrated in June, a couple of comments by the presenter scared quite a few developers - or at least turned the Internet into panic mode. I'm surprised this question hasn't been asked here before.
The best article on the topic I have found is Windows 8 for Software Developers on Ars Technica.
The short answer is: it will remain the same.
The long answer is: it will remain the same, but several things will be added. You may want to pursue using those if you're willing to bet on new Microsoft technologies. One particularly interesting one is WinRT, which is a new object-oriented native code API exposed through COM, which is supposed to be a new version of the old flat Win32 API. Details are in the linked article.
It is very, very, very, very unlikely that anything that already exists, especially based on Win32 or .Net, would be removed. That means your existing programs written in .Net or native C++ or Delphi will continue to work fine. It is also unlikely that the primary development platform will be HTML. More likely is that HTML applications will be encourage for specific scenarios - perhaps touchscreen, kiosks and tablets.
I'd encourage you to read the article I linked to above - it covers this in far more detail than any answer here can.
There are three ways to develop for Windows 8, and they all access the same underlying API, the Windows Runtime.
Use C++ and call WinRT functions much like calling Win32 APIs back in the day (you know, yesterday)
Use C# or VB and call what appear to be .NET methods (but aren't)
Use Javascript and call WinRT functions
The UI is built with XAML using a pretty reasonable designer. More details are still coming out: check http://channel9.msdn.com/Events/BUILD/BUILD2011 for videos with detailed coding demos. http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1005 is not a bad starting point.
There are 3 language/framework combinations that are all equally supported:
C++ and XAML
C#/VB and XAML
JavaScript and CSS/HTML
All are first class ways to write Windows 8 Metro style applications. Windows Runtime provides direct access to each of these languages and so choice of development environment can be based on familiarity or feature set of the language and not on restricted availability.
Update: I forgot one: C++/Direct3D (for games).
The original quote, in the context of writing a tablet desktop weather gadget application, is that the application uses "our new developer platform, which is, uhh, it's based on HTML5 and JavaScript."
The demonstrator never said a gadget is the preferred type for applications (How many Vista sidebar gadget or Windows 7 desktop gadget have you written in your life? Even when you can write them in simple HTML!), or the platform is the preferred platform for desktop weather gadget applications (How many animation control have you add to your application with video playing requirement? It is THE control used by Windows Explorer to display video!).
Today, after spending a few minutes playing with Windows 8 developer preview, I found that you can use Expression Blend 5 to easily auto-generate metro-styled applications in HTML and Javascript. Also in Visual Studio you can create exactly looking applications in Silverlight. :)
I am very excited!!! Go Windows 8! :)
I'd like to develop a stand-alone desktop application targeting Windows (XP through 7) and Mac (Tiger through Snow Leopard), and if possible iPhone and Android. In order to make it all work with as much common code as possible (and because it's the only thing I'm good at), I'd like to handle the main logic with HTML and JS. Using Adobe AIR is a possibility. And I think I can do this with various application wrappers, using .NET for Windows XP, Objective C for iPhone, Java for Android and native "widget" platform support for Mac and Windows Vista & 7 (though I'd like to keep the widget in the foreground, so the Mac dashboard isn't ideal). Does anyone have any suggestions on where to start? The two sticking points are:
I'll certainly need some form of persistent storage (cookies perhaps) to keep state between sessions
I'll also probably need access to remote data files, so if I use AJAX and the hosting HTML file resides on the device, it will need to be able to do cross-domain requests. I've done this on the iPhone without any problems, but I'd be surprised if this were possible on other platforms.
For me, Android and iPhone will be the easiest to handle, and it looks like I can use Adobe AIR to handle the rest. But I wanted to know if there are any other alternatives. Does anyone have any suggesions?
You might be interested in Appcelerator's Titanium. It's an alternative to Adobe AIR that lets you build native mobile and desktop apps using HTML and JS (with the WebKit rendering engine, so you can take full advantage of HTML5 and CSS3). It also satisfies your two sticking points:
SQLite is available for persistence storage.
There are no restrictions on cross-domain requests.
I used Titanium Desktop for a recent project and it was a relatively smooth development process. It's also open source so you have access to the full application at all times.
Check it out and let me know if it works for you.
You can create a desktop application with HTML, CSS & Javascript using either of the following two frameworks
TideSDK
AppJS
For mobile you can use the similar HTML and Javascript using PhoneGap
What GUI toolkit does Valve use for Steam? Is it Qt? I am interested in using the same toolkit for a project.
According to Valve itself:
"VGUI is Valve's proprietary Graphical User Interface. All Source and Steam applications use VGUI to draw windows, dialogs and menus. It also handles localization: the displaying of text in the user's preferred language. "
That's interesting, maybe if you guys do some research you can have it working in your programming language. I'll download the SDK to see if I can make it work with Java :)
http://developer.valvesoftware.com/wiki/VGUI_Documentation
Having had experience with the Source engine I know that Valve have an library called VGUI which they use for all their games and many of their tools (when in game the library sits on top of the Source renderer, when in tools it sits on top of the Windows API I believe). Although I can’t answer the question with 100% certainty I suspect that this is what they use for Steam as well (I seem to recall some Steam updates that mentioned VGUI) – I would be surprised if the new beta uses a different library.
Even if it is not using VGUI, given what I know of Valve I would think they will have written something else entirely in-house.
So, it is (almost certainly) proprietary and highly unlikely to ever be available for third party use (unless you have the funds to buy a Source engine license).
Steam only runs on Windows and predates QT for Windows, so I'd have to guess something else.
Since Steam has had the same GUI since 2003, chances are it uses some variant of MFC. It also uses an embedded Internet Explorer web browser for its Store and Community sections.
However, I can't give any guarantees about what the version currently in Beta uses. It looks quite a bit different and includs the Webkit rendering engine instead of using IE. It may use Webkit for everything rather than drawing their own GUIs.
Does this answer the question?
http://games.slashdot.org/story/10/02/25/0640233/Steam-UI-Update-Beta-Drops-IE-Rendering-For-WebKit