KGet Runner

Hi KGetters,

I just wrote a KRunner plugin allowing you to download any URLs found in the
KRunner query.

At the moment it uses a regular expression based on
www.ietf.org/rfc/rfc3986.txt to search for URLs in the entered text.

You can find an initial release at:
  http://kde-apps.org/content/show.php?content=112349

Urs Wolfer suggested that it might be included into the KDE tree. I don't see
why not. It's still pretty rough around the edges and needs some love...
This would be my first commit (anywhere, anytime) so I'd need some guidance on
this.

Yours, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Hey!

We talked about this yesterday already and I'm all for it... :)

About the validation of a specific text, maybe just use
KUrl("bla").isValid()... :)

Also I saw yesterday that you are using importLinks as dbus-call... maybe you
should/want to change it to "showNewTransferDialog", as that is usually used
to add new downloads...

Lukas

Am Sonntag 20 September 2009 23:12:44 schrieb Tomas Van Verrewegen:

> Hi KGetters,
>
> I just wrote a KRunner plugin allowing you to download any URLs found in
>  the KRunner query.
>
> At the moment it uses a regular expression based on
> www.ietf.org/rfc/rfc3986.txt to search for URLs in the entered text.
>
> You can find an initial release at:
>   http://kde-apps.org/content/show.php?content=112349
>
> Urs Wolfer suggested that it might be included into the KDE tree. I don't
>  see why not. It's still pretty rough around the edges and needs some
>  love... This would be my first commit (anywhere, anytime) so I'd need some
>  guidance on this.
>
> Yours, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>

_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

> About the validation of a specific text, maybe just use
> KUrl("bla").isValid()... :)

The problem with a (much simpler) approach like this is that just about
anything actually is a valid URL.
Eg: This is a sentence , built from 11 valid url's ...
      And so is this one: 1 + 2 = 3 !


> Also I saw yesterday that you are using importLinks as dbus-call... maybe
>  you should/want to change it to "showNewTransferDialog", as that is
>  usually used to add new downloads...

You're probably right.
I used "importLinks" because this is the way I most often use KGet:
  copy a whole bunch of links (or a whole web page) to the clipboard,
  click "Import links..." in the tray icon,
  then use the filters to choose which links to download.

Maybe the "Import Links" and "New Download" dialogs should be merged together
somehow?


Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Montag 21 September 2009 16:03:25 schrieb Tomas Van Verrewegen:
> > About the validation of a specific text, maybe just use
> > KUrl("bla").isValid()... :)
>
> The problem with a (much simpler) approach like this is that just about
> anything actually is a valid URL.
> Eg: This is a sentence , built from 11 valid url's ...
>       And so is this one: 1 + 2 = 3 !
lol, well then we could also try to use !KUrl("bla").protocol().isEmpty(),
that'd be more sensible I think... :)

>
> > Also I saw yesterday that you are using importLinks as dbus-call... maybe
> >  you should/want to change it to "showNewTransferDialog", as that is
> >  usually used to add new downloads...
>
> You're probably right.
> I used "importLinks" because this is the way I most often use KGet:
>   copy a whole bunch of links (or a whole web page) to the clipboard,
>   click "Import links..." in the tray icon,
>   then use the filters to choose which links to download.
>
> Maybe the "Import Links" and "New Download" dialogs should be merged
>  together somehow?

He nono, Import Links is for example to get all links from a specific html-
page, then we show all links in that dialog...

Switching to NewDownloadDialog makes sense anyway as it can handle multiple
urls as well... (the user gets some listwidget with checkboxes then...)

Lukas
>
>
> Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

> lol, well then we could also try to use !KUrl("bla").protocol().isEmpty(),
> that'd be more sensible I think... :)
I will check this out.

> He nono, Import Links is for example to get all links from a specific html-
> page, then we show all links in that dialog...
That was exactly the functionality I was looking for:
paste some junk with URLs mixed in into KRunner and download the URLs :)

