VNC: Translate Qt KeyEvent to usable X11/RFB keysym - windows

Background: I am currently in the process of creating a simple VNC viewer embedded in a QWidget for use on Windows. For this, I compiled the Qt-only VNC version of KRDC (remote desktop viewer for KDE) as well as its dependency libvncclient on windows. The problem which arose now however lies in the way krdc sends key events over vnc: it simply sends the value of QKeyEvent::nativeVirtualKey(), which on X11 is conveniently already a valid RFB keysym. On Windows however, this is not the case.
Now, to solve this problem, I think the best (and ultimately also portable) way is to translate Qt's QKeyEvent::key() and ::modifier() data back to valid X11/RFB keysyms. This seems somewhat complex though given that I need to pick different keysyms depending on modifier state (XK_a vs XK_A, I've only considered shift so far) as well. Looking into how X11 -> Qt translation is done in Qt's source code didn't really help either.
Might there already be a library or code snippet out there which accomplishes this? Or should I just attempt to write my own (incomplete) translation routine? If so, what would be the best way to go about this and also, are there other caveats related to X11 I should be aware of?

Well, seems like I'm actually blind; there was a reference in krdc's code, right below the e->nativeVirtualKey() statement, referencing another project's class where they encountered the exact same problem as me:
// hmm, either Win32-platform or too old Qt so we have to handle and
// translate Qt-key-codes to X-keycodes
I didn't test their solution but it seems solid. As I only discovered this now, I have already written a small routine myself which should work ok for most latin keyboards (but will probably break if the Qt team changes any of the Qt::Key values), if anyone is interested in it: link

Related

Lightweight X window library

I'm wanting to port a windows program I'm working on to linux. It entirely uses d3d11 to draw it output so I'll need to write an opengl alternative. That's fine. But I need to create a window and a few basic operations like resizing, setting fullscreen, getting notified of user keyboard and mouse input, and close and resize notification.
I won't require any child windows, or controls as everything is drawn by opengl.
So what is an appropriate way to do this? I looked at raw Xlib but it seems quite low level. I'm prepared to learn it but all the examples seem really old so I'm not sure if it's still the best way, plus will doing that work with whatever environment the user had (kde, gnome etc...)?
I could use qt, kde etc, but they are far, far more sophisiticated than I need for this so introduce a large dependency that I'd rather avoid if possible.
So, is Xlib an appropriate technology for this, or is there some other lightweight library I'm not aware of?
Look at SDL. It's pretty much the standard choice for applications like yours.
It looks like GLUT could suit your needs.

Is it possible to view the source of a mac app?

Would be usefull to see how things work but not sure on the legality of it
Most Mac apps are written using Cocoa in Objective-C; which, while it is a compiled language, means that there is a fair bit of information left over that could be used by a decompiler.
I'm not sure if there are a lot of decompilers out there that leverages this information, at least I haven't heard of any.
However, there are also another option; F-Script.
F-Script can be used to attach to an executable and explore its interfaces, while not as good as source, it can give you a pretty clear idea of how the executable is built, and how it operates.
As for the legality issue:
IANAL, but as far as I know, reverse-engineering for the purposes of compatibility is legal in many jurisdictions, and I can't imagine that decompiling an executable to look at its code is illegal, unless the specific EULA specifically prohibits it.
Edit: WRT Steam specifically, it is probably NOT written in Cocoa, but C# with some manner of .NET compatibility layer; and it's probably not a good place to start if you want to learn how to make applications for Mac OS X.
By far, the best Mac OS X disassembler I've used is Hopper available here:
http://www.hopperapp.com/
It will also convert the assembly to C pseudo code as best it can. It will generate code flow diagrams with blue lines (true blue, love it) for true and red for false paths.
It's The Mac OS reverse engineering tool. There are even Youtube videos that will show you how to use it.
If it's an open-source app, yes. Otherwise it's possible through decompilation but the output will be a real pain in the ass to look at. If you just want the protocols and the interfaces of categories and classes, have a look at class-dump.
I'm not aware of a nib decompiler.
Whether decompilation is legal: ask a lawyer. This may (and probably does) differ per jurisdiction.
Is it possible to view the source of a mac app?
Realistically, no. Sure, you might be a able to use a decompiler to get a peek, but the kind of output you'll get won't be easy to read. If you're asking this question, this route probably isn't going to be helpful to you.
Specifically interested in GUI and how the steam app for mac works
It's a good bet that it works about the same way that most other applications work. It might use custom controls to look different from a typical application that mostly uses the standard Cocoa controls. But underneath, just about any GUI application written for MacOS X will use the run loops, responder chain, and view hierarchy that Cocoa provide. The main exceptions would be applications that are built mostly using an alternate framework like OpenGL or WebKit.
Figure out what, specifically, the Steam application does that you'd like to do. Take a look at the tools that Cocoa provides to see if you can figure it out yourself; if not, ask about it here.

