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.
Related
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.
I obviously don't think it would work as it is. Its more like, does Windows internal architecture allows for some third party SW to integrate in between? From what I read about Compiz, I believe it creates its own window, and somehow mixes graphics from System X to its own. But it still has to catch events like EXIT button and so on.
Does Windows even allow this? Let 3rd program to scan for input of another window? And more, catching output of GUI and replace it?
Does Windows even allow this? Let 3rd
program to scan for input of another
window? And more, catching output of
GUI and replace it? Thanks.
It is certainly possible. See WindowBlinds for an example. Just note that Windows "officially" does not support this, applications like WindowBlinds use API hooking, subclassing etc. to perform their deeds.
Windows does not natively allow it - it has its own compositor framework built in called DWM that does much of the same internal functionality as Compiz. However, glitzy graphics that are systemwide are reserved for the OS to perform, sadly. As other people mention, doing this as a 3rd-party app is going to be really hacky and difficult.
API Hooking:
http://www.codeproject.com/KB/system/hooksys.aspx
Also, look at:
http://yodm-3d.en.uptodown.com/
A free 'Compiz' for Windows.
I'm trying to develop a simple program in python (but this is not a requirement, I can switch to another language if worthwhile) and I'd like to make it very usable by elderly people, is there some GUI library already available?
Well, which OS platform are we standing in? If you are in linux or windows and using C# take a look at MonoDevelop. If in linux, I would stick with QT LAF and there's also GTK too.
Now, if I was in your position I would start making prototypes of the program and presenting them to the ederly, survey them through the process and make best of their inputs. It's not an easy task but it will do the work at the end of the process. Keep it simple and don't try to clutter up the ui design.
if your making a seperate GUI for elderly people it's probably best you make it yourself from whatever existing code/libraries you have.
Like increasing the element and text sizes, and increasing the contrast. But not too much that you make the majority feel patronised.
Most GUI libs support some kind of widgets that can be used for people that have some problem with their eyes or such. However, i don't think that there is a library that is particularly targetted to that. Hence, i would use GTK or Qt. In the end, it comes down to how you design your GUI.
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.
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