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