[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: About the KRunner webshortcut plugin...
From: Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date: 2010-05-14 19:47:02
Message-ID: 201005142147.04065 () thufir ! ingo-kloecker ! de
[Download RAW message or body]
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.
The following fixed the problem for me:
kwriteconfig --file kuriikwsfilterrc --group General --key
KeywordDelimiter ':'
I wonder what will break now due to the wrong code in khtml_ext.cpp.
Regards,
Ingo
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic