Yet another canvas library
On Tue, 2006-02-28 at 18:10 +, Gustavo J. A. M. Carneiro wrote: > My proposal would be rather different. Have a single CanvasItem > object, which would emit a "draw" signal with a cairo_context_t as > argument. I too needed a canvas, so I put one together late last year. If anyone's interested I have YACL (Yet Another Canvas Library; these things are breeding like rabbits) at http://libpapyrus.sourceforge.net/ Actually, I think the fact that numerous canvas projects are popping up speaks to the need for a powerful Gtk+ canvas. I took that exact approach with a virtual draw method that takes a cairo context as a parameter (actually, since I moved it to cairomm it takes a Cairo::RefPtr ) simply because I wanted to be able to extend the drawing shapes as I needed. It has resulted in putting some basic shapes into the library like GnomeCanvas has, but the focus was on the ability to inherit from Papyrus::Drawable (or further down the hierarchy like Papyrus::Shape) and extend the draw() or draw_shape() methods. One of the ways that I handled the hit detection was through a virtual method called pick(x,y). The default implementation was to check the bounding box, but where important I left it open for the derived classes to use more appropriate methods; say Preparata's trapezoid method for point-location in polygons and such. I also took the approach of separating the canvas library itself from the Gtkmm widgets; the canvas itself only depends upon cairomm. Anyway, if anyone has any feedback or comments I'd welcome the input. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [cairo] Hit detect surface?
On 2/28/06, Bill Spitzak <[EMAIL PROTECTED]> wrote: > This can be used to see if some arbitrary Cairo code draws anything (or > anything non-transparent) in a parallelogram-shaped region. To do > accurate hit detection the caller should loop, using smaller areas each > time, until only one object is hit or a minimum size is reached. This sounds impossible to implement with any surface but the image backend -- cairo has no knowledge of what pixels actually get touched by underlying platform methods. What are the use cases for this? - Vlad ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[cairo] Hit detect surface?
This talk about GnomeCanvas needing complicated hit detection made me wonder if Cairo could support hit detection. This could be done with an entire new surface type and thus not affect any existing cairo backends. As I see it it would work something like this: 1. Program creates or reuses the hit-detect surface. This acts like an image surface of exactly one pixel. Program uses a surface-specific function to set a callback pointer. 2. Program adds a transformation so that the region of interest is transformed to the square 0,0..1,1. 3. Program uses any Cairo calls it wants to draw into this surface. 4. All attempts to modify the one pixel do the callback function, giving it the source color, the mask, and the op used, and possibly other information. This can be used to see if some arbitrary Cairo code draws anything (or anything non-transparent) in a parallelogram-shaped region. To do accurate hit detection the caller should loop, using smaller areas each time, until only one object is hit or a minimum size is reached. I'm not sure when exactly it should do the callback function. I think it should not call it if the pixel is clipped, or is outside the path, or the mask is zero. It should call it if the source color is zero, so that clicking on transparent parts of images works. It should also call it (with zero alpha) for any clear pixels inside the bounding boxes of glyphs, allowing the program to click on lines of text or letters themselves. However it could do the callback on *every* call, provided enough information is provided so the callback can ignore things that are outside the region of interest. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pango-1.11.99 "Just In Case" released [unstable]
On Mon, 2006-02-27 at 20:47 -0500, Behdad Esfahbod wrote: > We really need a tinder box that runs benchmarks too. It's too > frustrating to not touch my laptop for 10 minutes to run a > benchmark, and then repeat it 5 times to average, and then figure > out it was a debugging build, loop again. And then see > regressions, figure out fontconfig from CVS is to blame, > uninstall, repeat, ... We'll get a machine for tinderboxing very very soon :) Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Ter, 2006-02-28 at 12:42 -0500, Havoc Pennington wrote: > On Tue, 2006-02-28 at 16:33 +, Gustavo J. A. M. Carneiro wrote: > > > > That sounds complicated to get right in one go. Personally, I'd just > > be happy to have a canvas that lets you create items, with virtualized > > draw method, even at position/size statically controlled by the > > programmer, stacking/layering and events. Basically like GnomeCanvas. > > If we get that right, and optimise the redrawing properly using micro > > tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right > > away. It seems to me like everything else is either not so important > > that can't wait a bit more (like embedding widgets) or can be done on > > top of the existing framework (animations, layout, object graph file > > persistency). > > > > Maybe so. I feel like we kind of stopped using GnomeCanvas though, > because it just wasn't that much more useful than a drawing area, and > had its own kind of complexity and limitations ... retained mode in > particular adds the problem of keeping the retained graphics state in > sync with the state of the app, while with non-retained mode when the > app state changes you just queue_draw() and that's it. I think this is why GnomeCanvas failed too, but the precise reason seems to ellude everyone. You seem to think in terms of reimplementing the GnomeCanvas model of having many "Canvas Items", one for each shape--circle, polygon, text, etc. -- and let canvas item composition be used to accomplish more complex shapes. Of course this model is tedious, you have to keep adding and removing canvas items in order to modify how objects look. My proposal would be rather different. Have a single CanvasItem object, which would emit a "draw" signal with a cairo_context_t as argument. Also define a queue_draw method, like in gtk+ widgets. Then let programmers simply connect a handler to that signal--or even override the class virtual--and draw _whatever they want_ based on application document model. This has several advantages: 1- The programmer can direclty map document objects to canvas objects; 2- The programmer can use the full cairo API, instead of being restricted by the available shapes; 3- No need to keep adding/removing items to change appearance of objects; 4- It is rather intuitive for people used to program gtk widgets or with GtkDrawingArea. > > The two exciting features of GnomeCanvas really were antialiasing and > lack of flicker, and a drawing area has both of those now. The only > other thing the canvas really does for you is event handling on objects, > but GnomeCanvas wasn't that convenient for that because the hard part > really is coding the grab handling and such (behaviors). True. I think behaviours are important but, if I had to choose to leave behaviours out in order to have a basic canvas in gtk+ 2.10, I wouldn't hesitate. Keep in mind that having interactable objects in a canvas is just one part of what the canvas can do. For me, the canvas is more important because it allows you to have complex graphics in gtk+ that are both fast (no need to redraw everything all the time) and don't necessarily take lots of X server memory (no need to draw everything once to an offscreen pixmap in order to avoid redrawing complex graphics while something is being dragged over your widget). And of course that you can selectively redraw an object inside the canvas, instead of calling queue_draw and then forcing all the objects to redraw themselves. > > Also, I'm not sure all the cool features can be done on top, at least > not while keeping a nice simple API. Or put differently, maybe the API > can be better if it's a bit higher level than "put a line here and a > circle there" - think about making the XML format the primary usage > pattern, with subsequent manipulation from code, sort of like a web > page. Hhm.. cool, but not nearly as useful as having a way to draw complex graphics in gtk+ and be able to print them without losing vectorial quality. > > It's not like all my wishlist items are star trek hard - behaviors and > animations in particular seem pretty manageable, and for widget > embedding Alex already sorted out the hard bits. > > Just trying to cheerlead some ambitious goals ;-) All those features are nice, but I'm afraid that we might end up not getting anything into gtk+ 2.10 if we aim for too much, and I'd really really love to have a canvas in gtk+. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkTextBuffer crashes from data overload??
I have a program which writes text into the GtkTextBuffer for an open GtkTextView window, which shows the updates live. After several thousand lines and perhaps a megabyte of text, it crashes with a segmentation fault. Have I run into some limitation on the total number of lines or total amount of text? Can I overcome this if I delete lines from the top as I add them at the bottom, or would the limitation still apply? Is there a way to increase the limits? thanks mikecorn -- View this message in context: http://www.nabble.com/GtkTextBuffer-crashes-from-data-overload--t1200455.html#a3167967 Sent from the Gtk+ - Dev - General forum at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Tue, 2006-02-28 at 16:33 +, Gustavo J. A. M. Carneiro wrote: > > That sounds complicated to get right in one go. Personally, I'd just > be happy to have a canvas that lets you create items, with virtualized > draw method, even at position/size statically controlled by the > programmer, stacking/layering and events. Basically like GnomeCanvas. > If we get that right, and optimise the redrawing properly using micro > tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right > away. It seems to me like everything else is either not so important > that can't wait a bit more (like embedding widgets) or can be done on > top of the existing framework (animations, layout, object graph file > persistency). > Maybe so. I feel like we kind of stopped using GnomeCanvas though, because it just wasn't that much more useful than a drawing area, and had its own kind of complexity and limitations ... retained mode in particular adds the problem of keeping the retained graphics state in sync with the state of the app, while with non-retained mode when the app state changes you just queue_draw() and that's it. The two exciting features of GnomeCanvas really were antialiasing and lack of flicker, and a drawing area has both of those now. The only other thing the canvas really does for you is event handling on objects, but GnomeCanvas wasn't that convenient for that because the hard part really is coding the grab handling and such (behaviors). Also, I'm not sure all the cool features can be done on top, at least not while keeping a nice simple API. Or put differently, maybe the API can be better if it's a bit higher level than "put a line here and a circle there" - think about making the XML format the primary usage pattern, with subsequent manipulation from code, sort of like a web page. It's not like all my wishlist items are star trek hard - behaviors and animations in particular seem pretty manageable, and for widget embedding Alex already sorted out the hard bits. Just trying to cheerlead some ambitious goals ;-) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
no GTK+ team irc meeting this week
...I will only have spotty presence this week, and at unusual hours, so if a meeting takes place this afternoon, you will have to do without me... Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK-Canvas
On Ter, 2006-02-28 at 00:09 -0500, Havoc Pennington wrote: > Hi, > > On Tue, 2006-02-28 at 01:41 +0100, Sven Herzberg wrote: > > If you have questions, bug reports, recommendations, feel free to send > > them either per email (I read the lists I sent this email to) or take > > the newly created Wiki Page [1] and edit it. > > It looks slick and nicely done (congrats!) as a Cairo version of > GnomeCanvas, but I think you could do so much more - you probably saw my > earlier mail: > http://mail.gnome.org/archives/gtk-devel-list/2005-August/msg00067.html > > To summarize my wishlist: > - animations > - behaviors > - mixing in widgets (including layering and events) > - multiple views (you have this one already) > - path item (you have a shape item, but it's "abstract" >it looks like, not concrete) > - data/markup form of the object graph, with an >artist-usable editor > - layout management That sounds complicated to get right in one go. Personally, I'd just be happy to have a canvas that lets you create items, with virtualized draw method, even at position/size statically controlled by the programmer, stacking/layering and events. Basically like GnomeCanvas. If we get that right, and optimise the redrawing properly using micro tile arrays like in GnomeCanvas, then we can put that in gtk+ 2.10 right away. It seems to me like everything else is either not so important that can't wait a bit more (like embedding widgets) or can be done on top of the existing framework (animations, layout, object graph file persistency). > > One minor thing I noticed while looking at the code, > I'd make the objects more opaque, you have lots of data fields > and private-looking functions in the public headers. > > Havoc > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
need help
Hi all, I am a totaly newbies in GTK+ world. I just started learning GTK+.. I am trying building an file analysis tool(like File Browser not so many feature). I thought my application should have three panel. Left panel for tree view(directory with parent child relationship) right panel for viewing the file with concerned directory with file description(size,date,etc..) Lower right panel is for viewing graphics file My application should have menu also(open ,save,..). Now problem is that can anybody give me some code(example of that type) where i can understand and can do from scratch. I tried to look file Browser in GTK+(But it is so big that i could not able to understand the code ) Or can anybody suggest me where to look, how i can do. I started GLADE with "ANJUTA" IDE.but if anybody has suggestion please tell me how i will processed.. Thanks a lot -- Thanks & Regards Suman Adak ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About symbols in gtkfilesystem.h
On Tue, 2006-02-28 at 13:45 +0200, Tommi Komulainen wrote:
> On Mon, 2006-02-27 at 13:33 +0800, ext James Henstridge wrote:
> > >GtkFileSystem *_gtk_file_system_create (const char *file_system_name);
> > >
> > >is not exported. So I cannot really load such a filesystem object in my
> > >program.
> > >
> > > My question is that is it possible to export _gtk_file_system_create
> > >as semi-private symbol in gtk library??? Or is that any plan to make
> > >this head file more public?
> > >
> > >
> > Those symbols are not exported because no commitment has been made to
> > keep them stable. So if they were exported and you used them, your app
> > could break between versions 2.8.5 and 2.8.6, for instance.
>
> Isn't it enough to have the whole header file guarded with the
> GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED ifdef? Why should
> _gtk_file_system_create() be even more private?
The stuff that is protected with ENABLE_UNSUPPORTED is meant for
people implementing file systems ... which is the point of exporting
that header file semi-publically. _gtk_file_system_create() isn't
needed for that, so it's fully private.
> (In maemo we're exporting that symbol as hildon_gtk_file_system_create()
> since we need it in hildon-fm...)
>
> There are other symbols intended for derived widgets to use, protected
> methods you could say, but as they're not exported you're confined to
> gtk only.
In the early days of GTK+ we were very relaxed about what we exported -
you could take just about any bit of GTK+ code inside GTK+ and compile
it outside of GTK+. That was great for writing add-on widgets, but a
horror for trying to maintain compatibility. "Protected" is
a bit of a crock, since protected interfaces are interfaces too and
need the same stability guarantees and careful design as public
interfaces.
Nowdays we tend to make things private by default and export them
only as we have use cases and requests to do so. Often publicly
exporting a private interface requires re-evaluating it and
cleaning it up in significant ways.
There are a couple of concerns in particular about promoting
GtkFileSystem to a publically exported interface.
- We know that the problem domain of "virtual file systems" is big
and hard. GtkFileSystem is kept manageable by defining it as
*exactly* what the file chooser needs. If GtkFileSystem were
public, then it would be very hard to know on what grounds to accept
or reject RFE's until it became a gnome-vfs clone. And GtkFileSystem
isn't not designed how I'd design a VFS for general consumption.
- We still (two years later) aren't quite satisfied with how
GtkFileSystem ... see Kris's outstanding changes.
> Interestingly enough I just noticed none of the private _gtk_* symbols
> have 'visibility("hidden")' attribute. Is libtool really doing to right
> thing here, or should the private symbols be hidden properly?
Look a bit closer and you'll find extreme complexity. (We used to rely
on libtool doing the right thing, and with some coaxing, patches
submitted upstream, and so forth, it did, but there's a lot more going
on these days.)
Owen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About symbols in gtkfilesystem.h
On Mon, 2006-02-27 at 13:33 +0800, ext James Henstridge wrote:
> >GtkFileSystem *_gtk_file_system_create (const char *file_system_name);
> >
> >is not exported. So I cannot really load such a filesystem object in my
> >program.
> >
> > My question is that is it possible to export _gtk_file_system_create
> >as semi-private symbol in gtk library??? Or is that any plan to make
> >this head file more public?
> >
> >
> Those symbols are not exported because no commitment has been made to
> keep them stable. So if they were exported and you used them, your app
> could break between versions 2.8.5 and 2.8.6, for instance.
Isn't it enough to have the whole header file guarded with the
GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED ifdef? Why should
_gtk_file_system_create() be even more private?
(In maemo we're exporting that symbol as hildon_gtk_file_system_create()
since we need it in hildon-fm...)
There are other symbols intended for derived widgets to use, protected
methods you could say, but as they're not exported you're confined to
gtk only.
Interestingly enough I just noticed none of the private _gtk_* symbols
have 'visibility("hidden")' attribute. Is libtool really doing to right
thing here, or should the private symbols be hidden properly?
--
Tommi Komulainen<[EMAIL PROTECTED]>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
