Re: gksu 1.1.0, new API

[Filip Van Raemdonck]

Hi all,

On Thu, Jan 29, 2004 at 01:46:35PM -0200, Gustavo Noronha Silva wrote:
> 
> I am right now building the final deb packages for gksu 1.1.0, I still don't
> know whether I will make a formal release or a 'just for the development'
> one.

How about daily cvs snapshots until the API has cleared out? That way
people won't be tempted even to try and port their apps to a development
release, unless they're serious about checking out the API. (And realize
that it *will* change and eat their mail. Or something. ;)

> http://beterraba.no-ip.org/gksu/

Seems to be down ATM?

> I would very much like comments. The gksu demo-and-command-line-
> frontend-to-the-library-hey-ho app is already ported. The only serious
> caveat in the implementation now is that libgksu does *not* init the
> gtk library anywhere yet.

It probably should. Applications that use GTK+ themselves can then use
gksu_init at the start; programs that don't can call it right before
calling other gksu_* calls.

Hmm, can gtk_init be called multiple times with no side effects?
(compared to a single call)
If not, gksu_init should probably take care of that - and off course, if
it shouldn't be inited multiple times itself, either, take care of that
too.

One thing which seemed odd to me in libgksu 1.0.0 was that it didn't want
in-out arguments for the argv/argc parameters, contrary to gtk_init. Why
was this so?

> This is the new API:
> 
> GksuContext* gksu_context_new ();
> void gksu_context_free (GksuContext*);
<...> 
> 
> gchar* gksu_ask_password (GksuContext*);
> gboolean gksu_run (GksuContext*, gchar*);
> gboolean gksu_sudo_run (GksuContext*, gchar*);
> void gksu_set_user (GksuContext*, gchar*);
> const gchar* gksu_get_user (GksuContext*);
> 
> [...] 
> /* 
>   all the getters and setters functions remain mostly the
>   same, but receiving a GksuContext
> */

(just commenting on design, not functionality. I'll have to take a closer
look first)
Seems a bit awkward. Why aren't these methods on GksuContext instead of
plain gksu functions, if they all require a context to begin with?

And as others have already pointed out, this will very likely also affect
the ease with which to make python bindings.

> TODO (generated by devtodo, databse [.todo] on the CVS):
> 
> - create a libgksu-common package with the translations and images
>   (added Thu Jan 29 12:48:08 2004, incomplete, priority high)

Why the images? Libgksu will need them, so it'll always have to depend on
libgksu-common, and it makes no sense to split anything out in that case.
As for the translations, they could be lived without.

Also, I prefer libgksu-data. But that's just me :p


Regards,

Filip

-- 
Plug-and-Play is really nice, unfortunately it only works 50% of the time.
To be specific the "Plug" almost always works.
        -- unknown source