Bug 692

I have tried many different specific window settings to no avail. I'd be content if this bug could be resolved with any such correct settings.

I verified this bug.

I set the --use option in both kate.desktop and kde-kate.desktop.  Konqueror seems to use kde-kate.desktop when starting .txt files.

 After I did the above, when I started a text file in Konqueror it reacted exactl as Darrell described in his bug report.

 I did a lot of testing of different CLI options in the kde-kate.desktop file and most but not quite all would not work when --use was used.

 I tried Kstart in the kde-kate.desktop file and tested it with various Kstart and Kate options and got the same results as above, most of the options were ignored.

 I tried starting Kate from a terminal, with various options, and had similar responses as the above--many options quit working when -use was used.

I am using Firefox 2.6.24, Trinity 3.5.12 and Ubuntu 10.10.

Keith

Because of the usability issues whereby a user is misled to think Kate has the focus but does not, I want to bump this bug report from Normal to Major status. I think this needs repair before R14 because this bug is more than a paper cut candidate.

Tim, any objections to bumping the status?

BTW, I could be way off base, but seems the key code is located in katemain.cpp:221-234:

// since the user tried to open a document, let us assume [s]he
// wants to see that document.
// ### what to do about the infamous focus stealing prevention?
uint mwn = kRef.call("activeMainWindowNumber");
TQCString smwn;
DCOPRef wRef( kateApp, TQCString( "__KateMainWindow#") + smwn.setNum(mwn) );
if ( wRef.call("minimized") )
{
  if ( wRef.call( "maximized" ) )
    wRef.call( "maximize" );
  else
    wRef.call("restore");
}
wRef.call( "raise" );

The comments are interesting. I suspect once upon a time somebody remedied this focus issue. Probably succeeded but something else after that time has caused the focus to again fail.

Line 226 might provide a clue (again, I could be way off base here!):

DCOPRef wRef( kateApp, TQCString( "__KateMainWindow#") + smwn.setNum(mwn) );

When I look in my Kate Advanced Special Window Settings, Advanced tab, Window role, I find this:

__katemainwindow#1

The difference is the lower case. The window number is provided by smwn.setNum(mwn) and QQCString concatentates the text. I'm wondering whether changing line 226 to be lower case would resolve the focus problem?

Perhaps this:

DCOPRef wRef( kateApp, TQCString( "__katemainwindow#") + smwn.setNum(mwn) );

or this

DCOPRef wRef( kateApp, TQCString( "__KateMainWindow#").lower() + smwn.setNum(mwn) );

I wish I knew C++ better!

DCOPRef is found in tdelibs/dcop/dcopref.h, but understanding dcop is over my head right now.

Well, I tried a patch using the first example of all lower case and poo--- no proof of concept. :) kate would not grab the focus.

As I mentioned, I use the Kate Advanced Special Window Settings, Workarounds tab, to force focus prevention level to None only for Kate and that will bring Kate forward, but not with the focus.

Priority bumped.

<rant>
I am personally a bit frustrated with the (k|t)win focus stealing prevention.  If we are going to allow certain apps to steal focus, then there should be an Xorg atom that can be set to allow stealing, not a bunch of unreliable hacks that will eventually fail (as they apparently did in kate).
</rant>

The sane thing to do for now is to add kate to the default FSP whitelist, and go all the way by grabbing full focus instead of just bringing the window to the top of the stack.

