Re: how to customise gtk-doc output
Hi Stefan, > headers/footers customizable. Right now they are generated by the > docbook stylesheets and this makes it slow. Feel free to file a bug an > mention what changes you did. This will help me to design this features. OK, bug here: https://bugzilla.gnome.org/show_bug.cgi?id=781291 John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: how to customise gtk-doc output
On 12 April 2017 at 13:23, Sébastien Wilmet wrote:
> On Wed, Apr 05, 2017 at 10:24:00AM +0100, jcup...@gmail.com wrote:
>> I'd like to customise the gtk-doc output for my project: I'd like a
>> new header, and some tracker stuff in the footer.
>> xslt and the configure options to gtk-doc?
>
> I don't know how it is done on developer.gnome.org, but it should be
> implemented somewhere in
> https://git.gnome.org/browse/library-web/
Oh nice, I didn't find that, thanks! Yes, it seems they have some
fancy Python to reformat the pages.
I ended up doing something very simple. This line of Ruby:
template.at_css(".main-content").children = doc.at_css("body").children
Just takes everything inside and drops it into a standard
github pages template, making (for example) this:
http://jcupitt.github.io/libvips/API/current/VipsImage.html
Reformatter here:
https://github.com/jcupitt/libvips/blob/gh-pages/gen-api.rb
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
how to customise gtk-doc output
Hello everyone, I'd like to customise the gtk-doc output for my project: I'd like a new header, and some tracker stuff in the footer. I see glib does this. The online docs here: https://developer.gnome.org/gobject/unstable/ Have a new header and footer pasted into each page. What's the best way to do this? Does everyone write a tiny program to add these new sections, or is there something clever you can do with xslt and the configure options to gtk-doc? Thanks! John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Up-to-date Valgrind suppression file for GLib/GTK+ ?
On 29 December 2016 at 23:55, Emmanuele Bassi wrote: > As Philip explained earlier in the thread, Valgrind can only accept a > single suppression file. So, if GTK+ ships a suppression file, it > would need to include suppression rules for all its dependencies, and > you would still be unable to add your own on top of that. The only way I realize you're talking about the default suppressions file, but of course valgrind can load many non-default suppression files at once. Up to 100, according to the man page. $ valgrind --suppressions=/first/file.supp --suppressions=/second/file.supp ... So I think there would be some value in shipping separate, official .supps for glib, gobject, gio, gtk etc etc. We'd need one for each .pc file, so Stefan's suggestion of a pkg-config var sounds very reasonable to me. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: bug in gtk_adjustment_clamp_page()?
On 27 November 2015 at 12:21, Thomas Martitz wrote: > Am 26.11.2015 um 16:24 schrieb jcup...@gmail.com: >> >> Or maybe I've misunderstood what clamp_page is for. Is this a bug? >> >> The context here is tabbing focus into a scrolled window triggers >> gtk_adjustment_clamp_page(), which always scrolls back to the left/top >> because of these swapped tests. I'm working on an image viewer and I >> obviously don't want to move the image around when I tab into that >> window. >> >> If I swap the < and >, everything seems to work for me at least. >> > > I can't tell if that's the fix, but I also experience the erroneous > behaviour you describe. Thanks to Florian Muller I found the fix. I had a GtkDrawingArea inside a GtkScrolledWindow, and the drawing area could be tabbed to (I want various keyboard actions for image navigation). When you tab to something inside a container, if the container has scrollbars, they will automatically scroll to make the object visible. This code is in gtkcontainer.c: https://git.gnome.org/browse/gtk+/tree/gtk/gtkcontainer.c#n2680 The problem I had (and I guess you have?) is what happens if the object being made visible is larger than the viewport. The code in gtk_adjustment_clamp_page() will move the scrollbars to the top or left of the object, even if as much of the object as possible is already being displayed. The fix for me has been to make the scrolled window rather than the drawing area the thing you can tab to. If the drawing area isn't a tab target, you won't get the inappropriate auto-scroll behaviour. I attach my key event handler to the scrolled window and then translate event positions to drawing area coordinates myself. I suppose another solution would be to change the behaviour of gtk_adjustment_clamp_page() for objects larger than the viewport, but I doubt if there's much enthusiasm for that. My code is here, if it's any help: https://github.com/jcupitt/vipsdisp John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
bug in gtk_adjustment_clamp_page()?
Hi all, I've found some puzzling code in gtk_adjustment_clamp_page().
Maybe it's a bug? I'm unsure.
These lines:
https://git.gnome.org/browse/gtk+/tree/gtk/gtkadjustment.c#n932
Clamp the value of an adjustment so it lies between lower and upper.
But aren't the < and > reversed? Those lines should surely be:
if (priv->value + priv->page_size > upper)
{
priv->value = upper - priv->page_size;
need_emission = TRUE;
}
ie. if bigger than upper, limit to upper.
Or maybe I've misunderstood what clamp_page is for. Is this a bug?
The context here is tabbing focus into a scrolled window triggers
gtk_adjustment_clamp_page(), which always scrolls back to the left/top
because of these swapped tests. I'm working on an image viewer and I
obviously don't want to move the image around when I tab into that
window.
If I swap the < and >, everything seems to work for me at least.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building glib on windows
Hi Tim, On 3 November 2015 at 14:53, Tim-Philipp Müller wrote: > The build system GStreamer uses for this (cerbero) should be able to do > that (our windows build bots do that): > > http://cgit.freedesktop.org/gstreamer/cerbero/ From reading the sources, it looks like cerbero/ide/vs/genlib.py is run over all DLLs produced by all recipes. This class first runs `gendef` to make the .def file, then uses `dlltool` to make the .lib file from that. I'll trying hacking up something like this in bash and run it as a final pass before packaging. I realize there are issues around sharing resources created by different C runtimes, but I think in my case at least (node.js on win64 using a gobject-based library) I'll be OK. Thank you all very much again! John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: building glib on windows
On 3 November 2015 at 14:34, Ignacio Casal Quinteiro wrote: > have a look at this: > https://github.com/nice-software/gtk-win32 Hi Ignacio, that looks great, but unfortunately I need to build on linux and cross-compile :-( Does anyone have a link to linux-hosted win64 gtk build system I could have a look at? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
building glib on windows
Hi everyone, I'm trying to make my own 64-bit glib DLLs for Windows users. I'm cross-compiling from linux with jhbuild. It seems to be working, except that VS users can't link to the libraries I'm making. It looks like I need to generate .def and .lib files. Does anyone know the recommended way to do this? I see the (now too out of date, unfortunately) official ones have these files, but I can't see a simple way to make them myself :-( Is there some script to run that I've not been able to find? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Distributing OSX binaries
Hi Daniel, On 4 July 2015 at 03:37, Daniel Kasak wrote: > I've previously built OSX binaries, just for myself, but now I'd like > to share amongst some workmates. I'm not really up-to-speed with OSX > and packaging ( new job, Mac-only shop ). I use this: https://wiki.gnome.org/Projects/GTK+/OSX/Bundling I guess you saw the building page they have? Also very useful. https://wiki.gnome.org/Projects/GTK%2B/OSX/Building John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [glib] Why is g_ptr_array_set_size take a gint instead of guint for the length parameter?
>> >> I'm looking for the rational of using 'gint' instead of 'guint' in the >> >> call: >> >> >> >> g_ptr_array_set_size (GPtrArray *array, gint length); >> >> > >> > I imagine that the use of a signed integer was an oversight at the time >> > which can now not be corrected without breaking API. It's not worth >> > that. >> I remember (a long, long time ago) there was a dislike for uint. Mixing uint and int can be fiddly and produce a range of bugs, some more subtle than others, and the extra bit of range you get is unimportant. int-only code is usually simpler and safer. The uints scattered through xlib are a good example of the confusion they can cause. The argument the other way would be that declaring it unsigned gives extra information about what "length" means (it's a number of things, not a distance). I guess that point of view won out. I agree that the inconsistency is annoying and puzzling. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: New GObject Introspection tutorial
On 13 June 2013 07:54, Simon Kågedal Reimer wrote: > I've written a tutorial on how to make a basic multilevel "Hello > World" using GObject Introspection: > > http://helgo.net/simon/introspection-tutorial/ Looks great, thank you for making this, Simon. How about some notes on boxed types? They are necessary for any non-tiny library, and currently rather poorly documented, as far as I know. In fact, I've never been able to get them to work at all :-( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Partial frame synchronization TODO
This all sounds fantastic, but I have a stupid question: On Thursday, October 4, 2012, Owen Taylor wrote: > > * When there is a frame where no painting ends up being done, we still > at the moment are sending increments to the frame serial and waiting > for_NET_WM_FRAME_DONE. It may be worth tracking when we are about to > damage a toplevel window (by drawing or configuring it) and only at > that point start a frame. Then we'll avoid asking the compositor to > tell us when it's done painting a frame that involves no painting. > Does this mean we have a busy idle? Does this have implications for laptop battery life? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Infinite List
There was a useful thread last December about gtktreeview performance with large data sets: https://mail.gnome.org/archives/gtk-app-devel-list/2011-December/msg00092.html It included this very nice example of making a treeview with a custom model: http://pastebin.com/45br5X3Z You need to add this line of code after creating the columns (this was the bug the thread solved): gtk_tree_view_set_fixed_height_mode (GTK_TREE_VIEW (list), TRUE); John On Thursday, September 13, 2012, Nick Glynn wrote: > Hey guys, > > I'm writing an app that shows information from a website - a similar app > to Pattrn for Android but for Gnome- but don't want to have all data/images > downloaded and present before the app starts. > > What's the best widget/method to implement an Infinite List[1] style > mechanism using Gtk where more data requests are fired either by a reload > gesture/button or, preferably, by exposing the bottom of the list? > > Thanks, > Nick > > [1] http://designinginterfaces.com/patterns/infinite-list/ > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I want to fix a bug in GTK and need some guidance
Hi Noam, On 24 January 2012 10:12, Noam Yorav-Raphael wrote: > Can someone guide me on how to compile GTK with debugging enabled, and > how to compile a C program that would use the GTK I compiled, so I can > run it under gdb and try to fix the bug? It's pretty easy. Download the gtk sources, untar, and compile to a local prefix. Something like: tar xf gtk+-x.x.x cd gtk+-x.x.x CFLAGS=-g ./configure --prefix=/home/noam/mygtk You'll need to have the -dev packages for the gtk stack installed so that all the headers for all the prerequisites are available, but you probably have those already. Once it configures cleanly try: make make install Now get your build environment to see your new gtk before the system one. You need to set PKG_CONFIG_PATH to /home/noam/mygtk/lib/pkg-config. Finally, compile your test program and it'll see your private gtk gcc -g test.c `pkg-config gtk+-2.0 --cflags --libs` You can run into trouble if the gtk you build needs a more recent cairo / glib / pango / whatever than you have on your system. You'll find yourself installing more and yet more libraries to get a working gtk stack and then maintaining that pyramid of hand-built packages becomes a terrible pain. Use jhbuild to fix this. It's a Python program which will download, configure and install the entire gtk stack from git for you to a private prefix, and keep everything updated for you as well. https://live.gnome.org/Jhbuild It does take a little fiddling to get it working but it's probably worth it if you want to build the very latest code. Plus since everything is in git it'll format any bug fixes you make nicely ready to be passed upstream. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
On 13 January 2012 22:21, Paul Davis wrote: > there is a bigger issue there, i think. in an ideal world, you don't > want to base the date store for the TreeView on an object, but on an > interface. then you want a series of adapters/wrappers that wrap data > structures implemented in any language (or any language with a GTK > binding) with the required interface. some of which might be "null" > adapters that just do passthrough to the underlying data object. > > there's nothing more stupid that taking a "native" data structure > (e.g. a C++ list, a python array, some app-specific creation, etc) and > having to copy the data out of it into some GObject-based data > structure before being able to give it to the TreeView. well, ok, Off topic, but I believe that's more or less how it works now. You can define your own model that implements the GtkTreeModelIface and TreeView will then display from that. You need to put your data items into GValues but you don't need to make GObjects for them. And the GValues only need to be made on demand for the items which are being sent for display (the current window), you don't need to pack the whole thing. John Lindgren posted a complete small example a few months ago (though I think he's missing set-fixed-height mode in that code): http://pastebin.com/45br5X3Z You can display *huge* datasets directly from your application's internal structures. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gobject-introspection and GBoxed
Hi Tomeu,
On 12 January 2012 11:02, Tomeu Vizoso wrote:
> Looks like a bug in pygobject, could you file a bug with a backtrace?
>
> It may be worth trying out with the latest release to scope better the
> problem.
I've tried with git master gobject-introspection and 3.0.3 pygobject
and the crash has gone but it still doesn't work. Should I file a bug
or am I making a stupid error?
I have this in the header:
/* A very simple boxed type for testing. Just holds an int.
*/
typedef struct _VipsThing {
int i;
} VipsThing;
/**
* VIPS_TYPE_THING:
*
* The #GType for a #VipsThing.
*/
#define VIPS_TYPE_THING (vips_thing_get_type())
GType vips_thing_get_type( void );
VipsThing *vips_thing_new( int i );
int vips_thing_get_i( VipsThing *thing );
-
this in the .c file:
---
/* A very simple boxed type for testing. Just an int.
*/
/**
* vips_thing_new:
* @n:
*
* Returns: (transfer full): a new #VipsThing.
*/
VipsThing *
vips_thing_new( int i )
{
VipsThing *thing;
thing = g_new( VipsThing, 1 );
thing->i = i;
printf( "vips_thing_new: %d %p\n", i, thing );
return( thing );
}
static VipsThing *
vips_thing_copy( VipsThing *thing )
{
VipsThing *thing2;
thing2 = vips_thing_new( thing->i );
printf( "vips_thing_copy: %d %p = %p\n", thing->i, thing2, thing );
return( thing2 );
}
static void
vips_thing_free( VipsThing *thing )
{
printf( "vips_thing_free: %d %p\n", thing->i, thing );
g_free( thing );
}
int
vips_thing_get_i( VipsThing *thing )
{
printf( "vips_thing_get_i: %d %p\n", thing->i, thing );
return( thing->i );
}
G_DEFINE_BOXED_TYPE( VipsThing, vips_thing,
(GBoxedCopyFunc) vips_thing_copy,
(GBoxedFreeFunc) vips_thing_free );
---
But this happens in Python:
>>> from gi.repository import Vips
>>> dir(Vips)
... long list, all the GObject based types I use are there and work,
so I think the introspection stuff is OK
... Vips.thing* is not there, but Vips.Thing is
>>> Vips.Thing
Traceback (most recent call last):
File "", line 1, in
File "/home/john/vips/lib/python2.7/site-packages/gi/module.py",
line 243, in __getattr__
return getattr(self._introspection_module, name)
NotImplementedError:
>>> Vips.Thing(12)
NotImplementedError:
>>> Vips.Thing.new(12)
NotImplementedError:
>>> dir(Vips.Thing)
NotImplementedError:
>>> Vips.thing_new
AttributeError: 'gi.repository.Vips' object has no attribute 'thing_new'
>>>
The "/home/john/vips/lib/python2.7/site-packages/gi/module.py" in the
backtrace proves that I'm using my own build of gi master and not the
host one, I hope.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: new features
My 2p: DATA GRID I'd like to be able to display a grid of numbers with rectangular selection, a little like a spreadsheet. Unfortunately this is not possible with treeview. At the moment I use a fork of the ancient and broken GtkSheet widget, which is unfortunate. PLOTS As Jean said, goffice has a nice set of plotting widgets. I use them in my app and they work well and are easy to program. I've not tried doing an animated scrolling graph with them though. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gobject-introspection and GBoxed
Hi all,
I'm adding gobject-introspection support to my library. It's working
well for the GObject classes, but I just can't get it to work for
GBoxed objects. I'm sure I'm missing something obvious. Do I need to
write an override to make a class for the type myself?
I've spent some time googling and grepping around and not found a
simple example. Again, I'm probably being stupid.
I'm doing something like this in a header:
/**
* VIPS_TYPE_BLOB:
*
* The %GType for a #VipsBlob.
*/
#define VIPS_TYPE_BLOB (vips_blob_get_type())
GType vips_blob_get_type( void );
typedef ... VipsBlob;
VipsBlob *vips_blob_new( int n );
and this in the .c file:
GType
vips_blob_get_type( void )
{
static GType type = 0;
if( !type )
type = g_boxed_type_register_static( "VipsBlob",
(GBoxedCopyFunc) ...,
(GBoxedFreeFunc) ... );
return( type );
}
/**
* vips_blob_new:
* @n:
*
* Returns: (transfer full): the new #VipsBlob.
*/
VipsBlob *
vips_blob_new( int n )
{
return (...a new VipsBlob);
}
Now when I start up Python I get this:
>>> from gi.repository import Vips
>>> Vips.blob_new
>>> Vips.blob_new(12)
Program received signal SIGSEGV, Segmentation fault.
_args_cache_generate (callable_cache=0x9b04c0, callable_info=0xa6d280)
at /build/buildd/pygobject-3.0.0/gi/pygi-cache.c:1282
This is on current Ubuntu, so:
$ pkg-config gobject-introspection-1.0 --modversion
1.30.0
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On 9 December 2011 04:34, Allin Cottrell wrote: > On Thu, 8 Dec 2011, Ryan Lortie wrote: >> Today I landed the GMenuModel work on glib master [...] >> Menubars are no longer a per-window concept. They are now set for the >> entire application. This is done for two reasons: >> >> 1) every app already has the same menubar (content) in each window > > Whoa! Where is that notion coming from? Some empirical input seems to be > called for. It may not be the most typical situation, but a fair number of > GTK apps put up different-looking windows, with substantially different menu I like the sound of this change generally, but I think I need per-window menus in my program too. I have windows which display images, windows which display matrices, windows which display program code, windows which display large interactive graphs ... and so on. These different data types need different operations available. I have to be able to add and remove menus depending on the window type. I suppose I could have a single menu tree with everything from every window type rolled together, but then I'd need a way to grey out irrelevant items per-window, which is almost the same thing as multiple menus. And I'd think it would be frustrating for the user to have to work with a menu system where 2/3rd of the visible items are noise. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: Plans for GTK+ Bundles for win32 and win64?
On 8 September 2011 11:39, Alberto Ruiz wrote: > Third, and the most important. Windows has no package manager. You should > not delegate on users the responsibility of making sure that a working copy > of GTK is installed. This is annoying enough with Java. > > A .zip bundle (and maybe some facilities to shove that into your app > installer) is the best approach for now IMHO. Probably everyone knows about this, but just in case: http://coapp.org This is a package manager for Windows with some MS funding behind it (they are paying the lead dev and providing the infrastructure, I believe). If it takes off, this would be the way to get one gtk runtime for all installed gtk applications. Fingers crossed! It would be wonderful if this works out. Until that happy day I agree with Alberto that the best solution is to bundle a copy of the runtime with each application. It's easy to do and only adds a few MB to the download. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: decrease widget show time
Hi, 2011/3/21 czk : > Following is my test program and test result: > Obviously, most time spend on the last gtk_widget_show. You could try adding a call to realize, just before show(): gtk_widget_realize (window); This will do most of the initialisation, but not actually show the window. You can do this beforehand, perhaps in device startup, then when you want to present the window to the user, do the final show() operation. It might not make much difference, it probably depends a lot on your backend. Do you have any better profiling tools available? Things like font rendering and theme drawing can be slow too. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Re: How gvdb_table_is_valid works on glib/dconf??
On 16 February 2011 10:50, Joshua Lee wrote:
> I'm curious why gvdb_table_is_valid works. Here's the implementation
> of gvdb_table_is_valid.
>
> gboolean
> gvdb_table_is_valid (GvdbTable *table)
> {
> return !!*table->data;
> }
Ah I see, sorry. This function will return 1 if table->data points to
a non-empty string, and 0 otherwise.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: How gvdb_table_is_valid works on glib/dconf
On Wednesday, 16 February 2011, Joshua Lee wrote: > Then I run the test program, !!*data will always output 1. Here's the > output. Isn't that expected behaviour? Data points to a non-empty string, so *data will always be non-zero. Therefore !*data will always be zero, therefore !!*data will always be 1. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: cross compiling GTK+ on Linux for Windows
2010/6/16 Krzysztof Kosiński : > 2010/6/14 Tor Lillqvist : >> For anybody new looking into it, I certainly recommend using >> cross-compilation. Have a look at the spec files for the >> cross-compiled GTK+ stack (and much more) for Windows in the OpenSUSE >> Build Service. See >> http://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_11.0/src/ >> for the source RPMS, and sibling directories for "noarch" RPMs >> containing in fact Windows binaries. My plan is that eventually the >> Windows binaries offered from www.gtk.org / ftp.gnome.org will come >> from the OpenSUSE Build Service projects. > > Is there any "sanctioned" way of doing this on Debian? I do this on Debian using the set of mingw32* packages. They don't include a pre-compiled gtk stack, but Tor's zips work well for me. I use nsis (also in Debian) to automatically generate a .exe installer as well. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 2 April 2010 17:47, wrote: > I've now read the equivalent functions in openmp (which has an > incredibly complicated linux version, it's several hundred lines of > code), qt and gimp. I'll put a patch and some notes on bugzilla. I've put a patch on bugzilla, I guess discussion should continue there (if anyone still has anything to say, heh): https://bugzilla.gnome.org/show_bug.cgi?id=614930 John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 2 April 2010 11:21, Pavel Machek wrote: > Actually, he got the naming right. Even single-core cpus have cores... I've now read the equivalent functions in openmp (which has an incredibly complicated linux version, it's several hundred lines of code), qt and gimp. I'll put a patch and some notes on bugzilla. Everyone seems to call the function something like get_num_processors(), so I suggest we go for: int g_get_num_processors (void); John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 15 March 2010 23:08, Andrew W. Nosenko wrote: > GCC OpenMP implementation has one also. omp_get_num_procs(). > Mandated by OpenMP spec and essentially for the same reason :-) Thanks, I see they have versions for several other platforms. I'll nick some of their stuff too. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 15 March 2010 22:43, Sven Neumann wrote: > Feel free to use the implementation in GIMP as a starting point: Perfect! Thank you very much Sven, I'll try to make a patch and submit a bug. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 15 March 2010 17:46, Martin Nordholts wrote: > On 03/15/2010 12:14 PM, jcup...@gmail.com wrote: >> I'd my program (a threaded image processing system based on gthread) >> to be able to find out how many cores the host machine has. This would >> let me make my threadpools default to a sensible size. > > That would maybe work OK if only one program ran at a time, but I don't > think that is a fair assumption. If I were to attack this problem I would > look into porting Apple's libdispatch to Linux and go on from there. In > short, the libdispatch framework is an OS level mechanism that takes care of > distributing cores across programs. Yes, libdispatch is a nice mechanism. If anyone's not come across it, it provides dynamically resizeable threadpools with a central manager which adjusts pools globally to keep the system from bogging down (and a few other bells and whistles, or that's my understanding anyway). But it seems to me that we have a more immediate need: gthread has a threadpools, but no way to pick a reasonable size for a pool. I guess existing cross-platform applications and libraries which use threadpools must all have some duplicated code to pick a default pool size*. If we centralise this, we could perhaps add some standard mechanisms, like a --g-threadpool-size=N argument, or a G_THREADPOOL_SIZE environment variable. John * though I'm too lazy to look ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gthread: how many cores do I have?
On 15 March 2010 11:36, Tor Lillqvist wrote: >> int g_thread_get_cores( void ); > > Well, firstly the function name should use "processors" and not > "cores". But I think that in general such a function would be too > simplistic, and just look at things from the perspective of the > current low end of the market. You're right, it is rather low-level, but it's at about the same level as glib's threadpool API, for example: GThreadPool*g_thread_pool_new (GFunc func, gpointer user_data, gint max_threads, gboolean exclusive, GError **error); The call I'm suggesting would give you the maximum useful value for the max_threads parameter: the maximum number of concurrent threads you can run before you stop seeing a speedup. How about: int g_thread_get_processors( void ); > multiprocessing etc. (Note, I am certainly not an expert here.) You > will almost certainly need some platform-dependent code, surely? Or > use other libraries that already do it for you? My library is just built on pthreads (or these days, g_thread()). At the moment it defaults to 1 if you run it at the command-line (if you are running on a server it's rude to take all resources unless given permission) and 4 if you run it from a GUI (a desktop user will typically want to give a large chunk of their machine to a program). The "4" isn't very good and I'd like to improve that. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gthread: how many cores do I have?
Hi everyone, I'd my program (a threaded image processing system based on gthread) to be able to find out how many cores the host machine has. This would let me make my threadpools default to a sensible size. As far as I know, this is a difficult thing to find out portably :-( Is this something that might be considered as an addition for gthread? I'm happy to try to make a patch if there's interest. int g_thread_get_cores( void ); or somesuch. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/2 : > Sorry, I posted hastily, I do get an annoying number of leaks if I let > it run a little longer, I see what you mean. I'm sure it wasn't as bad > back in 9.04. > > I'll try to make a better suppression file tomorrow. Here's another suppression file: http://www.vips.ecs.soton.ac.uk/development/nip2.supp With this, I now get no reported leaks or errors with a short run of my huge gtk program: ==3148== LEAK SUMMARY: ==3148==definitely lost: 120 bytes in 1 blocks ==3148==indirectly lost: 1,675 bytes in 46 blocks ==3148== possibly lost: 0 bytes in 0 blocks ==3148==still reachable: 893,032 bytes in 10,617 blocks ==3148== suppressed: 1,333,240 bytes in 21,362 blocks The 120 bytes is due to my XML pretty-printer and is deliberate. I get three reported possible leaks with the gtk "hello world" program, but I think they are due to the way the hello world program has been written: it quits in a button click callback, so there are various things left unfreed related to the button-up handling. No doubt I've made various errors, but maybe this will help someone. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/3 Erik de Castro Lopo : > Erik de Castro Lopo wrote: >> Don't you think that maybe a suppression file is not the right approach >> to this problem? > > Specifically, I am concerned about the possibility of a suppressions file > that hides a real memory leak where a program bug continually allocates > resources that are not released *and* are suppressed by the supressions > file. I think suppressing reports from allocs inside g_type_create_*() and friends must be safe, since they can (by definition) only happen once. Libraries which don't use GObject often have a similar pattern and you can usually guess if an alloc comes from init from the stack trace. I agree that it's a bit more dangerous. I think you're arguing for GObject to add type deletion. It does support types in plugins that can be unloaded: http://library.gnome.org/devel/gobject/unstable/GTypePlugin.html I suppose GObject could be adapted so that all (most?) types were implemented this way and could be deleted, but the effort would be quite large, binary compatibility might be damaged, and the benefits would be rather small. > PS: I am the author of two well known libraries that have zero valgrind > warnings and errors (not even memory leaks) without the use of a > suppressions file. I think they are hard to avoid if you have a large number of dependencies (the number of libraries a GTK application links to under GNOME is eye-watering). People only usually make the effort to clean up on shutdown if their library can be loaded more than once, or might be repeatedly loaded and unloaded. Few libraries are like this :( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/2 Erik de Castro Lopo : >> for my 300,000 line GTK application. > > Is that public? In revision control somewhere? It's the nip2 GUI for the vips image processing library: http://www.vips.ecs.soton.ac.uk Sources here: http://vips.svn.sourceforge.net/viewvc/vips/ John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/2 Erik de Castro Lopo : > With your suppressions file on the helloworld program from the GTK > tutorial and valgrind on Ubuntu 9.10 run as: Sorry, I posted hastily, I do get an annoying number of leaks if I let it run a little longer, I see what you mean. I'm sure it wasn't as bad back in 9.04. I'll try to make a better suppression file tomorrow. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Valgrind and GTK
2010/1/2 Erik de Castro Lopo :
> when run as follows (suppression file from http://live.gnome.org/Valgrind):
I use the following suppression file on Ubuntu 9.10:
{
ldopen1
Memcheck:Addr4
obj:/lib/ld-2.6.1.so
}
{
xwrite1
Memcheck:Param
write(buf)
obj:/lib/ld-2.6.1.so
fun:_X11TransWrite
}
{
xwrite2
Memcheck:Param
writev(vector[...])
obj:/lib/ld-2.6.1.so
obj:/usr/lib/libX11.so.6.2.0
fun:_X11TransWritev
}
{
type_init
Memcheck:Leak
fun:*alloc
...
fun:g_type_register_*
}
{
type_init2
Memcheck:Leak
fun:*alloc
...
fun:g_type_init_*
}
{
type_init3
Memcheck:Leak
fun:*alloc
...
fun:g_type_create_*
}
Then run with:
$ export G_SLICE=always-malloc
$ export G_DEBUG=gc-friendly
$ valgrind --leak-check=yes nip2 > valgrind.log 2>&1
And I get no reported leaks (well, one report from selinux and one
from a getpwd call somewhere) for my 300,000 line GTK application.
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
2009/12/2 Alexander Larsson : > On Wed, 2009-12-02 at 11:48 +, jcup...@gmail.com wrote: >> 2009/12/2 Alexander Larsson : >> > I'm certainly for this. Does anyone know of any system in use where >> > gthreads are not availible? >> >> One problem I've had in the past is writing mysql plugins. >> >> I help maintain an image processing library, and one use of the >> library was a mysql plugin that added query-by-image-content. To get >> the plugin working we had to make sure we could run threadless. > > By threadless, do you mean not linking to the thread library, or do you > mean "don't spawn threads". Because initializing threads doesn't mean > we'll create threads, just that we make global us data threadsafe. Sorry, I wasn't clear. You mustn't even link to pthreads when building mysql plugins. Or that used to be the case anyway. I tried a quick google but couldn't find anything saying whether or not this was still a problem, so this might all be a red herring anyway. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
2009/12/2 Alexander Larsson : > I'm certainly for this. Does anyone know of any system in use where > gthreads are not availible? One problem I've had in the past is writing mysql plugins. I help maintain an image processing library, and one use of the library was a mysql plugin that added query-by-image-content. To get the plugin working we had to make sure we could run threadless. I've not actually checked for years, perhaps mysql allows plugins to link to more stuff now. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
2009/8/31 Dr. Michael J. Chudobiak :
> On 08/30/2009 09:51 AM, jcup...@gmail.com wrote:
>> able to supply pixels at a certain size. In particular, libjpeg can do
>> a very quick load-at-1/8th-size read where it just decompresses enough
>> to be able to get the DC component of each 8x8 block. If you use
>> libjpeg like this you can expect around a 100x speedup of the
>> decompress step.
>
> The gdk-pixbuf jpeg loader does this already.
That's good, but I wonder if this feature is being used? I tried this
tiny program:
#!/usr/bin/python
import sys
from vipsCC import *
thumb = 0
for name in sys.argv[1:]:
# load at 1/8th size
im = VImage.VImage (name + ':8')
scale = 200.0 / im.Xsize()
# bilinear shrink to 200 px across
im = im.affine (scale, 0, 0, scale, 0, 0, 0, 0,
int (im.Xsize() * scale), int (im.Ysize() * scale))
# write as uncompressed bitmap
im.write ('thumb%d.v' % thumb)
thumb += 1
--
then in a directory with 1,000 1920x1200 180kb jpegs (after flushing the cache):
$ time ~/try/thumb.py *.jpg
real1m0.495s
user0m33.442s
sys 0m8.109s
This is on a tiny netbook with a 1.6 GHz Atom CPU, a desktop machine
should be a lot quicker, though it will vary a lot with the detaiuls
of the test I guess (Mark's gdk-pixbuf version took 2m 30s for 1,900
files).
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
2009/8/28 Mark : > static GdkPixbuf * > scale_pixbuf_preserve_aspect_ratio (GdkPixbuf *pixbuf, > gint size, > GdkInterpType interp) One more idea: this will be very slow for JPEGs (your use case, I think). It will decode the whole file, then shrink. libjpeg supports shrink-on-load where it only decompresses enough of the file to be able to supply pixels at a certain size. In particular, libjpeg can do a very quick load-at-1/8th-size read where it just decompresses enough to be able to get the DC component of each 8x8 block. If you use libjpeg like this you can expect around a 100x speedup of the decompress step. I have some code that does this lying around, I'll try to clean it up and post it next week so you can test it. Or maybe glib does this already? I know imagemagick uses this trick for it's thumbnailing (if it didn't it'd be far slower than glib, heh). John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Performance issue when trashing files (backtraced to fsync)
2009/8/11 : > 2009/8/11 Alexander Larsson : >> Clearly we should do at least 3, which will fix this case (and other >> similar tempfile cases). However, given the extremely bad performance >> here we should maybe add the extra API in 2 allowing apps to avoid the >> cost when needed? Its kinda ugly to expose that to users, but the >> performance cost is pretty ugly too... > > I'm probably being stupid here, but how about putting the fsync in a > timeout? Instead of calling fsync() directly, add a new thing called > g_fsync_queue() which queues up an fsync 'soon'. Oh ahem, I guess I'm thinking of sync() rather than fsync(). Though in this case one sync() at the end of the delete would certainly be faster than thousands of fsync()s. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Performance issue when trashing files (backtraced to fsync)
2009/8/11 Alexander Larsson : > Clearly we should do at least 3, which will fix this case (and other > similar tempfile cases). However, given the extremely bad performance > here we should maybe add the extra API in 2 allowing apps to avoid the > cost when needed? Its kinda ugly to expose that to users, but the > performance cost is pretty ugly too... I'm probably being stupid here, but how about putting the fsync in a timeout? Instead of calling fsync() directly, add a new thing called g_fsync_queue() which queues up an fsync 'soon'. Inside g_fsync_queue(), start (or reset) a 1s (perhaps) timeout before fsync() is called. Maybe plus some login to fsync at least every 5s to stop starvation. The danger with not writing metadata in ext3 is (as I remember the discussions) you have a potentially large window after a disc operation before the metadata reaches disc (I think it was up to two minutes, can't remember) and crashes in that danger window could lose data. fsync() in a timeout would bring the window back, but keep it rather small. Perhaps this is a good compromise? John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ speed
2008/12/22 Eugene Gorodinsky : > question. My first impression when I looked at the architecture (using > GObject etc.) was that this must take quite a bit of processing cycles and > memory. So my question is: is there any room for improvement by rethinking > the architecture (using Vala for some of the things maybe?) with gtk+ 3.0 in > the works this question bothers me a bit :) This has been discussed in the past. My memory is that if you take a typical app and profile it, you find that for typical tasks (eg. the framerate when resizing a window) less than 10% of the runtime is spent in GObject machinery. Of course that's just from memory :-( I've probably got it wrong. Anyway, the point being, before considering architectural changes you need to perform experiments, make measurements, and try to predict the gains you might be able to achieve. At the moment, as far as I know, there is not much evidence that GObject is a significant factor in GUI speed and responsiveness. ( John ___ 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.
2008/8/20 Ali Sabil <[EMAIL PROTECTED]>: > 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: >> > 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 ? It's quite easy to make an immutable refcounted string with GValue. This should be quite a bit lighter than a GObject implementation. Fwiw, my code is here: http://vips.svn.sourceforge.net/viewvc/vips/vips7/trunk/libsrc/iofuncs/meta.c?view=markup search for 'refstring'. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.org page width
On 30/01/2008, Michael L Torrie <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Sorry to revive this again, but does anyone have a link to the > > discussion of this? My google search is failing me. > > > > It seems strange to me that GTK goes to a lot of trouble to support > > accessibility (atk and friends), but then has a homepage which breaks > > W3C accessibility guidelines. Other than this issue I really like the > > redesign, congrats to all who worked on it. > > Would not a fixed-width design meet accessibility guidelines and work on > small, mobile screens if it used a fixed width based on ems instead of > pixels? Seems to me the time of using pixels for layouts is as obsolete Yes, that's one of the solutions the W3C guidelines suggest: http://www.w3.org/WAI/WCAG20/quickref/20071211/Overview.php#qr-visual-audio-contrast-visual-presentation John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.org page width
On 30/01/2008, Martyn Russell <[EMAIL PROTECTED]> wrote: > Paul Pogonyshev wrote: > > Sorry, I noticed the discussion about new gtk.org design but didn't > > follow it. The only thing I don't like in new design is fixed to > > 700px page width. I think that goes against GTK+ friendliness to > > different font size etc. :) I'd like to see sth. like 70ex or > > 40em whatever. > > This issue has been raised time and time again. > > It is a design decision and has been discussed in previous mailing > threads. So it won't be changing. Sorry to revive this again, but does anyone have a link to the discussion of this? My google search is failing me. It seems strange to me that GTK goes to a lot of trouble to support accessibility (atk and friends), but then has a homepage which breaks W3C accessibility guidelines. Other than this issue I really like the redesign, congrats to all who worked on it. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: weakref semantics
On Jan 17, 2008 12:34 PM, Tim Janik <[EMAIL PROTECTED]> wrote: > On Thu, 17 Jan 2008, Alexander Larsson wrote: > > On Wed, 2008-01-16 at 15:03 +, [EMAIL PROTECTED] wrote: > >> I noticed the weakref introduction says that notifies can be called many > >> times: > >> > >> http://library.gnome.org/devel/gobject/unstable/gobject-memory.html#gobject-memory-weakref > >> > >>... which is invoked when the object runs its dispose method. As such, > >>each weak ref can be invoked more than once upon object finalization > >>(since dispose can run more than once during object finalization). > >> > >> I'm not sure this is right: looking at the source for gobject it seems > >> that the notifies are a fire-once thing, and are removed upon firing. > >> > >> Should I open a docs bug on this? (or am I confused?) > > you mis the facts that new weak refs can be added at any point in time, > such as after dispose, in finalize or even during weakref notifies. > (that's actually the semantics of GObject's GData mechanism which > is used to implement weakrefs) Sorry Tim, I'm still confused. I understand that weakrefs can be added at any time (and may therefore be called after dispose has finished), but I don't think a single weak_ref() can ever fire more than once. In other words, if I call: g_object_weak_ref( obj, myfunction, somedata ); then myfunction(somedata, obj) is guaranteed to be called exactly once. Is that right? It seems to contradict the docs I quoted above. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
weakref semantics
I noticed the weakref introduction says that notifies can be called many times: http://library.gnome.org/devel/gobject/unstable/gobject-memory.html#gobject-memory-weakref ... which is invoked when the object runs its dispose method. As such, each weak ref can be invoked more than once upon object finalization (since dispose can run more than once during object finalization). I'm not sure this is right: looking at the source for gobject it seems that the notifies are a fire-once thing, and are removed upon firing. Should I open a docs bug on this? (or am I confused?) John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Draw on a GtkFixed Widget with Cario and place some widgets inside?
On Dec 19, 2007 6:36 PM, Wolfman <[EMAIL PROTECTED]> wrote: > i have few questions i have to write a new tool for my work its something > like a node based node editor so the nodes must be connect via splines and > as content the node must have a tree view for the properties. So my first > thought was to use GtkFixed get the drawable and draw something with cario > on it and then place some treeviews widgets inside so do guys think it is > possible? Have you looked at GooCanvas? http://sourceforge.net/projects/goocanvas It's a Cairo canvas widget. I believe you can embed GTK+ widgets inside it. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: color of gtk widget
On 8/6/07, Prasanna Kumar K <[EMAIL PROTECTED]> wrote: > At present I'm not very much clear about gtkrc (also don't want to use them) Are you sure? They are easy to use and will do want you want very quickly. http://developer.gnome.org/doc/API/2.0/gtk/gtk-Resource-Files.html Use gtk_rc_add_default_file() to read the styles from a file, or gtk_rc_parse_string() to read them directly from your sourcecode. > but I guess if we get the style of a widget and then modify its style > attributes and then assign the same style to the widget back then also the > widget color can be modified. Yes, but it is much more complicated this way. There's no reason to do this. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: color of gtk widget
On 8/4/07, Benjamin Berg <[EMAIL PROTECTED]> wrote: > If you already use a style, you can also use > > widget "*red_widget*" style "red_style" > > instead. And then you just need to set the name on the button and none > of its children. As the label will also be affected with the above line > (because of the trailing *). I didn't know you could have trailing stars, that's useful, thanks. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: color of gtk widget
On 8/3/07, Prasanna Kumar K <[EMAIL PROTECTED]> wrote:
> I have a GtkWidget "Button. I want the color of the button should be
> complete red.
You can do it with a gtkrc. For example, set this resource file:
--
style "red_style" = "default"
{
bg[NORMAL] = "#C1665A"
bg[PRELIGHT] = "#E0B6AF"
bg[ACTIVE] = "#C1665A"
bg[SELECTED] = "#C1665A"
bg[INSENSITIVE] = "#884631"
}
widget "*red_widget" style "red_style"
--
Now in your code do:
void
set_name( GtkWidget *widget, const char *name )
{
gtk_widget_set_name( widget, name );
if( GTK_IS_CONTAINER( widget ) )
gtk_container_foreach( GTK_CONTAINER( widget ),
(GtkCallback) set_name, (char *) name );
}
set_name( button, "red_widget" );
And the button (and any widgets inside the button) should turn red.
No doubt there's a better technique :-(
John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Graphing widgets for GTK+
On 6/29/07, Kieran Clancy <[EMAIL PROTECTED]> wrote: > I'll have a look at the gtkplot API, it may give a good structure for > starting this. This project will probably use cairo directly instead > of using a canvas widget. Your call, of course, but I would consider using a canvas widget. If you make a canvas object for a data series (ie. the single object would draw all 1000 points in a series) you can avoid having to build huge canvas object sets. Plus using the canvas framework will make interactivity easy (or easier), since it already has a nice framework for handling selections, dragging, optimising updates, and so on. Finally your users will thank you for not reinventing a lot of the canvas API and forcing them to learn it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Graphing widgets for GTK+
On 6/29/07, Kieran Clancy <[EMAIL PROTECTED]> wrote: > Any comments would be very appreciated. I realise this isn't quite what you're targetting, but gtkplot (from gtkextra) redone on top of one of the nice new cairo canvas widgets would be very useful. The gtkplot API is just about OK (I think it could so most of your use cases). The main problem is with the awful canvas widget it uses as a base. Just swapping that for goocanvas or similar would be a fantastic step forward. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkPlot...using different scales left/righ axis
On 6/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > My problem is that i'd like that axis right and left have diffrent escales,and > of couse different ticks.Is it possible?? Is this the gtkplot from gtkextra? The testgtkplot.c demo program in the sources does this, though for the top and bottom axies. You should be able to steal stuff from there. JOhn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: What's about the efficiency of using c to OOP compare to the c++'s abstraction?
On 5/4/07, la deng <[EMAIL PROTECTED]> wrote: > Then ,what's the power of gobject vs c++ with the compiler's > Intelligence in OOP? I think the usual answers are: 1) portability: you can get a standard C compiler anywhere; C++ (at least back when gtk was started) is less portable 2) ease of language binding: it is significantly more difficult to make a binding for a language like Perl from a C++ library than a C library (though SWIG is pretty fantastic now) 3) ease of ABI maintenance: with C it's (usually) easy to see what source code changes will break ABI compatibility; C++ makes this (in my experience) much harder 4) history and personal developer preference: gtk has always been C, most of the developers either like it that way or don't object enough to bother complaining, it's hard to see it ever changing 5) unimportance: C++ might bring some small speed improvements, or it might not (see Qt's linking problems, though they might have fixed that), but in any case, 10% speed improvements in a widget toolkit internals are almost invisible to the user .. probably some more I've missed. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
