I am using gdm and my goal is to disable user interaction on a specific X window id.
I have tried to change many X-win properties like WM_PROTOCOLS, WM_HINTS, _NET_WM_ALLOWED_ACTIONS using xprop. Although, I was successful to change the properties it looks either wm is ignoring my changes and instead of taking defaults or an xsync(like) step is required to reflect those changes.
Using xprop as follows to change WM_HINTS:
xprop -id 0x6a001f9 -format WM_HINTS 32cbcxxiixx -set WM_HINTS 3,False,1,0x0,0x0,0,0,0x0,0x0
result of xprop -id 0x6a001f9 WM_HINTS [BEFORE]:
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
result of xprop -id 0x6a001f9 WM_HINTS [AFTER]:
WM_HINTS(CARDINAL):
Client accepts input or input focus: False
Initial state is Normal State.
Apart from property type, which changes from WM_HINTS to CARDINAL, everything else is as expected but still, window # 0x6a001f9 receives input.
Output of xwininfo confirms that:
xwininfo -id 0x6a001f9 -wm ====>
xwininfo: Window id: 0x6a001f9 "Log Attribute Selection"
No window manager hints defined
Window manager hints:
Displayed on desktop 0
Process id: (unknown)
Frame extents: 4, 4, 24, 4
What am I missing?
update: check this comment, it has the code that works here! https://gist.github.com/muktupavels/d03bb14ea6042b779df89b4c87df975d#gistcomment-3331569
unfortunatelly I cant comment... but this may help (one day when it is ready).
I have exactly the same problem:
https://unix.stackexchange.com/questions/590282/how-to-prevent-input-focus-for-a-single-window-in-gnome-shell-window-manager
I tested your command, it gives the same result, the window hint changes but it still receives input focus...
I guess we need to remove the WM_TAKE_FOCUS protocol then, but to do that may be complicated.
I think we could join forces to tweak this small code to let that happen:
https://gist.github.com/muktupavels/d03bb14ea6042b779df89b4c87df975d
I am still trying to understand it to see where/what to change there.
This may be the only answer if we manage to tweak that code.
obs.: what you did with xprop, may be if done with that gist code could work, it is like xprop cant change some things but can change others (like window title). So, it may be more simple as there is code there already to change window hints!
Related
When decompiling an app, I find lately, that a few apps' manifests do not seem to have designated activities for the view I want. For example, if com.example.app is on the view I want and I run the following command:
dumpsys window windows | grep -E 'mCurrentFocus|mFocusedApp'
the resultant output will be something like:
mCurrentFocus=Window{9280f2a u0 com.example.app/com.example.app.MainSubMenu}
mFocusedApp=AppWindowToken{da37759 token=Token{9d56fa0 ActivityRecord{5c490a3 u0 com.example.app/.MainSubMenu t98}}}
This is fine, but when the screen I am on is obviously a subactivity/subview/fragment, dumpsys nor logcat will show me the full path to this view. In short, I would like to find the name of the fragment/view and launch directly to it. This syntax looks promising for achieving a fragment view launch (perhaps with some variation):
am start -n com.example.app/.MainSubMenu -e :android:show_fragment com.example.app.somefragmentview
but I am unsure of how to find all fragment names for each activity of the app.
I ended up using AutoInput in combination with MacroDroid to select specific elements of the app's main (launch) screen, based on text. This gets me to any screen of an app without having to rely on touch event coordinates, since developers of these apps typically switch up menu item locations with subsequent updates.
Here is the AutoInput process in detail (which I imagine can be integrated with Tasker as well):
Install both aforementioned apps.
When selecting an Action for MacroDroid, choose the 'Locale/Tasker Plugin' option. This will list AutoInput's options, and any other options for different plugins you've downloaded, I suppose.
Choose the 'AutoInput Action' option from the list.
Select 'Action' from the next screen, then 'Click'.
For 'Field Type' choose 'Text', or any other piece of information you know about the menu/button/element that you would ordinarily select to get to the screen you want. We are talking about a menu/button/element that exists on the main (launch) screen of your app.
Fill in 'Field Text' with the menu/button/element's text.
Hit the checkmark at the top right when you are finished, and it will return you to MacroDroid.
A few notes:
The menu/button/element MUST be visible on the main (launch) screen for AutoInput to identify and select it. The initial menu item I was attempting to open could only be reached by scrolling down first. To remedy this, I told MacroDroid to run a script with an 'input swipe' command first to make the menu item visible.
If your target menu/button/element is not on the main (launch) screen, you will have to follow up your initial AutoInput Action with subsequent AutoInput Actions until you reach the menu/button/element/screen you want. The screen I wanted was twice removed from the main (launch) screen.
Maybe it goes without saying, but I separated each AutoInput Action with an appropriate pause (in MacroDroid, Actions-->'Wait Before Next Action') to select each menu/button/element while accounting for screen load time.
This is all a bit obtuse, I realize, but without knowing how to extract the (has extras) information from Logcat, this was the only available solution that didn't force me to rely on coordinates for touch events. Hopefully this offers a viable alternative until someone finds/offers a way to pull raw extra data from activities.
UPDATE3 - SOLVED with reservations, please see my solution below; leaving it open since the cause of the problem is unclear, and I don't know how robust the solution is.
UPDATE1: here's the short short version.
Currently, after .setEditText on a QComboBox, I get this:
so the next thing you type will overwrite 'Team '.
But the desired effect is this (unhighlighted / unselected), so that the next thing you type will be appended to 'Team ' instead of overwriting it:
Thanks for any help. The rambling details are below, which is the original post:
(this is all PyQt 5.4)
UPDATE2:
Apparently python doesn't think anything is actually selected:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:" and nothing else. To make sure that's working:
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(0,4)
print("selected text:"+self.entryForm.ui.teamField.lineEdit().selectedText())
prints "selected text:Team"
So that might be why many of the methods that affect selection are not working as expected (.deselect(), .setSelection(5,5), etc, and even some of the other methods give unexpected behavior, i.e. cursorForward(False,1) or cursorBackward(False,1) and such.
Original post:
This is for a radio log GUI, so keyboard interactions must be minimal and intuitive. openNewEntryForm (below) is called as a slot from a pushbutton on the main application GUI window:
self.ui.pushButton.clicked.connect(self.openNewEntryDialog)
It can also be called using a keyPressEvent in the same class:
def keyPressEvent(self,event):
if type(event)==QKeyEvent:
print("QKeyEvent:"+str(event.key()))
if event.key()==Qt.Key_T:
self.openNewEntryDialog('t')
event.accept()
else:
event.ignore()
Here's the method in question:
def openNewEntryDialog(self,key=None):
self.entryDialog=newEntryDialog()
if key=='t':
self.entryDialog.ui.to_fromField.setCurrentIndex(1)
self.entryDialog.ui.teamField.setFocus()
self.entryDialog.ui.teamField.setEditText("Team ")
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues()) # adds the log entry
so, the intended key press sequence is (from the main application GUI window):
a single keyboard press of 't' will open the entryForm, set the to_fromField to index 1 (which happens to be "TO"), give focus to teamField (also a QComboBox), set its text to "Team " and set itself up so that the very next keypress will appear as the text following "Team " in teamField.
So, starting from the main app GUI again, the plan is that typing 't3' should open the new entry window, set the to_fromField to "TO", and set the teamField to "Team 3", ready for a keypress of the tab key to move on to the next field in the entryForm.
The problem is that the teamField.setEditText("Team ") call leaves all of the text highlighted/selected, so that a subsequent key press of '3' would replace "Team " with "3"; I'm looking for a way to unhighlight/unselect "Team " but leave the cursor active at the right of that string, so that the subsequent key press of '3' would make the entire string "Team 3".
Ideas? Thanks in advance.
You can access the line-edit of the combo box, and then remove the selection:
self.entryDialog.ui.teamField.setEditText("Team ")
self.entryDialog.ui.teamField.lineEdit().deselect()
UPDATE:
The above code is correct, but it seems that the dialog will then clobber it when it initialises the focus handling for its child widgets after it is shown. If a dialog is opened with exec(), it will start its own event-loop, and some events (including focus events) will only be processed after it is fully shown. This is why it may appear that some changes made to child widgets before the dialog is shown are being ignored.
One way to work around this is to use a single-shot timer to ensure the changes are only attempted after the dialog is shown.
So add a method to the entry dialog class something like this:
def resetUI(self, key):
if key == 't':
self.ui.to_fromField.setCurrentIndex(1)
self.ui.teamField.setFocus()
self.ui.teamField.setEditText('Team ')
QtCore.QTimer.singleShot(0, self.ui.teamField.lineEdit().deselect)
and then use it like this:
def openNewEntryDialog(self, key=None):
self.entryDialog = newEntryDialog()
self.entryDialog.resetUI(key)
if self.entryDialog.exec_():
self.newEntry(self.entryDialog.getValues())
SOLVED with reservations, see UPDATE3 in the original post.
So, with the initial text all highlighted, tests show that it didn't actually think anything was selected. This solution was just stumbled upon by trial and error, fiddling with setting and clearing focus, selecting text and trying deselect:
def openNewEntryDialog(self,key=None):
self.entryForm=newEntryDialog()
if key=='t':
self.entryForm.ui.to_fromField.setCurrentIndex(1)
self.entryForm.ui.teamField.lineEdit().setFocus()
self.entryForm.ui.teamField.lineEdit().setText("Team ")
self.entryForm.ui.teamField.lineEdit().setSelection(5,1)
Notice there are two spaces after 'Team' and the second one is intentionally selected. Then the very next keypress will overwrite that second space; that is basically the desired behavior.
Anyway it looks like something bizarro with the selection scheme; one way to look at this is that the highlight isn't really a selection, but, if you set a valid real selection then it will override the original highlighted 'pseudo-selection'. The original highlighting behaves like a selection in that a keypress will replace everything that's highlighted, but, not like a selection in that the selection methods reveal that there is no 'selection', see UPDATE2 in the original post.
Can anyone help explain this behavior? I'd like to build some more confidence in it before accepting this coincidental answer.
Thanks
When saving a figure, what function does Matlab use? For example, when a user selects File > Save As... and then selects .png or another image format, what is going on behind the scenes?
I am asking because I am trying to automate saving, but when I use saveas or print, the resulting image is really pixelated. However, the image looks really good when I save the figure using the method described above.
What method should I use to save my figure from the command line? The actual method that the figure window uses would work, but if you guys have better solutions, I'd appricate it!
The callback for the "Save As..." menu item invokes the function FILEMENUFCN with the first input argument being the handle of the figure the menu is in and the second input argument being the string 'FileSaveAs'. If you have the figure handle stored in the variable hFigure, then the following command should be equivalent to clicking the "Save As..." menu item in that figure window:
>> filemenufcn(hFigure,'FileSaveAs');
A few notes...
The function FILEMENUFCN is only partially documented. You can do help filemenufcn in the command window, but there is no entry for it in the online documentation. In MATLAB 2009a, the function can be found in the following folder:
C:\Program Files\MATLAB\R2009a\toolbox\matlab\uitools\filemenufcn.m
Looking through the function code, it appears that it ultimately calls either the function SAVEAS for .fig files or the function HGEXPORT (with additional input arguments) for other file types.
I was able to hunt down the callback for the "Save As..." menu item by searching through the children of the figure window and its menus. You can do this yourself by setting the root property 'ShowHiddenHandles' to 'on' and then traversing through the 'Children' properties of the figure window and its menus using the GET command. An alternative is to use the FINDALL command, assuming you know some properties of the objects you are looking for. For example, this will find the handle to the "File" menu for the current figure window:
>> hFileMenu = findall(gcf,'Label','&File');
And this will find the handle to the "Save As..." menu item and display its callback:
>> hSaveAs = findall(hFileMenu,'Label','Save &As...');
>> get(hSaveAs,'Callback')
ans =
filemenufcn(gcbf,'FileSaveAs')
I don't know about you, but for me the saved image looks nice.
Code example:
... create some figure ...
saveas(gcf, 'some_figure.png');
To set a user specified resolution use:
print(gcf,'some_figure','-dpng','-rSOMENUMBER')
where SOMENUMBERis a parameter used for the resolution.
The final resolution is (SOMENUMBER*8) x (SOMENUMBER*6)
Inital Problem: to have no scattered windows when I use vspilt in Vim inside Screen
Attemps to solve the problem:
Impossible: to increase the Display Refreshing Rate for Mac's terminal code
to add something to .Xresources
alt text http://dl.getdropbox.com/u/175564/bugWithScreen.png
Unix Power Tools -book says that the problem can be solved in .Xresources.
However, it does not specify exacly how.
I have collected the following codes to my .Xresources
mrxvt*scrollBar: true
mrxvt*loginShell: true
mrxvt*syncTabTitle: true
mrxvt*font: Monaco
mrxvt*faceSize: 11
mrxvt*xft: True
mrxvt*xftFont: Monaco
mrxvt*xftSize: 12
mrxvt*xftAntialias: True
mrxvt*termName: xterm-256color
XTerm*VT100.metaSendsEscape: True
# translations used to coordinate xterm with xcilpboard
# Unix Power Tools: p.117
*VT100.Translations: #override\
Button1 <Btn3Down>: select-end(primary,CUT_BUFFER0,CLIPBOARD)\n\
!Shift <Btn2Up>: insert-selection(CLIPBOARD)\n\
~Shift ~Ctrl ~Meta <Btn2Up>: insert-selection(primary,CUT_BUFFER0)
Is this occurring when you run Tlist, or when reconnecting to a previously opened session?
If it's the latter (and your window size varies), it may be because of the options screen was launched with. Try launching screen with these options "-aADR". "-a" and "-A" will force screen to redraw upon reconnection.
Parsing of ~/.Xresources is done when the X11 server is started, as part of the X11 session init scripts. If you edit ~/.Xresources then you need to use xrdb(1) to load in the new file to tell the running X11 server about the changes.
BEWARE that xrdb(1) will, by default, replace the current resources instead of overwriting them and read from stdin is the default, so don't invoke it with no parameters! So you want to use
xrdb -merge ~/.Xresources
to load the changed file in. You can use
xrdb -query
to see what's already loaded.
For the Mac, I don't know what, where or when, might be looking at ~/.Xresources; because the X11 stuff is a program run to use the display, rather than the master of everything graphical, it might be rather minimal and not doing so by default. xrdb -query will help.
One thing that might help is to instead set XAPPLRESDIR as an exported shell variable; there's some knob somewhere in MacOS to set environment variables as a session thing, visible to all programs without hitting the user shell, but I forget where (found it when setting up the SSH Keychain once). XAPPLRESDIR is an env variable variable to point to a user's own overrides of application resources. It's value should be a directory ($HOME/share/xapps/ for instance). Every X11 application linked against the X Intrinsics library (libXt) will, at X11 init time, look in that directory for files matching the application class name. This way, you don't need to worry about loading resources, etc; edit the app file, start the program.
So resources for xterm go into a file XTerm, etc; to find out the class of an arbitrary program, you might use xprop(1) with no arguments, click in the target window while the pointer is a cross-hair and then look at stdout from xprop for the WM_CLASS property. For some older tools like xterm you can also use editres(1) to be able to interactively view the widgets of a running X application via remote inspection; there's a Get Tree menu item, to let you click on the target app and another menu item to show the class names.
Myself, my ~/share/xapps/XTerm file sets the menu background colour to a hideous yellow; that way, when I control-<left|middle|right>-click in an XTerm I immediately know if something is wrong and my resources weren't loaded.
#ifdef COLOR
XTerm.SimpleMenu*background: yellow
#endif
I'd like to dump the contents of an X window. Like this:
xwd -id | convert - capture.png
... which works quite well as long as the target window is not hidden (totally or partially behind other windows) or minimized.
Any idea on how to do this?
I guess we somehow have to send a "repaint" signal to the hidden window and then capture its response or something... :)
Do you have an objection to bringing it to the front first?
If not, you can use a tool like wmctrl to bring the window to the front (and maximize it, etc), use xwd to capture it, then send it back to where it came from with wmctrl.