GTK+ Forums

Discussion forum for GTK+ and Programming. Ask questions, troubleshoot problems, view and post example code, or express your opinions.
It is currently Sat Apr 19, 2014 7:21 am

All times are UTC




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: slow hiding of filechooser dialogs
PostPosted: Mon Sep 24, 2012 6:38 pm 
Offline
Familiar Face

Joined: Sat Sep 22, 2012 7:06 am
Posts: 6
Hi,
another question.
I built my file dialogs in glade.
I have a file loading dialog and a file saving dialog (for simplicity I decided to make two separate dialogs).
After file loading (multiple files) I do the following:
Code:
response = self.loadimages_dialog.run()
self.loadimages_dialog.hide()
if response == 0: #clicked OK
                global fileNames
                global filenamesstring
                fileNames = self.loadimages_dialog.get_filenames()
                filenamesstring = ""
                for fileName in fileNames:
                        # Make sure that spaces etc. in path/file names are
                        # covered by putting them within spaces
                         filenamesstring += "\"" + fileName + "\" "
else:
               print "user pressed Cancel in the filechooser"
               self.statusbar.push(0, "User canceled files selection")

After this no references are made anymore to the dialog and the program continues. It takes ages though before the dialog gets hidden.
Code:
response = self.filesaver_dialog.run()
self.filesaver_dialog.hide()
if response == 0: #clicked OK
                image_name = self.filesaver_dialog.get_filename()
                print "image_name choosen: " + str(image_name)
else:
                image_name = "Canceled"
                print "user pressed Cancel in the filechooser"
                self.statusbar.push(0, "User pressed cancel")

And that's the last interaction with the file dialog. The program continues with the rest of it's stuff. However, it takes forever before the dialog is hidden.

What's doing that?
I also tried a self.filesaver_dialog.destroy(), (which I don't want to do as I can't reuse the dialog anymore,) but just to test. That dialog is just as slowly destroyed as it was hidden in the other action.


Top
 Profile  
 
 Post subject: Re: slow hiding of filechooser dialogs
PostPosted: Mon Sep 24, 2012 7:45 pm 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 709
Location: UK
Hi,

Do do not know Python very well but this could be what is happening.

After you request that the dialog is to be hidden, there is code that does file saving or loading. This loading or saving takes some time to do. The actual hiding of the dialog only happens when control is returned to the GTK+ main loop, this is done for performance reasons so that all graphical updates are queued together. Since control does not return quickly to the GTK+ main loop then the hiding is delayed.

The best solution would be to add the loading or saving as a low priority call back using glib.idle_add() http://developer.gnome.org/pygobject/stable/glib-functions.html

_________________
E.


Top
 Profile  
 
 Post subject: Re: slow hiding of filechooser dialogs
PostPosted: Wed Sep 26, 2012 12:42 pm 
Offline
Familiar Face

Joined: Sat Sep 22, 2012 7:06 am
Posts: 6
Thanks.

As I'm only a beginner it took some time find it out but I have it now working in a slightly different way (googling from one direction into a slightly different direction).
I split up my function into smaller subfunctions and used
Code:
gobject.idle_add(gui_update, "some text to initialize")
gobject.idle_add(first_sub_function)
gobject.idle_add(gui_update, "something else I can update")
gobject.idle_add(second_sub_function)
gobject.idle_add(gui_update, "more text")
gobject.idle_add(third_sub_function)
gobject.idle_add(gui_update, "finshing up text")

This makes it much easier (at least for me) and it makes sure that all commands are nicely executed after each other. It complicates the python script due to more subfunctions and calls and so on, but I can live with that.

The gui_update function has quite a few parameters to make it possible to update the statusbar, some other progress message, a treeview, etc).

One of my sub_functions contains an "subprocess.Popen", immediately followed by a while loop that checks the outcome. When OK the while loop and thereby subfunction can end/close. This leaves my Gui usable for status messages and so on, and it doesn't result in a Gui that blocks and changes to a dark unresponsive "thing". I'm still looking into the "subprocess.communicate" callback but that's not working yet, hence the less optimized while loop.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group