[REMINDER] GTK+ Team Meeting - August 26th
hi everyone; this is the usual reminder for the IRC GTK+ Team Meeting. the meeting will be held in the #gtk-devel channel on irc.gnome.org, at 20:00 UTC[1]. the points are: o 2.14 release o non-x11 backends readiness o 2.90/3.0 plan o miscellanea eventual changes will be notified on the wiki page[0]. everyone can participate, as usual. ciao, Emmanuele. +++ [0] http://live.gnome.org/GTK+/Meetings [1] http://www.timeanddate.com/worldclock/fixedtime.html?month=8&day=26&year=2008&hour=20&min=0&sec=0&p1=0 -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Am Montag, den 25.08.2008, 14:12 +0200 schrieb Murray Cumming: > At the least, any Yes/No stuff in the API reference documentation should > have a note saying that they are generally a bad idea, probably with a > link to the GNOME HIG. And also, please mention that some languages don't even have proper equivalents for "yes" and "no" (IIRC, welsh [1]). [1] http://www.croeso-betws.org.uk/iaith/phrases.htm Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
getting and setting a pointer to a c++ class in a multi-level glib object hierarchy
folks, hi,
i have a particularly horrendous implementation requirement that i can't
quite get my head round and need some gobject advice for the webkit-gtk
implementation to provide DOM access (which will then percolate to pywebkitgtk).
webkit's c++ DOM object hierarchy is multi-level, is inherited (as best
i can tell) from a virtual base class, Node, and comprises a whopping
_four hundred_ individual classes derived, ultimately, from that base class .
i've written an auto-generator to create the glib-object-based code for all
of these classes: and, btw, i can _thoroughly_ recommend the use of this
code for other projects: it's _not_ just a tool that should stay in webkit,
it's generic enough to used elsewhere.
the problem i am having is best illustrated with an example. i managed
to get everything compiled and working yesterday, enough to test with this
code, in pywebkitgtk:
doc = main_frame.get_document() # equivalent to document in javascript
txtnode = doc.create_text_node('hello world') # equivalent to createTextNode
doc.append_child(txtnode) # equivalent to doc.appendChild in javascript
the "append_child" is where it all goes horribly wrong: here's why.
doc is of glib type GDOM_TYPE_DOCUMENT, and, naively on my part it contains a
"private" pointer to a c++ "Document" class from webkit.
GDOMDocument is a glib object that inherits from a GDOMNode glib
object, which in turn inherits from a GDOMObject glib object.
likewise, txtnode is of glib type GDOM_TYPE_TEXT_NODE which also happens
to inherit from GDOM_TYPE_NODE which inherits from type GDOM_DOM_OBJECT
which inherits from G_OBJECT.
each and every single GDOM_TYPE_XXX has a "priv" private pointer to its
c++ class - and that turns out to be my mistake.
the reason? Document::appendChild() takes a Node* - the virtual base
class - as its argument. and, because append_child is all the way down
at the GDOM_TYPE_NODE glib object level, _guess_ which one of the "priv"
pointer functions gets called to "get" a private member, and guess
which one of the "priv" pointer functions will have been called to _set_
the private member?
when the text node was created, _only_ the gdom_text_node_set_private()
was called, setting a priv member that is exclusive and private to
GDOM_TYPE_TEXT_NODE, and when append_child is called, it's called at
the GDOM_TYPE_NODE, level, resulting in gdom_node_get_private() getting
called (not gdom_text_node_get_private()), which returns... of course...
NULL!
so - this is where i'm a bit lost.
looking at the tutorials i was kindly referred to, there are "abstract
methods" which at first sight look suitable. however, i can't quite
work out if they can be multi-layer-inherited. G_DEFINE_ABSTRACT_TYPE
describes how to create an abstract method "super_human_eat", which
is passed in a pointer to a NatureHuman* - not a SuperHuman*.
i need to be able to call the *same* function at each level of the
glib inheritance structure, back down at the "GDOM_TYPE_DOM_OBJECT" base
glib object, which will store a "priv" private member pointer to
the c++ virtual base class (Node*).
the "Interfaces" example looks suitable for what i need but...
i've looked at the "Interfaces" example - and i don't get it. there
doesn't appear to be a way to store "data" - the example only shows
a method "move".
any help greatly appreciated - this is something really quite obscure
that is easy enough to do in c++ and python.
oh.
duh.
of course.
if i describe what i need in python, perhaps someone can tell me how
it's implemented using Glib Objects?
# base class
class Node:
def __init__(self):
self.children = []
self.parent = None
def appendChild(self, child):
self.children.append(child)
def set_parent(self, parent):
self.parent = parent
class TextNode(Node):
def __init__(self, txt):
Node.__init__(self)
self.txt = txt
class Document(Node):
def createTextNode(self, txt):
tn = TextNode(txt)
tn.set_parent(self)
return tn
that's the "implementation" - in c++
this is the GLIB object structure:
class GObject:
pass
class gdomDOMObject(GObject):
def __init__(self):
self.priv = None
def set_private(self, priv):
self.priv = priv
def get_private(self):
return self.priv
class gdomNode(gdomDOMObject):
def append_child(self, child):
self.priv.appendChild(child.get_private())
class gdomDocument(gdomNode):
def create_text_node(self, text):
tn = self.priv.createTextNode(text)
gtn = gdomTextNode()
gtn.set_private(tn)
return gtn
that's what i _really_ want - but i've made the mistake of doing "the
equivalent" - in glib object terms - of this:
class gdomNode(gdomDOMObject):
def __init__(self):
self.priv = None
def set_private(self, priv):
self.priv = priv
def get_private(self):
return self.priv
def append_child(self, child):
self.priv.appendChild(child.get_private())
class g
Re: Inter process communication.
You might want to look at DBus: http://freedesktop.org/wiki/IntroductionToDBus 2008/8/19 Yasir <[EMAIL PROTECTED]> > Hi, > > How can two Gtk based top level windows communicate with each other using > (message passing)? > How can we add a user-defined signal and how can we emit this signal? > > Thanks. > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:49 -0400, Colin Walters wrote: > On Wed, Aug 20, 2008 at 9:39 PM, Jamie McCracken > <[EMAIL PROTECTED]> wrote: > > > > Are you saying Yacc/Bison and lex/flex source files which generate c > > files are also incompatible with GPL? > > Of course not; it's perfectly valid in general to have code generate > code. But if your build process doesn't invoke yacc or bison but just > relies on the shipped generated .c files, that is a problem. not a problem if the vala source and means to build them using valac and makefiles are publically available. GPL only affects distribution so if you also make the original vala source distributable (separately or in the same package with the same terms) then it should not be an issue In any case, distros can always use valac to build anything written in vala (or genie) so im not sure why any of this matters? jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:18 -0400, Colin Walters wrote: > On Wed, Aug 20, 2008 at 9:07 PM, Havoc Pennington <[EMAIL PROTECTED]> wrote: > > > > What about a libvala? I guess vala is supposed to have this property > > that it doesn't create dependencies in distributed tarballs, but that > > design goal has brought us autoconf and libtool in the past... not > > sure I'm sold on it. > > Another nail in the no-libvala idea's coffin is that it seems to me[1] > it's a violation of the GPL to distribute code that doesn't build > using the "preferred form of the work for making modifications to it" > (GPL sec 3). In other words, generated .c files are no different from > .jars and the like, and free OS vendors should not allow software > which includes them. > > [1] IANAL etc. Thats obviously not the case Are you saying Yacc/Bison and lex/flex source files which generate c files are also incompatible with GPL? if so a whole load of software is in violation (including gcc) jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Wed, 2008-08-20 at 21:07 -0400, Havoc Pennington wrote: > Hi, > > On Wed, Aug 20, 2008 at 8:47 PM, Yu Feng <[EMAIL PROTECTED]> wrote: > > First, it is very difficult to manage a string without a reference > > count. The current vala implementation is to assume that strings are > > immutable, and to copy the strings almost everywhere where increasing > > the ref-count should be used. The copying mechanism produces workable > > code, but doesn't work in a efficient way. This is where it hurts. > > > > Secondly, vala doesn't introduce any additional dependency other than > > GLib, to implement it in VALA level, the only way is to embed it in the > > compiler. A compiler with embeded code to do a ref-counted string > > doesn't sound nice. This is why I think it should be done at GLib level. > > > > If we think of GLib features as either for C, or for language bindings > in general, or for vala, this particular feature seems like it would > be *only* for vala - refcounted strings would be pretty strange in > plain C, and just overhead for other language bindings that already > have native string types they have to convert gchar* to. > > Putting only-useful-for-vala features in GLib would seem odd to me. > Just one opinion, though. > > Can't vala do the same optimizations a C programmer would do by hand > in most cases - avoiding a copy for a const char* that is only stored > temporarily in local scope, for example? For other cases, a plain C > program would have the same inefficiencies as vala it seems like, and > they are not fatal inefficiencies... > > What about a libvala? I guess vala is supposed to have this property > that it doesn't create dependencies in distributed tarballs, but that > design goal has brought us autoconf and libtool in the past... not > sure I'm sold on it. > > Or then, embedding it in the compiler does not seem like a very big > deal - it's just two operations ref and unref, both of which are > trivial and can just be inlined... > > Havoc I think we are confusing issues here Its GString and not char * which needs the ref counting Other languages (C++ and Delphi) both use ref counting for their strings and they are invaluable to C devs too who do multi-threaded stuff. This is clearly not vala specific as a result (ever tried to free a string correctly where its used in multiple threads?) At the moment there is an inconsistent split between glib structures like GHashTable which use ref counting and the others (GList, GString et all) which dont. I do hope GLib 3 will fix this jamie ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: [Vala] Lacking of a ref-counted string.
I think it has what you ask for, if a class doesn't inherit from gobject then internally it inherits from gtypeinstance which is what you said. Sometimes people don't distinguish between the two, though. However I want compact non-gobject non-gtype instance (I want I want... Never satisifed with what Juerg et al have produced for me...) Sam -Original Message- From: Ali Sabil <[EMAIL PROTECTED]> Sent: Wednesday, August 20, 2008 9:25 PM To: Bastien Nocera <[EMAIL PROTECTED]> Cc: gtk-devel-list ; Vala Mailing list <[EMAIL PROTECTED]> Subject: Re: [Vala] Lacking of a ref-counted string. On Wed, Aug 20, 2008 at 9:15 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote: On Wed, 2008-08-20 at 15:10 -0400, Yu Feng wrote: > Dear Devs, > > Is there any particular reason that GLib doesn't provide a ref-counted > string and a ref-counted array type? Lacking them in GLib makes the VALA > language a real pain. You could just wrap simple GObjects around GString and GPtrArray. Wouldn't that be overkill ? do we need signals and properties for strings and arrays ? maybe GLib/GObject should have something like GstMiniObject that only provides reference counting and no signals/properties ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Inter process communication.
Hi, How can two Gtk based top level windows communicate with each other using (message passing)? How can we add a user-defined signal and how can we emit this signal? Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
On Mon, Aug 25, 2008 at 8:22 AM, Christian Dywan <[EMAIL PROTECTED]> wrote: > Am Mon, 25 Aug 2008 14:12:38 +0200 > schrieb Murray Cumming <[EMAIL PROTECTED]>: > >> At the least, any Yes/No stuff in the API reference documentation >> should have a note saying that they are generally a bad idea, >> probably with a link to the GNOME HIG. > > If we want to keep people from doing stupid things I agree, the API > reference should just point out very expressly that one shouldn't use > these buttons deliberately. > > I wouldn't assert so strongly that Yes and No are "generally a bad > idea", though. I think there are appropriate use cases. I'd be ok with adding a paragraph somewhere in the api docs that points out the benefit of following some interface guidelines, and maybe pointing at the gnome HIG as an example. I don't think the docs for YES/NO are the ideal place for that, though... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Am Mon, 25 Aug 2008 14:12:38 +0200 schrieb Murray Cumming <[EMAIL PROTECTED]>: > At the least, any Yes/No stuff in the API reference documentation > should have a note saying that they are generally a bad idea, > probably with a link to the GNOME HIG. If we want to keep people from doing stupid things I agree, the API reference should just point out very expressly that one shouldn't use these buttons deliberately. I wouldn't assert so strongly that Yes and No are "generally a bad idea", though. I think there are appropriate use cases. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
At the least, any Yes/No stuff in the API reference documentation should have a note saying that they are generally a bad idea, probably with a link to the GNOME HIG. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Morten Welinder wrote: 2008/8/25 Mathias Hasselmann <[EMAIL PROTECTED]>: Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. [..] (For the record, I seem to have lots of _RESPONSE_ lying around, but no _STOCK_ ones. Unless they are somehow hidden in glade files.) You can easily find out by doing a grep for "gtk-" on all your .glade files. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
2008/8/25 Mathias Hasselmann <[EMAIL PROTECTED]>: > Hi, > > The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES > and GTK_STOCK_NO encourages creation of horrible user interfaces. What a terrible idea! First, GTK_RESPONSE_YES and GTK_RESPONSE_NO do not imply much about user interfaces, good or bad. They are response codes, nothing else, and can be paired with any GTK_STOCK_* in full observance of the HIG. Second, for GTK_STOCK_YES and GTK_STOCK_NO, do you really want to break a pile of GTK applications just because they run afoul of a related project's (i.e., Gnome's) guide lines? Note: guide lines are not strict rules. (For the record, I seem to have lots of _RESPONSE_ lying around, but no _STOCK_ ones. Unless they are somehow hidden in glade files.) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Lacking of a ref-counted string.
On Sat, 23 Aug 2008 09:58:12 -0400
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:
> If you're talking about converting existing APIs to refcounted
> strings, that's a very different proposal from just adding some kind
> of refcounted string feature. It would break thousands of apps, or
> else duplicate hundreds of API entry points ...
Personally, I didn't have in mind a change of existing API; simply an
addition of something new:
typedef struct {
gchar *str;
gsize len;
gint refcount;
} GCString;
GCString *g_cstring_new_static(gchar *data);
GCString *g_cstring_new_from_gstring(GString *clone);
GCString *g_cstring_ref(GCString *str);
void g_cstring_unref(GCstring *str);
should be sufficient for immutable strings. copy-on-write mutable ones
would probably want allocated length in the struct too, and add something
like
GCString *g_cstring_dup(GCString *clone);
which can then sit in the beginning of the modifier functions, looking
something like
GCstring *g_cstring_append(GCstring *s, gchar *data)
{
if(s->refcount > 1)
s = g_cstring_dup(s);
/* now modify s */
return s;
}
From my experience using GString I'd find the following macro useful;
#define GCSTR(s) (s?s->str:NULL)
Then you can
printf("Hello, my name is %s\n", GCSTR(s));
a little safer.
Or note that C requires the address of a struct must be the address of
its first member; so a simple cast is sufficient
printf("Hello, my name is %s\n", (gchar*)s);
--
Paul "LeoNerd" Evans
[EMAIL PROTECTED]
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Am Mon, 25 Aug 2008 09:00:05 +0200 schrieb Mathias Hasselmann <[EMAIL PROTECTED]>: > Hi, > > The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES > and GTK_STOCK_NO encourages creation of horrible user interfaces. One > recent example is on Planet GNOME right now[1]. Other examples were > posted on Planet GNOME in the past, and still exist in applications > like OpenOffice.org. > > So I wonder if we should deprecated those symbols, in the hope that > people obey the GNOME HIG and properly label the buttons of their > message dialogs. Hey, you did find a really nasty example there indeed. "Would you like to continue ignoring those warnings" does not only pose a rather bad question, it also includes a small secondary icon and a secondary message that looks simply confusing. However I have doubts that deprecating these stock icons can help much here. Even if the buttons weren't there, chances are that the developer still uses Yes and No labels, or if he, say chooses "Ignore" and "Don't ignore" instead and keeps the confusing layout with mutiple messages and multiple icons, the situation isn't much different from before. Just my two euro cents, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RFC: Deprecate GTK_{RESPONSE,STOCK}_{YES,NO}
Hi, The pure existence of GTK_RESPONSE_YES, GTK_RESPONSE_NO, GTK_STOCK_YES and GTK_STOCK_NO encourages creation of horrible user interfaces. One recent example is on Planet GNOME right now[1]. Other examples were posted on Planet GNOME in the past, and still exist in applications like OpenOffice.org. So I wonder if we should deprecated those symbols, in the hope that people obey the GNOME HIG and properly label the buttons of their message dialogs. Ciao, Mathias 1:http://libwilliam.wordpress.com/2008/08/25/alerting-users-of-mistakes/ -- Mathias Hasselmann <[EMAIL PROTECTED]> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
