[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:       Simon Hausmann <shaus () helios ! Med ! Uni-Magdeburg ! DE>
Date:       2000-03-24 14:47:20
[Download RAW message or body]



On Fri, 24 Mar 2000, David Faure wrote:

> > On Thu, 23 Mar 2000, Cristian Tibirna wrote:
> > 
> > > - if I split to 2 views, link the (e.g.) left one (master) to the right
> > > one, then unlink them, last mouse click pass the focus to the former
> > > master, but doesn't refresh the green led in the status bar. Have to
> pass
> > > focus to former slave view and back again to former master to have the
> led
> > > functional again
> > 
> > I guess that this is due to the fact that we don't catch FocusIn in
> > the partmanager anymore?
> Looks like.
> 
> > Hrmmm, I wish we could fix that... if it just wouldn't break kspread..
> I forgot about this issue. Yes, we need to look into it.
> It worked great before KOffice was KPartized...

Did koparts really catch FocusIn?

> > Hm, perhaps this was some qt bug and is fixed now in beta3?
> > (I'll check that)
> Keep us up to date !

Bad news :-( It still doesn't work :-(

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.

But perhaps I'm wrong here and it's correct that the toplevel window
receives a FocusIn event.
 
> > > - kimap files are mimetyped as executable .desktop files.
> > 
> > David, any idea how to solve this?
> Well, they are desktop files... Just not executable, but the same problem
> happens with Link and Service desktop files and some other (Well, you 
> can execute a link by clicking on it, but for instance it accept drops 
> whereas it shouldn't). And with Type=MimeType same problem with drops.
> 
> > 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...

Okay ;-)

> > > - 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.... ;-)

Ciao,
 Simon

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