System overlay window with Android NDK C++, inc. OpenGL-ES for graphics - opengl-es

I am very experienced with Visual C++ and I am just starting to program native Android C++ apps with Visual Studio 2015 C++.
I need to do a homescreen overlay-style app, presumably by using a TYPE_SYSTEM_OVERLAY window and SYSTEM_ALERT_WINDOW permission.
Is it possible to do this with the NDK? Will all required API calls be available to use?
Am I correct to assume that I won't be able to use OpenGL-ES to display my graphics in the window (since it isn't full-screen)? I would love to be able to use cocos2d-x for graphics, input etc but I have a feeling that won't be possible at all.
Is it just going to be too difficult to use NDK for this type of app, and should preferably just sit down and learn Java and SDK?
(last question is probably a bit opinional)

On Android, anything you can do with Java, you can do with the NDK, because you can simply use JNI. If you are making many calls into Java from the NDK, you should consider creating an JNI wrapper class, which reduces the calling mechanism to fewer lines.
Although I haven't tried it, there is nothing in the Android documentation to suggest that GLSurfaceView cannot be used with a particular type of window layout.

Related

DirectX sample code c++

I'm looking for source code (as I bet a lot of others are / were and will) for learning purposes of DirectX. I would like something similar to the vs2013 Graphics Editor when dealing with *.fbx files, etc. Every thing I find is old and outdated, or way to simple and does not show the basics like transformation cursor, picking objects or points on objects. I'm just looking for something basic.
many thanks in advance
The DirectX Tool Kit is a good place to start and includes some tutorial content as well. It supports loading models using the VS 2013 content pipeline that produces CMOs from FBX files.
You didn't state if you were looking to write a Windows desktop application (aka a Win32 application) or if you were looking to write for Windows Store / Windows phone. DirectX Tool Kit supports either, although the tutorial is written using a Windows desktop application template so that developers using Windows 7 could also utilize it.
You should also refer to the DirectX SDK Samples Catalog for locations of updated versions of the legacy DirectX SDK samples that build fine using VS 2013 only.

Does every window running use System.Windows.Forms.Form?

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.

Compiling WebKit for Windows8-Metro Environment

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.

Windows Applications and CLR

What is this Common Language Runtime that I've been hearing about?
I've recently started a project to create my own, small, personal windows application. I've used DirectX for drawing in the window and such before, for games and whatnot, however this time, I wanted to make it a more standard style application, with menus, and selectable text, and right clicking.
I've searched, but I found no information on how to actually write code for such things, I've only found things telling me to use the drag-and-drop form interface, for windows.
Anyways, I've found that using the forms, actually lets me see the code behind it, too, so I guess I could learn that way....
...but its forcing me to compile using CLR. Why? What is CLR? Can I not create this style of windows application without it?
-Stefan
CLR (Common Language Runtime) is a Virtual Machine. Whenever you compile your .Net programs they are converted into an intermediate language whereas a regular compiler would compile to native code of the target platform. Now whenever there is a CLR implementation available for an OS your program will run on that OS. This is how your .Net programs are portable! Read more here http://en.wikipedia.org/wiki/Write_once,_run_anywhere
The CLR is the runtime for the .Net framework.
You can only run .Net code on the CLR.
Since WinForms is a .Net library, you can only use WinForms in .Net.

MS Windows Programming advice for Mac/Unix developer

I have a few years of experience writing Unix command line tools (no GUI experience) in python, C and C++, and only recently crossed into the GUI world (Cocoa and IOS only). I've learned quite a bit of objective-C and am getting to understand how cocoa MVC works. However, one of the apps I am developing needs a Windows version and I was wondering what a good place to start would be given that I have absolutely no Windows development experience.
I was thinking about using Visual C++ 2010 Express as my development platform (because it's free and because I don't need to learn C++). My application is relatively simple, it will have only two windows and spend most of the time running in the background. It will however need to communicate with the OS (load dll's etc) and an online server (HTTP methods) and I'm not sure whether Visual C++ Express edition gives me access to the required API's. Would a Windows Forms application suffice? Am I going about this the wrong way? Do I need to learn C#? Any advice will be appreciated.
If you are already happy with proper c++, visual Studio C++ express should suit you fine. Given that you are not making a complicated GUI, you don't even need to dip into the managed code - C++ express allows you to create proper c++ console and GUI apps. You also don't need to install the platform SDK - it is part of VS C++ express.
Not being managed C++, you will be able to share source files between your various projects. managed c++, despite the c++ in the name, really is a different enough language that it will be annoying to work with if you simultaneously have to deal with iso C++.
--
Note: The native windows API is a C api, not a C++ framework. So it does not provide a rich set of classes in a coherent framework to deal with. On the other hand, while, large, it is actually quite simple to work with.
Also: Given that you are already familiar with Mac development, there is a LGPL (iirc) package called CFLite that builds on windows and that implements the C api that underlays the Objective-C Cocoa API.
If you use its abstratcions you can share a greater part of code between windows and Mac (and other platforms).
Other C++ IDE's you might want to consider:
Code::Blocks
QT Creator
both of which can be configured to use the MINGW port of GCC to windows.
you'll be better off with c++ than c# if you need more "low-level" stuff. Loading dlls (that is, libs) is simple (pragma comment lib...), as is pure HTTP transfer and communication.
So, VC++ with windows form will suffice, and it is "very c++".
You have access to all global APIs, and loading specific apis like http requires only two lines: one to include wininet header, and other lib (libs are actually "references" to dlls).
If you go the C++ Express way then you need to install Windows SDK separately, and set it up for Visual Studio to use it. And you can't use MFC.
I would however, suggest C#, because it feels like putting little toy bricks together. Easier to debug and maintain. Problem with C# is that it has so many library functions that you can not possibly know if what you want is already made to a function. But that's why we are here :-) If you feel that something you want to do should already exist then ask a question about it. One notable feature that C# lacks is zip archives (it has something similar, but not quite). For zips you can use public libraries, like SharpZipLib or DotNetZip.
If I were you, I wouldn't jump into a whole new API so quickly. Have you considered using Python on Windows? Most of the Python packages I've seen are also available for Windows, so you'll feel at home. And if you need some GUI, you can opt for wxPython, pyGTK or something similar.
For Windows specific things, you can always use ctypes. Especially if they're as simple as loading a DLL.
have you considered approaching Adobe AIR? it allows you to deploy on Mac, Linux, Windows, iOS, etc. communicating with and launching native processes has been possible since 2.0 and the the latest 2.5 SDK can target Android OS and TVs. with your experience you should be able to pick up ActionScript3 / MXML in no time.
additionally, there are a handful of free IDEs you can use with the Flex and AIR SDKs. or, if you're a student or low-income developer, you can get a free copy of Flash Builder 4 from Adobe: http://www.adobe.com/devnet-archive/flex/free/
edit: i believe deploying AIR applications on iPhone requires Flash Professional CS5, which includes the packager for iPhone options. at the same time, i've read that AIR and other cross-compilers for iOS are painfully slow, so it's perhaps best to develop natively in Objective-C for iOS.

Resources