[maemo-developers] mbarcode/maemo-barcode dialog oddity and progress report

[From: Graham Cobb]

On Thursday 15 October 2009 07:50:21 Kimmo Hämäläinen wrote:
> On Thu, 2009-10-15 at 01:09 +0200, ext Simon Pickering wrote:
> > So all in all it's still work in progress, but it does at least work
> > well enough to test. Except that I use dialogs to ask the user if they
> > want to open a decoded URL/add a decoded vCard, and if these dialogs are
> > displayed the UI locks up straight afterwards. If I comment them out the
> > code continues quite happily after opening the browser/adding the URL,
> > so the fault must presumably lie with the dialogs.
>
> What kind of windows you are playing with?  We have a special feature in
> Fremantle where Gtk+ dialogs do not use pointer grabs anymore (*, so
> it's possible that Gtk+ gets confused there when it does not receive the
> pointer events.

Ah, yes, I had similar problems in GPE.  I haven't looked at your code, Simon 
(sorry) but in GPE I had dialog boxes with a similar problem.  It was even 
more noticeable in scratchbox where, after the dialog is dismissed, the 
background would reappear and my application window was nowhere to be seen.  
On the device, the application window appeared to be visible but clicks were 
going to the desktop instead (so, for example, I could invoke a desktop 
widget if I touched in the right place)!

In most cases the problem seemed to be that the existing code used the 
following sort of construct:

gtk_window_set_transient_for
	(GTK_WINDOW (dialog), GTK_WINDOW (gtk_widget_get_toplevel (widget)));

In most cases I replaced that with setting it as transient for my main window 
(a HildonStackableWindow).  I don't know what the toplevel widget is on 
Hildon but whatever it is it doesn't seem to be useful!

In at least one case, the right thing to do was to replace the whole dialog 
with a HildonStackableWindow and create a Fremantle-style UI with a stacked 
window.

No idea if that will help in your case. 

Graham