Re: GTK - DISPLAY
В Пнд, 04/07/2005 в 18:24 +0530, Kala B пишет: > Hi, > I have a query regarding GUI applications on Linux. > > I have a daemon which needs to collect some user information, on a > particular event. It has some GTK based GUI (which is a simple > password collecting dialog). This daemon exposes some APIs, which > applications could use. For a particular API, I need to prompt for a > password from the daemon. I think, the best way would be to exec the > GUI. But I am not sure, where the GUI would appear, when there are > multiple desktops. > Could you give me some ideas on how this could be best implemented. > > thanks! > Kala B. Hello Kala. You've wrote to a wrong list, this is devoted to gtk development, not to development with gtk. Probably gtk-app-devel-list@gnome.org is more suitable for such kind of questions. About your application design, I think you are doing something unclear. Usually, client should ask for a password and then pass it to server (encoded of course). As I've understood you are going to ask for a password in server itself. That's not a good idea I think. > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Tue, 2005-07-05 at 12:29 -0400, muppet wrote: > On Jul 5, 2005, at 7:57 AM, Tim Janik wrote: > > > On Tue, 5 Jul 2005, Gustavo J. A. M. Carneiro wrote: > > > >> Currently [construction properties will] be set by the GObject > >> system at the wrong time, i.e. before the python proxy object is > >> attached to the GObject instance. > > > > i'd rather say, you are trying to setup your proxy at the wrong > > time, i.e. after _init() which is too late. if you properly setup > > your proxy in _init() construct properties will work fine out of > > the box. > > For what it's worth, this is similar to the approach we took with > gtk2-perl. The perl+C combination object is set up the first time > the GObject is marshaled to perl; if that happens to be in a > set_property override as part of g_object_new(), then so be it. This > works the same way for all GObjects, regardless of whether they are > derived in perl code. I think we already talked about this. If I remember correctly, in Perl you always use the equivalent of Python's tp_new slot, which is responsible for creating the proxy object from scratch. In PyGTK, for historical and compatibility reasons, we use tp_init/__init__ instead. When subclassing in python, users' should override __init__ and call the parent class' __init__, which means that by the time GObject.__init__ gets called we already have a PyObject, and in this case we have to avoid creating a new one. > > > > >> If we attach the proxy after g_object_newv returns then it is > >> already > >> too late to handle construction properties in python space. > >> > > > > no, this is case (1), i.e. you are creating a C Object and have > > nothing todo > > with its construction properties, e.g. a GtkButton. so attaching > > the python > > proxy to the fully constructed object is good enough. > > An important thing to remember here is that the _init()s will all run > from the inside out *before* any set_property()s get called by > g_object_new(). Yep, I realize now the importance of this property. This way we can avoid overriding constructor, but unfortunately we need to pass an extra pointer into _init. Either TLS or an extra parameter works, but TLS is not very nice. I get this feeling we may get into trouble using global variables if creating one instance triggers creation of another instance before the first one returns. But I guess we can use TLS if nothing better is available... Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Jul 5, 2005, at 7:57 AM, Tim Janik wrote: On Tue, 5 Jul 2005, Gustavo J. A. M. Carneiro wrote: Currently [construction properties will] be set by the GObject system at the wrong time, i.e. before the python proxy object is attached to the GObject instance. i'd rather say, you are trying to setup your proxy at the wrong time, i.e. after _init() which is too late. if you properly setup your proxy in _init() construct properties will work fine out of the box. For what it's worth, this is similar to the approach we took with gtk2-perl. The perl+C combination object is set up the first time the GObject is marshaled to perl; if that happens to be in a set_property override as part of g_object_new(), then so be it. This works the same way for all GObjects, regardless of whether they are derived in perl code. If we attach the proxy after g_object_newv returns then it is already too late to handle construction properties in python space. no, this is case (1), i.e. you are creating a C Object and have nothing todo with its construction properties, e.g. a GtkButton. so attaching the python proxy to the fully constructed object is good enough. An important thing to remember here is that the _init()s will all run from the inside out *before* any set_property()s get called by g_object_new(). -- "that's it! you're a genius!" "yes. that's what i think. do you think i deserve a raise?" - dialogue from 'Godzilla versus Mothra', 1964 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ team irc meeting
The meeting is intended for the GTK+ team, but everybody is welcome to come and listen. The meeting logs will be posted on the GTK+ website (http://www.gtk.org/plan/meetings). Place: irc.gnome.org:#gtk-devel Time: 20:00 UTC (16:00 EDT), Tuesday, July 5 Agenda: - What needs fixing until 2.8 ? - Reusing cell renderers (bug 309221) - Remaining Cairo (?) problems (bug 305459, 309512) - Any forgotten small api additions ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Tue, 2005-07-05 at 13:57 +0200, Tim Janik wrote: > On Tue, 5 Jul 2005, Gustavo J. A. M. Carneiro wrote: > > > On Tue, 2005-07-05 at 02:26 +0200, Tim Janik wrote: > >> On Tue, 7 Jun 2005, Gustavo J. A. M. Carneiro wrote: > >> > >>> I'd like to propose an API enhancement to GObject, in order to solve > >>> pygtk bugs 161177 and 123891 in a way that doesn't involve some "hack". > >>> > >>> As people may or may not know, in PyGTK there is, for each GObject, a > >>> corresponding "python wrapper" PyObject. Normally, the PyObject is > >>> create first, then __init__ is called, and this in turn calls the parent > >>> __init__ which takes care of creating the GObject with g_object_newv. > >>> > >>> Now, in bug 123891 we'd like to solve the "construction properties" > >>> problem. The only place where we may set construction properties is, as > >>> you may know, in the GObjectClass->constructor method. > >> > >> what do you mean with "we may set construction properties"? > >> construction properties are supposed to be passed in as (name,value) > >> pairs to g_object_newv(), and they'll be set by the GObject system > >> automatically at the right time. > > > > Currently they'll be set by the GObject system at the wrong time, i.e. > > before the python proxy object is attached to the GObject instance. > > i'd rather say, you are trying to setup your proxy at the wrong time, i.e. > after _init() which is too late. if you properly setup your proxy in _init() > construct properties will work fine out of the box. Your solution seems almost reasonable, except the TLS part... :| Any chance to pass a "gpointer data" into _init()? I suppose passing an extra parameter into a callback function doesn't break anything, right? g_object_newv would pass in NULL by default, and legacy _init's would happily ignore it, or we could call a new g_object_newv_with_data to pass something else, like a PyObject*. Would that be acceptable? Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Tue, 5 Jul 2005, Gustavo J. A. M. Carneiro wrote:
On Tue, 2005-07-05 at 02:26 +0200, Tim Janik wrote:
On Tue, 7 Jun 2005, Gustavo J. A. M. Carneiro wrote:
I'd like to propose an API enhancement to GObject, in order to solve
pygtk bugs 161177 and 123891 in a way that doesn't involve some "hack".
As people may or may not know, in PyGTK there is, for each GObject, a
corresponding "python wrapper" PyObject. Normally, the PyObject is
create first, then __init__ is called, and this in turn calls the parent
__init__ which takes care of creating the GObject with g_object_newv.
Now, in bug 123891 we'd like to solve the "construction properties"
problem. The only place where we may set construction properties is, as
you may know, in the GObjectClass->constructor method.
what do you mean with "we may set construction properties"?
construction properties are supposed to be passed in as (name,value)
pairs to g_object_newv(), and they'll be set by the GObject system
automatically at the right time.
Currently they'll be set by the GObject system at the wrong time, i.e.
before the python proxy object is attached to the GObject instance.
i'd rather say, you are trying to setup your proxy at the wrong time, i.e.
after _init() which is too late. if you properly setup your proxy in _init()
construct properties will work fine out of the box.
So
the idea to workaround this problem was to strip the construction
properties while calling standard GObject constructor, then attach the
python proxy, and only then set the construction properties.
right this'd just be a "workaround". trying to kludge around the problems
you created yourself with not setting up the proxy in _init() ;)
Related to this is bug 161177, which aims to fix the problem of
creating custom python GObjects from a C g_object_new call. For this to
work, we need to create the PyObject inside the GObject constructor.
And of course the constructor needs to "know" whether a PyObject already
exists or not.
i'm not sure i fully understand your problems here, so far i see
three use cases:
1) you create a GObject derived C object and have a PyObject proxy
2) you create a GObject derived Python object and have a PyObject proxy
3) you create a GObject derived Python object and have no PyObject proxy
i suppose (1) is as easy as:
static void
python_proxy_create_gobject (PyObject *pob,
GType object_type,
guint n_parameters,
GParameter *parameters)
{
GObject *object = g_object_newv (object_type, n_parameters, parameters);
python_proxy_attach (pob, object);
}
If we attach the proxy after g_object_newv returns then it is already
too late to handle construction properties in python space.
no, this is case (1), i.e. you are creating a C Object and have nothing todo
with its construction properties, e.g. a GtkButton. so attaching the python
proxy to the fully constructed object is good enough.
for (2), you derived from some GObject type, so you get to provide your own
GInstanceInitFunc and can do something like:
static __thread PyObject *current_proxy = NULL;
static void
python_gobject_init (GObject*object,
GTypeClass *g_class)
{
PyObject *pob = current_proxy;
current_proxy = NULL;
python_proxy_attach (pob, object);
}
[ Wow, didn't know about __thread for TLS. Is this standard and
portable? ]
OK, using TLS for this is a hack. We have a patch using this
approach, but it's not "nice" at all.
i've not seen a patch doing this in bugzilla. and no, you need to check
at configure *and* at runtime whether __thread is available since support
for it may be broken depending on your glibc version, gcc version and
kernel version (the latter is what might make it break at runtime).
it's just a concise way of writing g_private_get() and g_private_set()
however so it can be fully portable for you.
static void
python_proxy_create_python_object (PyObject *pob,
GType python_gobject_type,
guint n_parameters,
GParameter *parameters)
{
g_assert (current_proxy == NULL);
current_proxy = pob;
GObject *object = g_object_newv (python_gobject_type, n_parameters,
parameters);
}
and the extension to cover (3):
static PyObject*
create_python_gobject (GType python_gobject_type,
guint n_parameters,
GParameter *parameters)
{
PyObject *pob = python_proxy_create();
python_proxy_create_python_object (pob, python_gobject_type,
n_parameters, parameters);
return pob;
}
Another problem is that GObject->constructor currently does not allow
chaining to parent class in some situations. For objects implemented in
C
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Tue, 2005-07-05 at 02:26 +0200, Tim Janik wrote:
> On Tue, 7 Jun 2005, Gustavo J. A. M. Carneiro wrote:
>
> > I'd like to propose an API enhancement to GObject, in order to solve
> > pygtk bugs 161177 and 123891 in a way that doesn't involve some "hack".
> >
> > As people may or may not know, in PyGTK there is, for each GObject, a
> > corresponding "python wrapper" PyObject. Normally, the PyObject is
> > create first, then __init__ is called, and this in turn calls the parent
> > __init__ which takes care of creating the GObject with g_object_newv.
> >
> > Now, in bug 123891 we'd like to solve the "construction properties"
> > problem. The only place where we may set construction properties is, as
> > you may know, in the GObjectClass->constructor method.
>
> what do you mean with "we may set construction properties"?
> construction properties are supposed to be passed in as (name,value)
> pairs to g_object_newv(), and they'll be set by the GObject system
> automatically at the right time.
Currently they'll be set by the GObject system at the wrong time, i.e.
before the python proxy object is attached to the GObject instance. So
the idea to workaround this problem was to strip the construction
properties while calling standard GObject constructor, then attach the
python proxy, and only then set the construction properties.
>
> > Fine, let's
> > override GObject->constructor for PyGTK GObjects then. But there's a
> > problem, here.
>
> overriding the constructor is meant to be useful only for implementing
> singletons or object construction that needs execution after all construct
> arguments are set. here's the initial proposal for the pupose of
> constructor():
> http://mail.gnome.org/archives/gtk-devel-list/2000-August/msg00322.html
> though it's a bit dated it still carries a lot of relevant meat.
>
> > In the case described above, we already have a PyObject
> > for this GObject, and we need to "attach" the PyObject to the GObject
> > inside the construction, before setting any construction properties.
>
> is this requirement in place, because you are actually talking about
> construction properties implemented in python?
Yes. Construction properties implemented in Python do not work yet
and we'd like to fix it at the same time (bug #123891).
>
> > However, there is currently no way to pass the PyObject into the
> > constructor. The idea of creating a special property to pass the data
> > into the constructor was mentioned, but this is an ugly hack we'd like
> > to avoid at all costs.
>
> if you implement your construction properties in python and they need
> the PyObject attached already, this could also break for two reasons:
> - argument ordering, currently the construct parameters are set in the order
>trhey are passed in to g_object_new(), so may not always have the PyObject
>property coming first.
> - construct properties set from derived types, if an object derived from
>your python objects sets a construct property in its _init() function
>your PyObject wouldn't be setup yet (though depending on your support of
>GInstanceInitFunc this may not be triggered by your binding)
>
> > Related to this is bug 161177, which aims to fix the problem of
> > creating custom python GObjects from a C g_object_new call. For this to
> > work, we need to create the PyObject inside the GObject constructor.
> > And of course the constructor needs to "know" whether a PyObject already
> > exists or not.
>
> i'm not sure i fully understand your problems here, so far i see
> three use cases:
> 1) you create a GObject derived C object and have a PyObject proxy
> 2) you create a GObject derived Python object and have a PyObject proxy
> 3) you create a GObject derived Python object and have no PyObject proxy
>
> i suppose (1) is as easy as:
> static void
> python_proxy_create_gobject (PyObject *pob,
> GType object_type,
> guint n_parameters,
> GParameter *parameters)
> {
>GObject *object = g_object_newv (object_type, n_parameters, parameters);
>python_proxy_attach (pob, object);
> }
If we attach the proxy after g_object_newv returns then it is already
too late to handle construction properties in python space.
>
> for (2), you derived from some GObject type, so you get to provide your own
> GInstanceInitFunc and can do something like:
>
> static __thread PyObject *current_proxy = NULL;
>
> static void
> python_gobject_init (GObject*object,
> GTypeClass *g_class)
> {
>PyObject *pob = current_proxy;
>current_proxy = NULL;
>python_proxy_attach (pob, object);
> }
[ Wow, didn't know about __thread for TLS. Is this standard and
portable? ]
OK, using TLS for this is a hack. We have a patch using this
approach, but it's not "nice" at all.
>
> static void
> python_proxy_create_python_object (P
Re: GObjectClass->constructor revised, g_object_newv_with_data
On Tue, 5 Jul 2005, Tim Janik wrote:
On Tue, 7 Jun 2005, Gustavo J. A. M. Carneiro wrote:
i'm not sure i fully understand your problems here, so far i see
three use cases:
1) you create a GObject derived C object and have a PyObject proxy
2) you create a GObject derived Python object and have a PyObject proxy
3) you create a GObject derived Python object and have no PyObject proxy
[...]
for (2), you derived from some GObject type, so you get to provide your own
GInstanceInitFunc and can do something like:
static __thread PyObject *current_proxy = NULL;
static void
python_gobject_init (GObject*object,
GTypeClass *g_class)
{
PyObject *pob = current_proxy;
current_proxy = NULL;
python_proxy_attach (pob, object);
}
static void
python_proxy_create_python_object (PyObject *pob,
GType python_gobject_type,
guint n_parameters,
GParameter *parameters)
{
g_assert (current_proxy == NULL);
current_proxy = pob;
GObject *object = g_object_newv (python_gobject_type, n_parameters,
parameters);
}
and the extension to cover (3):
static PyObject*
create_python_gobject (GType python_gobject_type,
guint n_parameters,
GParameter *parameters)
{
PyObject *pob = python_proxy_create();
python_proxy_create_python_object (pob, python_gobject_type,
n_parameters, parameters);
return pob;
}
i need to correct myself here. (3) was meant to cover the case where
someone creates a python object from C code, i.e. via g_object_new().
so solving (3) does not involve writing a wrapper around g_object_newv(),
but demand creation of a python proxy in python_gobject_init(), i.e.
forget create_python_gobject() and apply the following:
static void
python_gobject_init (GObject*object,
GTypeClass *g_class)
{
PyObject *pob = current_proxy;
current_proxy = NULL;
+ if (!pob)
+ pob = python_proxy_create();
python_proxy_attach (pob, object);
}
---
ciaoTJ
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