> Switching to NewDownloadDialog makes sense anyway as it can handle multiple
> urls as well... (the user gets some listwidget with checkboxes then...)
I'll change the code.
But it's a shame we loose the filtering capabilities... I know this probably is
overkill for most users.


Any ideas on how to handle different protocols?
Now I use 2 regexps for allowed/disallowed protocols, but I think this is too
geeky for general use. Maybe a simple list of allowed protocols...
Or even better: a way of asking KGet what protocols it supports ;)


Yours, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Montag 21 September 2009 17:46:15 schrieb Tomas Van Verrewegen:

> > lol, well then we could also try to use
> > !KUrl("bla").protocol().isEmpty(), that'd be more sensible I think... :)
>
> I will check this out.
>
> > He nono, Import Links is for example to get all links from a specific
> > html- page, then we show all links in that dialog...
>
> That was exactly the functionality I was looking for:
> paste some junk with URLs mixed in into KRunner and download the URLs :)
>
> > Switching to NewDownloadDialog makes sense anyway as it can handle
> > multiple urls as well... (the user gets some listwidget with checkboxes
> > then...)
>
> I'll change the code.
> But it's a shame we loose the filtering capabilities... I know this
>  probably is overkill for most users.

Yeah I think so as well...
>
>
> Any ideas on how to handle different protocols?
> Now I use 2 regexps for allowed/disallowed protocols, but I think this is
>  too geeky for general use. Maybe a simple list of allowed protocols... Or
>  even better: a way of asking KGet what protocols it supports ;)
Yeah that could be done... aka implementing some QStringList protocols(); into
MainWindow + QStringList protocols(); in each TransferFactory...

Lukas

Offtopic: That said we should check whether a transfer-plugin supports a
specific protocol before asking it to create a transfer when the protocols()
per factory is implemented... That'd remove the check for the protocol in each
createTransfer() method...
>
>
> Yours, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Ok, I saw the latest version of this... looks very promising :)

The only thing which looks a bit suspect to me is the QRegExp, I don't really
like them... maybe we can find a better understandable way to do the things it
used to do ;)

Anyway, I think we could merge this into trunk + do the changes for the
protocol...

Lukas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

I understand your concern, and thought about changing it myself. Maybe just
QString::split(' ') or similar.

But since this would probably be less efficient/accurate, I left it as is for
now.
The regexp "\b\S+" would match
  "http:///...
  =http://...
and the likes where a split on whitespace wouldn't.

I think it's important to try and get every last url out of there. This
solution is far from perfect. Would even be nice to also get some sloppy urls,
maybe default to http:// when something looks like a url...
What's your view on this?


I updated the dbus code with a decent error check/message. Could use a
KNotification for this...


I'll upload a new version tomorrow. Time for bed now -.-


Yours, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Mittwoch 23 September 2009 02:34:14 schrieb Tomas Van Verrewegen:
> I understand your concern, and thought about changing it myself. Maybe just
> QString::split(' ') or similar.
>
> But since this would probably be less efficient/accurate, I left it as is
>  for now.
> The regexp "\b\S+" would match
>   "http:///...
>   =http://...
> and the likes where a split on whitespace wouldn't.
Ok then, anyway please put a comment to that code and explain what it does...
:)
>
> I think it's important to try and get every last url out of there. This
> solution is far from perfect. Would even be nice to also get some sloppy
>  urls, maybe default to http:// when something looks like a url...
> What's your view on this?
Mmh, I remember we closed a bug like this for kget-core as WONTFIX ;)
>
>
> I updated the dbus code with a decent error check/message. Could use a
> KNotification for this...
Yeaps...

>
>
> I'll upload a new version tomorrow. Time for bed now -.-
Ok great! :)

Lukas
>
>
> Yours, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

> Mmh, I remember we closed a bug like this for kget-core as WONTFIX ;)
I guess then we'll WONTFIX here either...

