(*** This bug was imported into bugs.kde.org ***) Package: kwin Version: KDE 2.2.1 Severity: wishlist Installed from: Debian Packages Compiler: Not Specified OS: Not Specified OS/Compiler notes: Not Specified The KWin DCOP interface leaves a lot to be desired. The particular behavior I'm trying to enable is as follows. I want to be able to press a particular key (say F11) to cause a particular window (say Konsole) to be activated (mapped uniconified raised and given focus). This would be useful as I have a fixed set of windows I switch between regularly and hitting a single function to key to switch to a particular window is more efficient (for me) than hitting Alt-Tab a variable number of times or using the mouse. Anyhow exposing those operations via the KWin DCOP interface (focusWindow raiseWindow uniconifyWindow and their counterparts) would allow me to implement this using DCOP and a little bit of external code. Thanks for your help. (Submitted via bugs.kde.org)
What should happen when you have 2 konsole windows open at the same time? -- Cristian Tibirna .. tibirna@sympatico.ca PhD Student .. ctibirna@giref.ulaval.ca .. www.giref.ulaval.ca/~ctibirna KDE contact - Canada .. tibirna@kde.org .. www.kde.org
> What should happen when you have 2 konsole windows open at the same time? You're asking more generally about how to uniquely identify a particular window. I'll give you two answers. The easy answer is for KWin to just pick one at random. This would work fine for me since I never have more than one Konsole window or anything like that. The more complicated answer is one that leads us to a full-featured DCOP interface for KWin which would eventually allow software to fully perform all window manager actions without the user ever touching the mouse or keyboard (e.g. for voice-controlled window-managing or something like that). This answer is not the one I expect you to implement unless you happen to share my vision. The approach I think makes the most sense would be to allow the user to retrieve a list of some other form of window identifier based on the name and then specify a window by identifier. For example (in Python-ish syntax): konsoles = getWindowsByName("konsole") for konsoleID in konsoles: raiseWindowByID(konsoleID) focusWindowByID(konsoleID) The identifier list function probably wants to do simple substring matching or something similar to make sure no windows are left out. With access to these window identifiers in place it become straightforward to be able to query and set other information about windows as well e.g.: width = getWindowDWidthByID(konsoleID) # "discrete" width if width != 80: setWindowDWidthByID(konsoleID 80) xpos = getWindowXPosByID(konsoleID) if xpos < horizontalCenter: # do "left" Konsole stuff pass else: # do "right" Konsole stuff pass Given enough accessors et al I could write an entire object-oriented interface to KWin using whatever language and DCOP. Anyhow that's the complicated answer. Please let me know what you think. Of course if you have your own ideas about how to address the problem I'd be happy to discuss them with you. - Abhay
This doesn't have to do anything with KWin's DCOP interface, but for the thing you want (activating windows by shortcuts), you may want to try http://dforce.sh.cvut.cz/~seli/en/khotkeys (unstable version only at the present time).
Thank you for the info. I have (since late last year) solved my particular needs in a different way, partly by adjusting my keyboard and mouse habits. This issue is not of particular relevance to me any longer, though I suppose in some ways the feature request may still have some value. Shall I resolve the bug, perhaps as "won't fix" or something else?
*** Bug 45630 has been marked as a duplicate of this bug. ***
We should also have a way via dcop to get the ID of the active window. i.e. if we have multiple konqueror windows open, it should return the dcop name for the one that is currently active (toplevel). That way, from a bash script you can bind those pesky multimedia keys to do things like refresh the browser, etc. (with something like lineakd)
Comment #6: How about simply assigning the multimedia keys to the respective actions in the keyboard shortcuts configuration dialog? There's no need for DCOP there. (Oh, and the obvious thing everybody forgets about: Make sure your keyboard layout is configured properly).
Now that we have khotkeys2, it'd be nice to map keyboard keys/gestures to kwin's dcop functions. however, the usefullness of this is diminished because of kwin's poor DCOP interface with regards to the current window. It'd be nice to to have at least minimizeCurrentWindow, maximizeCurrentWindow, makeCurrentWindowSticky, doNotManageCurrentWindow, shadeCurrentWindow, resizeCurrentWindow(x,y), moveCurrentWindow(x,y) This would truly make khotkeys2 and kwin useful in KDE 3.2.
*** Bug 64782 has been marked as a duplicate of this bug. ***
*** Bug 66822 has been marked as a duplicate of this bug. ***
As my bug report #66822 has been closed as a duplicate of this report, although it is unrelated, I add the bug description here: It is no longer possible to resize windows via dcop to sizes larger than the working area. This was possible before kwin_iii and I used this feature regularly. If somebody asks dcop to resize a window to e.g. 2000 2000, that's for a reason, and the system should IMHO not try to be wiser. :-] Example: $ dcop `dcopstart konsole` konsole-mainwindow#1 resize 2000 2000 * Lubos Lunak 2003-10-29 14:22: > KWin doesn't let applications grow larger than the workarea [...] Yes, it does: Alt (or Meta)+RMB! This is a useful feature, and if it can be done with the mouse, it should be doable via dcop, too. > [...] for good reasons. Such as? I understand that a user shouldn't be allowed to place a whole window outside the working area. But why should he not be able to make a window wider? A konsole window could contain a very wide table (e.g. some logging output). Making the window narrower than the user asked to totally screws the output and makes it unreadable. Please reconsider this. And here is a brutal fix for this restriction: diff -u -p -r2.26 geometry.cpp --- geometry.cpp 29 Oct 2003 09:53:32 -0000 2.26 +++ geometry.cpp 29 Oct 2003 13:59:11 -0000 @@ -907,11 +907,6 @@ void Client::resizeWithChecks( int w, in int newx = x(); int newy = y(); QRect area = workspace()->clientArea( WorkArea, this ); - // don't allow growing larger than workarea - if( w > area.width()) - w = area.width(); - if( h > area.height()) - h = area.height(); QSize tmp = adjustedSize( QSize( w, h )); // checks size constraints, including min/max size w = tmp.width(); h = tmp.height();
*** Bug 77003 has been marked as a duplicate of this bug. ***
*** Bug 100035 has been marked as a duplicate of this bug. ***
NOTE TO SELF: Check all duplicates.
Since you've closed my bug report as a duplicate of this I'll put my comments here. Just assigning a multimedia key in the shortcuts doesn't help for external non-kde specific programs like lineakd (which is my software btw) to control windows or applications in a general way, from one place. I don't want to have to reconfigure each applications shortcuts when I can use lineakd, with the media-detect plugin and it's host of KDE plugins to handle it transparently for me. You are also assuming with the shortcuts solution that all keys can be seen by KDE, some cannot and need extra help by programs like lineakd. (Some keys have codes by no KeySyms, some have no keycodes in X at all, and need binding of the scancodes to linux keycodes before X sees them, etc.) We really do need KWin to have a much better DCOP interface solution like that described in comment #2. Please implement this!
Kwin could really use having all its window managing actions exposed as described above, like focusWindow, raiseWindow, etc. This would allow a great deal more customizabilty. To get a good idea of what should be added, take a look at the sawfish (a wm customizable in lisp) programming manual (link below), which details all the functions users can call to get the wm to do exactly what they want. This would allow power users to add features they really want, but that really don't belong in kwin/kde itself. For example, in sawfish I set up a Jump-Or-Execute action that I can bind keys to. If I set Hyper+F to Jump-Or-Execute Firefox, then pressing H-F will start firefox if it hasn't already started, _or_, if it has started, then it will focus and raise it. It's a much cleaner solution to have hackers implement this for themselves with dcoppython scripts then to try to code Jump-Or-Execute as a key configuration option into kde itself. Right now you can get _some_ of the functionality that sawfish allows by using the special windows setting option, but it only lets you match by window class and role. Sawfish basically opens access to all the X properties of a window. Here's the link to the sawfish manual: http://home.blarg.net/~sand/sawfish/v0.11/sawfish/index.html If this is the functionality users want, why not just use sawfish? you ask: 1) Sawfish is hardly maintained anymore. 2) DCOP is language agnostic, you aren't constrained to lisp. 3) Kwin is superior in other ways. A robust DCOP interface to KDE could really improve it's status as a power user wm and help breakdown the stereotype that it's only for users that need their hand held.
JJ: This should be fairly trivial, just adding more DCOP methods and mapping them to KWin's internal functions.
Created attachment 12277 [details] Patch to fix /close this Bug I am adding the patch for it. This patch is intended to be specially for scripting purpose(it means that output of dcop commands need to be parsed). These 4 additional functions provide all user controlled window function to be script controlled. Here, resizing is plainresize, instead of resizewithcheck. The reason is obvious. If someone specially intends to resize to larger area, he is responsible for it. Badly behaving window clients don't use Window Manger DCOP :)
Forgot to tell that, I am using kde-3.5 branch. So patch is against that.
is the patch not good enough? not commited yet?
Created attachment 13738 [details] DCOP interface (by Jezz) I worked on a patch for my personnal use too. In opposition to patch of Vinay Khaitan, it oriented to direct usage, especialy for KHotKeys. I give an exemple file for KHotKeys. With with interface, you can control mostly kwin with KGestures (really fun!). If you problem with negative numbers in QPoint, QRect, QSize, etc... using dcop command, see #117292. I work on 3.4.3 version of kdebase from experimental packages of Debian (deb http://ftp.de.debian.org/debian ../project/experimental main). You shouldn't have problems to use this patch with most of other versions. Code: - As you can see, I tried to modify less possible existing files. I prefered to add new classes. - I split my code in different objects (Windows, Desktops and Cursors). It allows a better understanding for user and developer (And I dislike too big classes) - I am attached to K&R coding style, sorry - I made public some members I needed in classes workspace and client. If you have some ideas about fonctions would usefull, I am open.
Created attachment 13739 [details] Control kwin using KGestures exemple
http://www.kde-apps.org/content/show.php?content=40425 - and it's not KWin-specific.