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
24 matches
Mail list logo