> > I updated the dbus code with a decent error check/message. Could use a
> > KNotification for this...
I'm having some trouble getting the KNotification to work. I followed
instructions at http://api.kde.org/4.x-api/kdelibs-
apidocs/kdeui/html/classKNotification.html but no luck :( Must be overlooking
something...
So for now, it's a QMessageBox.


New version uploaded to kde-apps.


Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Mittwoch 23 September 2009 13:22:20 schrieb Tomas Van Verrewegen:

> > Mmh, I remember we closed a bug like this for kget-core as WONTFIX ;)
>
> I guess then we'll WONTFIX here either...
>
> > > I updated the dbus code with a decent error check/message. Could use a
> > > KNotification for this...
>
> I'm having some trouble getting the KNotification to work. I followed
> instructions at http://api.kde.org/4.x-api/kdelibs-
> apidocs/kdeui/html/classKNotification.html but no luck :( Must be
>  overlooking something...
> So for now, it's a QMessageBox.

There are some KNotification examples in kget/core/kget.cpp you might want to
have a look there... :)

>
>
> New version uploaded to kde-apps.
Ok great!

Lukas
>
>
> Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Mittwoch 23 September 2009 15:33:45 schrieb Lukas Appelhans:

> Am Mittwoch 23 September 2009 13:22:20 schrieb Tomas Van Verrewegen:
> > > Mmh, I remember we closed a bug like this for kget-core as WONTFIX ;)
> >
> > I guess then we'll WONTFIX here either...
> >
> > > > I updated the dbus code with a decent error check/message. Could use
> > > > a KNotification for this...
> >
> > I'm having some trouble getting the KNotification to work. I followed
> > instructions at http://api.kde.org/4.x-api/kdelibs-
> > apidocs/kdeui/html/classKNotification.html but no luck :( Must be
> >  overlooking something...
> > So for now, it's a QMessageBox.
>
> There are some KNotification examples in kget/core/kget.cpp you might want
>  to have a look there... :)
>
> > New version uploaded to kde-apps.
>
> Ok great!

Had a look there, looks great to me... when the KNotification is fixed we
should push this to trunk imo, implement the protocols() stuff there and merge
it in there...

Also we need to remove the temporary config-dialog...

Lukas

PS: I saw you used GPLv3, I have no clue whether KDE is fine with v3 only, as
long as they are, I am as well... :) (KGet is v2+)

>
> Lukas
>
> > Tomas
> > _______________________________________________
> > Kget mailing list
> > Kget@...
> > https://mail.kde.org/mailman/listinfo/kget
>
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>

_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

> Had a look there, looks great to me... when the KNotification is fixed we
> should push this to trunk imo, implement the protocols() stuff there and
>  merge it in there...
Will I'll look into this tonight. Then the next version can go into trunk.

> Also we need to remove the temporary config-dialog...
When you guys fix protocols()...

> PS: I saw you used GPLv3, I have no clue whether KDE is fine with v3 only,
>  as long as they are, I am as well... :) (KGet is v2+)
To be honest, I just copy/pasted the license from another runner. Maybe it's
best to use the same license as the rest of KGet.

One other thing: should I update the .desktop files with translated names, or
how does this work?

Yours, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Mittwoch 23 September 2009 15:59:21 schrieb Tomas Van Verrewegen:
> > Had a look there, looks great to me... when the KNotification is fixed we
> > should push this to trunk imo, implement the protocols() stuff there and
> >  merge it in there...
>
> Will I'll look into this tonight. Then the next version can go into trunk.
>
> > Also we need to remove the temporary config-dialog...
>
> When you guys fix protocols()...
Suresure, but the fixed protocols() is a requirement for it shipping with 4.4
imo, so we'll do it anyway :)
>
> > PS: I saw you used GPLv3, I have no clue whether KDE is fine with v3
> > only, as long as they are, I am as well... :) (KGet is v2+)
>
> To be honest, I just copy/pasted the license from another runner. Maybe
>  it's best to use the same license as the rest of KGet.
>
> One other thing: should I update the .desktop files with translated names,
>  or how does this work?
No, just leave the .desktop file untranslated... the translation teams
translate them and scripty helps us to update them :)

