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

List:       kfm-devel
Subject:    RE: fast, dirty, but hopefully useful (clueless user report :-)
From:       David Faure <David.Faure () cramersystems ! com>
Date:       2000-03-24 14:56:48
[Download RAW message or body]

> Did koparts really catch FocusIn?
Perhaps not, but then again... perhaps that it doesn't need it.
That would be an easy solution, BTW.
A parameter to the PartManager constructor, to enable/disable
handling of FocusIn events...
Does KOffice need it ?

> I'm totally lost with this :-(
> Here's how you can reproduce it:
> edit partmanager.cpp and remove the comments from FocusIn in the
> eventFilter() . (compile and install ;-)
> Launch kspread, embed another kspread document into the root document.
> Activate the child document. Bring up the insert-part-dialog, 
> choose some part and press OK. In 99% of all cases it activates the
toplevel shell
> (here) , while the focus *should* go back to the embedded child.

Yes, I remember you told me all this, and I still didn't have time
(and forgot) to look into this, so we're still at the same point.
I'll try to have a look this weekend.

> But perhaps I'm wrong here and it's correct that the toplevel window
> receives a FocusIn event.
That's the bit I'm unsure of.
A bit of debug output will help (like, printing focusin events
in Qt, for all apps, and watching what happens with 'normal' apps).

> > > I mean: Should we open up each .desktop file with KConfig 
> and look if
> > > there's an Exec entry? (sounds like overhead to me)
> > 
> > For the kimap files there is an easy solution: define a mimetype
> > (i.e. just look for the extension).
> > For the non-Application desktop files, there is no other way than
> > opening... either manually (huh) or simply by defining them in 
> > the magic file (requires separate mimetypes).
> > The problem is that we don't use KMimeMagic when we have a known
> > extension...
> > All this comes from the fact that the same extension was chosen for
> > all those files, even though they are quite different.
> > I think we have to live with that choice...
[second thought]
Although... if we accept to open up any file (to get its mimetype),
why not do it on desktop files too... Simply by using KDesktopFile
on any .desktop file, to know what it is and what can be done with it.
Actually makes sense (for local dirs of course).

> > > > - if, once in a dirtree mode, the slave view is passed 
> > > > in tree view, konqui crashes (not so reproductible)
> > > 
> > > Any idea how to reproduce this one? :)
> > Standing on a hammoc ? (French saying, not sure it translates) :-)
> 
> Hmm, not sure what it means >;-)
> (got a wild guess, but.... ;-)
Wild ? You surely got it then ;-)

David.

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