About the KRunner webshortcut plugin...

[Dawit A]

On Friday, May 14, 2010 15:47:02 Ingo Klöcker wrote:
> On Friday 14 May 2010, Michael Pyne wrote:
> > On Thursday, May 13, 2010 15:29:57 Andreas Hartmetz wrote:
> > > On Thursday 13 May 2010 18:50:53 Aaron J. Seigo wrote:
> > > > On May 13, 2010, Ingo Klöcker wrote:
> > > > > I should probably file a bug report for this: Web shortcuts
> > > > > never worked for me in KRunner (currently using 4.4.2 on
> > > > > openSUSE 11.2). When I type "gg:test" nothing happens. KRunner
> > > > > simply sits there showing no runners to chose from. In
> > > > > Konqueror web shortcuts work.
> > > > 
> > > > first ensure that the webshortcuts runner is enabled in the
> > > > krunner config diaog.
> 
> Check. (Of course, I had checked this already multiple times before.)
> 
> > > > if it is, then something pretty odd/interesting is happening on
> > > > your system since it works for others very reliably. maybe put
> > > > some debug into
> > > > kdebase/workspace/plasma/generic/runners/webshorcuts/webshortcutr
> > > > unner.c pp in the match method.
> > > 
> > > I have the same problem on two computers but not on my main desktop
> > > PC. My main desktop has four cores, the other two have one. Maybe
> > > that is the important difference?
> > 
> > Also make sure that those particular web shortcuts are enabled in
> > Konqueror.
> 
> Check. (I had checked this also already multiple times before.)
> 
> > Somehow a few of the ones I use all the time (including gg:) got
> > disabled in the Web Shortcuts KCM. Konqueror apparently ignores that
> > and so they still worked, but the web shortcut runner doesn't and
> > therefore ignored those prefixes.
> 
> Same here. Enabling them didn't help though.
> 
> Maybe it's a problem with config migration. I migrated straight from 3.5
> to 4.4 beta 1.
> 
> Hmm, I had a quick look at
> kdebase/workspace/plasma/generic/runners/webshorcuts/webshortcutrunner.cpp
> 
> WebshortcutRunner::loadDelimiter() loads the KeywordDelimiter from
> kuriikwsfilterrc.
> 
>     m_delimiter = generalgroup.readEntry("KeywordDelimiter",
> QString(':'));
> 
> Obviously, it assumes this delimiter to be a character with ':' being
> the default. But my kuriikwsfilterrc contains
> KeywordDelimiter=58
> 
> Of course, 58 is the ASCII code of ':'.
> 
> Looking for other parties interested in KeywordDelimiter I found
> 
> in kdelibs/khtml/khtml_ext.cpp:
>   const char keywordDelimiter = cg.readEntry("KeywordDelimiter",
> static_cast<int>(':'));
>
> in kdebase/runtime/kurifilter-plugins/ikws/kuriikwsfiltereng.cpp:
>   m_cKeywordDelimiter = QString(group.readEntry("KeywordDelimiter",
> ":")).at(0).toLatin1();
> 
> in kdebase/runtime/kurifilter-plugins/ikws/ikwsopts.cpp:
>   QString delimiter = group.readEntry ("KeywordDelimiter", ":");
> and
>   group.writeEntry("KeywordDelimiter", QString(delimiter() ));
> 
> in kdebase/runtime/kurifilter-plugins/tests/kurifiltertest.cpp:
>   cfg.writeEntry( "KeywordDelimiter", QString(s_delimiter) );
> 
> 
> Conclusion:
> Either khtml_ext is wrong or all other users of KeywordDelimiter are
> wrong.

Neither khtml nor the krunner plugin or any other application should NOT 
directly use the configuration files of the urifilter plugins! I have no clue why 
people think this is an okay thing to do! There is no guarantee the plugins 
will not change their configuration option information or even the filename 
itself! 

If this was done because there is some feature or functionality missing from 
the KURIFilter class, then the missing functionality needs to be added there. 
This blatant misuse of the configuration files need to stop.

Oh well more stuff for my TODO list. Funny how I no longer have the time to 
work on the stuff I actually should be working on!!

Regards,
Dawit A.