Lukas
>
> Yours, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Ok. Fixed the notification.
You tend to forget how easy things can be :)

When testing the message, I did stumble on an annoying little problem though:

If you keep the "New Download" dialog open for too long, the DBus call times
out, and you get an error message.

I looked through the code and apparently the dialog gets exec()ed, which
blocks the call until the dialog has been closed.

So I moved some stuff around... Should be fixed now.

New version is on kde-apps.org.
I think we're ready to push to trunk. Will you commit this? Or should I create
a SVN account?


Yours, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Am Donnerstag 24 September 2009 12:00:21 schrieb Tomas Van Verrewegen:
> Ok. Fixed the notification.
> You tend to forget how easy things can be :)
Hehe yeah :)

>
> When testing the message, I did stumble on an annoying little problem
>  though:
>
> If you keep the "New Download" dialog open for too long, the DBus call
>  times out, and you get an error message.
>
> I looked through the code and apparently the dialog gets exec()ed, which
> blocks the call until the dialog has been closed.
>
> So I moved some stuff around... Should be fixed now.

Great, code looks fine to me... :)
>
> New version is on kde-apps.org.
> I think we're ready to push to trunk. Will you commit this? Or should I
>  create a SVN account?
You're welcome to register your own account, then you can push it yourself :)

Lukas
>
>
> Yours, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Ok. Got my SVN account details, so I committed this.


2 comments:

1. org.kde.kget.service needs to be added to "kdenetwork/kget/desktop".
But I don't really know how to tell cmake to put the correct install prefix in
the entry: "Exec=/usr/bin/kget".... Anyone?

2. Because "showNewTransferDialog()" blocks, krunner became unresponsive as
long as the "New Download" dialog was open. I switched the DBus code to an
"asyncCall" to work around this.
But....
I stumbeled on some weirdness in the showNewTransferDialog() implementation:
Reproduce like this (using runner from svn):
- in krunner, type: "http://a"
- choose "download with kget"
- leave the dialog open
- again in krunner, type: "http://a"
- choose "download with kget"
-> now the dialog contains "http://a" twice
- leave the dialog open
- again in krunner, type: "http://a"
- choose "download with kget"
-> now the dialog contains "http://a" once again

This behaviour only occurs when the URL's you enter are identical.
I haven't found the time yet to investigate this further.
If you like, I can put this in a bug report...



Cheers, Tomas
_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Sorry, I got some surgery on tuesday, so I wasn't able to respond more
quickly...

1) I have not much of a clue, but do we really need that file?

Anyway: we call kget-dbus as well from kget_test_transfers app, so maybe check
how we do it there... :)

2) yeah the newtransferdialog should always add urls if the method gets called
and it is still open...

Lukas

Am Dienstag 29 September 2009 10:42:56 schrieb Tomas Van Verrewegen:

> Ok. Got my SVN account details, so I committed this.
>
>
> 2 comments:
>
> 1. org.kde.kget.service needs to be added to "kdenetwork/kget/desktop".
> But I don't really know how to tell cmake to put the correct install prefix
>  in the entry: "Exec=/usr/bin/kget".... Anyone?
>
> 2. Because "showNewTransferDialog()" blocks, krunner became unresponsive as
> long as the "New Download" dialog was open. I switched the DBus code to an
> "asyncCall" to work around this.
> But....
> I stumbeled on some weirdness in the showNewTransferDialog()
>  implementation: Reproduce like this (using runner from svn):
> - in krunner, type: "http://a"
> - choose "download with kget"
> - leave the dialog open
> - again in krunner, type: "http://a"
> - choose "download with kget"
> -> now the dialog contains "http://a" twice
> - leave the dialog open
> - again in krunner, type: "http://a"
> - choose "download with kget"
> -> now the dialog contains "http://a" once again
>
> This behaviour only occurs when the URL's you enter are identical.
> I haven't found the time yet to investigate this further.
> If you like, I can put this in a bug report...
>
>
>
> Cheers, Tomas
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>