Creating a minimalistic MSHTML-based window

I have a library for Haskell that can take an ordinary web application, run it on a local server, and then open up a window displaying that application using QtWebkit. The code to interface with Qt is very short. However, I would like to avoid the Qt overhead for Windows users.
It seems like the best approach would be to have an alternative to this QtWebkit-based C++ file that instead uses the MSHTML library on Windows. Unfortunately, I have almost no experience with Windows-specific libraries. It seems like I need to use the IWebBrowser2 interface, but that seems mostly speculative.
If someone can point me in the right direction on this, I would be much obliged. The final trick here is that it has to compile with MinGW. Not sure how much of a complication that is in this case.
Thanks
You can use hdirect to call the IWebBrowser2 interface from Haskell. It's messy to code against OLE/COM but it can do the job. Making a C binding to the interface is possible but if you need MinGW then it may actually be harder than a purely Haskell approach.

Capture sound output on mac

I am trying to port my screensaver from windows to mac and one of its features was reacting on system sound output. On windows it was easy using Direct Sound, but I can't find any example of capturing sound output on mac. Is it possible even possible without writing something like kernel extension? Using flash it is also very easy — it even gives computeSpectrum method to get raw data or even fft transformed data.
All programs that I have already found use Soundflower or their own kernel extension. But I don't think that asking to install separate program or using kernel extension is a good way.
One thing you can do, considering that Soundflower is open source, is take a look at how they did it. You can't copy & paste GPL code, but you can surely study the techniques used and create your own solution (point you in the right direction).
You won't find Apple being very helpful here. Sound capturing, in this manner, can be used for all kinds of nefarious purposes. I'm not even sure if Core Audio lets you do this without hacks. In any case, you have a working implementation of what you're trying to accomplish. I'd take advantage of it.
I'm not on my Mac right now, but I'm pretty sure that Quartz Composer has a patch for just this thing. Depending on what language you're writing your screen saver in, it may be fairly easy for you to port your code into a QC patch. Well... it probably won't be easy, but it may be doable.

Common Lisp GUI Programming With System Calls

Can anyone tell me about using (Steel Bank) Common Lisp for writing GUIs via system calls? I know there are some libraries out there but this is a language learning exercise, so I want to do it myself.
I'm developing on Kubuntu 8.10 and SBCL 1.0.18.
Thanks.
You can take a closer look at the sb-posix-package. But as the page sais "The functionality contained in the package SB-UNIX is for SBCL internal use only; its contents are likely to change from version to version."
Another Possibility - the one I would choose - is to include the C-syscall(2)-Instruction via CFFI, and then perform it.
To create a windowed GUI, you must use X11, at least to give you a Window to paint on. Therefore, you must know the X11-Specifications to create a window, and implement the Syscalls for accessing Unix Domain Sockets, or initiating shm-devices etc.
If you just want graphics on a console, you could think of using the framebuffer-device /dev/fb*. You need ioctl(2)'s and the syscalls for read(2)ing and write(2)ing to use it, but still, I think this would be a lot easier than using X11 for this (even though still a lot of work). Maybe you shoudld look at the sourcecode for libFB or something similar to see how to initialize it, etc.
Is this really what you want to do? This is a lot of work, you will learn a lot, but more about the linux system infrastructure, rather than about SBCL, I think. If you want to use Syscalls under SBCL, maybe its better to try to open TCP-Sockets only with Linux-Syscalls - alone this can take hours of frustration.
By writing GUI via system calls you mean not using any GUI toolkit such as Gtk+ or Qt? In such case, you should talk directly to the X-server via socket and implement all the X11 protocol (or use CLX) and GUI on top of it. But that is not an easisest task, because X11 is complex.
In case you decide to dig into X11, there are some links for specifications: http://www.xfree86.org/current/specindex.html
http://www.freedesktop.org/wiki/Specifications?action=show&redirect=Standards

Resources