Dear Miguel,
 I'm trying your patch to prepare it for inclusion in svn. It seems fine and 
look quite nice, even if I think we will have still to work on the appearence. 
Main problem now is that on my Mac (Qt/Cocoa 4.7.0) your event loop does not 
prevent the widget to loose focus (the window is not quite modal). So for 
example you can return to the canvas, type or open a replace dialog inside a 
running replace dialog.

I was wondering if on your machine the widget is really modal or not?

According to the Qt docs you cannot have a non top level widget modal.

A possible solution (on the short term) would be to check if we loose focus and 
in the case dismiss the widget and quit the run loop. Other solution would be 
to prevent the focus to go away but I do not find any possibility for this in 


On 2 nov. 2010, at 19:40, Miguel de Benito Delgado wrote:

> Hi,
>   I'm sorry for all the noise (meaning my duplicate email), I wasn't 
> receiving my mails back from the list and I thought they hadn't got through 
> some spam filter, so I sent yet another one. I just checked and saw your 
> reply, which by the way I don't fully understand.
> My first issue is already solved, as you can see in my last post, but the one 
> with the canvas not being repainted isn't. You said:
> I doubt that reimplementing an event loop would be a good solution. Probably 
> Qt allows for passing all incoming events to a subwidget.
> Indeed it does, though I think they are actually propagated to parent 
> widgets, which is what the main window is with respect to the status bar. And 
> in what I wrote, as far as I understand it, no event other than a key press 
> is being handled, so there should be no "hijacking".  I'll look into it and 
> get back to you when I have a solution.
> Regards,
> ________________
> Miguel de  Benito.
> _______________________________________________
> Texmacs-dev mailing list

Texmacs-dev mailing list

Reply via email to