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
