[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Bug#30768: marked as done (local html files can be translated) by David Faure <david@mandrakesof
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-08-28 18:45:23
[Download RAW message or body]

(Moving to kfm-devel, konq-bugs is too crowded)

On Mardi 28 Août 2001 21:15, Simon Hausmann wrote:
> On Mon, Aug 27, 2001 at 11:34:06PM +0200, David Faure wrote:
> > > > Tricky. For the babelfish plugin, we need a way for the plugin to know what
> > > > the current URL is, and disable it... Sounds like we need to listen to the
> > > > KParts's OpenURLEvent - right, Simon ?
> > > 
> > > Hm, yes, but that event isn't sent to the sender itself :}
> > 
> > Hmm, two problems here indeed.
> > * The sender part doesn't get it.
> > * Even if it would, a plugin of that part wouldn't get the event either, right ?
> > Ah, it would install an event filter on its part ? Ok, that bit is ok then....
> > 
> > Would there be any problem in sending the event back to the sender too ?
> > In some cases the part would have to check if the sender is itself, before reacting,
> > I guess (but where to we currently use this event anyway, except in konq_mainwindow ?)
> 
> Yep, I guess it's safe to add another roundtrip :)
> 
> Well, in fact it arises the question whether to ditch the direct openURL call
> in favour of an event based approach where the default event handler in Part
> makes a call to openURL :-)
> 
> Of course that requires an additional flag to allow a distinction between
> a notification event and a real request event.

Hmm, let me summarize the current situation :

1- Part -> MainWindow :  emit openURLRequest()
2- Mainwindow -> [View->] Part :    openURL() call
3- [View->] Mainwindow -> all other parts :   KParts::OpenURLEvent.

Ah, I see. 1- is called a request, but is unrelated to what we're talking about.
It's just that the similar naming confused me for a minute ;)

Your idea would be to merge 2- and 3- into an openurlevent that has a flag for
"this is really for you, or it's just an info that it's for someone else" ?
Sounds a bit dirty to me (and breaks quite a lot ;)
Also, it would create some sort of a race condition: unless we make sure we 
talk to the right view first, we might send a notification about something that
hasn't happened yet ? Not good.

Hmm, I think it's just cleaner if we keep the real openURL() and the notification separated.
It's more flexible.
Imagine we decide that the notification should be sent once the URL opening
has been fully completed... Hmm, one could use the current event and connect to the
part's completed() signal, to do that, I guess.

Not convinced about the gain here (other than avoiding sending the event
to the part, which should know very well that it opened a URL - it knows,
but its plugins don't know). I think the performance penalty is very very small.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/ , http://www.konqueror.org/
KDE, Making The Future of Computing Available Today

[prev in list] [next in list] [prev in thread] [next in thread]