_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

No prob.


1.

I figured it out in the meantime :)

I also checked "test_transfers.cpp". Here "KRun::runCommand(...)" is used to
start KGet if it isn't already running.

DBus offers the same functionality (see http://dbus.freedesktop.org/doc/dbus-
specification.html#message-bus-starting-services ).

The code I'm using now is far from perfect, but I've been doing some more
research on DBus and will clean this up a bit in the next couple of days,
cause the way I'm doing it now is not very clean and there are better options.

The "org.kde.kget.service" tells DBus that KGet can be automatically started,
so even if it isn't used in KGet internally, it's nice to provide the option
of starting KGet via DBus.


2.

That's what I thought, but not what happens.... (at least not with  
KGet-2.3.1/KDE-4.3.1, might have changed in trunk).

Can you verify these scenarios:

(A) 3 x the same URL:
- in krunner, type: "http://a"
- choose "download with kget"
- leave the dialog open
- in krunner, type: "http://a"
- choose "download with kget"
-> now the dialog contains "http://a" twice
- leave the dialog open
- again in krunner, type: "http://a"
- choose "download with kget"
-> now the dialog contains "http://a" once again

(B) 3 different URLs:
- in krunner, type: "http://a"
- choose "download with kget"
- leave the dialog open
- in krunner, type: "http://b"
- choose "download with kget"
-> now the dialog contains "http://a" and "http://b"
- leave the dialog open
- again in krunner, type: "http://c"
- choose "download with kget"
-> now the dialog contains only "http://c"


Yours, Tomas


On Thursday 01 October 2009 14:03:37 Lukas Appelhans wrote:

> Sorry, I got some surgery on tuesday, so I wasn't able to respond more
> quickly...
>
> 1) I have not much of a clue, but do we really need that file?
>
> Anyway: we call kget-dbus as well from kget_test_transfers app, so maybe
>  check how we do it there... :)
>
> 2) yeah the newtransferdialog should always add urls if the method gets
>  called and it is still open...
>
> Lukas
>
> Am Dienstag 29 September 2009 10:42:56 schrieb Tomas Van Verrewegen:
> > Ok. Got my SVN account details, so I committed this.
> >
> >
> > 2 comments:
> >
> > 1. org.kde.kget.service needs to be added to "kdenetwork/kget/desktop".
> > But I don't really know how to tell cmake to put the correct install
> > prefix in the entry: "Exec=/usr/bin/kget".... Anyone?
> >
> > 2. Because "showNewTransferDialog()" blocks, krunner became unresponsive
> > as long as the "New Download" dialog was open. I switched the DBus code
> > to an "asyncCall" to work around this.
> > But....
> > I stumbeled on some weirdness in the showNewTransferDialog()
> >  implementation: Reproduce like this (using runner from svn):
> > - in krunner, type: "http://a"
> > - choose "download with kget"
> > - leave the dialog open
> > - again in krunner, type: "http://a"
> > - choose "download with kget"
> > -> now the dialog contains "http://a" twice
> > - leave the dialog open
> > - again in krunner, type: "http://a"
> > - choose "download with kget"
> > -> now the dialog contains "http://a" once again
> >
> > This behaviour only occurs when the URL's you enter are identical.
> > I haven't found the time yet to investigate this further.
> > If you like, I can put this in a bug report...
> >
> >
> >
> > Cheers, Tomas
> > _______________________________________________
> > Kget mailing list
> > Kget@...
> > https://mail.kde.org/mailman/listinfo/kget
>
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>

_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget

Hey!

Can't get the Runner to do anything useful, I think you've forgotten to add
the .service-file?

Lukas

Am Donnerstag 01 Oktober 2009 16:10:35 schrieb Tomas Van Verrewegen:

> No prob.
>
>
> 1.
>
> I figured it out in the meantime :)
>
> I also checked "test_transfers.cpp". Here "KRun::runCommand(...)" is used
>  to start KGet if it isn't already running.
>
> DBus offers the same functionality (see
>  http://dbus.freedesktop.org/doc/dbus-
>  specification.html#message-bus-starting-services ).
>
> The code I'm using now is far from perfect, but I've been doing some more
> research on DBus and will clean this up a bit in the next couple of days,
> cause the way I'm doing it now is not very clean and there are better
>  options.
>
> The "org.kde.kget.service" tells DBus that KGet can be automatically
>  started, so even if it isn't used in KGet internally, it's nice to provide
>  the option of starting KGet via DBus.
>
>
> 2.
>
> That's what I thought, but not what happens.... (at least not with
> KGet-2.3.1/KDE-4.3.1, might have changed in trunk).
>
> Can you verify these scenarios:
>
> (A) 3 x the same URL:
> - in krunner, type: "http://a"
> - choose "download with kget"
> - leave the dialog open
> - in krunner, type: "http://a"
> - choose "download with kget"
> -> now the dialog contains "http://a" twice
> - leave the dialog open
> - again in krunner, type: "http://a"
> - choose "download with kget"
> -> now the dialog contains "http://a" once again
>
> (B) 3 different URLs:
> - in krunner, type: "http://a"
> - choose "download with kget"
> - leave the dialog open
> - in krunner, type: "http://b"
> - choose "download with kget"
> -> now the dialog contains "http://a" and "http://b"
> - leave the dialog open
> - again in krunner, type: "http://c"
> - choose "download with kget"
> -> now the dialog contains only "http://c"
>
>
> Yours, Tomas
>
> On Thursday 01 October 2009 14:03:37 Lukas Appelhans wrote:
> > Sorry, I got some surgery on tuesday, so I wasn't able to respond more
> > quickly...
> >
> > 1) I have not much of a clue, but do we really need that file?
> >
> > Anyway: we call kget-dbus as well from kget_test_transfers app, so maybe
> >  check how we do it there... :)
> >
> > 2) yeah the newtransferdialog should always add urls if the method gets
> >  called and it is still open...
> >
> > Lukas
> >
> > Am Dienstag 29 September 2009 10:42:56 schrieb Tomas Van Verrewegen:
> > > Ok. Got my SVN account details, so I committed this.
> > >
> > >
> > > 2 comments:
> > >
> > > 1. org.kde.kget.service needs to be added to "kdenetwork/kget/desktop".
> > > But I don't really know how to tell cmake to put the correct install
> > > prefix in the entry: "Exec=/usr/bin/kget".... Anyone?
> > >
> > > 2. Because "showNewTransferDialog()" blocks, krunner became
> > > unresponsive as long as the "New Download" dialog was open. I switched
> > > the DBus code to an "asyncCall" to work around this.
> > > But....
> > > I stumbeled on some weirdness in the showNewTransferDialog()
> > >  implementation: Reproduce like this (using runner from svn):
> > > - in krunner, type: "http://a"
> > > - choose "download with kget"
> > > - leave the dialog open
> > > - again in krunner, type: "http://a"
> > > - choose "download with kget"
> > > -> now the dialog contains "http://a" twice
> > > - leave the dialog open
> > > - again in krunner, type: "http://a"
> > > - choose "download with kget"
> > > -> now the dialog contains "http://a" once again
> > >
> > > This behaviour only occurs when the URL's you enter are identical.
> > > I haven't found the time yet to investigate this further.
> > > If you like, I can put this in a bug report...
> > >
> > >
> > >
> > > Cheers, Tomas
> > > _______________________________________________
> > > Kget mailing list
> > > Kget@...
> > > https://mail.kde.org/mailman/listinfo/kget
> >
> > _______________________________________________
> > Kget mailing list
> > Kget@...
> > https://mail.kde.org/mailman/listinfo/kget
>
> _______________________________________________
> Kget mailing list
> Kget@...
> https://mail.kde.org/mailman/listinfo/kget
>

_______________________________________________
Kget mailing list
Kget@...
https://mail.kde.org/mailman/listinfo/kget