[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gksu 1.1.0, new API
Gustavo Noronha Silva
Re: gksu 1.1.0, new API
Mon, 16 Feb 2004 21:36:15 -0300
Sorry for the delay, I'm CCing carlos, because of the authserver
Em Sat, 07 Feb 2004 16:14:08 +0100, "Sven Herzberg, GNOME Deutschland"
> I think the preferred way should be to simply have to libs libgksu
> (providing the auth stuff, should -- IMHO -- just be linked against
> glib, gthread and gobject) and libgksuui (which includes several
> re-usable code like authentication dialogs); then we have the gksu
> application which simply provides its own main window (as I don't think
> that this window might be reused anywhere).
hmmm, that looks good, but do you have a suggestion
on what kind of API we'd have then?
I thought about this quite a bit, but I don't know if it should
be a long term or short term goal.
Better make the right thing all at once, I think, but then,
I would not like to have gksu1.0 as 'stable gksu' for a
long time, as its API is too flawed, IMO.
> I'd also strongly vote for an integration into GNOME 2.8 (which
> happens to be released about september). Until a module proposal we
> should have the gksu client to be able to replace the current gnome run
> dialog and have some python bindings to be used within a new version of
> the gnome system tools.
That's feasible, let's work on that. Are you aware of carlos' project
of an authorization server? I agreed with him that it is a much prettier
solution, but I am not sure it's doable for gnome2.8...
Maybe we should start thinking about that? Maybe have libgksu become
a client for that server when it is built?
> Then we could ask the nautilus maintainers whether they want to
> support multi-user nautilus (e.g. 'Open as other user...') and we should
> try to get this done too.
> This way we could get widespread testing and lots of demo-code
> demonstrating how to use gksu correctly.
> > - have gksuexec show an option to select between su and sudo
> > (added Thu Jan 29 13:11:26 2004, incomplete, priority medium)
> I'd prefer to hide the backend from everything that uses the library. We
> might want to have a GConf-Key for advanced users to select the
> authentication method (at least until we get a way to ask sudo whether
> or not we're able to execute the command)
Looks like a good idea. Need to think a bit more on gksu's main
address@hidden: Gustavo Noronha <http://people.debian.org/~kov>
Debian: <http://www.debian.org> * <http://www.debian-br.org>
"Não deixe para amanhã, o WML que você pode traduzir hoje!"