I want to make my own window manager for OS X, or at least give it the appearance of a new one. I have many designs written down in a book, and would like to implement them. These include altering, or even completely removing, menu bars, creating entirely new guis for switching applications, etc.
I know that OS X does not have a window manager, and that basically the functions that an X11 window manager would perform are done by Carbon, Cocoa, the Dock application, and the window server. I've read that it would take an incredible amount of reverse engineering to write my own api, etc. at the hardware level. I am still not that good at programming though, and don't have that kind of time. That's why I was thinking of maybe running an application on top of OS X that will function like a separate window manager - and do everything that the normal OS GUI / window manager would do.
Is this possible? For example: making a custom button that would appear upon a certain key combination, that could be clicked to access a document viewer, change the time, minimize a window, etc. Is there some way to access functionality to basic tasks / actions like this without using the default OS X button controls, and implementing them with my own GUI? I am talking about more than a simple theme change, I want to completely change the user experience. This means that this application would be run in a full screen mode that blocks out default OS X menu bars.
I've heard something about using graphics architectures to plug in your own window manager? Would this be an option too? If so, how would I go about doing that?
Related
I am a noob when it comes to Desktop GUIs. Is there a way for me to programmitically figure out which application window is the top most in terms of display environment?
So, basically, I can have a process running in the background, that might then change the behavior of the top-most (or say the selected) window. My go to operating system would be MacOS (then Linux family). Also, for instance, there is an app called spectacle app, which listens to key bindings to snap resize and move active windows on MacOS.
I use Mac OS X 10.10 and I would like to write a program that looks continuously for a window analyzing all the names of the opened windows. When the windows appear, I would like that the program will look for a button with a specific label and once found it, the app should send it a "pressed message".
I would be able to do it under windows, but I am not so familiar with Mac.
I have found a question related to mine (How do I get a list of the window titles on the Mac OSX?), but I think the most difficult part is finding the button and sending it a "pressed message".
Thank you in advance!
What you are looking for is the Accessibilty APIs. These are mostly Core Foundation style C APIs and typically prefixed with AX.
You might also want to consider additional identifiers beyond window title as window titles are not necessarily unique.
Using the AX APIs is not easy and is extremely verbose. You can use them to explore the UI and find things and interact with them but you might have more limited success observing user interaction. That might require a more fragile combination with event monitoring using NSEvent globalMonitor or CGEventTap depending on the UI widgets involved.
Also note that using the AX APIs to control anything outside your app is not sandbox capable.
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.
We have a Linux based system that does not use a Window manager. When we start certain applications (for instance Firefox) from a terminal window (e.g. Firefox &) we find that no matter what we do, we can't get the application to display full screen.
If we run xrandr, it shows the default resolution is 1280x1024, but when we try to maximize Firefox (by pressing F11) the application is only sized to 1203x650.
Another application that seems to have the same problem is the evince PDF reader.
Our application is not configured to run a window manager (and we don't want to add one), so I'm wondering if there is something else that we can do to get these applications to render full screen.
Thanks...
Although you don't want to use a window manager, you might need to use a window manager.
I haven't dug into the X server sources around this, so I can't definitively say X requires a window manager to run properly. But as somebody who writes X client code, and hacks the X server, on minimalist embedded devices with small screens, low CPU power and no GPU... let's just say, all the major players in that space use one, and have good reasons for it.
If you want to avoid chewing up a lot of disk space, RAM or CPU power doing window management, you should check out matchbox. It's a low-footprint window manager designed to meet those criteria, and it's what many folks in that minimalist embedded space are using. My employer uses it on cell phones, configured so that only one app at a time is visible to the user, and the foreground app takes up the whole screen with no window borders. But you can use it other ways, too - Nokia uses it for their Maemo-based network tablets.
You could use xwit(1) to forcibly resize and place the windows. But as as far as I know, X11 in itself does not have the concept of a "maximized" window; the very idea is only added by most window managers and/or applications (like Firefox).
Does passing the "-geometry=1280x1024+0+0" option to Firefox help?
Oh, also... if you don't explicitly set a window manager, you might be unexpectedly falling back to the default X11 window manager. If you're not absolutely positive there's no window manager, you should check into this possibility.
Does anyone know if it's possible to get a Win32 application to run under wine / crossover but have the main toolbar appear as a Mac toolbar (i.e. outside the wine / crossover app)?
What is the "main toolbar"? In Win32, windows do not require a menu bar (ie: IE), or even a main window (!) so this is obviously not possible in general. If you really wanted to, you could send GetMenu() to the first created window, then use (something like? I haven't used the menu APIs much) GetMenuItemInfo() to fill the mac toolbar whenever the app gains focus, but I think this would be a lot of work for an 80% at best solution, not to mention I wouldn't know where to start to integrate this with WINE or crossover.