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
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
Federico Mena Quintero 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?
>
Model-
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 Cl
Carl Worth 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 approa
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 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 num
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 Mon, 2007-04-23 at 09:20 -0400, Owen Taylor wrote:
> I want to point out here that while you can specify units in points or
> ems, or whatever, with a data type of fixed point numbers,
> or doubles, or whatever, you simply can't ignore the pixel grid and
> expect to get good looking results; i
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 the
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
El lun, 23-04-2007 a las 18:50 +0200, Carlos Garnacho escribió:
> On Sat, 2007-04-21 at 10:30 -0500, Federico Mena Quintero wrote:
> > canvas = new Canvas ();
> > svg = canvas.load_svg ("foo.svg");
> > handle = svg.get_object_by_id ("bouncing-ball");
> > handle.animate (new BounceAnimation
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 mat
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 f
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 usa
>
>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
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 (inst
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.:
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,
El dom, 22-04-2007 a las 22:26 +0100, Damon Chaplin escribió:
> So basically it is all kinds of data visualization and manipulation, and
> the occasional animation. Plus some WYSIWYG stuff to be printed.
For the record, I fully trust Damon to do the right thing for the
programmatic side of the ca
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
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
>
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
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 (instabil
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 l
On Sat, Apr 21, 2007 at 05:09:09PM -0400, Havoc Pennington wrote:
> Hi,
>
> Kalle Vahlman wrote:
> >> 6. I want to make slightly interactive diagrams with a clearly
> >> distinctive style from regular gtk widgets, namely i want to draw math
> >> plots for later export into articles. For t
Hi,
Kalle Vahlman wrote:
>> 6. I want to make slightly interactive diagrams with a clearly
>> distinctive style from regular gtk widgets, namely i want to draw math
>> plots for later export into articles. For this kind of content, users
>> don't want their selection of gtk theme to inter
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
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 bi
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 i
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 gene
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
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 can
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 adva
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 inte
> 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 t
Sven Herzberg 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 eve
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 alm
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.
>
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 doi
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 i
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 featur
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 replaceme
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.
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 globa
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 c
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 t
48 matches
Mail list logo
