Carlos Garnacho wrote:
Hello!,
On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg 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
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
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,
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 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 Sun, 2007-04-22 at 21:16 +0100, Damon Chaplin wrote:
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
On Sat, 2007-04-21 at 22:12 +0300, Kalle Vahlman wrote:
2007/4/21, Gustavo J. A. M. Carneiro [EMAIL PROTECTED]:
I can tell you the reasons why I usually use a canvas:
1. Writing widgets is _very hard_ (when compared to e.g. canvas
items).
Depends on your language (and on
Hi Havoc!,
On Fri, 2007-04-20 at 10:13 -0400, Havoc Pennington wrote:
In HippoCanvas we took this to the extreme of not including gdk.h or
gtk.h in the canvas core. I happen to really like this approach, but
in
general I tend to like to keep code almost annoyingly
layered/orthogonal, just
Hi Federico :),
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.:
Hello!,
On Fri, 2007-04-20 at 17:11 +0200, Sven Herzberg 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
e.g. the SVG spec says high quality viewers should use doubles for
calculations:
http://www.w3.org/TR/SVG11/types.html#BasicDataTypes
The problem with double is not the size it is the speed of them. Right
now there are people like (me) who are trying to use GTK on cell phones.
Working with
Hi,
Federico Mena Quintero wrote:
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?
For most Flash usage,
Hi,
Carlos Garnacho wrote:
What are we missing in the current core? What benefits would bring a new
one?
I certainly have not sat down and exhaustively tried to figure this out.
There is a fair bit of cruft in the core; if you were starting over, I'm
sure you'd want to just kill GdkWindow
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 then the items can use whatever they like
internally.
it's not a matter
El lun, 23-04-2007 a las 13:44 -0400, Havoc Pennington escribió:
For most Flash usage, API really is not the issue... people do it like
HTML, where they write the markup then add a little bit of scripting
(for Flash, it isn't literally markup, but what I mean is 'data not
code'). Unlike
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 then the
On Mon, 2007-04-23 at 19:19 -0400, Damon Chaplin wrote:
But the cairo API already uses doubles, for coordinates and
transformations. So if the canvas used fixed point numbers you'd be
converting to doubles and then back again. With 32-bit fixed point
numbers you also cut down the maximum
On Tue, 24 Apr 2007 00:19:08 +0100, Damon Chaplin wrote:
On Mon, 2007-04-23 at 20:09 +0100, Emmanuele Bassi wrote:
floats. in Clutter, for instance, most of the operations are done using
fixed point algebra and transforming doubles in the public API into
16.16 or 21.11 fixed point numbers
Hi!,
On Mon, 2007-04-23 at 14:03 -0400, Havoc Pennington wrote:
I certainly have not sat down and exhaustively tried to figure this out.
Oh, nice list below, I was somehow thinking a shorter in scope, less
tangential, set of changes.
There is a fair bit of cruft in the core; if you were
On Sáb, 2007-04-21 at 17:09 -0400, Havoc Pennington wrote:
[...]
So another structure could be that there's a core which tries to
encapsulate the minimum amount of structure for multiple objects to
negotiate their usage of the screen area and keyboard, and then there
are objects that layer
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
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 right track here. You can pile an immense feature list
on top of the
Hmm: Once again I too fast on pressing send and forgot the links:
Vala: http://live.gnome.org/Vala
EggDocument: http://taschenorakel.de/svn/repos/eggdocument/trunk/
Am Samstag, den 21.04.2007, 17:49 +0200 schrieb Mathias Hasselmann:
Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena
Am Samstag, den 21.04.2007, 10:30 -0500 schrieb Federico Mena Quintero:
[Side note... at this point I think doing a canvas in C is a big
mistake. Interesting canvases will inevitably get cycles in the pointer
graph, and reference counting becomes just too painful then. [This is
irrelevant to
Federico Mena Quintero wrote:
[snip]
[Side note... at this point I think doing a canvas in C is a big
mistake. Interesting canvases will inevitably get cycles in the pointer
graph, and reference counting becomes just too painful then. [This is
irrelevant to .net or whatever; it's a general
On Qui, 2007-04-19 at 15:00 -0400, Havoc Pennington wrote:
Hi,
Carlos Garnacho wrote:
First of all we need to specify the feature requirements for the
canvas.
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
2007/4/21, Gustavo J. A. M. Carneiro [EMAIL PROTECTED]:
I can tell you the reasons why I usually use a canvas:
1. Writing widgets is _very hard_ (when compared to e.g. canvas
items).
Depends on your language (and on your widget of course). In python,
deriving a widget not a big
Am Samstag, den 21.04.2007, 11:57 -0500 schrieb Yevgen Muntyan:
Federico Mena Quintero wrote:
[snip]
[Side note... at this point I think doing a canvas in C is a big
mistake. Interesting canvases will inevitably get cycles in the pointer
graph, and reference counting becomes just too
Cody Russell wrote:
I'd like the canvas system to be generalized enough that we can have
multiple implementations of it, in the same way that GDK allows us to
port to Win32 or MacOSX. In particular, I think we could have an
implementation that is much like what most of the canvases are doing
Carlos Garnacho wrote:
First of all we need to specify the feature requirements for the
canvas. The following is a list of features I think we should
consider, hope it's a good start, please add to it if there are others:
- GTK+ suitable API.
- a11y support.
- Model/View split.
- Size
Sven Herzberg wrote:
I don't think the GtkWidget API and the GtkCanvas API shouldn't be tied
together too much.
In HippoCanvas we took this to the extreme of not including gdk.h or
gtk.h in the canvas core. I happen to really like this approach, but in
general I tend to like to keep code
Sven Herzberg herzi at gnome-de.org writes:
Sounds pretty good until this point. Benjamin just mentioned in IRC that
*theming* is also pretty important. We want to be able to render the
same canvas item in different ways for different themes.
Let me elaborate on this a bit. I think right now
So does Gtk want to reduce themeing and just have a simple file that specifies
colors (like Metacity) or does it want to increase its features to allow stuff
such as allowing theme engines to do animations, fades and what do I know?
If we care about looking native on Win32 and OSX, I'd say
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
issues). Mozilla converts css units in twips (an arbitrary integer
On Fri, 2007-04-20 at 12:02 +0200, Sven Herzberg wrote:
Well, isn't the right way to go the cairo path and make the
communication of cairo and the GPU faster (that's improve Xrender,
the
drivers etc.)? As this needs to be improved for a GPU based GTK
anyway you won't get any advantage by
Hi all!,
After reading Tim's mail about volunteer tasks [1], I've bitten the
bullet and will try to help out fostering the GtkCanvas discussion, so
here it goes!
There have been several discussions about getting a canvas into GTK+,
being the last one in the GTK+ meeting at Fosdem [2], where one
On 4/19/07, Carlos Garnacho [EMAIL PROTECTED] wrote:
Hi all!,
After reading Tim's mail about volunteer tasks [1], I've bitten the
bullet and will try to help out fostering the GtkCanvas discussion, so
here it goes!
There have been several discussions about getting a canvas into GTK+,
being
Hi,
Carlos Garnacho wrote:
First of all we need to specify the feature requirements for the
canvas.
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.:
- when is a canvas item used vs. a widget? what
Marco Pesenti Gritti wrote:
* Key navigation (which is obviously also a prerequisite for a11y)
I'd add to this bullet anything GtkWidget has that HippoCanvasItem does
not - basically HippoCanvas is the GtkWidget/GtkContainer replacement
school of canvas thought.
* Ability to set a global
On 4/19/07, Havoc Pennington [EMAIL PROTECTED] wrote:
Hi,
Carlos Garnacho wrote:
First of all we need to specify the feature requirements for the
canvas.
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.:
On 4/19/07, Havoc Pennington [EMAIL PROTECTED] wrote:
Marco Pesenti Gritti wrote:
* Key navigation (which is obviously also a prerequisite for a11y)
I'd add to this bullet anything GtkWidget has that HippoCanvasItem does
not - basically HippoCanvas is the GtkWidget/GtkContainer replacement
On Thu, 2007-04-19 at 18:51 +0200, Carlos Garnacho wrote:
There have been several discussions about getting a canvas into GTK+,
being the last one in the GTK+ meeting at Fosdem [2], where one of the
conclusions was that we needed to gather the candidates on one side
and
the desired feature
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
issues). Mozilla converts css units in twips (an arbitrary
44 matches
Mail list logo
