How to best implement a custom quad-paned widget?
Greetings everybody! Before I start, take a quick look at what I intend to achieve with my custom widget (named GtkXPaned): http://macslow.mine.nu/shots/GtkXPaned-mockup.jpg This program seen in the screenshot is currently a workaround using two GtkHPaned widgets embedded in one GtkVPaned widget. What I want to be able to do in the end, is to grab the "intersection" of the two paned-handles and move it around thus causing the resizing of all embedded children-widgets. I started with GtkXPaned basing it off GtkPaned and taking clues from GtkHPaned/GtkVPaned of the gtk+-2.6.10 release. I have the new GtkXPaned widget in a "working" state now (gtk+ compiles, GtkXPaned widget is instance-able from a normal gtk+-program). But it doesn't really do all the things I want it to do yet (e.g. handle-dragging doesn't work). I have to admit that I'm totally new to developing custom gtk+-widgets (just reading the "GTK+ 2.0 Tutorial" atm). So it's a rough ride for me, but without a real-world example I would never get around learning it. Now I wonder what's the best way to represent/paint the "cross"-handle of GtkXPaned. Should I split it up in two overlapping GdkWindow-widgets or split it in three parts (e.g. top-bar, horizontal-bar and bottom-bar) or maybe even split it up in five parts (top-bar, right-bar, bottom-bar, left-bar and intersection-part)? What gtk_paint_* functions do you suggest would be best to use for any of those possible split-ups? The user should get a direct clue from the handles appearance that it not a GtkVPaned/GtkHPaned. The cross-part at the intersection should probably be drawn in a gtk_paint_handle-way... maybe like: http://macslow.mine.nu/shots/GtkXPaned-handle.jpg I don't intend to release GtkXPaned to the public once it's finished (unless anybody sees a general need for such a widget... I'm mainly doing this because it's very handy for me doing a quad-view in a 3D-tool). I know it would also work equally well if put in files separated from the gtk+ source-tree. But aside from my main goal I'm also using it as a learning experience for several things... to get a better understanding of gtk+ itself... importing the source-tree as project into Eclipse to check out how Eclipse handles a project of that size. Thanks in advance for you time and kind advice! Best regards... MacSlow -- Mirco "MacSlow" Müller <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
API documentation, GtkTextBuffer signals
Hi,
I have written some documentation of the GtkTextBuffer signals.
If this is useful I will try to find time to continue with more signals
- they seems to be neglected in most of the documentation.
I include a patch against 2.6.7 and would like to hear your
comments/criticism.
Is this useful? How do I submit it for inclusion?
Søren
--- orig/gtk+-2.6.7/gtk/gtktextbuffer.c 2005-03-20 07:25:29.0 +0100
+++ gtk+-2.6.7/gtk/gtktextbuffer.c 2005-09-19 21:28:12.844393536 +0200
@@ -186,6 +186,23 @@
GTK_TYPE_TEXT_TAG_TABLE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY));
+ /**
+ * GtkTextBuffer::insert-text:
+ * @textbuffer: the object which received the signal.
+ * @location: position to insert @text in @textbuffer.
+ * @text: the UTF-8 text to be inserted.
+ * @len: length of the inserted text in bytes.
+ *
+ * The insert_text signal is emitted to insert text in a #GtkTextBuffer
+ * (see gtk_text_buffer_insert() ).
+ * Insertion actually occurs in the default handler.
+ * Note that if your handler runs before the default handler it must not
+ * invalidate the @location iter (or has to revalidate it).
+ * There is no need to keep the iter valid in handlers
+ * which run after the default handler (see g_signal_connect_after() ).
+ * The default signal handler revalidates it to point to the end of the
+ * inserted text.
+ */
signals[INSERT_TEXT] =
g_signal_new ("insert_text",
G_OBJECT_CLASS_TYPE (object_class),
@@ -199,6 +216,22 @@
G_TYPE_STRING | G_SIGNAL_TYPE_STATIC_SCOPE,
G_TYPE_INT);
+ /**
+ * GtkTextBuffer::insert-pixbuf:
+ * @textbuffer: the object which received the signal.
+ * @location: position to insert @pixbuf in @textbuffer.
+ * @pixbuf: the #GdkPixbuf to be inserted.
+ *
+ * The insert_pixbuf signal is emitted to insert a
+ * #GdkPixbuf in a #GtkTextBuffer.
+ * Insertion actually occurs in the default handler.
+ * Note that if your handler runs before the default handler it must not
+ * invalidate the @location iter (or has to revalidate it).
+ * There is no need to keep the iter valid in handlers
+ * which run after the default handler (see g_signal_connect_after() ).
+ * The default signal handler revalidates it to be placed after the
+ * inserted @pixbuf.
+ */
signals[INSERT_PIXBUF] =
g_signal_new ("insert_pixbuf",
G_OBJECT_CLASS_TYPE (object_class),
@@ -211,6 +244,23 @@
GTK_TYPE_TEXT_ITER | G_SIGNAL_TYPE_STATIC_SCOPE,
GDK_TYPE_PIXBUF);
+
+ /**
+ * GtkTextBuffer::insert-child-anchor:
+ * @textbuffer: the object which received the signal.
+ * @location: position to insert @anchor in @textbuffer.
+ * @anchor: the #GtkTextChildAnchor to be inserted.
+ *
+ * The insert_child_anchor signal is emitted to insert a
+ * #GtkTextChildAnchor in a #GtkTextBuffer.
+ * Insertion actually occurs in the default handler.
+ * Note that if your handler runs before the default handler it must not
+ * invalidate the @location iter (or has to revalidate it).
+ * There is no need to keep the iter valid in handlers
+ * which run after the default handler (see g_signal_connect_after() ).
+ * The default signal handler revalidates it to be placed after the
+ * inserted @anchor.
+ */
signals[INSERT_CHILD_ANCHOR] =
g_signal_new ("insert_child_anchor",
G_OBJECT_CLASS_TYPE (object_class),
@@ -224,17 +274,20 @@
GTK_TYPE_TEXT_CHILD_ANCHOR);
/**
- * GtkTextBuffer::delete_range:
- * @buffer: the object which received the signal.
- * @start: the start of the range to be deleted
- * @end: the end of the range to be deleted
+ * GtkTextBuffer::delete-range:
+ * @textbuffer: the object which received the signal.
+ * @start: the start of the range to be deleted.
+ * @end: the end of the range to be deleted.
*
- * The ::delete_range signal is emitted to delete a range from
- * a #GtkTextBuffer. Note that your handler must not invalidate the
- * @start and @end iters (or has to revalidate them), if it runs before the
- * default handler. There is no need to keep the iters valid in handlers
+ * The delete_range signal is emitted to delete a range
+ * from a #GtkTextBuffer.
+ * Note that if your handler runs before the default handler it must not
+ * invalidate the @start and @end iters (or has to revalidate them).
+ * There is no need to keep the iters valid in handlers
* which run after the default handler (see g_signal_connect_after()), but
- * those don't have access to the deleted text.
+ * those do not have access to the deleted text.
+ * The default signal handler revalidates the @start and @end iters to
+ * both point to the place where the text was deleted.
*
Re: ./teststatusicon (was Re: A cross-platform status icon api)
On 19.09.2005 00:38, Tor Lillqvist wrote: Hans Breuer writes: > BTW: I'd appreciate if somebody with a deeper understanding of gtk internals > could do a review of gtktrayicon-win32.c. Maybe what I've done is considered > too much of a hack ;-) I appreciate your work, but why the rush? Isn't it better to wait some time and let the X11 implementation mature first? Having HEAD broken - i.e not even compile - for a long time does not look right to me, no. Also silently agreeing on an API - without trying it - up until short before a release doesn't either. If it turns out that there are cross-platform issues I think the earlier they are detected the better. It isn't exactly like GTK 2.10 would be close to release. GTK+ 2.8 is the stable version, and 2.6 is even more stable on Win32. (At least, unless you use a fresh CVS snapshot of pango-1-10). Are you using HEAD as your "production" environment? At least I try. Usually starting to build from cvs from from GLib over Pango up to Gtk+. [So I'm using Pango cvs as of yesterday.] If I find problems I usually report them, try to solve them or run out of spare time. So yes, I try to use cvs HEAD as "production" environment. At least for programs I don't use in production ;-) Didn't we have some problems in the last cycle when gtkfilesystemwin32 was copy-pasted from gtkfilesystemunix before the latter was "ready", Copy and pasting always is a problem. But merging one function twice when the original became more mature IMO isn't. and then subsequent improvements to gtkfilesystemunix didn't get mirrored in gtkfilesystemwin32? I don't recall the details, sorry. Looking at http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtkfilesystemwin32.c it seems as if most 'subsequent improvements' were win32 specific. * gdk/win32/gdkwindow-win32.c(gdk_window_set_urgency_hint) : only use only use (WINVER >= 0x0500) when available from the SDK. Otherwise fall back to true dynamic linking of FlashWindowEx. Makes gtk+ work on NT4.0 again - if compiled properly. Hmm, why should we use different *code* depending on the *compilation* environment? (I understand ifdefs for preprocessor defines or type definitions that aren't present in older headers.) Wouldn't it be better here to use the dynamic lookup of FlashWindowEx() all the time then, so that the code would work on NT4 even if built against fresher headers? (Is FlashWindowEx() really the only Win32 API we use that isn't present in NT4?) The only benefit I see is letting the compiler check the compatibility with the newer API. Especially FlashWindowEx appears to have had some brokeness in it's history. But feel free to remove the non dynamic part. BTW: simply defining some high WINVER at the start of a .c or worse a .h file never does look right to me. But Microsoft will love it. Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ./teststatusicon (was Re: A cross-platform status icon api)
On Mon, 2005-09-19 at 01:38 +0300, Tor Lillqvist wrote: > Hans Breuer writes: > > BTW: I'd appreciate if somebody with a deeper understanding of gtk > internals > > could do a review of gtktrayicon-win32.c. Maybe what I've done is > considered > > too much of a hack ;-) > > I appreciate your work, but why the rush? > > Isn't it better to wait some time and let the X11 implementation > mature first? It isn't exactly like GTK 2.10 would be close to > release. GTK+ 2.8 is the stable version, and 2.6 is even more stable > on Win32. (At least, unless you use a fresh CVS snapshot of > pango-1-10). Are you using HEAD as your "production" environment? The GtkStatusIcon code has spent several years in libegg and should be quite mature at this point... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ./teststatusicon (was Re: A cross-platform status icon api)
On Sun, 2005-09-18 at 14:27 +0200, Hans Breuer wrote: > On 06.09.2005 15:08, Matthias Clasen wrote: > > On Mon, 2005-09-05 at 23:25 +0200, Hans Breuer wrote: > [...] > >>Also gtkstatusicon-x11.c not only implements the fdo spec but it also > >>defines a bunch of status icon api. Not only 21 functions but additionally > >>quite some properties. Should all this be duplicated to get the > >>cross-platform status api ? > > > > > > Hmm, good point. When I did that code I thought a clean separation > > between the X and win32 implementations would be better, but looking at > > the code in gtkstatusicon-x11.c, only a few lines deal with the tray > > icon. Do you think it would be feasible to #ifdef out the > > platform-specifc parts without too much pain ? If so, then we should > > probably do the cvs surgery to rename gtktrayicon.c to gtktrayicon-x11.c > > and gtkstatusicon-x11.c gtkstatusicon.c. > > > Before diving too deep into the code of (now) gtkstatusicon.c I've tried > it on Linux - but it does not work there, too. What am I supposed to > update so see any effect of ./teststatusicon ? (I'm running gnome-2.10.2 > on gentoo with xorg-x11-6.8.2) Works fine for me. If I run teststatusicon, a blinking icon shows up in the system tray in my panel. You have a system tray on your panel, right ? > I've just checked in a dummy implementation for gtktrayicon-win32.c to > make gtk+-2.9 compile again. To make a working implementation for win32 > the missing pieces are : > > - get rid of the GtkPlug inheritance - maybe even in gtktrayicon.h ? > - convert the icon/pixbuf to a HICON. There is code to do that in >_gdk_win32_pixbuf_to_hicon() > - define a gtk signal to be emitted when the user clicks on the trayicon > - ... Still wrong, IMO. the GtkTrayIcon is a detail of the X11 statusicon implementation. It is specific to the freedesktop system tray specification, which builds on the XEmbed spec. Therefore it is most logical to derive it from GtkPlug. On Win32, you should just implement the GtkStatusIcon API, which does have the activate and popup_menu signals you are supposed to emit when the icon is clicked, btw. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[ANNOUNCE] GtkJavaScript and RadojoWidgets
Hi Folks, I'l like to announce some proof-of-concept code i've been working on. This is the first public announcement of this work. The general problem i'm trying to address is the divergence of web UI programming and native UI programming and I have a novel solution (travelling on the wake of what Google have been doing with AJAX dynamic non-page reloading web interfaces that try to appear and respond like native UIs). As JavaScript is the defacto web presentation-tier programming language i.e. being supported in every major browser and the initial teething problems of compatibility being solved by better conformance with ECMA-262 (as i've found in my testing across a wide range of browsers), my proposal involves developing a UI focused JavaScript toolkit API that can be used by next generation web applications (rather than the clumsy, not standard across all browsers and document focused DOM API) . Instead of inventing a new API I've studied a few of the available APIs and settled upon Gtk due to its elegance and simplicity :). My initial problem was a lack of JavaScript Gtk bindings. gtk.org language bindings page: http://www.gtk.org/bindings.html lists JsGtk although this project seems dead and the archive I found only supported a very small number of Gtk1.2 widgets so I set about starting off a new set of JavaScript bindings for Gtk2 as well as an extensible shell interpreter for the Mozilla SpiderMonkey JavaScript engine (the Gtk2 bindings are a plugin to it): http://www.radojo.org/GtkJavaScript http://www.radojo.org/PluggableJavaScript My bindings although much further along than the previous work still need more development (i could use some help). The next step which is the real point of my project is to implement an API compatible implementation of the Gtk widgets in pure JavaScript that will run in any recent browser: RadojoWidgets. So RadojoWidgets (aka Rwt) is a lightweight GUI toolkit for JavaScript. The API is modeled on an object oriented variant of the Gtk API (more like Gtk-- although of course Gtk is object oriented). It is unique as far as JavaScript GUI Toolkits go as in addition to a DHTML/DOM implementation that runs in most recent browsers, it is able to use the native GtkJavaScript implemtation to allow Rwt applications to run as standalone native UI applications thus providing a platform to convergence native and web user interfaces (my second goal). ie. The same code can be run outside of the browser using native Gtk widgets. Rwt abstracts away differences in the DOM implementations between browsers and provides a much simpler and more productive GUI focused programming interface than DOM (which is very cumbersome to use and not designed from a GUI programming perspective). Rwt can run in the following browsers (no plugins required): Firefox 1.0, Mozilla 1.7, Internet Explorer 6.0, Konqueror 3.4, Safari 1.2, and Opera 8 Rwt uses the following software components to enable native GUI operation: PluggableJavaScript: http://www.radojo.org/PluggableJavaScript GtkJavaScript: http://www.radojo.org/GtkJavaScript The raison d'etre of Rwt is to be used in combination with a web-tier RPC such as RadojoRpc http://www.radojo.org/RadojoRpc to allow dynamic AJAX sytle communication with the server-side. Your server side can be implemented in any number of languages that have JSON-RPC implementations such as Java, python, ruby, PHP, ... Rwt is still alpha code but almost enough functionality has been built at present to create some interesting next generation web applications. It currently implements the Gtk signal system, has some basic containers and widgets, implements the TreeModel, ListStore, TreeStore and a partially working version of the TreeView (quite a complex widget). Take a look at the treeview component test (remember to enable popups): http://app.radojo.org/src/radojo-rwt/dhtml-tests/test_treeview_tree.html Here are some other relevant links: http://app.radojo.org/src/radojo-rwt/dhtml-tests/ http://www.radojo.org/RwtWidgetStatus http://app.radojo.org/src/radojo-rwt/ I believe this _could_ revolutionize the way web applications are developed (or in fact not just web applications). Presently it is hard graft building highly interactive web interfaces and they are in fact specialized and the code will only work on the web. This system will enable the same presentation tier code in a multi-tier system to be deployed both as a web app and as a native app and the code is much easier and faster to write and will have the potential to be more portable than clumsy DOM code. I've got it to a stage where I believe my proof-of-concept shows me that it is in fact an achievable goal. ie. it is possible to get the Gtk rendering and packing model overlayed on top of the DOM constructs and I have the basic object/signal/container system working. Of course it is early days yet - much more coding to do. Feedback, flames, discussion most welcome. Most impo
Re: Watching filedescriptors
Soeren Sandmann wrote: Hi, > One thing I and many other people regularly need is to be notified > whenever something happens on a file descriptor. This is needed when > you write networked applications, or when you with to communicated > with spawned child processes, and in many other circumstances. > > The way you are supposed to do that with glib right now is with > GIOChannels. Unfortunately, GIOChannels are quite painful to use, and > somewhat overengineered. While GIOChannel might be a bit hard to get the first time they get the job done. Having two APIs that does essentially the same would in my opinion be more confusing. Best Regards, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
