I would like to have GUI window without window decoration (title bar, borders, etc...).
I use wm overrideredirect set to true, but then window manager doesn't see my application and it is not shown on taskbar or under alt+tab switch in Windows7.
Is it possible to have window without decorations but seen as normal application in window manager?
Unfortunately, you can't. Setting the overrideredirect flag basically puts the window outside the control of the system window manager — it's how things like menus and tooltips actually work under the covers — and it is system policy that known windows have decorations.
There are a few slight exceptions that you might be able to enable in some circumstances with wm attributes:
You can run in full-screen mode with wm attributes $w -fullscreen 1
You can tinker with wm attibutes $w -type to find something that has the effect you want, but only on Unix (it's a platform-specific feature).
I suspect neither applies to you.
Related
Is there a way to remove the option to minimize the application or maximize it, in pygame?
To not make it able to be resized, only add your dimensions to the pygame.display.set_mode function. Do not add options. If what you mean by "removing the option to minimize the application or maximize it" is get rid of the button altogether, you can't do this. When you create a window in pygame, pygame creates a window with whatever window api is for your platform. Pygame doesn't get to decide how your window should look (menu-bar/options). This is why windows in macos and linux look different from windows in windows. To recap, you don't get to chose how your windows look. That's the job of whatever window manager api your system uses.
screen = pg.display.set_mode((width, height), pg.NOFRAME)
Im using the MIPs Mars 4.5 and Im trying to find out how to increase the size of text such as the menu bar etc.. Not the editor but the program itself.
Thanks
While there's no way within Mars to explicitly set the scaling, if you have a high dpi display and have everything in Windows scaled up, Windows' built-in compatibility can fix this.
The runMARS.bat calls javaw.exe -jar Mars4_5.jar
Assuming you've got java in your PATH...
Navigate to C:\ProgramData\Oracle\Java\javapath
Right click on javaw.exe, -> Properties
In the Compatibility tab, check Override high DPI scaling behavior
Select System for Scaling performed by
Now, running Mars with runMARS.bat will start it with proper scaling.
If java isn't in your path, do the above steps for whichever executable Mars4_5.jar is using. If you're not sure, the which javaw command might come in handy.
Also, Java9 properly supports hidpi screens, so this won't be a problem.
open mars,
1.click on settings -> editor...
2.select the font-size that you want
3.click on apply
I am looking for an equivalent of AdjustWindowRect function that allows to get widths/heights of window caption and borders.
Do we have this functionality in GTK 3 at all? Seems like not.
I've looked through all gtk_window_xxx, gtk_widget_xxx and gdk_window_xxx* functions...
Update:
In principle I am able to determine window-chrome/decoration dimensions as a delta of gdk_window_get_frame_extents() and gtk_widget_get_allocation() / gdk_window_get_origin() but
it works only after window appeared on the screen. I need it before that - to calculate initial window position.
it is really a hack.
It's up to Window Manager to decide.
You can request it by sending a message _NET_REQUEST_FRAME_EXTENTS as explained in the specification of EWMH (Extended Window Manager Hints):
_NET_REQUEST_FRAME_EXTENTS
window = window for which to set _NET_FRAME_EXTENTS
message_type = _NET_REQUEST_FRAME_EXTENTS
A Client whose window has not yet been mapped can request of the
Window Manager an estimate of the frame extents it will be given upon
mapping. To retrieve such an estimate, the Client MUST send a
_NET_REQUEST_FRAME_EXTENTS message to the root window. The Window Manager MUST respond by estimating the prospective frame extents and
setting the window's _NET_FRAME_EXTENTS property accordingly. The
Client MUST handle the resulting _NET_FRAME_EXTENTS PropertyNotify
event. So that the Window Manager has a good basis for estimation, the
Client MUST set any window properties it intends to set before sending
this message. The Client MUST be able to cope with imperfect
estimates.
Rationale: A client cannot calculate the dimensions of its window's
frame before the window is mapped, but some toolkits need this
information. Asking the window manager for an estimate of the extents
is a workable solution. The estimate may depend on the current theme,
font sizes or other window properties. The client can track changes to
the frame's dimensions by listening for _NET_FRAME_EXTENTS
PropertyNotify events.
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472648576
So, in two words, you send a _NET_REQUEST_FRAME_EXTENTS msg to WM (to the root window - it's gdk_get_default_root_window() in case of gdk), then wait for the reply (_NET_FRAME_EXTENTS PropertyNotify), and get the desired data from your window's _NET_FRAME_EXTENTS property.
Unfortunately situation with GTK is even worse than just problem of getting decorations.
The first:
gtk_window_move(window, x, y) sets border frame position of the window.
And gtk_window_resize(window, w, h) sets client dimensions of the window.
And there is absolutely no way in GTK API to set border frame size programmatically and explicitly. And so there is no way to set window frame position/size of decorated windows.
On Windows and MacOS, using their APIs, that is easy to do, and reliably. But on GTK they only have this:
gtk_window_move(): Begs the window manager to move window to the
given position. Window managers are free to ignore this; most window
managers ignore requests for initial window positions (instead using a
user-defined placement algorithm) and honor requests after the window
has already been shown.
You are correct that the functionality is not there. GTK is agnostic of the decorations that the window manager places on the window; for all that your application is aware of, there may be giant decorations, or there may be none.
What you can do, is use gtk_window_set_titlebar() to tell the window manager to let you use your own decorations; then you have full control over their size.
For what it's worth, AdjustWindowRect() and AdjustWindowRectEx() assume that you are working purely with the default Windows window decorations and, optionally, one row of default Windows menus. It's not suitable for custom window decoration or multiple rows of menus; in these cases, you use the WM_NCCALCSIZE message, which has to be sent to a specific window. DefWindowProc() does all the work for you if you just want the defaults. (Example for multi-row menus. And if you aren't using default Windows menus, then just tell Windows that you aren't; you'll be responsible for positioning everything yourself in this case. GtkMenuBar works on this principle too.)
Since you want the default decorations, though, you merely luck out in that Windows provides an AdjustWindowRect() function in the first place, and that it will work for the default window decoration because it's provided by Windows.
(It is entirely possible for a program to lie in its WM_NCCALCSIZE, but it'd be lying to Windows as well, and Windows does not like a liar. I imagine the same would hold for _NET_REQUEST_FRAME_EXTENTS, though I'm not sure how bad the damage would be in that case.)
So the fact that X11 doesn't have this guarantee that all window managers must follow means you're out of luck in that department. (In fact, I don't think Wayland has such a thing either; does it?) Hell, nothing prevents a window manager from not having window decorations at all. Or you can even not run a window manager in the first place!
In theory, you could compare the size and position of a window (either the geometry of the GdkWindow or the allocation of the GtkWindow) with and without CSD to see what space you lost. But I don't know if this is reliable. A GTK+ developer will need to confirm.
I want to make a Tcl/Tk application that is--mostly--a conventional menus-and-buttons direct manipulation tool, where most of the interaction is through a graphical interface implemented in Tcl/Tk.
However, for certain advanced uses (and debugging), I'd like to have a widget (subwindow) within the main window that contains a Tk console where I can type commands, see output, and otherwise control the application.
It seems easy enough to start TkCon (or wish) and get one top-level window, then create my application interface in a separate top-level window. The application will work fine that way, but I'd like the two windowso be part of the same layout, to move together, to support resizing, etc.
Is there an easy way to do this with TkCon?
I'd also like the TkCon window to be able to display messages that bubble up from within my application (e.g., debug output). Some messages would be generated by Tcl code; others by C code that makes up part of my application. I don't need to capture stdout as such--I'm willing to call a special-purpose function to deliver the messages--but it's not clear what's the most effective way to to get them to display like that.
For tkcon specifically see Donal's answer. I will add however that you can embed the Tk built-in console that is used on Windows. This script is available on non-Windows and can be made to embed into a tabbed notebook page for example.
See tkchat_console.tcl for an example of this - the file loads the Tk console.tcl file and the ::tkchat::EmbeddedConsoleDemo function at the bottom shows how you might use this.
The following code works for me:
set f [labelframe $p.console -text "Interactive:"]
frame $f.test -container 1
namespace eval ::tkcon {
set OPT(exec) {}
set PRIV(root) .tkcon
set embed_args {}
}
option add *tkcon.Use [winfo id $f.test] interactive
package require tkcon
tkcon::Init
This code addse -use option to tkcon toplevel via "X11 options". ::tkcon::embed_args is also vital.
Reading the documentation I only see ways to make it work officially as its own toplevel window. (In particular, tkcon new doesn't take any arguments…) So we're talking a hack to get what you want.
If you've got Tk 8.6 and aren't on OSX (or are using an X11-based build on that platform), you can morph the toplevel into a frame with wm forget and embed that way, but I don't know if the lack of control over the widget name in that case will hurt.
Otherwise, if you've got BLT available I believe that has the ability to reparent widgets. I've never tried doing that so this is hearsay, but it might be able to put a toplevel inside another widget.
Getting more hacky, you could edit the tkcon sources so that you can specify the -use option to the toplevel it creates. That would let you place it in another widget (a frame with the -container option turned on; you'd have to piece things together with winfo id too) but again, it's a bit complex and I don't know what the consequences of doing this are on your platform. This should work on older versions of Tk (it was the foundation of how the Tcl/Tk browser plugin functioned).
Is it possible to create some kind of fullscreen mode (e.g. no window title bar) in Tk applications?
I used to use the wm overrideredirect trick in my code. Recently I found it to be buggy on Ubuntu. Not sure why, maybe a gnome issue, maybe a glx issue. Currently I'm using:
wm attributes . -fullscreen 1
which so far works on Windows and Linux. Haven't tested on Mac although I don't see why it wouldn't work.
OK read the man page. It says it works on Windows, OSX (Quartz) and X11.
Additional info
for those who didn't believe me
The man page says:
-fullscreen
Places the window in a mode that takes up the entire
screen, has no borders, and covers the general use area
(i.e. Start menu and taskbar on Windows, dock and menubar
on OSX, general window decorations on X11).
which seems to imply that the window decorations (title bar etc) is removed in -fullscreen mode. And in my real-world experience (I just checked my code 2 seconds ago) that seems to be the case on Windows and Ubuntu (linux). Don't know if it's true for OSX but the man page says it should be.
If this is ever not true on any platform then I believe it is a bug in the documentation. In which case it should be noted in the man page clearly on which platform are window decorations not removed.
Yes. You wan to set the overrideredirect flag on a toplevel.
toplevel .top
wm overrideredirect .top 1
If you run this interactively you need to withdraw the window and them deiconify it so that the window manager has a chance to remove the frame from the window.
This only removes the window manager decorations. You need to manage the size as a separate step in the normal way.
For more information see the man page on the wm command