OS X transparent panels in Qt? - cocoa

Is there a way to create a transparent panel as described by the Apple Human Interface Guidelines in Qt 4.6 (built for OS X 10.6/Cocoa)?
If not, are there any alternatives similar in look and function?
I understand that Qt is a cross platform toolkit, but I want my application to feel as "native" as possible.

I haven't tried on Mac, but this should be possible. Here's what the QWidget docs say:
Creating Translucent Windows
Since Qt 4.5, it has been possible to create windows with translucent regions on window systems that support compositing.
To enable this feature in a top-level widget, set its Qt::WA_TranslucentBackground attribute with setAttribute() and ensure that its background is painted with non-opaque colors in the regions you want to be partially transparent.
Platform notes:
X11: This feature relies on the use of an X server that supports ARGB visuals and a compositing window manager.
Windows: The widget needs to have the Qt::FramelessWindowHint window flag set for the translucency to work.
I imagine your panel is a top-level widget, so make sure to set Qt::WA_TranslucentBackground as directed in the above.

Related

GUI framework to create a Windows app with opacity that can be captured by OBS

The question breaks down into two:
Is it even possible to create a Windows app with an opaque (not fully transparent) background that can be overlayed on top of other sources in OBS? Any examples of such apps?
What I mean is:
If yes to (1), then what GUI frameworks (preferably C++) can be used to reach this? I know for sure that WinUI and WPF can't do it.
Dear GUI, Sciter, Cegui?

Is it possible to keep the Windows' compositor working normally when using a fullscreen OpenGL application?

Under Windows, when the DWM composition is active, there's a somehow "special path" for fullscreened OpenGL applications that prevents all other subwindows (popups, menus, tooltips) to be correctly layered on top of the fullscreened OpenGL window.
While this is useful for games and such, it's totally a pain for other fullscreen OpenGL applications (CAD, 3d editors, etc.). This problem is causing endless troubles for Qt users, see here, here, or here.
Is there a way to tell Windows not to enable the special path for a given application / fullscreen window? Either in the manifest, or via DWM APIs, I don't care.
Yes, this can be done by tricking Windows into thinking that the Window should be composited with transparency. For this you call DwmEnableBlurBehindWindow on the window. In case of a fullscreen WS_POPUP window this makes the window fully transparent (instead of the glass effect) and you can use the window's alpha channel to control the opacity; for a regular window with a title area and border you get the glassy effect then.
Now if you configure the pixelformat without an alpha channel or set the alpha channel to all 1 (full opacity) the compositor still has to assume some transparency may be present and goes through full composition.
Small update
Although WinXP and Win2k are beyond their EOL, it may be undesireable to hardlink the dwmapi.dll to the executable, e.g. if you have to support legacy systems with your software for some reason. For that I wrote a small wrapper library dwm_load that dynamically loads the dwmapi.dll if available or falls back to failsafe implementation of the DWM functions.

How does stylesheets work in Qt?

It is just curiosity. In Windows, for instance, how Qt interprets the stylesheets? this seems to be trivial, but, how does Qt tells the operating system to change the appearance of the widgets? Which library of methods of the Windows API uses? Does WPF uses the same Windows API libraries?
Cheers,
Qt custom draws all widgets. Qt may, under the hood, call into to OS provided API's for rendering each widget but a QButton is not an HWND using the BUTTON window class on windows. Qt does seem to use the OS for rendering text on the widgets but only the glyphs, not the complex rendering available in QLabel for example.

Does Qt Extended Support

I am evaluating Embedded Linux GUI toolkits for an upcoming project and have put together a must have “feature list” to help me with the decision:
Color gradients in graphics (for menu headers buttons, icons, etc…)
The ability to draw complex wave graphics with say a background grid, notations.
The ability to swap between to landscape and portrait orientation.
Qt Extended seems to be a popular toolkit with a wide user base. Can anyone tell me if the above features are available in Qt Extended? Any links to tutorials or documentation would be great!
Yes, either through a custom style, a style sheet or by implementing custom widgets (depending on how exotic you want to get)
Sure, you can draw anything. For what you're after, check out Qwt.
Yes, but you might have to apply some magic of your own here. The screen driver does support this, so it can be done. Also, the Qt for Symbian port does this on the fly, so looking at their solution and then applying it to your scenario might work.

GUI framework for automatic resizing

I want to build a desktop app where the size of both the window and the content is resized automaticly according to the resolution of the monitor. I know it can be done easily with the docking features of .NET Forms, but my customer insists on going with Linux so I can't use it.
I tried Flex & Air, but the content is not resized automaticaly when I put the app in fullscreen or in another resolution (the app goes full screen but I still have tiny buttons). Now, I am looking at Qt and Gtk...
Is there a GUI framework that can do that? I don't care about the programming language.
Also, since the app will go in a bar it would be nice to be able to customize easily the skin. (like in Flex, WPF, etc.)
Regards,
Pascal
An excellent place to start is understanding how the Screen class works: MSDN Even though that is .Net, it will give you an idea of how the screen size, dpi, etc. can be obtained. In addition that information should translate to the Mono platform. Since your client is insisting on Linux, you should look at MonoDevelop and then possibly the GTK# framework. My understanding is that GTK# is not a very friendly (that is pretty) development system (yet).
See:
MonoDevelop
GTK#

Resources