Bug 34882 - JJ: More complete KWin DCOP interface
Summary: JJ: More complete KWin DCOP interface
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Other
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 45630 64782 66822 77003 100035 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-11-14 04:03 UTC by Abhay Saxena
Modified: 2007-06-04 13:14 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Patch to fix /close this Bug (7.71 KB, patch)
2005-08-20 14:34 UTC, Vinay Khaitan
Details
DCOP interface (by Jezz) (32.58 KB, patch)
2005-12-02 15:50 UTC, Jerôme Pouiller
Details
Control kwin using KGestures exemple (12.38 KB, text/plain)
2005-12-02 15:52 UTC, Jerôme Pouiller
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Abhay Saxena 2001-11-14 03:53:00 UTC
(*** 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)
Comment 1 Cristian Tibirna 2001-11-20 04:12:59 UTC
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
Comment 2 Abhay Saxena 2001-11-20 20:44:51 UTC
> 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
Comment 3 Lubos Lunak 2002-09-26 15:10:38 UTC
 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). 
 
Comment 4 Abhay Saxena 2002-09-26 18:18:33 UTC
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?
Comment 5 Lubos Lunak 2002-10-03 19:10:55 UTC
*** Bug 45630 has been marked as a duplicate of this bug. ***
Comment 6 tormak 2003-09-20 21:23:29 UTC
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 7 Lubos Lunak 2003-09-24 14:16:26 UTC
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). 
 
 
Comment 8 Sashmit Bhaduri 2003-09-25 00:06:25 UTC
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. 
Comment 9 Lubos Lunak 2003-09-25 20:22:54 UTC
*** Bug 64782 has been marked as a duplicate of this bug. ***
Comment 10 Lubos Lunak 2003-10-29 14:22:59 UTC
*** Bug 66822 has been marked as a duplicate of this bug. ***
Comment 11 Melchior Franz 2003-10-29 15:00:36 UTC
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();

Comment 12 Lubos Lunak 2004-04-19 13:34:11 UTC
*** Bug 77003 has been marked as a duplicate of this bug. ***
Comment 13 Lubos Lunak 2005-03-25 12:43:04 UTC
*** Bug 100035 has been marked as a duplicate of this bug. ***
Comment 14 Lubos Lunak 2005-03-25 12:43:40 UTC
NOTE TO SELF: Check all duplicates.
Comment 15 tormak 2005-03-25 18:21:54 UTC
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!
Comment 16 Joseph Garvin 2005-05-13 17:14:44 UTC
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.
Comment 17 Lubos Lunak 2005-06-17 15:17:19 UTC
JJ: This should be fairly trivial, just adding more DCOP methods and mapping them to KWin's internal functions.

Comment 18 Vinay Khaitan 2005-08-20 14:34:56 UTC
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
:)
Comment 19 Vinay Khaitan 2005-08-20 14:53:49 UTC
Forgot to tell that, I am using kde-3.5 branch. So patch is against that.
Comment 20 Vinay Khaitan 2005-09-01 16:59:44 UTC
is the patch not good enough? not commited yet?
Comment 21 Jerôme Pouiller 2005-12-02 15:50:15 UTC
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.
Comment 22 Jerôme Pouiller 2005-12-02 15:52:37 UTC
Created attachment 13739 [details]
Control kwin using KGestures exemple
Comment 23 Lubos Lunak 2007-06-04 13:14:15 UTC
http://www.kde-apps.org/content/show.php?content=40425 - and it's not KWin-specific.