Re: moving egg_screen_* into libgnomeui
Havoc Pennington <[email protected]> 16 Sep 2002 21:06:23 -0400
| Newsgroups | gmane.comp.gnome.lib.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi, I think the naming of these functions is poor - what's a GnomeScreen? It should be gnome_execute_async_with_screen() (or on_screen(), whatever gtk normally does), gnome_url_show_with_screen(), etc. Mark McLoughlin <[email protected]> writes: > /* Utility methods for changing $DISPLAY to make > * a given screen the default screen. > */ > char *gnome_screen_exec_display_string (GdkScreen *screen); > char **gnome_screen_exec_environment (GdkScreen *screen); > These names don't make sense to me - what does the 'exec' mean? Doesn't the first one for example just return ":0.x" where .x is the screen number (assuming display 0)? I don't really understand why these functions belong in libgnomeui, if they do not belong in GTK. There's nothing gnome about them. libgnomeui should be the layer that glues GTK to above-GTK technologies, e.g. glue GTK to bonobo and gconf and the help browser. These don't fit in to the clearly-defined functional purpose that libgnomeui should have, they are a step down the dark path to libgnome* as dumping ground. ;-) > /* Multiscreen variants of the gnome-exec family > */ > int gnome_screen_execute_async (GdkScreen *screen, > const char *dir, > int argc, > char * const argv []); > int gnome_screen_execute_shell (GdkScreen *screen, > const char *dir, > const char *command); > gboolean gnome_screen_execute_command_line_async (GdkScreen *screen, > const char *command, > GError **error); > Isn't the whole gnome-exec family deprecated? (If not, shouldn't it be?) Should we really be adding extra variants? My feeling is that we should consider gdk_spawn_* here. > And to libgnome we would need to add variants of the gnome-url > and gnome-help methods which you can specify the enviroment of the > spawned viewer: Are these generally useful, or should they be a private API used only by libgnomeui? Also, a more generic approach is as with g_spawn, a "ChildSetupFunc" instead of providing the environment. Do the with_env functions replace or supplement the environment? If they replace it's probably broken to do that, if they supplement the function names are misleading as you would expect execve() behavior. Havoc