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)
Related
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 create a hotkey to minimize and restore the sublime but even the Main.sublime-menu is undefined !
{
"keys": ["ctrl+shift+w"], "command": "toggle_minimize_restore_window"
}
I apologize if there is a mistake in the text, because my English is not good too :)
Toggling the state of Sublime Text windows is not something that is possible to do at the moment - you can not maximize, minimize, restore, or resize a Sublime Text window using Sublime Text commands. There have been feature requests for this but you can not do it at present.
If you are using Linux, you might be able to achieve this functionality by writing a shell script which uses wmctrl to achieve that functionality and then assign the script to a global hotkey. No doubt there are ways of doing the same thing with OS X and Windows but I do not know what the equivalents would be.
You can try using the built-in window's keystrokes in order to minimize and maximize.
windows key + down (arrow) = minimize the window.
windows key + up (arrow) = maximize the window.
You can try with Mac with Command.
If you want to minimize for a customized position, you can detach the tab adjust it as you wish. Next time you minimize the window, it will appear in this last position you set.
I have an adobe AIR app. When I send some data with a local connection from a web page, I want the app in front of the browser and all the other windows.
I tried with both activate() and orderToFront() but I have no results.
The only script working is:
window.alwaysInFront=true;
window.alwaysInFront=false;
But this doesn't give the focus to the app. So when I click the button on the browser, I have the app on the top, but if I click on the browser the app stays on top until I click on it (giving it the focus) and than I click on the browser window again. It works fine If I click on the browser top bar.
I think that activate() would solve the problem giving the focus to the app, but doesn't work.
Here it is the code (I worked with the native window to resize, minimize and maximize the window too). The function I call from local connection is "primopiano"
import flash.display.StageAlign;
import flash.display.StageScaleMode;
import flash.display.MovieClip;
import flash.display.NativeWindow;
var window = stage.nativeWindow;
function trascina (event:MouseEvent) {
window.startMove();
}
...
function primoPiano (event) {
trace("porto in primo piano...");
//window.activate(); // doesn't work
//window.orderToFront(); // doesn't work
window.alwaysInFront=true;
window.alwaysInFront=false;
}
Did I forgot to import something or do I have to define a different window to do this?
Thanks!
Nadia
Have a look at the Documentation and API Reference
AIR provides several methods for directly changing the display order of windows. You can move a window to the front of the display order or to the back; you can move a window above another window or behind it. At the same time, the user can reorder windows by activating them.
You can keep a window in front of other windows by setting its alwaysInFront property to true. If more than one window has this setting, then the display order of these windows is sorted among each other, but they are always sorted above windows which have alwaysInFront set to false. Windows in the top-most group are also displayed above windows in other applications, even when the AIR application is not active. Because this behavior can be disruptive to a user, setting alwaysInFront to true should only be done when necessary and appropriate. Examples of justified uses include:
Temporary pop-up windows for controls such as tool tips, pop-up lists, custom menus, or combo boxes. Because these windows should close when they lose focus, the annoyance of blocking a user from viewing another window can be avoided.
Extremely urgent error messages and alerts. When an irrevocable change may occur if the user does not respond in a timely manner, it may be justified to push an alert window to the forefront. However, most errors and alerts can be handled in the normal window display order.
Short-lived toast-style windows.
Note: AIR does not enforce proper use of the alwaysInFront property. However, if your application disrupts a user’s workflow, it is likely to be consigned to that same user’s trash can.
I have tried:
window.alwaysInFront = true;
window.alwaysInFront = false;
window.activate();
You could also try with a reference to a display object on the window stage:
displayObject.stage.nativeWindow.alwaysInFront=true;
//(where displayObject is your instance name)
And works fine. I'm using Adobe AIR 4
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