Re: moving egg_screen_* into libgnomeui

Hi Havoc,

On 16 Sep 2002, Havoc Pennington wrote:

>
> 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.

	Yeah, you're right. The naming is particularily lame.
>
> 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. ;-)

	Sure. I had already logged the first to gdk bugzilla. I
suppose the second one wold make sense there if the first one does.

>
> > /* 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.

	Agreed. I'll start a GEP on that ...
>
> > 	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?

	I don't see them being useful outside of libgnomeui, no.
>
> 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.

	Interestingly gspawn allows both behaviours - with the execve
behaviour taking precendence over the ChildSetupFunc. Why is it broken
to use execve in this case ?

	So, I'd actually be more concerned about getting the gnome-url
and gnome-help functions in before 2.2 than the gnome-exec ones. The
gnome-exec ones are just wrappers functions so we're not copying to
much code around the place using libegg - but the gnome-url and
gnome-help ones can't be wrapped so libegg actually contains a copy of
their implementations.

Good Luck,
Mark.