(In reply to comment #4)
> Priority bumped.
> 
> <rant>
> I am personally a bit frustrated with the (k|t)win focus stealing prevention. 
> If we are going to allow certain apps to steal focus, then there should be an
> Xorg atom that can be set to allow stealing, not a bunch of unreliable hacks
> that will eventually fail (as they apparently did in kate).
> </rant>
> 
> The sane thing to do for now is to add kate to the default FSP whitelist, and
> go all the way by grabbing full focus instead of just bringing the window to
> the top of the stack.

Is there a way to manually request the raising of a window? Like set an alert ( i thought this as possible via EHWM? )

I think whitelisting is the last solution. It in itself is just a workaround.

(In reply to comment #5)
> (In reply to comment #4)
> > Priority bumped.
> > 
> > <rant>
> > I am personally a bit frustrated with the (k|t)win focus stealing prevention. 
> > If we are going to allow certain apps to steal focus, then there should be an
> > Xorg atom that can be set to allow stealing, not a bunch of unreliable hacks
> > that will eventually fail (as they apparently did in kate).
> > </rant>
> > 
> > The sane thing to do for now is to add kate to the default FSP whitelist, and
> > go all the way by grabbing full focus instead of just bringing the window to
> > the top of the stack.
> 
> Is there a way to manually request the raising of a window? Like set an alert (
> i thought this as possible via EWMH? )
> 
> I think whitelisting is the last solution. It in itself is just a workaround.

Further research into ICCCM and EWMH hasn't turned up anything then being able to set "attention" which then depends on the WM aka what we currently have.

Here is a patch to enabled MDI being always on. It is a global setting.

Created attachment 294 [details]
A patch to enable forced MDI interfaces.

Created attachment 296 [details]
Patch updated for GIT

I updated the patch for GIT. The 3.5.13 patch would not merge because of other kate patches.

I am able to build tdebase with the updated but have yet to test. I am unlikely to start testing for a few days.

Preliminary tests:

New check box exists. No crashes.

I opened several text files from konqueror and they all opened in the current instance, but they did that previously with the --use parameter too. The new option does seem to resolve the problem I reported in the list with respect to opening web page sources in an external editor. Now when I do that only the current instance of kate is used. That is good news. :)

But ---

There is a bug with the new option. I can't disable the option. When uncheck the new box and close kate, the option will be reenabled when I open Kate. I can close kate, edit the katerc file with kedit, open kate, and the option again is set to true.

When we fix this bug I will repeat the Firefox test with the option disabled. Right now I can't test further because the option is always enabled.

With respect to the original problem of this bug report, kate does not grab the focus. Same description as before. I can set the focus stealing prevention level for kate to be different than the global setting. When Kate's focus stealing prevention level is set to None kate will pop forward but still does not grab the focus.

Calvin,

Would you please look at this patch to figure out why the option cannot be disabled? The option is always enabled, which is great for MDI people like me, but will not be what SDI people want. :)

Created attachment 481 [details]
Patch updated to fix check box behavior

Patch updated to fixed check box behavior. Check box and associated katerc useInstance setting now work correctly.

Reminder that this patch is a great improvement but does not address the original problem of focus.

Right, this addresses a fundamentally different issue. Can we push this patch 
for the sake of pushing it?

The real problem is with twin correct?

Created attachment 483 [details]
Patch to fix kate focus

I will push your patch unless Tim disagrees.

Now for the bizarre news of the day: I solved the focus problem.

I set my global Focus stealing prevention level to Low. Without modifying any special window settings, kate will pop forward (raise) but will not grab the focus (show). No Focus stealing prevention level works with kate. I believe the fundamental problem is kate is designed for SDI usage despite supporting a quasi-MDI mode. When in SDI mode, opening a document in kate from konqueror will cause kate to grab the focus just like any other app. Trying to enforce an MDI or --use mode changes that behavior. Which I suspect is why that special snippet of code exists in katemain.cpp.

Today I found a workaround solution to the focus problem here:

http://forum.krusader.org/viewtopic.php?p=9633

I tried the following in konsole:

kateid=`dcop "kate-*"`; dcop $kateid __KateMainWindow#1 hide; dcop $kateid __KateMainWindow#1 show

I don't know why the hide is needed before the show but the snippet won't work otherwise. Yet by golly Kate receives the focus.

Noticing that the existing code in katemain.cpp:232-245 was already using dcop I thought all I needed was to patch the existing code with hide and show.

A simple two line patch.

By golly Kate now receives the focus.

Patch attached for peer review.

I am stunned. Speechless. Tongue-tied. Dazed. This focus problem has been a proverbial thorn in my side for years!

Just a note to the kate meister: bug report 927 seems related to this bug report.

Although I seemed to have resolved the issue a while back, observations shared in the discussion list indicate kate's mdi usages is not completely resolved yet.

I found the cause of the problem with bug report 927. I had to reverse a patch used to resolve bug report 394. Therefore this bug report remains unscathed and we can continue process of providing/testing MDI usage in kate.

I don't know whether anybody else is testing the MDI and focus patches provided here.

The MDI patch does seem to force all openings to use the existing Kate session.

Without the focus patch I never get Kate to pop forward from the background. With the patch I sometimes do but sometimes don't. I haven't yet figured out the behavior patterns. The focus patch seems to have a hit-and-miss personality.

The good news is I stumbled across some glue, so to speak: optimize the Special Application Settings for Kate. I haven't tested thoroughly, but I think the focus patch remains necessary even with the special application settings.

Each TDE app can be fine-tuned with special window settings and special application settings. Although similar, they function differently. In the case of getting Kate to pop forward, the special applications settings must be used. Be sure not to get confused when selecting the respective dialog. :)

