My application has a GUI, it first reads a initialization file and then decides how many control objects (e.g., wxTextCtrl, wxToggleButton, etc.) need to be added to a wxFrame. When there are too many objects on the wxFrame, some objects are out of visible boundary, i.e., they are on the wxFrame, but user can not see them.
I am wondering whether it is possible to add a vertical and a horizontal scroll bar into wxFrame.
Thanks.
You should not add controls to a wxFrame. The wxFrame can be used to hold windows, including scrolled windows, on which controls can be placed.
Take a look at some of the sample apps in the distribution to see how this works.
Related
I am creating a terminal-based RPG game. Recently, due to issues with the CMD (flickering when refreshing and other problems) I decided to move to curses.
I encountered issues with screen capacity during, say, long dialogues. In the CMD the screen just scrolled automatically - and that is what I am looking for.
My approach was as follows. I have a number of scripts containing classes and functions grouped according to functionality (such as ones pertaining to the board, to the player, NPCs, general utility functions script etc.). All of them also require access to some shared variables and objects; I group those in a shared.py script and subscribe the remaining scripts to it; the portion of that script relevant to the display mechanism looks like this:
shared.py
import curses
sc = curses.initscr()
scr = curses.newpad(1000,1000)
scr.scrollok
And for refreshing I use:
shared.scr.refresh(0, 0, 0, 0, shared.sc.getmaxyx()[0] - 1, shared.sc.getmaxyx()[1] - 1)
But at the moment, when the display fills up, the new content is, I believe, still being dumped into the pad, but is not visible on the display. I could probably come up with a way of shifting the arguments of refresh() so that the bottom line of the display is always coincident with the most recent line added to the pad, but that still only gives me one screen's worth of visibility.
Is it possible to print the contents of the pad into the window in such a way so that the old contents are retained and accessible by scrolling up? Effectively, I want to be able to keep adding lines to my display and as it fills up, I want more display area to be generated and the old content that no longer fits inside the display to move out through the top edge of the display (but for it to still be accessible by scrolling).
What's the best approach to mimic the Windows Explorer navigation bar in PyQt?. Perhaps a list of QComboBoxes as part of a parent class that concatenates the current item of each combo box to resolve the final path?
Is it possible to get a similar look by using stylesheets?
This is the object I need to mimic. I just want a theoretical approach about the best way to mimic it.
Thanks in advance
This is technically known as a breadcrumb widget.
There are multiple approaches to this. The closest emulation to Windows Explorer's behavior--leaving out the normally hidden line editor--involves a chain of widgets like so:
A top level parent QWidget-derived class with your implementation, which would have:
A QHBoxLayout
An arbitrary number of QComboBoxes
A QFileSystemModel from which to populate the combo boxes.
Alternatives
You could use a single QLabels with a series of hyperlinks divided by path separators if you don't care about drop-down behavior. Qt Creator does this.
If your data source is static and not as gigantic as the filesystem, you could use QToolButtons backed by a tree of QAction/QMenus. This is possibly a masochistic approach, given that you have to populate all of the actions and menus. Since that's what they are there for, though, it might be handy as part of a context-sensitive menubar or tab bar.
I was looking for such a widget too without any luck. So I've tried to implement this by myself. It's not finished yet and needs some more work, but here's the first result: breadcrumbsaddressbar.
It's based on QToolButton widgets with menu. Parts of address which don't fit are hidden like in Windows Explorer. Also the widget has auto-completion feature.
Update: there's also a C++ widget QtAddressBar which I have't tried.
I would like to draw some sort of window on top of all the other windows. For example, to display some debugging infos (like conky) or things like a timer.
The main thing is that I would like to able to continue using the other windows while using it (the events go through transparently).
I've tried doing it with pygtk, pyqt and others but can't find a way to make it a real overlay with no event capture.
Is there some low-level x11 solution?
I think the Composite-extension-approach will not work when a compositing manager is running (and thus Composite's overlay window is already used).
Since you explicitly mention "no event capture":
The SHAPE extension allows to set some different shapes for a window. Version 1.1 of this extension added the "input" shape. Just setting this to an empty region should pretty much do what you want.
Some concrete example of exactly what I think you ask for can be found in Conky's source code: http://sources.debian.net/src/conky/1.10.3-1/src/x11.cc/?hl=769#L764-L781
Edit: Since you said that you didn't find anything in Gtk (well, PyGtk), here is the function that you need in Gtk: https://developer.gnome.org/gdk3/stable/gdk3-Windows.html#gdk-window-input-shape-combine-region
You might need Composite extension + GetOverlayWindow request:
Version 0.3 of the protocol adds the Composite Overlay Window, which
provides compositing managers with a surface on which to draw without
interference. This window is always above normal windows and is always
below the screen saver window. It is an InputOutput window whose width
and height are the screen dimensions. Its visual is the root visual
and its border width is zero. Attempts to redirect it using the
composite extension are ignored. This window does not appear in the
reply of the QueryTree request. It is also an override redirect
window. These last two features make it invisible to window managers
and other X11 clients. The only way to access the XID of this window
is via the CompositeGetOverlayWindow request. Initially, the Composite
Overlay Window is unmapped.
CompositeGetOverlayWindow returns the XID of the Composite Overlay
Window. If the window has not yet been mapped, it is mapped by this
request. When all clients who have called this request have terminated
their X11 connections the window is unmapped.
Composite managers may render directly to the Composite Overlay
Window, or they may reparent other windows to be children of this
window and render to these. Multiple clients may render to the
Composite Overlay Window, create child windows of it, reshape it, and
redefine its input region, but the specific arbitration rules followed
by these clients is not defined by this specification; these policies
should be defined by the clients themselves.
C api : XCompositeGetOverlayWindow
PyGTK Solution:
I think the composite and shapes X extensions are sufficiently ubiquitous and shall assume here that they are active on your system. Here's PyGtk code for this:
# avoid title bar and standard window minimize, maximize, close buttons
win.set_decorated(False)
# make the window stick above all others (super button will still override it in the z-order, which is fine)
win.set_keep_above(True)
# make events pass through
region = cairo.Region(cairo.RectangleInt(0, 0, 0, 0))
my_window.input_shape_combine_region(region)
win.show_all()
# set the entire window to be semi-transparent, if we like
win.set_opacity(0.2)
Basically what this does is tell Gtk that other than pixel (0,0) the entire window my_window should not be considered part of itself in terms of event propagation. That in turn, according to my current understanding means that when the pointer moves and clicks, the events go to the underlying window under the pointer position, as if my_window was not there.
Caveat:
This does allow your overlay window being the focus window (due to user-solicited window switching or just because it pops up and gets the focus when your application starts). Which means that for example, keyboard events will still undesirably go to it up until the user has clicked through it to make it lose focus in favor of whatever window is under the cursor. I would likely use the approach described here to iron out this aspect.
If there's a different and proper approach for making a portion of the screen "display stuff but not receive events", without building an oddball window like above over it, I'm happy to learn about it.
I assume that one's particular desktop environment (gnome, unity, etc. on linux) may interfere with this solution depending on version and configuration, on some occasions.
I am trying to create a dockable window in Qt (it sits taking 4px width at the edge of the screen, always on top and it slides out when you hover it). I have to use WindowFlag BypassX11WindowManager (in order to hide taskbar hint, disable moving/resizing/etc. from window manager). I use these flags:
Qt::FramelessWindowHint
Qt::CustomizeWindowHint
Qt::X11BypassWindowManagerHint
Qt::WindowStaysOnTopHint
When I need my dock to be activated, I use the activateWindow() method. However, I have no idea, how to deactivate it.
Is there a way I can force my window deactivate? Now I can do it only by clicking another window and then return to the one that was active before revealing dock.
You should be able to use ->hide() to simply hide it if you don't want it to appear at certain points.
I assume, by the way, you know there is QDockWidget/ class that may help you as well. It's unclear from the above if you're using it or not.
I am using Visual Studio 6.0 (VC++ with MFC) in Windows XP platform. I am trying to create a group box with the title of the group box as a check box. My intention is this: If the check box is enabled, the controls inside the group box should be enabled; or else disabled.
Is this possible to accomplish? If yes, please give me some directions.
Thanks.
There are a few things you can try, depending on how true you want to stay to your idea and how much work you are prepared to put into the effort:
Simple method
Use a normal group box, and then inside this make the first item be the checkbox. This is simple to accomplish, but you lose the goal of having the checkbox as the title.
Funky drawing method 1
Use a normal group box, then in the space over where you know the title is to go, place your checkbox. You will have to perform some tricky calculation to get it to fit in nicely and draw well without flicker.
Funky drawing method 2
Use some form of superclass or subclass/subclass on the group box. You can override the WM_PAINT handler to draw in only the frame for the group box. Place a normal checkbox in the place where you know the title is to go. This should work better because you will have more control over the drawing, but it is likely to be tricky to get right. In my experience, subclassing is lower risk to implement than superclassing.
Are you using the Dialog editor? If so, put down the group box. Next, on top of it, put a check box over the line of the group box. Edit the resource to set the Z order, or do it in code. You want the checkbox to be on top of the group box. Add a handler for the checkbox and enable / disable controls depending on the check box state.
I wrote one called CGroupCheck a few years back and it's available from CodeProject: http://www.codeproject.com/KB/buttons/groupcheck123.aspx