compiling gtk in windows
Hi: I am really interested in gtk for windows but i see like like a problem the build system autotools nowadays for mingw. I would like could compile the last gtk version by myself. I try compile much apps with autotools in windows but i see it very freak. Any interested in WAF build systems for GTK and GTKMM??. any help in this arena? Regards. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: compiling gtk in windows
I am really interested in gtk for windows but i see like like a problem the build system autotools nowadays for mingw. I would like could compile the last gtk version by myself. Are you trying to build GTK+ from svn, or from a tarball? In general building from a tarball should be a bit easier, as you don't need to run autogen.sh (i.e. aclocal, automake, autoconf) but just the configure script. What problems do you have *exactly*? (But please, no hundreds of lines of build logs in mail, thanks. Either trim them down to the essential errors messages, or use pastebin.) Any interested in WAF build systems for GTK and GTKMM??. any help in this arena? WAF? PS: as this is about compiling GTK+ itself, not GTK+-using applications, please follow up to gtk-devel-list. You could also come over and talk on #gtk on irc.gimp.org, or #win32 on the same server. Ask your question and wait patiently. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
natural size for widgets packed in a GtkScrolledWindow
Hi all, This may be related to the natural-size stuff I saw floating on gtk-devel-list a couple months ago, so maybe my answer is just wait for the next major gtk release, but here goes... Consider a dialog just with a scrolled window in it, and, inside the scrolled window, some widget that can hold arbitrary amounts of information, like a tree view, icon view, etc. If I put a bunch of rows in the tree view (for example), and then show the dialog, I get this tiny dialog that shows only a single row in the tree view. But I'd really rather it show, say 10 rows at a time. Same issue with a GtkIconView, only it's worse -- if I set it up for sideways icons (icon on the left, text on the right), and pack a bunch of icons in there, the dialog shows itself with exactly one icon showing, and I need to scroll to see the rest. Say I'd like to start off showing 3 columns and 4 rows, or whatever. Is there any way to do this without writing a bunch of nasty hacky code? It seems like these widgets are much less useful without some sort of intelligent autosizing. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Full Screen mode and odd menu behavior
Hey All, When I put my application into full screen mode (by calling fullscreen), the Linux System menu (Applications, Places, etc.) nicely goes away. However, doing some things in my app (e.g. bringing up a modal dialog) can cause the system menu to appear unexpectedly. Am I missing something on how this is supposed to work? Thanks in advance. -Garth -- Garth Upshaw Garth's KidStuff ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to restrict mouse pointer movement within a certain area using DirectFB?
Hi, I need to restrict mouse pointer within a certain area of the window using DirectFB. I got one idea to use void gdk_display_warp_pointer http://library.gnome.org/devel/gdk/stable/GdkDisplay.html#gdk-display-warp-pointer (GdkDisplay http://library.gnome.org/devel/gdk/stable/GdkDisplay.html *display,GdkScreen http://library.gnome.org/devel/gdk/stable/GdkScreen.html *screen, gint x, gint y); But, the function is not implemented for DirectFB, in any of the gtk distribution. I will be grateful enough for your suggestion regarding my query Regards Dhananjoy. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-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
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
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}
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: 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}
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}
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}
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
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: [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 gtk-devel-list@gnome.org; 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
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: 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: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: 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
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 gdomDocument(gdomNode):
def
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
[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=8day=26year=2008hour=20min=0sec=0p1=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
