I'm wondering how to dock / snap a window to the side of the screen in Windows, preferably with straight Win32 API. The effect I'm looking for is like the task bar -- a window that has a reserved space on screen, so that maximizing another window makes that window take up the rest of the screen, but leaves my window in place and visible.
I know various IM clients do this, but haven't been able to find any resources on how to do it. Not sure what the appropriate name for it is either.
Edit: "Application Desktop Toolbar" is the search term to use to find info on this.
IIUYC you're looking for an app bar (MS-officially "Application Desktop Toolbar"). You can indeed create these with the Windows API.
"App Bar" - you turn a window into an App Bar by sending the ABM_NEW message. Examples on MSDN:
http://msdn.microsoft.com/en-us/library/cc144177(VS.85).aspx
http://support.microsoft.com/kb/134206
Related
It is possible to make audio phone calls directly from macOS using the Facetime app and this works very well. Unfortunately a small Window is placed on the top/right counter of the screen and I cannot seem to be able to move or minimize this window. Has anyone an idea on how to customize the location of this window?
You can't move or minimize the window that supports a call, it's a sort of static notification.
More people are annoyed by this:
https://discussions.apple.com/thread/8095870
https://discussions.apple.com/thread/8085443?page=1
You can disable the notification via System Preferences > Notifications > Facetime by unticking "Badge app icon".
I do appreciate the notification to answer the call. Even though my MacBook has a touch bar which also allows me to Answer/End, Video or Mute. Also note the touch bar doesn't sport the button you need when you have to dial during a call ("Select 1 for department A, Select 2 for department B"). So, you'll need the pop-up.
You can kill the pop-up as documented over here:
https://apple.stackexchange.com/a/313721
(somebody even shared a script for the kill command using an Automator Applet)
Don't forget to provide Apple feedback on this. Even though it's been a few years, hopefully they'll find a better solution than the current notification.
https://www.apple.com/feedback/macbook.html
I recently discovered a simple way to hide the call window. Right click on the FaceTime dock icon and click Hide. That's it. You can also move the window by clicking and dragging the waveform area.
I noticed the following feature of the "buddy list" window of pidgin on windows: If you drag the window not far from the top right corner of the desktop, the following things happen:
The appearance of the border slightly changes:
Before:
After:
It docks on the right of the desktop
And here is the most interesting: it reserves the space on the desktop. All other maximized windows are reduced by the width of pigin window. All other windows behave as if the width of the desktop was shorter by the width of the pidgin window
Q: What is the name of the feature implemented by the last point ?
You create custom toolbars that the desktop observes when it calculates the working area with the SHAppBarMessage() api function. Check the MSDN Library page for documentation, it also googles really well to find sample code.
its called docking. Microsoft one-note has the same feature.
My Cocoa app displays a transparent window on the screen, but when the user tries to take a screenshot using Mac OS X's built-in screen capture key with the option of selecting full windows (Command-Shift-4, then Space Bar), my window gets highlighted as part of the possible windows to capture.
How can I tell my Window or App not to allow this? My Window already refuses to be the Main Window or Key Window through -canBecomeKeyWindow and -canBecomeMainWindow both returning NO, but this still happens.
The Window is also at the NSModalPanelWindowLevel and NSScreenSaverWindowLevel does the same thing.
Notice that every window is eligible for screenshots, even the desktop, dock and menu bar, which are special windows. You can even take a screenshot of the Exposé overlay window itself. This leads me to believe that there is no way to do this.
I suppose you could hook the Command+Shift+4 key event and hide the window, but that key combo is user-definable, so it is subject to change.
I have a desktop application written in Ruby that is using GTK2. It's just a small test application to play with GTK2, but I'm having problems achieving what I want to do. Is there any way using GTK2 to get at the titlebar (apart from setting the title), specifically to either add a button to it (beside the min/max/etc, B in the below diagram) or to add an option to the menu that pops up when you click the icon on the titlebar (A in the below diagram)?
I'm thinking there might not be because GTK is meant to work with many many different window managers, but I just wondered if there was. As a side question, what event does clicking the 'cross' button fire? At the moment if the user clicks that the window disappears but the program doesn't end - I need to capture that event and quit the program.
Thanks for any help, including hitting me over the head and telling me how silly I am.
Note that this is possible in GTK 3.10 and up, by using gtk_window_set_titlebar(). It replaces the window manager's title bar with a custom one. GtkHeaderBar is a good custom title bar class to use.
You can't, however, make it look just like the window manager would, because you won't know which window manager the user is running.
No, the title bar is owned by the window manager and you will typically not have direct access to it.
When the user tries to close the window by clicking the window manager's button, the window will receive the delete event.
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.