Hello,
Yes, I realised the error of my ways at about 3AM this morning.
Woke up and thought Damn, why did I do that for?
After checking the GTK doc I realised that what I should have done is
this:
- DONT destroy anything.
- Dont ceate a new treeview.
- Create the liststore as usual.
- use:
Jason Brisbane wrote:
Hello All,
I am looking for a fix for a Treeview issue that I am having.
I have created a Treeview that gets its data from a database and
populates the list with the results of the database.
This works well as even if the database table was empty (rows=0) then it
On Tue, 2007-04-24 at 15:14 +0800, Jason Brisbane wrote:
Hello,
Yes, I realised the error of my ways at about 3AM this morning.
Woke up and thought Damn, why did I do that for?
After checking the GTK doc I realised that what I should have done is
this:
- DONT destroy anything.
- Dont
Hi
I'm wondering if a signal is emitted when a user
changes the font, tab width etc in a
GtkSourceView/GtkTextView object.
Any ideas?
Thanks
___
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
On Tue, Apr 24, 2007 at 10:02:19PM +0100, Adam Tertial wrote:
I'm wondering if a signal is emitted when a user
changes the font, tab width etc in a
GtkSourceView/GtkTextView object.
Any ideas?
GtkTextView does not provide any controls to change font,
tab positions, etc. Therefore the user
--- David Neèas (Yeti) [EMAIL PROTECTED] wrote:
On Tue, Apr 24, 2007 at 10:02:19PM +0100, Adam
Tertial wrote:
I'm wondering if a signal is emitted when a user
changes the font, tab width etc in a
GtkSourceView/GtkTextView object.
Any ideas?
GtkTextView does not provide any
On Tue, Apr 24, 2007 at 11:46:13PM +0100, Adam Tertial wrote:
How would I know when these properties change?
Because notify::property-name is emitted.
Yeti
--
http://gwyddion.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
Carl Worth cworth at cworth.org writes:
I'm quite convinced that using floating-point at the interface, and
fixed-point internally as needed provides the right combination of
performance and ease-of-use for cairo. I'd highly recommend any new
canvas interfaces being proposed follow the same
Hi Brandon,
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
My point is _not_ that these features are not useful, just
that glib would be a better library with a more strict focus and useful
to more developers if some of this functionality were moved to a
separate library.
Don't
On Tue, 2007-04-24 at 00:19 +0100, Damon Chaplin wrote:
thinking 'in these days of 64-bit machines' would basically screw up all
of the people working on getting GTK+ to work on small devices which -
surprise! - have no FPU, hence perform like shit with doubles and
floats. in Clutter,
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
The problem I had was in compiling glib on IRIX and its dependency
on gettext.
Thanks, finally. Details are good. I note that this is about building
from source, not at all about performance.
I can't imagine that anyone is seriously using
Federico Mena Quintero federico at ximian.com writes:
Now for the other use-case... in GNOME we don't have much experience
with loading SVG-like things and then manipulating them (think Flash).
Maybe we can find someone with Flash experience to comment on what API
would be helpful to them?
On Mon, 2007-04-23 at 21:15 +0100, Martyn Russell wrote:
Does anyone have a view on this?
the GNOME web team recently did a breakdown of CMS for the GNOME web
sites[1], and the choose Plone[2]. so I'd really like, for sake of
consistency and maintenance, that gtk.org used the same CMS.
ciao,
Dear maintainer,
GNOME 2.18 was released ~1 month ago, and we've all started to focus
on the next development cycle. A new roadmapping process has been
proposed[1] to know our short-term and long-term plans. The goal is to
compose a GNOME-wide roadmap for the next stable releases. And we need
Dear maintainer,
GNOME 2.18 was released ~1 month ago, and we've all started to focus
on the next development cycle. A new roadmapping process has been
proposed[1] to know our short-term and long-term plans. The goal is to
compose a GNOME-wide roadmap for the next stable releases. And we need
On Tue, 24 Apr 2007, Lucas Rocha wrote:
Dear maintainer,
GNOME 2.18 was released ~1 month ago, and we've all started to focus
on the next development cycle. A new roadmapping process has been
proposed[1] to know our short-term and long-term plans. The goal is to
compose a GNOME-wide roadmap
On Tue, 2007-04-24 at 08:12 +, Benjamin Otte wrote:
[...]
So what does that mean for a GtkCanvas?
The canvas should make it easy to load the full graphical description from a
file created by a graphic artist.
[...]
I strongly agree and strongly disagree (which might or might not mean
On Mon, 23 Apr 2007, Martyn Russell wrote:
Martyn Russell wrote:
Hi,
I recently commented on the mailing list [1] about improving the GTK+
web site so that .html files don't include formatting. The idea was to
make it easier for developers and anyone else contributing patches to
focus on
On Tue, 24 Apr 2007, Murray Cumming wrote:
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
The problem I had was in compiling glib on IRIX and its dependency
on gettext.
Thanks, finally. Details are good. I note that this is about building
from source, not at all about performance.
Brandon Casey wrote:
It's hard for me to think of unicode as
being low-level when it adds so much overhead to string handling.
Isn't (a part of) the unicode handling needed for correctly processing
paths under Windows? As I remember it, Windows-native calls take either
ASCII or a slightly
Hi,
Brandon Casey wrote:
It's hard for me to think of unicode as
being low-level when it adds so much overhead to string handling.
I think many just wouldn't agree - yes it adds overhead, but without
Unicode, string handling doesn't *work* - so saving the overhead is
pretty useless unless
On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote:
Hi Brandon,
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
My point is _not_ that these features are not useful, just
that glib would be a better library with a more strict focus and useful
to more developers if some of
On Tue, 24 Apr 2007, Behdad Esfahbod wrote:
On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote:
Hi Brandon,
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
My point is _not_ that these features are not useful, just
that glib would be a better library with a more strict focus and
On Tue, 2007-04-24 at 10:39 -0400, Tim Janik wrote:
with the current state of the gtk.org machine and limited available HD space,
i'd not dare to change the web system for www.gtk.org. the Gimp project has
cleared the necessary money for setting up a new machine, Manish Singh is
supposed to be
On Tue, 24 Apr 2007, Behdad Esfahbod wrote:
On Tue, 2007-04-24 at 10:39 -0400, Tim Janik wrote:
with the current state of the gtk.org machine and limited available HD space,
i'd not dare to change the web system for www.gtk.org. the Gimp project has
cleared the necessary money for setting up
Le mardi 24 avril 2007 à 12:51 -0500, Brandon Casey a écrit :
On Tue, 24 Apr 2007, Behdad Esfahbod wrote:
On Tue, 2007-04-24 at 03:26 -0400, Xavier Bestel wrote:
Hi Brandon,
On Mon, 2007-04-23 at 17:44 -0500, Brandon Casey wrote:
My point is _not_ that these features are not useful,
On 24.04.2007 18:31, Jake Goulding wrote:
Brandon Casey wrote:
It's hard for me to think of unicode as
being low-level when it adds so much overhead to string handling.
Isn't (a part of) the unicode handling needed for correctly processing
paths under Windows? As I remember it,
27 matches
Mail list logo
