Bug 34882

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.