Version: 3.5-rc1 (using KDE KDE 3.4.92) Installed from: Compiled From Sources Compiler: gcc-4.0.2 OS: Linux By using older versions of kopete I got used to the fact that kopete blinks my tasktray on an incoming message. I've been unable to configure kopete 3.5-rc1 to behave like this. I've also seen that the "Raise window on incoming message" behaves very broken: When the window is already opened, kopete still tries to raise the window, with the annoying result that it will be put into the background. Here is a quick fix for it. It fixes the Raise Window behaviour and this comes with the advantage that taskbar blinking will just work again if the user checks the option. Feel free to download the complete patch from my webspace: http://tienstra4.flatnet.tudelft.nl/~gerte/kopete-0.11-kde.3.5-rc1-raisewindow-patch Here it is if my webserver happens to be down (without the update of behaviorconfig_events.ui) diff -Nur kopete-orig/libkopete/private/kopeteviewmanager.cpp kopete/libkopete/private/kopeteviewmanager.cpp --- kopete-orig/libkopete/private/kopeteviewmanager.cpp 2005-10-10 16:57:54.000000000 +0200 +++ kopete/libkopete/private/kopeteviewmanager.cpp 2005-11-22 21:48:43.000000000 +0100 @@ -250,7 +250,10 @@ d->foreignMessage=!outgoingMessage; //let know for the view we are about to create KopeteView *thisView = manager->view( true ); d->foreignMessage=false; //the view is created, reset the flag - if( ( outgoingMessage && !thisView->isVisible() ) || d->raiseWindow || activate ) + + if (d->raiseWindow) + thisView->raise( true ); + else if( ( outgoingMessage && !thisView->isVisible() ) || activate ) thisView->raise( activate ); else if( !thisView->isVisible() ) thisView->makeVisible();
> By using older versions of kopete I got used to the fact that kopete blinks my tasktray on an incoming message. I've been unable to configure kopete 3.5-rc1 to behave like this. Tasktray? There is a "Taskbar" (containing entries for windows) and a "System Tray" (containing icons, especially kopete's). First's flashing can be enabled via "Configure Notifications...", "Flash the taskbar entry" column. Second's flashing via "Configure..."->"Behavior"->"General"->"Show system tray icon" and "Use message queue". > I've also seen that the "Raise window on incoming message" behaves very broken: When the window is already opened, kopete still tries to raise the window, with the annoying result that it will be put into the background. This is something I cannot reproduce. And I cannot find the code that would put the chat window into the background. :-( IMHO enabling "Configure..."->"Behavior"->"General"->"Queue unread messages" renders "Configure..."->"Behavior"->"Events"->"Raise window on incoming message" useless. Did you enable both? > Here is a quick fix for it. It fixes the Raise Window behaviour and this comes with the advantage that taskbar blinking will just work again if the user checks the option. IMHO your patch is wrong. Please read the comment of the raise method in kopete/chatwindow/chatview.cpp: // this shouldn't change the focus. When the window is raised when a new message arrives // if i am coding, or talking to someone else, i want to end my sentence before switching to // the other chat. i just want to KNOW and SEE the other chat to switch to it later // (except if activate==true) You are setting activate=true for d->raiseWindow, AFAIK the chat window will steal the focus. My problem is that I cannot imagine what code will hide the window on activate=false.
Hi Jan, > Tasktray? There is a "Taskbar" (containing entries for windows) and a > "System Tray" (containing icons, especially kopete's). Yes I know. I should have been more careful using these terms which are completely different things. Flashing the tasktray works well. I was talking about the taskbar. Kopete in kde 3.4 flashed my taskbar on an incoming message and I liked that. > First's flashing > can be enabled via "Configure Notifications...", "Flash the taskbar entry" > column. Second's flashing via "Configure..."->"Behavior"->"General"->"Show > system tray icon" and "Use message queue". I completely missed "Configure Notifications". I was not aware that this was a configuration item for kopete. Today I configured flashing my taskbar, but it still doesn't work. >> I've also seen that the "Raise window on incoming message" behaves very >> broken: When the window is already opened, kopete still tries to raise >> the window, with the annoying result that it will be put into the >> background. > > This is something I cannot reproduce. And I cannot find the code that > would put the chat window into the background. :-( No, but it just happens for me. It's in foreground and when I receive a message it just disappears behind for example my web browser. > IMHO enabling "Configure..."->"Behavior"->"General"->"Queue unread > messages" renders "Configure..."->"Behavior"->"Events"->"Raise window on > incoming message" useless. Did you enable both? Yes, I did. It might not be a usefull combination. > IMHO your patch is wrong. Please read the comment of the raise method in > kopete/chatwindow/chatview.cpp: > // this shouldn't change the focus. When the window is raised when a new > message arrives > // if i am coding, or talking to someone else, i want to end my sentence > before switching to > // the other chat. i just want to KNOW and SEE the other chat to switch to > it later > // (except if activate==true) The secret here is, that focus won't get stolen. activate=true means for me that taskbar blinking works and it makes the "Raise Window..." option less buggy. With activate=true nothing happens with the actual focus. > You are setting activate=true for d->raiseWindow, AFAIK the chat window > will steal the focus. My problem is that I cannot imagine what code will > hide the window on activate=false. Unfortunately this is exactly what seems to happen. More interesting for me, is that taskbar bliking happens on activate=true, but not on activate=false. I will never say my patch was a clean feature enhancement. For me it was just a quick fix to be included in KDE 3.5 (and it doesn't seem to break anything). But OK, I started hacking some code without knowing how it was meant to work (I missed "Configure Notifications"). However, Taskbar blinking is broken on chatwindows and that's what I'm missing in the new version. The Raise window thing is also broken in my opinion. Thanks, Gerte
Maybe this behaviour results from KDE beta2, which you seem to be using. I use KDE 3.5 rc2 and the raising/blinking works perfectly. Of course I have to disable the "prevent windows from raising" in kwin's preferences. (Right-click on a window's titlebar > window preferences > Advanved > prevent window raising > none) Otherwise windows will only be raised, if some kopete-window is active, as they are not allowed to raise above other apps on their own.
Hi Sven, Beta2? I'm running RC2. The only thing that remained of any earlier installation is ~/.kde. > Maybe this behaviour results from KDE beta2, which you seem to be using. > > I use KDE 3.5 rc2 and the raising/blinking works perfectly. Of course I > have to disable the "prevent windows from raising" in kwin's preferences. > (Right-click on a window's titlebar > window preferences > Advanved > > prevent window raising > none) Otherwise windows will only be raised, if > some kopete-window is active, as they are not allowed to raise above other > apps on their own. > I really can't find that option, not even window preferences.
The bug-report states Version: 3.5-rc1 (using KDE KDE 3.4.92) i.e. kopete rc1 but using .92 of KDE which is beta2. Anyway, the setting can be found as follows: Right-click on the titlebar of a window, i.e. that thingy with the X on the right. Choose the entry above close. Choose the entry that displays on the right the settings for active window-borders, below that you will find the settings for suppressing the "self-activation" of windows.
I'm seeing another behavior and that is if the window is on top and does not have focus (I have focus follows mouse set in kwin), the window will jump from the top to the bottom. If the window is not on top, then it does not change position.
It is a problem with the KWin focus stealing policy. The problem is in KWin. we tell KWin to raise the window, KWin should raise it. Lubos, may i have your opinion. For the background, we use QWidget::raise , and we expect the window to be placed above each other. but that doesn't always work. if we want to give the window the foccus, we use KWin::activateWindow( m_mainWindow->winId() ); which works fine.
What do you need to know more beside what's said in description of KWin::activateWindow() and KWin::forceActiveWindow() ? QWidget::raise() and KWin::raiseWindow() are the same for raising, the first one being a request from normal apps like KWin::activateWindow(), the second being like KWin::forceActiveWindow().
The problem is QWidget::raise() should not lower the window. See the original bug report: | When the window is already opened, kopete still tries to raise the window, | with the annoying result that it will be put into the background.
What are the exact steps or testcase to reproduce the problem?
*** Bug 136459 has been marked as a duplicate of this bug. ***
Unreproducible with Kopete 0.12.5. If the window is in the foreground, it is not lowered as described in this report.
I notice this bug is marked as "RESOLVED", but it's apparently in full effect for me. Just as described above. When a chatwindow is topmost and some other window has focus, it gets thrown underneath any other window. My versions: KDE 3.5.8, Kopete 0.12.7, kubuntu 7.10
*** Bug 166844 has been marked as a duplicate of this bug. ***