HP webOS needs javascript,HTML to develop applications.but is it possible whatever we can do through javascript in c++ or c? have they given any API list for it?I found PDK is for openGL game porting .Have they given any option for C++ developers?
If using C/C++, you are essentially on-your-own when it comes to the interface unless you build a plugin in for a hybrid PDK app that uses HTML and JavaScript for the UI. You are provided with APIs for system services and accessing the hardware (drawing to the screen, keyboard presses, etc.) in C++. The intention is that you'll use C/C++ when you need speed, and JavaScript the rest of the time when speed is less critical (as in, you're not doing anything that the user will notice as slower than if you had written the code in C/C++).
To answer the question I sense lies beneath your question, you're probably going to have to learn JavaScript to program for webOS unless you want to develop openGL games only.
Related
It seems that the Win32 API (the C API for native Windows applications) is becoming more and more overtaken by more modern frameworks and toolkits, including Microsoft's own WPF and Qt.
If the programming language is not a concern -- if you're not set on a managed environment, or a functional programming style, etc. -- does Win32 API bring anything to the table? Is there any functionality that one can implement with Win32 API that's not available with WPF or other frameworks?
I know it's possible to mix Win32 code into WPF/managed software, so one doesn't have to choose one or the other. But what are some examples of needing to break out Win32 API when developing a program in a higher-level language/framework?
Another more specific example is "windows hooks".
I needed to hook some socket programs at some point and the only possible way was windows api.
To elaborate i wanted to receive all communication received on some listening socket on a different one. Doing this requires hooks
Certainly.
All the frameworks are written in terms of the Win32 API. The frameworks cover 80-95% of what programmers need to do, but if you need really low-level control over something, you'll need to drop to the underlying Win32 API. Some examples would be:
precise control over text rendering (via DirectWrite),
detailed control over speech recognition using SAPI (there are literally dozens of interfaces not exposed through System.Speech),
low-level networking code (i.e., anything not HTTP related),
Practically anything audio related, if you're interested in performance.
... and don't forget about direct hardware access like "WinUSB" and debugging functionality (writing programs that act as debuggers).
The Win32 API is nowhere close to be taken over by any framework at the moment.
If that was the case, most of the API would not be updated by Microsoft. Instead, lots of new interfaces are added and updated.
There are framekorks like Qt, but, unless what you need to create is trivial, you will eventually use the API, especially for new graphics libraries, audio, video, usb, ribbon, sockets, network, COM automation, biometrics, encryption, digital signatures, security, scripting, etc.
Actually, most libraries are quite outdated and, while you can create an application that relies mostly on worker threads and not on the interface, building a nice, modern and useful application today certainly requires the API. So investing on a framework that would only cover a minimum part of your application is not worth the learning curve, these frameworks mostly target really new and unexperienced windows developers.
Does every window running use System.Windows.Forms.Form?
The title says it. From Java to C++ to Visual Basic to Console Apps. Does every compiled window use the class System.Drawing.Forms.Form?
No.
In .NET, System.Windows.Forms is (essentially) just a tool to draw windows, but it is not the only tool. Other languages have their own tools; Java has the Swing libraries, Python and Perl have several other GUI toolkits, each which do things differently. Console Apps use an entirely different way of presenting information. How things are drawn not only depends on the language, but also the GUI API used. For example, a window might be entirely drawn using C++ and DirectX and custom drawing routines; these would not use .NET at all, nor any underlying tools that .NET uses. That same window might be drawn with C++ and Open GL; the same data might be displayed, but the routines invoked to draw it would be different. In fact, you could do all the drawing with assembly if you were really masochistic!
Short answer No.
System.Windows.Forms.Form is an abstraction used by the WinForms .Net library to interact with the actual Windows provided by the OS.
Other languages have other abstractions: Java could use Swing or AWT or any other UI library which offer different ways to draw forms.
Likewise C++ could employ an abstraction over the OS provided objects (i.e. the MFC library) or use the Windows API directly.
All the UI libraries need in the end to use the Windows API to draw their windows, but not all of them do it to the same extent, so .Net's UI libraries will use some of the same API calls as Java's or C++'s UI libraries.
I'll update this answer if I find a good explanation of how the UI and UI libraries work on windows.
I remember reading a good one not long ago with some of the history and the changes in Windows 8 but don't remember where.
I was just thinking. C# has Winforms/WPF, Java has Swing and other frameworks, C++ has QT and so on; is it possible to create an application without using a Framework?
Putting aside the practicality of it, I'm just curious. How would one create an application that Just Works(tm) without needing external frameworks?
Two options come to mind:
Classical Win32 applications written in C. I don't know if standard Windows SDK API also counts as an "external framework" in your book, but that's as low as it gets.
DirectX/OpenGL games written from scratch with your own homebrew framework (not external, right?) There you get to do all the drawing yourself - although again, you use a pretty big library of primitive drawing functions.
If you want even less "framework", you'll have to code your own OS and drivers. :P
C# needs .NET Framework, not WinForms (which is an optional library used by some application). The same with Java.
Unmanaged (native) applications usually use some runtime library - the library of common functions. You can write a native application without any library - the compiler lets you do this, but you will need to (re)write lots of common functions, eg. for string manipulation etc..
Firstly, what is a framework?
Really a framework is just a bunch of code that is provided to you. You could, at least in theory, write the same code yourself. In that case you wouldn't be using a framework.
Your application can only do what the operating system allows it to do. Your program cannot directly manipulate the graphics card for example. So you have to use the APIs of your operating system in order to do anything.
So you are going to be calling into other code. (unless you write your own operating system). You will also being using another framework or api to get stuff done.
Yes. How: in the way that the frameworks you mentioned are implemented.
From a Windows point of view, you would register your window with Windows, then listen to window messages and react as required. Everything would be up to you - from drawing the window to building controls.
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
I want to write a front-end to an application written in C/C++.
I use Solaris 10 and plan to port the application to some other architectures (Windows first).
I'd recommend taking a look at wxWidgets to provide some cross platform UI widgets that will work on Solaris and Windows.
Qt 4 is the best tool for this job. If you want to work with other languages, it also has bindings for Java and Python
On a Mac, this would be easy. The Cocoa API is great when programming in Objective C (which compiles fine with C/C++ files).
Otherwise the situation is a bit more grim. As for Rapid prototype, you might want to check the CodeGear (Borland/C++ Builder) tools. I think their VCL library is cross-platform.
Otherwise, you could interface with a scripting language like Ruby and use fantastic front end libraries like Shoes. Python also interfaces with wxWidgets to make writing cross-platform front ends easy. Keep in mind that this all requires taking time to make sure your C/C++ code can talk to the scripting language. This is not trivial, and the amount of effort required depends upon the style of your code base. (Oh my God.)
Lastly, you could just use wxWidgets itself. This might be your best bet since it requires no additional overhead than coding the UI itself. That said, C++ is not the greatest language for designing UIs.
And super lastly, consider writing a code generator that converts from say Shoes to whatever wxWidgets code is needed to generate the same Shoes app. That way you can do easier UI design but still get C++ code in the end. Likewise, you could code gen off of the Python/wxWidgets code. Then sell such a code generator. :-)
GTK-- and Glade.
Thats' the C++ bindings on GTK
GTK will work on windows ( just look at GIMP )
Works everywhere, no QT license to mess with your millions-making.
I use wxWidgets myself. It makes good use of the C++ language features and uses smart pointers, so object and memory management is not that hard. In fact, it feels like writing in a scripting language.
Coupled with a dialog editor/code generator like wxFormBuilder or wxDesigner, (links to screenshots) it becomes a good toolkit for rapid development.
Have a look at FLTK which supports X11 and Windows.
Ultimate++ is a cross platform rapid application development framework for C++. It is aimed specifically at rapid development. The Ultimate++ website provides some comparisons to other frameworks mentioned such as Qt and wxWidgets.
I have used ASP.NET Web Forms to make UI front-end to collection of command line application written in legacy language, RESTful-ish web service, and bash scripts.
Once it works on Firefox, it should work at least on Firefox on other architecture. If you haven't played around with it, you should give ASP.NET a try (ASP.NET MVC seems to be the current trend). Not quite the same as RAD, but it does give you visual design of forms etc.