Question about glib g_scanner_peek_next_token
Hello I'm using the GScanner lexical scanner of glib in a project. I have a question about g_scanner_peek_next_token: In the documentation says that if I call g_scanner_peek_next_token and change the scope, the token isn't reevaluated, i.e if I change the scope and then get the token by g_scanner_get_next_token, the token returned is not evaluated again. I have seen the code of gscanner.c, in the function g_scanner_peek_next_token. If supported to force the token reevaluation assigne to scanner-next_token the value G_TOKEN_NONE?. Greetings Carlos ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: libglade and GObject support
ext Tristan Van Berkom wrote: I think it would be much better for everyone if we get GtkBuilder done now and not evolve on libglade, my concern here is mostly based on the diverse ways in which you can represent widgets in xml: libglade might do it one way, GtkBuilder might want to do it another - then with all kinds of glade files in circulation things will definitly be harder to manage. Agreed. About GtkBuilder, wouldn't it be a good idea to push it into svn? That would give it more visibility and probably speed up its inclusion in gtk+. Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Please Help
Iam converting values from 32bit Color space to 16bit color space ( supported by GdkColor) while using the API to set the color values i need to convert the corrosponding values of Red , Green and Blue and the pixel depth as follows GdkColorcolor; color.pixel = 4 color.red = red color color.green = green color color.blue = Blue color gdk_color_alloc( gdk_colormap_get_system(), color ); gdk_gc_set_background( gdkgc, color ); but the 32 bit color value 0x7FFF has the alpha value present in it, How do i convert that value and set it to the GdkColor Structure in order to have the same look.?? please guide me on the proper conversion and the value of pixel variable Thankx -- Best Regards, Masroor Khan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: DirectFB backend eventualy fixed in both trunk and gtk-2-10
On 5/10/07, Attilio Fiandrotti [EMAIL PROTECTED] wrote: One more thing: i often need to disturb mike or loic to get patches cheched in, may i get write access to gnome's svn repo to manage the directfb backend? Check this out: http://developer.gnome.org/doc/policies/accounts/requesting.html -- my place on the web: floss-and-misc.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
Hi Alex, On Thu, 2007-05-10 at 09:41 +0200, Alexander Larsson wrote: So, if you were to implement gstreamer sinks and sources for gvfs, an api like: gssize g_input_stream_read (GInputStream *stream, void *buffer, gsize count, GCancellable *cancellable, GError **error); Would be ok with you? Its a blocking call, but if you pass in a GCancellable you can use that to cancel the call from another thread. I pinged this off a couple of other folks and we all think it's OK. Make sure the read never happens if the cancellable was cancelled before the read began, of course. And you wouldn't be interesting in async (mainloop-using) i/o operations at all? I do not see GStreamer taking advantage of this, no. Cheers, Andy. -- http://wingolog.org/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Wed, May 09, 2007 at 02:01:20PM +0200, Sven Neumann wrote: Wouldn't it make more sense to introduce a new signal row-delete and use that instead of changing the semantics of row-deleted? If that would have been done in the first place, then you wouldn't have said inconsistency now. Yes, I agree that this complete problem wouldn't exist if we had added a new signal. However, right now both the filter and sort models have been emitting row-deleted before deleting the row and the documentation has had the said note for quite some time now, so personally I prefer to fix up the list and tree store at this point. Later on we can then easily add a post-row-deleted if required. Moving the filter and sort models over to a pre-row-deleted would require patching up tree view and will break any object (views, models, etc) which create their own references to iterators and release those on row-deleted, plus all third-party models doing reference counting. I think such a change would be more troublesome from a compatibility point of view than the change of gtk_tree_model_foreach() (for just the list and tree store) as outlined in my previous mail. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Pango: slight performance tweak.
I've made a change to pango-layout.c. When fitting text in a line, the
current algorithm does a linear search to find the break. I thought that
performance would be further increased by storing character width
cumulatively (rather than differentially) so that a binary search could be
performed. I made the change and I think I see a 35% reduction in search
time for the ONE use case I tried. I ran this:
./pango-view --wrap=word --width=800 test-long-paragraph.txt
and counted the number of loops to find the width breakpoint, then counted
the number of loops to find the line break.
The way this works is once the character width is stored cummulatively you
can get the width for however many characters like this:
width = state-width[state-log_widths_offset + num_characters] -
state-width[state-log_widths_offset];
The routine does a binary search for the number of characters that will fit
on the line then does a linear search backwards for a proper line break.
Index: pango-glyph.h
===
--- pango-glyph.h (revision 2271)
+++ pango-glyph.h (working copy)
@@ -100,6 +100,12 @@
PangoRectangle *ink_rect,
PangoRectangle *logical_rect);
+void pango_glyph_string_get_cummulative_widths (PangoGlyphString *glyphs,
+ const char *text,
+ int length,
+ int embedding_level,
+ int *cummulative_width);
+
void pango_glyph_string_get_logical_widths (PangoGlyphString *glyphs,
const char *text,
int length,
Index: glyphstring.c
===
--- glyphstring.c (revision 2271)
+++ glyphstring.c (working copy)
@@ -297,6 +297,79 @@
* @text: the text corresponding to the glyphs
* @length: the length of @text, in bytes
* @embedding_level: the embedding level of the string
+ * @cummulative_width: an array whose length is g_utf8_strlen (text, length) + 1
+ * to be filled with the cummulative character widths. The first
+ * entry is always 0.
+ *
+ * Given a #PangoGlyphString resulting from pango_shape() and the corresponding
+ * text, determine the screen width corresponding to each character. When
+ * multiple characters compose a single cluster, the width of the entire
+ * cluster is divided equally among the characters.
+ **/
+void
+pango_glyph_string_get_cummulative_widths (PangoGlyphString *glyphs,
+ const char *text,
+ int length,
+ int embedding_level,
+ int *cummulative_width)
+{
+ int i, j;
+ int last_cluster = 0;
+ int width = 0;
+ int last_cluster_width = 0;
+ const char *p = text; /* Points to start of current cluster */
+ int cummulative = 0;
+
+ if (cummulative_width) cummulative_width[0] = 0;
+
+ for (i=0; i=glyphs-num_glyphs; i++)
+{
+ int glyph_index = (embedding_level % 2 == 0) ? i : glyphs-num_glyphs - i - 1;
+
+ /* If this glyph belongs to a new cluster, or we're at the end, find
+ * the start of the next cluster, and assign the widths for this cluster.
+ */
+ if (i == glyphs-num_glyphs || p != text + glyphs-log_clusters[glyph_index])
+ {
+ int next_cluster = last_cluster;
+
+ if (i glyphs-num_glyphs)
+ {
+ while (p text + glyphs-log_clusters[glyph_index])
+ {
+ next_cluster++;
+ p = g_utf8_next_char (p);
+ }
+ }
+ else
+ {
+ while (p text + length)
+ {
+ next_cluster++;
+ p = g_utf8_next_char (p);
+ }
+ }
+
+ for (j = last_cluster; j next_cluster; j++)
+ cummulative = cummulative_width[j+1] =
+ (width - last_cluster_width) / (next_cluster - last_cluster) +
+ cummulative;
+
+ last_cluster = next_cluster;
+ last_cluster_width = width;
+ }
+
+ if (i glyphs-num_glyphs)
+ width += glyphs-glyphs[glyph_index].geometry.width;
+}
+}
+
+/**
+ * pango_glyph_string_get_logical_widths:
+ * @glyphs: a #PangoGlyphString
+ * @text: the text corresponding to the glyphs
+ * @length: the length of @text, in bytes
+ * @embedding_level: the embedding level of the string
* @logical_widths: an array whose length is g_utf8_strlen (text, length)
* to be filled in with the resulting character widths.
*
Index: pango-layout.c
===
--- pango-layout.c (revision 2271)
+++ pango-layout.c (working copy)
@@ -30,6 +30,9 @@
#include pango-layout-private.h
+#define GET_WIDTH(num_characters) \
+ (state-width[state-log_widths_offset + num_characters] - \
+ state-width[state-log_widths_offset])
typedef struct _Extents Extents;
typedef struct _ItemProperties ItemProperties;
@@ -3014,7 +3017,7 @@
int start_offset; /* Character offset of first item in state-items in layout-text */
Re: Tap and Hold API
On Wed, 2007-05-02 at 16:34 +0200, Tim Janik wrote: [excellent analysis snipped] so i'd say that tap-and-hold expiration is one of the rarer cases, where one should always use GDK_CURRENT_TIME for menu popups. that in turn means there's no point in carrying across a time stamp (which would be outdated or misleading anyway) in the tap-and-hold API. it might make sense to add this consideration to the docs though. Yeah, very good point - I hate that constant because it makes for buggy programs, but this seems to be one of the very few cases where it is indeed the right thing :) The docs for tap-and-hold should definitely mention that you should use GDK_CURRENT_TIME for your popup's timestamp. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Tap and Hold API
On Fri, 2007-05-04 at 12:15 +0200, Kristian Rietveld wrote: On Tue, May 01, 2007 at 07:47:25PM -0500, Federico Mena Quintero wrote: You have two tap-and-hold actions: pop up a menu and pop up a tooltip with extra info. Should those have the same I'm armed animations? Yes, I would say that for both of those actions the animations should be the same; for both of them the user is holding down the stylus and you want to show the same indication that the system is doing something with that action regardless of what will show up next. Okay, then. So you should follow the current fashion of posting a video of this in action, so that we can a) drool at your sexy handheld gadgets, and b) drool at the APIs :) tap-and-hold-keysym = FunkyKey in your ~/.gtkrc? Yes, but probably with a default key combination in GTK+ modifiable via key themes. Are there handheld thingies besides Nokias which have a similar immediate tap-and-hold key? One of those pushable-wheel thingies may let you change the focus by rotating the wheel, then immediate-tap-and-hold by pressing the wheel (then pick a menu item with the wheel again). I think I want one now. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
FYI: The scripts I use to build GTK+ for Win32
Poked by arc (Alberto Ruiz) on IRC, here is a description of the (totally homegrown and not really meant to be used as such by others) mechanism I use to build GTK+ etc. The top-level script, one for each package and version, has a name like gtk+-2.10.11.make. Here is that gtk+-2.10.11.make script, with blank lines and verbose comments added: cut here # First identify what this script is building. These shell variables # have no meaning outside this script. MOD=gtk+ VER=2.10.11 THIS=$MOD-$VER # I use a randomish hex digit string in the path passed as --prefix to # configure to hopefully make it more clear that this is just a # temporaryish path used on the build system, not something that is # expected to exist on the end-user systems. HEX=`echo $THIS | md5sum | cut -d' ' -f1` TARGET=c:/devel/target/$HEX # Here I get the list of dependencies. The latest.sh script outputs # a single line of text, like: # glib-2.12.12 atk-1.18.0 cairo-1.4.2 pango-1.16.4 # This list will then be used below to add the paths of the bin # folders of the corresponding binary distributions to PATH, and to # the add the paths of the lib/pkgconfig folders to PKG_CONFIG_PATH. # latest.sh uses just a single file listing the latest stable version # of each package. No recursive dependencies handled. For the higher # level GNOME packages I have to list the closure of dependencies # here. # For instance, in evolution-2.8.2.make, I have: # DEPS=`/devel/src/tml/latest.sh glib atk cairo pango gtk+ libglade libIDL ORBit2 libbonobo GConf libbonoboui gnome-mime-data libgnome libgnomeui gnome-vfs libsoup evolution-data-server gnome-icon-theme libgnomeprint libgnomeprintui libart_lgpl libgnomecanvas gail gtkhtml` DEPS=`/devel/src/tml/latest.sh glib atk cairo pango` # I don't want libtool to do its relink stuff, as it makes building # even slower, and also is unnecessary IMHO. I think I have even seen # it cause hard to understand build problems earlier. So I edit the # ltmain.sh script (from the gtk+ tarball). sed -e 's/need_relink=yes/need_relink=no # no way --tml/' ltmain.sh ltmain.temp mv ltmain.temp ltmain.sh # The usedev and usemsvs6 shell functions set up the PATH, # PKG_CONFIG_PATH and ACLOCAL_FLAGS environment variables for a basic # development environment with mingw32, various gnuwin32 packages, and # other necessary things, but no GTK+ or GNOME-related stuff. # ACLOCAL_FLAGS of course isn't used when running a configure script, # but I use the same shell functions also when building stuff from SVN # and running autogen.sh scripts # usemsvs6 adds MSVC6 to PATH etc, needed here only to get lib.exe # from MSVC6, which is used to produce the import libraries (.lib # files) included in the developer package for MSVC users. usedev usemsvs6 # Add the bin folders of the dependencies listed above to PATH, and # the lib/pkgconfig folders to PKG_CONFIG_PATH. MY_PKG_CONFIG_PATH= for D in $DEPS; do PATH=/devel/dist/$D/bin:$PATH MY_PKG_CONFIG_PATH=/devel/dist/$D/lib/pkgconfig:$MY_PKG_CONFIG_PATH done # Then run the configure script. I explicitly pass in -I flags in # CFLAGS and -L flags in LDFLAGS pointing to where I have various # dependencies not handled by the latest.sh mechanism. # The -mthreads option doesn't do awfully much in a C compilation, but # should still be used when building code that potentially could be # used from multiple threads. (On the other hand, the actual # GUI-related GTK+ functions will not work if used from multiple # threads on Win32, so it's kinda pointless, but shouldn't hurt # anyway.) # The --enable-auto-image-base is used to get a randomized base # address for DLLs. This is the default (if I recall correctly) in # more recent libtools, but the one packaged in the gtk+ tarball # packager would use a fixed base address otherwise, causing all DLLs # to need relocation at run-time, which adds some (minimal) overhead. # The --with-wintab and --with-ie55 switches are needed to get Wintab # and ActiveIMM support in the stable branch. In trunk, wintab support # gets compiled in always (the required header file is # redistributable, and included in GTK+ sources in trunk), and # ActiveIMM support has been removed (because it was something for # Win9x and NT4 only). PKG_CONFIG_PATH=$MY_PKG_CONFIG_PATH:$PKG_CONFIG_PATH CC='gcc -mtune=pentium3 -mthreads' CPPFLAGS='-I/opt/gnu/include -I/opt/gnuwin32/include -I/opt/misc/include' LDFLAGS='-L/opt/gnu/lib -L/opt/gnuwin32/lib -L/opt/misc/lib -Wl,--enable-auto-image-base' LIBS=-lintl CFLAGS=-O2 ./configure --with-gdktarget=win32 --with-wintab=/devel/src/wtkit126 --with-ie55=/devel/src/workshop/ie55_lib --enable-debug=yes --disable-gtk-doc --disable-static --prefix=$TARGET # libtool-cache is a nifty method to speed up libtool. See # http://libtool-cache.sourceforge.net/ libtoolcacheize unset MY_PKG_CONFIG_PATH # Then run a make install. I'm not sure if adding .libs to PATH # actually is necessary, it's
Re: Fixing the GtkTreeModel::row-deleted inconsistency
On Thu, 2007-05-10 at 17:04 +0200, Kristian Rietveld wrote: There are no clear rules for this, actually. Most simple models don't have a real use for this. The filter and sort models both use this mechanism to keep track of which levels to cache and monitor. Models which reference external objects might want to use it. A node is referenced when it is visible. In the rule all expanded nodes count as visible; all nodes which are in GtkTreeView's internal rbtree are referenced. So in general - A node is referenced if it is within the scrolled-in area of the view. - A node is referenced if it is expanded, even if it is not within the scrolled-in area (i.e. everything which the rbtree mirrors is reffed). Is that correct? [Humm, toplevel nodes are always in the rbtree, I think. Does this mean that all toplevel nodes are always reffed?] I'd love to watch a little toy model that just keeps an int for each node, and printf()s the references for each node as they change. Then you could see if scrolling the view up and down indeed keeps only the required nodes reffed --- this would be good evidence that you can indeed implement a model which doesn't have all its data exploded in memory all the time. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Default DND action when multiple actions defined
Heya, It doesn't seem possible to achieve the following in GTK+: - widget accepts GDK_ACTION_COPY and GDK_ACTION_MOVE, but widget has a *default* action of GDK_ACTION_MOVE (not copy) I'm trying to get to the following behaviour in Totem: - dnd on the video canvas defaults to link which would clear the playlist, and add the dropped items to the list. Pressing Ctrl at the same time would add the items to the playlist. - dnd on the playlist which would copy by default, and only add the items to the list. Pressing Shift at the same time would replace the items in the playlist. Is it possible to do this in GTK+ right now? (in which case, pointers appreciated, and I'd update the docs to show that) If not, is it an XDND protocol limitation, or a GTK+ one? Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
