I want to create a widget in Mac OS X that exists on the desktop background rather than the dashboard. The widget will be interactive (the widget will be able talk through text boxes when the user clicks on it, similar to Clippy) and I need it to be floating (always been on top of all windows). The widget should also be able to be flexible- by this I mean it can change shapes (i.e. how Clippy always moves). It should almost be like a character from a game on the desktop.
I have absolutely not idea how to do this, nor do I could I find any resources that instructed me how to.
Does anyone know how I could create an interactive widget on the desktop background on all major versions of Mac OS X (i.e. Snow Leopard, Lion) that floats using either C++ or Obj-C? (C++ is much more preferable)
Borderless Windows, and HUDs can be used to simulate a widget by creating a transparent, floating window.
For more info, refer to: How to create transparent notification window?
Related
I've been weighing the pro's/con's of making a gui app, and I've decided a console app is much more powerful for my calculator, especialy since it does different things like foil, quadratic equations, etc. So my question is make the console look like a gui based app?
The answer to your question depends on exactly what you mean by "console." If you're talking about Windows console windows, then the answer is "maybe." Some Windows installations can emulate VGA/EGA graphics within a console window, making them able to play old games for DOS.
Your mission would be to implement every GUI widget you need, such as clickable buttons, text-entry fields, etc. in terms of simple graphics primitives for drawing lines and rectangles. Then you have to write code that figures out where the mouse is and draws the mouse pointer in the right spot. You'd also have to write code to make the cursor blink, to make the arrow keys move the cursor, and to make it possible to select characters in a text entry box and copy, cut, and paste them.
When you got done, you'd have a program that works on some people's computers, but not on others. On some Windows installations, the console windows can't do graphics or go fullscreen. Your app wouldn't work at all on those systems, although you could write a fullscreen Windows app using a 2D game library such as SDL or Allegro instead of writing a console app, which would bring you back to the previous paragraph.
As you might have guessed by now, rolling your own GUI would be a whole lot more work than writing a Windows GUI program in which the buttons, text fields, etc are already implemented for you, the cursor already blinks, the mouse already clicks, etc.
Also, the code that does the actual calculations should be totally separate
from the code that gets the input from the user and puts the answers on the screen, so that code shouldn't factor into whether you want to write a GUI or a console app. They shouldn't even be in the same .cpp file as the I/O routines.
Now, some programmers use the term "console" to refer to xterm windows on Linux. These are not the same thing at all, and cannot draw graphics (and "console" is the wrong name for them to boot). But sometimes you see menus and stuff within them, "drawn" with colored text. Usually, these are drawn and managed using the external dialog shell command.
I'm writing a desktop. I already know the basics of Qt and GTK+ through Python but I don't understand how to display the finished Desktop. How do you make it the root window of a Window Manager, or is there a method for displaying the desktop I'm not familiar with?
You don't make it the root window. X has one root window which you can't change. There are a number of ways to do what you want
X Root window
The old way was that the desktop was just the standard X root window. Icons were just individual borderless windows.
Desktop Window
Now most systems open a large window, and mark it as being a desktop window. Most window managers then know never to raise it above any other windows. The X root window is still behind it, but it is hidden. This means you can do anything you want on this window, draw to it, include icons or widgets or anything else your toolkit can do.
If you are using Gtk+ then the relevant information is found in the GdkWindowTypeHint enum, specifically the GDK_WINDOW_TYPE_HINT_DESKTOP. The documentation can be found here: GdkWindow
Compositor
However, there is a newer way that desktops like Gnome3 or Unity use, which is called the Compositor Overlay Window. When a compositor is running there is an overlay window which covers all the windows on the system. It is then up to the compositor to draw the actual contents of the windows on this overlay. However, the overlay can draw whatever it wishes on this overlay window. For example, in Gnome3 when you enter the window selector and the windows arrange themselves into a grid the windows aren't really moving and shrinking, the compositor has just decided to draw them that way. In reality, the windows are still in the same position they were before, but hidden under this overlay.
This is a very advanced way to do things, and certainly not for the novice developer. You probably want to be focusing on the second method.
I know how to make a QWidget (in Qt4 or Qt5) / QWindow (since Qt5) borderless, draw a custom title bar and manually implement mouse dragging to move the window on the screen by simply tracking the mouse position with some mouseMoveEvent and updating the window position.
However, this movement behaves different than the native one as implemented by the window manager. For example, moving the window near the screen's border can be interpreted as "fullscreen" or "split screen"; or windows snap to each other's borders, depending on the system / window manager. These things don't work if you implement the window movement like above.
Google Chrome / Chromium is only one example for an application which implements a custom window title bar and border, while still adapting to the native behavior of the window manager. I'm wondering whether Chrome implements these by itself (and detects the window manager and its configuration) or if there is some functionality in most window managers (clearly, this is still highly platform-dependent) for telling "start native window movement" and "stop native window movement" or similar.
Is something like that possible in Qt? If not, maybe using some other libraries like Qxt?
FYI: I'm mainly targeting Windows and Linux, where I see the difficulty that the user can have any window manager installed.
Based on attempting the same with Qt4 recently, I fear the answer is, you need to tune this per-platform / per-window-manager. I expect patches to QWindow to improve the behaviour in this area would be accepted, but I'm not aware of any standard hook to tell the OS/window-manager what you're trying to achieve.
Equally Qt should be not be 'getting in the way' of solving this, it's simply an area where it can't do anything to help you in a generic way.
I'm not sure quite how to phrase the question concisely, so if there is a similar question, please point me in the right direction and close this one.
I am currently building a CAD app, the user interacts within the 3D viewports primarily through the mouse and the three keyboard modifiers (alt, shift, ctrl). Shift and control modify the currently selected tool options, and alt operates the camera - much like any other 3D CAD app.
However I'm currently developing with a Gnome desktop, and it's window manager (AFAIK) catches any Alt-RightButton mouse dragging events and interprets them as a window drag command - even when not holding the title bar and regardless of the currently highlighted widget.
This is a disaster for me because camera keyboard controls are quite standardised in my target industry. So does anyone know of a way to override this behaviour, preferably from within Qt, and preferably focus it for my one scenario in one particular widget class?
Thank you,
Cam
If you use the Qt::X11BypassWindowManagerHint on the window, then the window manager can't steal your keypresses. However, this means you lose the native window frame (including decoration, moving, and resizing), so it is likely you don't want to do this.
Another way: if your users are only on 1 or 2 varieties of Linux, add something to the installer which asks the user whether they want to manipulate the gnome (or whatever) keysettings, and if so, changes them via gconftool-2 (or equivalent).
I'm trying to figure out how to create a graphical interface, in X11, which exists outside of a window manager's/desktop environment's standard window frame. For example, when Thunderbird finds new mail, it shows a special alert in the lower right hand corner of the screen which is shown without any frame (no close/minimize buttons, etc.).
I'm specifically interested in doing this in QT with C++, but if someone knows a solution with a different graphical library, that would be helpful too.
For QT pass Qt::FramelessWindowHint as a window flag when you construct your top level widget.
See here for more info:
http://doc.qt.nokia.com/main-snapshot/qt.html#WindowType-enum
You can do this with X as well although I haven't done so in a long time.
http://www.xfree86.org/current/XCreateWindow.3.html
With GTK you would use gtk_window_set_decorated(), which would probably be Gtk::Widget->set_decorated() (I think, I don't use gtkmm).
http://developer.gnome.org/gtkmm/unstable/classGtk_1_1Window.html#a67adb1d8051a38e0e5272f141bb8778c