How do you get the column number from a GtkTreeViewColumn pointer? Is
there a way to get the previous and/or next Column or column number?
Use gtk_tree_view_get_columns() to get a GList of all the column and check
the pointer of focus_column against the GList with g_list_index(), this will
These questions were just examples. Have you read gtk tutorials? Have
you looked at the gtk examples? Do you know how the glib object system
(gobject) works? Have you even started writing the code? I doubt it.
Don't ask the question unless you actually need the answers. When you
start writing
Eric Masson @ Savant Protection wrote:
Hi All,
I had a small problem that was bugging me for a while, and I figured I'd
share the results of my findings.
The problem was this:
You have several widgets inside of a container and you call
gtk_widget_set_sensitive with false to gray
Hi Nisha,
I think here is not problem of writing into file. This problem is
because of file permission. check the permission of the
respective file , does it has writing permission for the user as well? , if
not give the write permission.
as I know on maemo if your application creates a
On Tue, Jul 15, 2008 at 6:36 AM, Gabriele Greco [EMAIL PROTECTED]
wrote:
static void handle_click_cbk(GtkWidget *mywidget_, MyClass *data) {
data-handle_click(); }
You can't make a callback function intended to be used by C code be inside
of the C++ class. It will not be able to find it.
Hi,
On Tue, 2008-07-15 at 20:22 -0400, Morten Welinder wrote:
It really is the elaborate deprecation (as opposed to simply
dropping in a comment and not maintaining the code any more) that
is causing the burden. That's what the log say -- assuming gtkclist
is representative -- which I would
Hello,
I've read the PDF at
http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf
I am wondering what the options will be for users of the GTK lib, that
still use deprecated widgets?
In the project I work for, we do have a lot of them:
[claws-mail/src]$ grep -r GtkItemFactory *|wc -l
Am Mittwoch, den 16.07.2008, 09:16 +0200 schrieb Colin Leroy:
What do you plan on doing for users of your toolkit who don't have
time to rewrite things every four years?
One obvious option would be to stay with GTK2 forever, and to take over
bug fixing for it.
Another **rough** idea I always
On Wed, 2008-07-16 at 09:16 +0200, Colin Leroy wrote:
Hello,
I've read the PDF at
http://people.imendio.com/kris/gtk-state-of-the-union-2008.pdf
I am wondering what the options will be for users of the GTK lib, that
still use deprecated widgets?
In the project I work for, we do have a
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:
Hi,
IMO, if you're still using GtkCTree and GtkCList, which were
deprecated when GTK+ 2.0 was released 6 years ago, you're asking for
trouble.
Well, they do work for us. When GTK+ 2.0 was released six years ago, we
were already too
Colin Leroy skrev:
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:
Hi,
Hi,
IMO, if you're still using GtkCTree and GtkCList, which were
deprecated when GTK+ 2.0 was released 6 years ago, you're asking for
trouble.
Well, they do work for us. When GTK+ 2.0 was released six years
On Wed, 16 Jul 2008 12:18:24 +0200, Mikael Hallendal wrote:
Hi,
It sure would lessen the burden for applications still using
deprecated widgets (which is the hard part of the ABI break).
Well, the hardest part in my opinion, for free software at least, is the
API break :-)
There's something
2008/7/15 Alberto Ruiz [EMAIL PROTECTED]:
Oh, and spacing between widgets shouldn't be a fixed part of layout. It
should all be defined in themes. No more studying the HIG and manual
labour to get that right. 100% consistency and flexibility instead.
That works belongs to
Hello,
I'm writing a binding of Gtk+ for the smalltalk language. Most of the
widgets are supported that's pretty cool.
But I've a problem with :
gtk_main_iteration_do (1)
In fact I use this function in a thread and the squeak virtual
machine also use X events
for the morphs (an old
On Tue, 15 Jul 2008, Alessandro Vesely wrote:
This discussion reminds me that smc_notify_tree() does not actually check
which thread does a chunk belong to. Could that result in misbehavior?
No, chunks may be freely passed back and forth betwen threads without
problems. Except for a few
On Wed, 2008-07-16 at 11:20 +0200, Colin Leroy wrote:
On Wed, 16 Jul 2008 09:51:03 +0100, Bastien Nocera wrote:
Hi,
IMO, if you're still using GtkCTree and GtkCList, which were
deprecated when GTK+ 2.0 was released 6 years ago, you're asking for
trouble.
Well, they do work for us.
On Wed, 16 Jul 2008 09:25:43 -0400, Owen Taylor wrote:
Hi,
Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
(e.g., I remember doing that for gftp, not a trivial app.)
Probably not trivial, but 30k LOCs is much less than Claws ;)
Porting to GtkCList and GtkCTree was was
Hi,
On Wed, Jul 16, 2008 at 6:16 AM, Gwenael Casaccio [EMAIL PROTECTED] wrote:
In fact I use this function in a thread and the squeak virtual machine also
use X events
for the morphs (an old user interface). Here is the problem after some
events everything
is frozen the morphs and the gtk
On Mon, Jul 14, 2008 at 5:42 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
Hi all,
this is a summary of the issues discussed and the roadmap about a new
theming API for Gtk+ at GUADEC:
Current situation:
Misc:
* Engines are too dependent on widget implementation
Hmm, strangely most code worked fine with GTK+ 2.0 with a recompile...
(e.g., I remember doing that for gftp, not a trivial app.)
That sounds like a serious case of selective memory. Or maybe gftp
has the ui from hello, world.
Here's a partial list of suffering that we went through. Let's
Hi,
Am Mittwoch, den 16.07.2008, 18:08 -0400 schrieb Paul Davis:
On Wed, 2008-07-16 at 16:51 -0400, Morten Welinder wrote:
i totally agree with those who are arguing against the current notion of
what GTK3 should be. i haven't seen any evidence that any of the
problems that our developers
On Wed, Jul 16, 2008 at 4:51 PM, Morten Welinder [EMAIL PROTECTED] wrote:
[ lots of whining cut out]
You want us to go through some variant of that every 3-4 years? That's
insane!
GTK2 is not going away any time soon. Enterprise distributions will have
to keep it alive in maintenance mode
On Thu, 2008-07-17 at 04:11 +0200, Sven Herzberg wrote:
Paul, just in case this wasn't made clear enough already; the GTK+ team
want to deploy a GTK+3 that will be API-compatible to the latest GTK+2
including all deprecation flags that are there (disable deprecated,
multihead safe, single
On Wed, 2008-07-16 at 23:03 -0400, Paul Davis wrote:
if its API compatible, why a change in major version numbers?
As I understand it, because:
a) they're removing all the deprecated stuff, and
b) the API sill start changing after 3.0 in ways that won't be
compatible with 3.0
All good.
AfC
On Tue, 2008-07-15 at 06:19 -0500, Ryan Schmidt wrote:
I posed this question on July 3 and nobody responded. I also asked
the cairo list on July 6 and nobody answered there either. Can anyone
give me any guidance about how to deal with this issue?
If no one replied, chances are no one can
Hi all,
Is there a way to load a gtkimage from bytes string ? I tried with
GdkPixbufLoader but no luck.
Regards,
Fred.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
http://library.gnome.org/devel/gtk/stable/GtkImage.html
says:
The GtkImage widget displays an image. Various kinds of object
can be displayed as an image; most typically, you would load a GdkPixbuf
(pixel buffer) from a file, and then display that.
There's a convenience function to do this,
douwe vos a écrit :
http://library.gnome.org/devel/gtk/stable/GtkImage.html
says:
The GtkImage widget displays an image. Various kinds of object
can be displayed as an image; most typically, you would load a GdkPixbuf (pixel buffer) from a file, and then display that.
There's a convenience
2008/7/16, fred [EMAIL PROTECTED]:
douwe vos a écrit :
http://library.gnome.org/devel/gtk/stable/GtkImage.html
says:
The GtkImage widget displays an image. Various kinds of object can be
displayed as an image; most typically, you would load a GdkPixbuf (pixel
buffer) from a file,
if you mean an image that is contained (in some format) in memory that you
want to render to the screen, then you need to first convert this data to an
array of RGB values for each pixel, and then call:
gdk_draw_rgb_image()
with all the appropriate parameters. fill the array properly and get
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Diego Jacobi
Sent: Saturday, July 12, 2008 9:53 AM
I love GTK, it is easy a pritty, but is ony pritty under Linux, and easy
to program under linux.
Users of others platforms like windows found applications in made gtk
ugly. And as
I was reading some of the notes on GTK 3, I looked around for the G_SEAL
code (want to see how it works) and couldnt see to find it. Where is it
located? I assumming svn/trunk revision.
--
Jordan Walsh
___
gtk-list mailing list
gtk-list@gnome.org
If you have the images already in a directory under your gtk2.0 directory, try
the following code (using the pixmap engine). See border explanation below.
style button = default
{
xthickness = 3
ythickness = 3
engine pixmap
{
image
{
function= BOX
Is itposible to draw circle in Cairo and to place in the midle of it Button in
gtk+?
-- реклама ---
Домен БЕСПЛАТНО!
С хостинг-планом на http://www.hostpro.ua
___
gtk-list mailing list
El jue, 17-07-2008 a las 01:56 +0300, Иван Васильев escribió:
Is itposible to draw circle in Cairo and to place in the midle of it
Button in gtk+?
Yes, you can. Use an empty GtkButton and place a GtkDrawingArea inside
of it, then draw here.
Claudio
--
Claudio Saavedra [EMAIL PROTECTED]
On Wed, 2008-07-16 at 19:52 -0400, Claudio Saavedra wrote:
El jue, 17-07-2008 a las 01:56 +0300, Иван Васильев escribió:
Is itposible to draw circle in Cairo and to place in the midle of it
Button in gtk+?
Yes, you can. Use an empty GtkButton and place a GtkDrawingArea inside
of it,
Hi,
The general idea is to make a Dialog type widget, that returns
data instead of predefined button values, as a Dialog does it.
So I used a non-blocking delay ( shown to me by muppet :-) ),
to make a window stay open during a Show(). Without the delay,
the Show() would return right away.
In
Matthew Braid wrote:
Every so often it would stop working (ie, the helper process would
claim it sent a message, but the main process wouldn't act on it), and
after a lot of debugging it turned out that if an incoming message was
longer than 1024 characters the remaining part after the first
zentara wrote:
Hi,
The general idea is to make a Dialog type widget, that returns
data instead of predefined button values, as a Dialog does it.
So I used a non-blocking delay ( shown to me by muppet :-) ),
to make a window stay open during a Show().
Hey, don't blame that on me! ;-)
On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
muppet [EMAIL PROTECTED] wrote:
Okay, several comments:
- Why are you reinventing Gtk2::Dialog?
- Why are you reinventing Gtk2::ColorSelection?
- Why are you reinventing Gtk2::ColorSelectionDialog?
- Why are you using a canvas to get colored text?
For
Torsten Schoenfeld [EMAIL PROTECTED] writes:
- ret = POPi;
+ sv = POPs;
+ ret = sv_2bool (sv);
The pushed_in return in gtk2perl_menu_position_func() might be similar
too. Think it's a boolean rather than an integer.
--
If confronted by an angry leopard, John Davis, Keeper of
Hi,
2008/7/17 muppet [EMAIL PROTECTED]:
The trick in C code is to mark the file as non-blocking, and read chunks until
read returns 0 bytes. I can't take the time to experiment right now, but i'm
reasonably certain that this works in perl, as well.
Gah. I'm still thinking in Perl/Tk terms. I
Hi,
2008/7/17 zentara [EMAIL PROTECTED]:
On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
Well the idea is not just for color. I'm looking for a general purpose
popup that returns whatever I want, instead of integers(like a dialog).
I might want a textbox, or entries, etc.
Rather than making a whole
Matthew Braid [EMAIL PROTECTED] writes:
opened with IPC::Open2
I've been using Proc::SyncExec because it's got good exec error
reporting. Doesn't look like Open2/Open3 has that, you'd think they
probably should.
I was trying to figure out why the filehandle wasn't being picked up
as 'still
On Jul 16, 2008, at 4:01 PM, zentara wrote:
On Wed, 16 Jul 2008 14:43:53 -0400 (EDT)
muppet [EMAIL PROTECTED] wrote:
Okay, several comments:
- Why are you reinventing Gtk2::Dialog?
- Why are you reinventing Gtk2::ColorSelection?
- Why are you reinventing Gtk2::ColorSelectionDialog?
- Why
45 matches
Mail list logo
