Re: python2.5 - unnecessary multiple processes forked
Hi, ext Jayesh Salvi wrote: On 1/3/08, Jayesh Salvi [EMAIL PROTECTED] wrote: Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app. Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape pluginshttp://code.google.com/p/altcanvas/wiki/GimpPublishr. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles. I found out that the sluggishness observed was because of the Microb engine. Last night when I tried by switching to Opera engine, it worked very fast. So it's not the multiple threads that hildon or GTK fork, that cause performance issues. You could also try disabling Flash from the Browser to see whether it helps. - Eero Thanks, Jayesh On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I found out that the sluggishness observed was because of the Microb engine. Last night when I tried by switching to Opera engine, it worked very fast. So it's not the multiple threads that hildon or GTK fork, that cause performance issues. On 1/3/08, Jayesh Salvi [EMAIL PROTECTED] wrote: Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app. Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape pluginshttp://code.google.com/p/altcanvas/wiki/GimpPublishr. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles. Thanks, Jayesh On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Thanks for all the info. I am planning to run the FileChooserDialog in a different process than my rest of the app. That may sound weird, but it fits my application's context alright. My pygtk app will run as a service, so that it can be invoked by other applications as well. FileChooserDialog is just one entry point into my app. Detail of my app if you are interested: It is a pygtk GUI that lets you upload images to Flickr or Picasaweb. I have already published the code as Gimp, Inkscape pluginshttp://code.google.com/p/altcanvas/wiki/GimpPublishr. Now I am putting the same code on maemo. I will soon release a .deb file once I iron out some wrinkles. Thanks, Jayesh On 1/2/08, Eero Tamminen [EMAIL PROTECTED] wrote: Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
ext Frantisek Dufka [EMAIL PROTECTED] writes: I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. I think you are correct. I heard that some gnome-vfs plugins, for example UPnP, start their own thread (or something like that). But I'm a network guy, I know jack about our UI. So I might be wrong here. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Hi, ext Jayesh Salvi wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. They are not processes, but gnome-vfs worker threads (you don't want the UI to freeze e.g. until network timeouts). So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. They remain in the gnome-vfs thread pool even after the UI component is destroyed. The memory usage issue is elsewhere. You could look into your program Private_Dirty memory usage in /proc/PID/smaps file. Or run the same program on your PC under Valgrind Massif plugin: http://maemo.org/development/tools/doc/valgrind http://valgrind.org/docs/manual/ms-manual.html I'm not sure how well that tells about issues in Python code. Is there any memory profiler for Python applications? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Hi, don't believe everything that 'top' tells you. :) 'top' on Linux also lists threads as standalone processes, thus giving the illusion of wasting lots of memory. If the entries show exactly the same amount of memory, then you can often assume that they share the same amount of memory. Cheers, Martin 2007/12/31, Jayesh Salvi [EMAIL PROTECTED]: forgot to cc the list. On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: BTW, are you sure the memory situation is really worse because of this? What I see is, in 'top' all these processes show same percentage of memory utilization under %MEM column (17% or so for each of them). I am not sure if this is virtual memory or physical memory. My application logic flow goes like this: It gets the filename from the user (hence FileChooserDialog) and after some processing it has to open a URL in the browser. It sends an RPC request to the browser. What I am observing is, the browser takes a long time to open that URL and by the time it has opened it, my app gets killed without any error message. Once I had seen a low memory message during this process, but now my parent app gets killed without any such message. I am still trying to establish if the above behavior is only because of memory over consumption. I will update as I make progress. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
On 12/30/07, Jayesh Salvi [EMAIL PROTECTED] wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: ... Do you have any tips, as to what might be going wrong? With the following C code[1] the same problem happens. [1] http://pastebin.com/m2d7c9783 -- Lauro Moura INdT - Instituto Nokia de Tecnologia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis [EMAIL PROTECTED]: I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I tried Lauro's C example in scratchbox environment and see that it's indeed forking 4 more processes. So this is not a python problem. This problem's root cause seems to reside in the widget library. I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? On 12/31/07, Martin Grimme [EMAIL PROTECTED] wrote: Especially make use of gc.collect() after you have worked with gdk.Pixbuf objects. They won't free their memory otherwise. It's a good habit to free unused Pixbufs with del and run the garbage collector afterwards. And be aware that if a class overrides the __del__ method (some sort of destructor), it won't be freed by the garbage collector at all. Cheers, Martin 2007/12/31, Alex Iliadis [EMAIL PROTECTED]: I recommend using the garbage collector module manually to override the defaults. Python for some reason doesn't reclaim memory fast. So if you put in your code: import gc gc.collect() (at the right spots, probably after the file chooser dialog and after some memory intensive tasks). You should notice a lot of memory being free'd up. -Alex On Sunday 30 December 2007 05:20:34 pm Jayesh Salvi wrote: Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: I can't imagine any valid reason for gtk/hildon to fork more processes just to show a GUI dialog. Does anyone know? I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: I'm not sure but think it is because of gnome-vfs. Don't know proper terminology but maybe each vfs 'provider' in the dialog (like mmc, phone etc.) starts new process or something like that. That sounds correct. I experimented with other dialogs that do no involve filesystem access (NamePasswordDialog, SortDialog), and they do not fork any extra processes. So this behavior seems valid for FileChooserDialog. But then I should be able to cleanup those extra processes when I am done with the FileChooserDialog. I called destroy() on the dialog object, but that doesn't help. I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. They keep occupying the same amount of memory as their parent. This is really taxing on my n770. If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
Jayesh Salvi wrote: I guess there isn't much to do - for an app programmer at least. I found the same behavior with osso_pdfviewer. It also uses hildon's FileChooserDialog. But even before that dialog is invoked, multiple processes are forked. ... and they do not disappear until their parent exits. I think once they are initialized they don't go away since you may actually need them if user clicks some file in the dialog which is 'provided' by them. They keep occupying the same amount of memory as their parent. This is really taxing on my n770. If this is the default behavior of gnome-vfs based GTK apps, then I hope it gets improved for embedded devices. BTW, are you sure the memory situation is really worse because of this? If yes then maybe this is specific to python. In C forked process does not add much memory overhead because memory pages in childs are shared with the parent until they are modified. So I guess when programming in C this is not a big issue so nobody cared so far. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: python2.5 - unnecessary multiple processes forked
forgot to cc the list. On 12/31/07, Jayesh Salvi [EMAIL PROTECTED] wrote: BTW, are you sure the memory situation is really worse because of this? What I see is, in 'top' all these processes show same percentage of memory utilization under %MEM column (17% or so for each of them). I am not sure if this is virtual memory or physical memory. My application logic flow goes like this: It gets the filename from the user (hence FileChooserDialog) and after some processing it has to open a URL in the browser. It sends an RPC request to the browser. What I am observing is, the browser takes a long time to open that URL and by the time it has opened it, my app gets killed without any error message. Once I had seen a low memory message during this process, but now my parent app gets killed without any such message. I am still trying to establish if the above behavior is only because of memory over consumption. I will update as I make progress. -- --- Jayesh -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
python2.5 - unnecessary multiple processes forked
Hi, I am porting a pygtk application to maemo. It works alright, but I noticed that it was consuming lot of memory, preventing me from opening other applications. When I investigated, I found that my python application was forking 4 more instances of itself, each one identical in memory footprint. Thus they consumed nearly 60-70% of my memory. So I ran my application using pdb and narrowed down to a code segment that was leading to multiple instances of the process. It turned out that when I call run() on hildon.fileChooserDialog object, the dialog opens and at that moment in the top I see 4 more instances being forked. I fail to understand this behavior. I replaced the hildon widgets by pure gtk widgets and I see similar behavior, except that 2 more instances get forked. Also when using gtk.FileChooserDialog, these new instances get created in the instantiation of the dialog object, rather than call to run(). (code included below) So to further explore the problem, I ran same application on my desktop with gtk widgets. But I verified that when fileChooserDialog's run is called, there are no additional instances of python. I am running this code on n770, with 2007 HE and python2.5 runtime. My application code is pure python and not using any additional libraries. In fact following would be a simpler version of it to reproduce the problem: import gtk import hildon #window = gtk.Window(gtk.WINDOW_TOPLEVEL) #fileChooser = gtk.FileChooserDialog( # title=Choose a photo to publish, # buttons=(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL, # gtk.STOCK_OK, gtk.RESPONSE_OK)) fileChooser = hildon.FileChooserDialog( window,gtk.FILE_CHOOSER_ACTION_OPEN) result = fileChooser.run() if result == gtk.RESPONSE_OK: print fileChooser.get_filename() Do you have any tips, as to what might be going wrong? This problem is fatal at least on n770 - it will trigger low memory message when other applications are used on the side. Any help will be useful. Thanks, -- --- Jayesh ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