With Kate open:

* "Right-click" on the title bar
* Select Advanced
* Select Special Application Settings (Note: not Special Window Settings)
* Select the Workarounds tab.
* Enable the Focus stealing prevention check box
* Select the Force option
* Select the None option

With those settings and the two patches, I now have Kate acting like an MDI document and popping forward from the background.

More testing by other users is needed.

Calvin,

I notice a weird side effect of the MDI patch: The Kate About dialog is empty. Do you have any ideas of the cause or how to fix?

Thanks!

Darrell,

Huh!

Let me check it out

Calvin

I am bumping this report to Major.

With the small focus patch provided here, Attachment 483 [details], (not yet merged to GIT), and the focus configuration outlined in Comment 17, I no longer experience focus issues. The patch and configuration steps work both in TDE and KDE3.

Unless there are objections I would like to push the small focus patch to GIT.

To resolve this bug report that leaves the MDI patch provided by Calvin. The patch is a good idea and should resolve any corner cases that might occur with the focus.

I have not been testing the MDI patch because of the About dialog issue. Upon being resolved I will continue testing.

I want to further test the MDI patch to learn whether the patch eliminates any need for the special configuration outlined in Comment 17.

(In reply to comment #20)
> I am bumping this report to Major.
> 
> With the small focus patch provided here, Attachment 483 [details], (not yet merged to
> GIT), and the focus configuration outlined in Comment 17, I no longer
> experience focus issues. The patch and configuration steps work both in TDE and
> KDE3.
> 
> Unless there are objections I would like to push the small focus patch to GIT.

Looks to me like you might be overriding the focus stealing prevention with Attachment 483 [details].  This is not necessarily a problem (Kate does so already), but I would recommend adding a comment to that section of code briefly explaining what bug you are hacking around (no references to this bug report though please).  Other than that, go ahead and push.

Okay, I'll add a comment and push the patch.

Calvin, oh Calvin --- do you still want to pursue your MDI patch? If yes, then I'll open a new bug report (enhancement request) and attach the existing patch there.

I would like to explore the MDI patch concept to learn whether the patch eliminates the need for the special window/application focus settings. If we continue with the patch then we need to determine why the About dialog goes funky with the patch (Comment 18).

Patch (with verbose comment) pushed in GIT hash 377f8485.

This resolves the bug report but will wait for Calvin's response about the MDI patch before tagging as resolved.

I also still to wait if Calvin's MDI patch will be corrected (About dialog). For now, I remove patch from the queue for v3.5.13.1.

Any progress on this?  Any problems noted with the patch that has been in GIT now for some time?

I no longer experience kate focus problems as originally reported, based upon the patch I pushed in Comment 23 and the configuration options mentioned in Comment 18.

This bug report remains open only for Calvin's proposed MDI patch. The patch has a bug affecting the kate About dialog (Comment 18). Calvin's patch is not required to tag this bug report as resolved. If Calvin wants to continue with his proposed patch then perhaps the patch should be moved to a new report as an enhancement request?

(In reply to comment #26)
> I no longer experience kate focus problems as originally reported, based upon
> the patch I pushed in Comment 23 and the configuration options mentioned in
> Comment 18.
> 
> This bug report remains open only for Calvin's proposed MDI patch. The patch
> has a bug affecting the kate About dialog (Comment 18). Calvin's patch is not
> required to tag this bug report as resolved. If Calvin wants to continue with
> his proposed patch then perhaps the patch should be moved to a new report as an
> enhancement request?

Someone seems to have marked Calvin's patch obsolete.

Would you mind sorting through this mess of a bug report and creating a new enhancement request with Calvin's last patch attached to it and a description of what the enhancement is and why it is needed?  Copy+pasting text from this report is perfectly fine. ;-)

Thanks!

No mess. The updated patch with attachment 481 [details] rendered the original patch obsolete. Refer to Comment 12. The original patch also was created in 3.5.13 and did not work in R14.

My updated version of Calvin's patch did not fix the kate About dialog problem noted in Comment 18. That is the only remaining item in this bug report.

The patch I pushed to fix the focus problem needs additional configuration in the Special Application Settings to ensure kate always pops forward and grabs the focus (Comment 17). I don't know where we should document that behavior other than perhaps somewhere in the wiki. Tribal knowledge is always a challenge to document.

The proposed patch in attachment 481 [details] is moved to enhancement request 1127.

As the original problem reported here has been resolved, marking this bug report accordingly.

To future users: please notice the additional configuration requirements in Comment 17. At the time this bug report is being closed, there is no place for this information to be found. Perhaps the Kate help handbook should be updated to include this information. Suggestions are welcomed to ensure this tribal knowledge is not lost. :-)

This patch
http://git.trinitydesktop.org/cgit/tdebase/commit/kate/app/katemain.cpp?id=377f84855a6141625e53e10778e4f47e1d05ae53

causes Kate to jump from one position in the taskbar to another whenever a new document is opened.  This is very annoying and not expected behaviour, though I do see how the added code would cause this to happen.

Another method of fixing the focus stealing will be needed; the mentioned patch has been reverted in GIT hash b545fc3.  My initial suggestion is just to add a new Kate override to the FSP whitelist in twin.

Yes, we need a fix. Now kate focus is broken on my system. For now I will build tdebase by locally reverting b545fc3.

Part of this bug report has been properly fixed in GIT hashes 6f1973a (tdelibs) and 719298b (tdebase).  However, we need to decide on the correct behaviour of kate before this report can be closed:

Behaviour #1 (current):
On opening a file, Kate does not jump to the foreground, but instead flashes on the taskbar indicating it desired focus but was blocked by the window manager.  The user can set an override for Kate in the window manager to disable FSP if desired; if this is done, Kate will jump to the foreground with focus.

Behaviour #2 (possible):
On opening a file, Kate jumps to the foreground with focus.  This would be accomplished by setting a default FSP override in tdelibs for kate.  The user can disable this override if FSP is desired.

Thoughts?

On my system, with no special FSP settings, with kate not yet open, and --use defined in kate.desktop, opening any text file with kate from konqueror results in kate opening and jumping to the foreground. This is what I expect. So far so good.

Keep kate open. Repeat the act and open a second text file with kate from konqueror. Kate will pop forward but does not steal the focus. The focus will remain with konqueror. Because of that, keyboard shortcuts affect konqueror and not kate but the user doesn't see that. As I am purposely opening the text file in kate, I expect kate to steal the focus. I never found an approprite FSP setting to resolve the problem, hence the original patch.

(In reply to comment #33)
> On my system, with no special FSP settings, with kate not yet open, and --use
> defined in kate.desktop, opening any text file with kate from konqueror results
> in kate opening and jumping to the foreground. This is what I expect. So far so
> good.
> 
> Keep kate open. Repeat the act and open a second text file with kate from
> konqueror. Kate will pop forward but does not steal the focus. The focus will
> remain with konqueror. Because of that, keyboard shortcuts affect konqueror and
> not kate but the user doesn't see that. As I am purposely opening the text file
> in kate, I expect kate to steal the focus. I never found an approprite FSP
> setting to resolve the problem, hence the original patch.

This particular problem (kate jumping to foreground without focus) is fixed in the two recent GIT commits mentioned above.  At this point I just need to know whether Kate should be able to steal focus by default--it sounds like you think this is user-expected behaviour, and I am inclined to agree, therefore I will see what I can do to insert a default FSP override for Kate.

I'll rebuild and test with the latest commits and report later.

The whole problem is that kate is not a true MDI app. The --use flag is a kludge and browsing the web reveals the kludge never worked 100% and still does not work 100% in KDE4.

I don't think those who prefer to use kate as an SDI app have these problems.

Probably best to wait until I rebuild and test before spending more time on this. :-)

I rebuilt and tested. Note: I have --use configured everywhere, even in an shell alias. I want kate to function as an MDI app. I don't use kate in SDI mode or use sessions.

With the latest commits, when I don't configure any FSP options, opening subsequent files from konqueror results only in the task bar icon flashing, regardless of whether kate is maximized or minimized.

When I use the Advanced Special Application Settings and set kate to a FSP of None, and kate is not minimized, then kate obtains focus when opening subsequent files from konqueror, konsole, or the mini cli. From my perspective that is what I expect and want.

There is a glitch. Despite setting FSP in Advanced Special Application Settings, when kate is fully minimized and I open a subsequent text file from within konqueror, kate opens and jumps to the foreground but does not grab the focus. That glitch means the original problem remains unresolved. :-(

OK, this should be fixed in GIT hash 93993eb (tdelibs).  Please confirm and close this report if true. :-)

Seems to be fixed here. Thanks and good job!