On Tue, 2007-07-31 at 13:09 +0300, Tor Lillqvist wrote:
Roberto writes:
I would know: does this old bug
http://bugzilla.gnome.org/show_bug.cgi?id=141721
has ever been fixed?
Doesn't look so.
GDK_INCLUDE_INFERIORS seems like still not working in windows, as you
can test with
On Sat, 2007-06-16 at 01:59 +0200, Tim Janik wrote:
On Sat, 16 Jun 2007, Damon Chaplin wrote:
On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote:
please read Kris' description again.
if you set ::tooltip-markup, ::has-tooltip is set automatically, and
you don't need to worry about
On Fri, 2007-06-15 at 11:25 +0200, Tim Janik wrote:
On Thu, 14 Jun 2007, Damon Chaplin wrote:
On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote:
2. When you need a tooltip with a little more fancy contents, like
adding an image, or you want the tooltip to have different
On Thu, 2007-06-14 at 11:55 -0300, Johan Dahlin wrote:
Damon Chaplin wrote:
On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote:
Anyway, my point here is not wrt code that exists already in Gtk+,
I am of the opinion that GContainer iface is missing, and that
objects in general
I think its quite important here to not repeat one of the
the most obvious mistakes of glade/libglade, swapping the
signal based on the fact that an object was specified
is confusing - it also rules out the use case of specifying
a signal that is not swapped has an object user_data.
Back
On Thu, 2007-06-14 at 12:42 +0300, [EMAIL PROTECTED] wrote:
So, I'm asking: Why not include something like set widget name option
into glade and xml-file, or separate property for the name to be set??
Those widgets that have this flag set will have gtk_widget_set_name called,
other do not
On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote:
Anyway, my point here is not wrt code that exists already in Gtk+,
I am of the opinion that GContainer iface is missing, and that
objects in general use other objects in general, and in that process
of ownership, packing properties
On Mon, 2007-04-30 at 12:52 -0400, Havoc Pennington wrote:
Something like:
- get a few reviews and comments on candidate codebases
- iterate codebases accordingly
- try to get a couple real-world apps to try them out
- iterate accordingly
- get review and feedback from gtk
On Wed, 2007-05-02 at 01:12 +0100, Rob Taylor wrote:
Michael Lawrence wrote:
I made some suggestions along those lines a while ago on the GtkDocFuture
page: http://live.gnome.org/DocumentationProject/GtkDocFuture. It's at the
bottom of the page.
I'm not sure I like the idea of the gtk-doc
Why do the *_type_register_static() functions use
g_intern_static_string() for the type name?
Should apps be using g_intern_static_string() as well? If so, the docs
should mention it.
There is some inconsistency as well. Some calls don't seem to use it:
GtkPaperSize GtkTextIter GtkRecentInfo
On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote:
On Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote:
In these days of 64-bit machines I don't think sizeof (double) is a big
deal, if its just for a few coordinates per item. Anyway if we're using
interfaces for items
On Thu, 2007-04-19 at 16:19 -0400, Havoc Pennington wrote:
Marco Pesenti Gritti wrote:
There is something which bothers me though. Support for some units,
points for example, would require floating points measures. And I
suspect we don't want to do layout in floating point (instability
On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
El jue, 19-04-2007 a las 15:00 -0400, Havoc Pennington escribió:
I'd step back first and do use-cases instead, and also talk about at a
high level what the canvas is for and when it would be used, i.e.:
Havoc is on the
Hi,
I've put GooCanvas 0.8 up on sourceforge:
http://sourceforge.net/project/showfiles.php?group_id=173653
GooCanvas is a cairo-based canvas widget for GTK+.
I want to freeze the API soon, so now is the time to discuss any
problems with it.
GooCanvas Features:
o Optional model/view
On Sun, 2007-03-18 at 01:22 +0100, Tim Janik wrote:
the main reason for ::has-tooltip is efficiency, because the new tooltips
potentially do many tip checks currently (ca. on every mouse motion, however
we might implement some coalescing to limit the number of tip checks to
16-25 per second),
Is there any real need for the has-tooltip property? From a quick look
at the API it doesn't seem that useful to me.
The developer either wants to set a simple tooltip with tooltip-markup
or connect to the signal-query signal to set context-sensitive
tooltips.
Have I missed something?
Damon
On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote:
However, the first method you describe:
~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt
sounds perfect. It's rich (we can get back the mount info later),
extensible (we don't have to figure out the entire set
On Fri, 2006-12-08 at 13:13 +0100, Tim Janik wrote:
On Fri, 1 Dec 2006, Damon Chaplin wrote:
On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
Hey all,
this is a proposal for allowing pluggable widget types and implementations,
assorted bug report: http://bugzilla.gnome.org
On Tue, 2006-11-28 at 14:53 +0100, Tim Janik wrote:
Hey all,
this is a proposal for allowing pluggable widget types and implementations,
assorted bug report: http://bugzilla.gnome.org/show_bug.cgi?id=356864
How about a sort of widget/object factory?
So you'd set the default implementation
On Tue, 2006-09-19 at 11:20 -0400, Havoc Pennington wrote:
Hi,
Damon Chaplin wrote:
So how are we going to decide on a list of requirements for a canvas?
I think there seem to be two main use cases:
A) DTP/Graphics apps that want a canvas for the main document.
(A model/view
So how are we going to decide on a list of requirements for a canvas?
I think there seem to be two main use cases:
A) DTP/Graphics apps that want a canvas for the main document.
(A model/view split, device-independent layout, zooming printing
are important here.)
B) Flashy user
On Thu, 2006-08-31 at 13:03 +0200, Marco Pesenti Gritti wrote:
Goocanvas has a view/model split at item level too. There is an
ItemModel and and ItemView, and the Item interface has a create_view
method. IHMO this introduce needless complexity, especially in the
event handling.
Mouse
On Wed, 2006-05-10 at 11:51 -0300, Johan Dahlin wrote:
We've made a couple of important decisions:
* GMarkup based parser which parses and creates the object tree in one step
go instead of saprving a whole tree in memory.
* breaking xml format compatibility with libglade
* not supporting
On Wed, 2006-04-26 at 11:16 +0200, Murray Cumming wrote:
On Tue, 2006-04-25 at 21:02 +0100, Damon Chaplin wrote:
I've put GooCanvas 0.3 (a GTK+ cairo canvas widget) up at:
http://www.dachaplin.dsl.pipex.com/goocanvas/
This release adds pretty much all of my list of essential features
Hi,
One of the main missing pieces of my GooCanvas widget is support for
embedded widgets (especially a GtkTextView).
I know Alex worked on offscreen rendering of widgets a while back. Is
there any code available for that?
To be honest, that sounds pretty difficult to me (especially trying to
I've put GooCanvas 0.3 (a GTK+ cairo canvas widget) up at:
http://www.dachaplin.dsl.pipex.com/goocanvas/
This release adds pretty much all of my list of essential features:
o New GooCanvasPath item (similar to SVG path element).
o Accessibility support.
o Keyboard focus navigation.
o API
On Tue, 2005-12-06 at 10:27 +0100, Alexander Larsson wrote:
On Mon, 2005-12-05 at 22:44 +, Damon Chaplin wrote:
I've put goocanvas 0.2 (my cairo canvas widget) up at:
http://www.dachaplin.dsl.pipex.com/goocanvas/
New features:
o affine transformations for all items.
o event
I've put goocanvas 0.2 (my cairo canvas widget) up at:
http://www.dachaplin.dsl.pipex.com/goocanvas/
New features:
o affine transformations for all items.
o event handling, including support for pointer grabs.
o support for simple animation.
o finished port of FooCanvas demo, and added
On Fri, 2005-11-18 at 14:28 +0100, Alexander Larsson wrote:
Why don't you split the group only methods from GooCanvasItemIface into,
say GooCavnasCompositeItemIface. Right now you can call
goo_canvas_item_add_child() on any item, but it will crash since
iface-add_child is NULL.
I could split
On Thu, 2005-11-17 at 12:47 +0100, Jean Bréfort wrote:
Hi,
It seems that things do not advance a lot by now. AFAIK, no much work
have been done except Alexander Larsson's patch available at:
http://bugzilla.gnome.org/show_bug.cgi?id=318807
I've almost got a canvas widget working. It's
On Fri, 2005-10-07 at 23:22 -0400, Owen Taylor wrote:
Some fodder for discussion this weekend:
1. Is there a cross-platform printing user interface?
Actually, what we are interested in is not the printing
user interface per-se, but the points of interaction between
the
On Wed, 2005-09-21 at 11:18 -0400, Dan Winship wrote:
So, what if we made it so that the extra annotations needed to generate
correct gobject-introspection metadata go into the gtk-doc comments
(thus encouraging people to write API docs, because it's essentially
necessary to get working
On Tue, 2005-09-20 at 20:26 +0200, Guillaume Cottenceau wrote:
Hi,
I'm currently scanning the nice Index of new symbols in 2.8
documents, and while they are immensely useful, I have noticed that
they don't list new properties and new signals. For example,
GdkEventGrabBroken is a new symbol
On Sat, 2005-09-17 at 11:34 +0100, Damon Chaplin wrote:
I've had a look at all the composite children that Glade uses for GTK+
widgets. I think all of these could have been avoided if the widgets had
been written slightly differently:
GladeChildOKButton;
GladeChildCancelButton
I've had a look at all the composite children that Glade uses for GTK+
widgets. I think all of these could have been avoided if the widgets had
been written slightly differently:
GladeChildOKButton;
GladeChildCancelButton;
GladeChildApplyButton;
GladeChildHelpButton;
On Thu, 2005-09-15 at 15:46 -0400, Tristan Van Berkom wrote:
as specially noted that there are in effect three types of child
widgets; normal, added as a result of a property value; added
as a composite child which is constantly present.
I think that if we're going to talk of ideal
On Fri, 2005-09-16 at 12:14 +0100, Gustavo J. A. M. Carneiro wrote:
On Fri, 2005-09-16 at 11:02 +0100, Damon Chaplin wrote:
avoid composite
children unless absolutely necessary (and even then only use simple
ones).
I don't agree it's fair to limit developers' options on code reuse
On Wed, 2005-09-14 at 23:27 -0400, Tristan Van Berkom wrote:
On a more practicle note; I was thinking that internal children of
composite widgets should be more introspectable; for the purpose
of GUI builders and loaders, if every child widget implicitly created
by its parent at least had a
On Thu, 2005-06-16 at 10:00 +0200, Mathieu Lacage wrote:
I understand that this might not be high on the todo list of the gtk+
developers but I would appreciate an answer to that email.
Most of the initial glib 1.x documentation was written by me, plus
Sebastian Wilhelmi wrote the Threads
On Wed, 2005-02-09 at 12:23, Christian Neumair wrote:
Problems - in short - with the current tooltip system:
- Not flexible enough (only plain text can be set)
- Unable to set popup location
- Exposes too many internals (GtkTooltipsData, tip_text, tip_private)
without getters/setters
40 matches
Mail list logo
