Re: GtkCanvas requirements?
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 starting over, I'm > sure you'd want to just kill GdkWindow for example, and many other "Xlib > leakages" such as how some of the events work. You'd want to be > Cairo-only, use interfaces instead of objects for the core APIs (widget, > container), rethink GtkContainer and its common subclasses (as > HippoCanvas does), fix the theme system, blah blah. The list could get > pretty long. > > The question is which of these are cosmetic cleanups that aren't really > worth it and which add new capabilities, and how long is the new > capabilities list. Probably not nearly as long as the cosmetic list. > > Replacing the core with a more canvas-ish solution would not have to be > done all in one shot, though; the WidgetCanvasItem and CanvasWidget > provide a lot of interoperability. You could also have some of the > existing widgets implement the CanvasItem interface directly, for > example GtkEntry could be both a GtkWidget and a CanvasItem. > > There's no real disruption to the current core while building a new > canvas-style core either, in fact I'd suggest evolving the canvas stuff > outside of GTK+ for at least a couple of years. It is probably also true > that certain "heavy" widgets such as TextView and TreeView never benefit > from conversion to a canvas-like model. I agree this is a great idea for a testbed independent to GTK+, but even in this case you could only test a subset of the things mentioned here, other ones could prove to be hardly interoperable with the current GtkWidget/GdkEvent functional details (Events handling, GdkWindow revamp, ...). IMVHO, such testbed should become directly a gdk/gtkwidget proof of concept experiment, with two or three widget implementations to play with, and such codebase could be reused later when it proves to be a substantial improvement. But, even being the canvas a great excuse to begin this effort, I don't think it's going to offer enough improvements to the canvas itself to deserve such a long wait, I think leaving potential API users with the current canvas buffet for (say) these two years would harm us in the medium/long term. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 internally; That's a similar approach as has been used in cairo very successfully. > >we also expose a fixed > > point API to avoid using doubles altogether. is this hard? yes. As a datapoint, cairo does not do this. > > cairo and pango developers and contributors went all the lengths to > > reduce the floating point usage in their libraries; we shouldn't screw > > the developers on embedded devices *again*. > > 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. Some people have misunderstood what kinds of optimizations happened in cairo. Cairo has always had a floating-point API, with an implementation that tries to get to fixed-point as quickly as possible. There were several performance problems that were fixed between the 1.2 and 1.4 releases of cairo that involved the following: * Using clever techniques to make the conversion of floating-point to fixed-point values as fast as possible. * Using similar techniques to make the rounding of floating-point values to integers as fast as possible. * Avoiding floating-point arithmetic where the result was unchanged, (multiplying by an identity matrix, for example). At this point, cairo seems plenty fast on embedded systems for the kinds of things that people are throwing at it. Now, some of that speed comes from simply not doing some of the scaling and transformation that might be desired, (see the identity transformation optimization mentioned above). But even if more scaling and rotation were desired, there would be plenty of ways to optimize this, (using fixed-point arithmetic when the scaling is small enough to avoid overflow, using fast integer techniques for computing things like square roots, etc.). And all of that could be done without ever adding any fixed-point API to cairo. 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 approach. -Carl pgpzlnZ1k131g.pgp Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
Behdad Esfahbod skrev: > On Mon, 2007-04-23 at 16:15 -0400, Martyn Russell wrote: Hi, >> Jeff volunteered to help set up gtk.org with moinmoin [2] and >> mentioned that http://www.pango.org/ and http://www.gnome-db.org/ currently >> use >> that particular Wiki. My personal view of it, is that it seems >> somewhat simplistic and might not cater for our needs? > > Drupal is a fully armed CMS. I don't see what feature of it we may need > that we don't get from a wiki engine. Moinmoin is not exactly my > favorite wiki engine, but its been serving many projects good enough. A > problem Fedora recently faced with moinmoin though is that lots of > content (like various meeting logs...) slowed down search functionality > drastically... But for Gtk+, I don't think there going to be such > problems anytime soon. Just let people edit it... I'd use Drupal over a simple wiki any day. It has several things that might come in handy over time for gtk.org. * News/blog engine, very useful for release notes and possibly a www.gtk.org/blog in the future for updates in the projects. With RSS generation. * CMS managed aggregator (create a gtk.org planet and manage it from the same admin system). * Better ACLs if certain pages require moderation (which I believe they might). * Forums integrated, there are a lot of people feeling uncomfortable asking questions through mailing lists. * Attachment handling (this is possible through many wikis as well, not sure about Moinmoin). * Localized content (If I recall Drupal came short here though and was one of the reasons why it weren't chosen for gnome.org. However this is something that is being worked on in Drupal afaik). While some of these items might not be interesting today, they might become over time. Also, we won't loose any functionality by using Drupal over Moinmoin and can even start out by using it as a wiki + news engine for release notes. And then turn on other bits as the site grows. >> Does anyone have a view on this? >> Can anyone provide a good comparison between drupal and moinmoin? >> Does anyone have a better solution to suggest? I can't compare with Moinmoin as I haven't run it for quite a bit of time but I'm very happy with Drupal for developer.imendio.com and two other sites I'm setting up with it. Keep it up, wonderful to see this being picked up! Cheers, Mikael Hallendal -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 possible size of the canvas, > plus > you lose the precision of doubles (which may be important for some > data > visualization apps). I completely agree here with Damon. With fixed point api, bug reports will come in very soon that "if I zoom in 1000x on a point and try to move it, it jumps around...". We've had similar reports when people tried to port Inkscape to cairo, because cairo uses a 16.16 fixed point internally. When you are locked with fixed point, it would be really hard to get out of it. On the other hand, since cairo has double api already and we don't see adding fixedpoint api any time soon, the canvas can do a good job at avoiding floating-point arithmetic completely and use cairo transformations for all the work. And we have been optimizing cairo as much as possible to make this usecase fast for example for non-scale non-rotation matrices. Doing affine transformations completely in fixedpoint is very hard, and probably even impossible to support extreme zoom factors with. -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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; it matters whether a line is 1.5 > pixels wide (a black line next to a gray line), or 2 pixels wide (a > black line.) > > It was a deliberate design decision for the HippoCanvas that layout > happens in integer pixels; a get_width_request() call returns 29px or > 30px, never 29.5px. > > If you say that a box has a spacing of "10pt" you don't want to > interpret that as 10 * (96 / 72.) = 13.33 pixels, you want to interpret > that as 13 pixels. Yes, I had thought of adding something like an "integer-layout" property to GooCanvas, so that the layout in containers like GooCanvasTable can be done in pixels if necessary. I don't think it is that difficult to add. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 items can use whatever they like > > internally. > > it's not a matter of space. > > 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, 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 internally; we also expose a fixed > point API to avoid using doubles altogether. is this hard? yes. is it > necessary? yes. should it be a part of the initial design and > implementation? hell, yes. because history teach us that starting with > "well, we have 64-bit machines nowadays, what's a double going to do" is > the perfect way to hit the wall of performance regressions. > > cairo and pango developers and contributors went all the lengths to > reduce the floating point usage in their libraries; we shouldn't screw > the developers on embedded devices *again*. 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 possible size of the canvas, plus you lose the precision of doubles (which may be important for some data visualization apps). If the canvas item API uses doubles, items can still use fixed point numbers internally if necessary. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Emmanuele Bassi wrote: > On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: >> On Mon, 23 Apr 2007, Murray Cumming wrote: >>> On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: >>> [snip] What do we do? >>> [snip] >>> >>> We wait until someone has an actual need for such a change, or an actual >>> problem. >> >> Uh, I don't get it. Do you imply the problem and need I described are >> not actual? Whoa. That stirred up a hornets nest. I thought Murray's comment was a little sarcastic so I responded with a little sarcasm myself. But he's right, I didn't actually state a problem. It wasn't intentional, I just didn't think my specific case was important. > honestly, I still don't quite understand the problem you have, as you've > been pretty vague about what problems you encountered in porting GLib on > a 'non-linux' platform. The problem I had was in compiling glib on IRIX and its dependency on gettext. I had some trouble compiling gettext, but I did not see that as the issue, rather glib's dependency on gettext. I'm not sure if glib should have any dependencies. With enough effort you can get anything to compile on any system. For me it was gettext, for someone else maybe iconv, for someone else maybe some other dependency that is already installed on my system. I think the value of glib, to developers not creating a gtk+ program, is in the data structures it provides. Good, stable, implementations of lists, arrays, hashes, binary trees, etc. I also find the portability macros useful. If you are writing a gtk+ program, it doesn't matter because you need everything anyway. So this low-level core library requires gettext, and iconv and all of this Unicode manipulation functionality that isn't needed to implement a good linked list or g_malloc or a gint32. I think I'm starting to ramble, so I'll just end with.. I think glib has strayed somewhat from being a low-level core library with the inclusion of unicode handling for one and possibly other features. 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. This would make glib leaner and easier to compile (with fewer dependencies), and hence more portable. -brandon > dependencies? yes, they are an issue, but unfortunately stuff that is > considered "core features" of GLib requires them. GLib maintainers have > been very wary about adding dependencies, so you cannot accuse them to > be "dependencies happy". > > if you want to target a specific system you can remove stuff from GLib > yourself, by adding switches to configure.in; for instance, you can > remove most of the main loop, gmarkup and gkeyfile without really > creating much of an hassle; obviously, the resulting library would be > completely useless on most of the platforms following the GMAE stack, so > I don't think a patch introducing those switches would be applied > upstream. > > ciao, > Emmanuele. > > -- > Emmanuele Bassi, E: [EMAIL PROTECTED] > W: http://www.emmanuelebassi.net > B: http://log.emmanuelebassi.net > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On Mon, 2007-04-23 at 16:15 -0400, Martyn Russell wrote: > > Jeff volunteered to help set up gtk.org with moinmoin [2] and > mentioned > that http://www.pango.org/ and http://www.gnome-db.org/ currently use > that particular Wiki. My personal view of it, is that it seems > somewhat > simplistic and might not cater for our needs? Drupal is a fully armed CMS. I don't see what feature of it we may need that we don't get from a wiki engine. Moinmoin is not exactly my favorite wiki engine, but its been serving many projects good enough. A problem Fedora recently faced with moinmoin though is that lots of content (like various meeting logs...) slowed down search functionality drastically... But for Gtk+, I don't think there going to be such problems anytime soon. Just let people edit it... > Does anyone have a view on this? > Can anyone provide a good comparison between drupal and moinmoin? > Does anyone have a better solution to suggest? -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
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 content and not have to worry about style. For a while now, I > have thought that the GTK+ web site is in dire need of updating, to give > it a more professional look and feel. > > I spent some time looking into the structure of the gtk-web SVN module > to familiarise myself and formulate some questions, so before I continue: After speaking with Jeff Waugh on IRC tonight, he mentioned an idea I too had been considering this week. The idea was to use some kind of Wiki for the gtk.org site and use aliases to link to documentation. At Imendio, we use Drupal [1] for http://developer.imendio.com/ and it works out quite nicely. It is very easy to create/update content, set up aliases and to make announcements. I would like to see this used for the gtk.org site if it fits our needs. Jeff volunteered to help set up gtk.org with moinmoin [2] and mentioned that http://www.pango.org/ and http://www.gnome-db.org/ currently use that particular Wiki. My personal view of it, is that it seems somewhat simplistic and might not cater for our needs? Does anyone have a view on this? Can anyone provide a good comparison between drupal and moinmoin? Does anyone have a better solution to suggest? [1] http://drupal.org/ [2] http://moinmoin.wikiwikiweb.de/ -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GObject based Collection framework
> > > I think you mean "below" the gobject stack, don't you? The data > > > structure libraries are required by gobject after all, aren't they? > > > > > > > Heh, yeah maybe my idea of gobject'ized glib data structs is a little > > futile :) not sure just exactly what I'd do with a derivable GList, > > I'm sure something random could come of it haha, maybe > > I've found myself wanting GObject derived GList. The idea is to have a > "list of things with some GType", and make the API which modifies that > list emit "changed", "deleted", "inserted" signals, etc. I coded a > GObject derived class to do most of this. Regarding a GObject based collection framework: Currently Jürg Billeter, Philip Van Hoof, Johannes Schmid and others work on such a framework called libtpz, as they need/want reference counting collection classes. Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 HTML, the data part is edited in a dedicated app rather > than written by hand or using templates. And a "dedicated app" to create the drawing content is exactly the killer feature of Flash. That's what I want to do with "use Inkscape and slap the SVG into the canvas; then write some simple code to interact with it". People in the Real World need a very simple way to do interactive displays (be it with graphics or just text widgets). A few years ago in Brazil I had a gentleman ask me, "why is GTK+ and Glade so complicated? I'm using a database that lets me write GUIs by typing Enter Name [] (write-your-GUI-though-ASCII-art), and it will then let me name the field, define its type, etc.". People *need* that level of simplicity. Draw something, BANG - it's there. You just write some glue code to the rest of your app. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 (1.5, 1.3, 2.0, 3.4));
>
> I see this more as a higher level abstraction over the canvas rather
> than an intrinsic feature.
Oh, yeah, definitely. I just want to avoid architecture-astronauting;
it's pretty easy to do with a canvas. [In the Piccolo site, look for a
paper about a comparison between a "scene graph canvas" and Piccolo's
current architecture. They wrote two canvases, one very layered and
abstract which was impossible to use, and a more direct one which was
okay --- they found about this by porting the same software to both
canvases. Talk about academia having nothing better to do than...] :)
> > The canvas also needs to have performance goals defined up front. We
> > don't want the case where people avoid using the canvas because it is
> > too slow (like what happened with the antialiased GnomeCanvas).
>
> hmm, right, what should be a reasonable/feasible goal? visualizing a
> bunch of thousand items with little/no noticeable delay? moving a few
> tenths/hundreds around? I guess that making performance studies on the
> current canvases could help here.
It's very hard to predict what people will put inside a canvas. I like
the idea that someone posted on cairo-list; unfortunately I don't
remember whom: it's basically to compare the performance of
swfdec/cairo versus the proprietary Flash player. We could compare the
performance of our canvas with an equivalent Flash drawing.
[Obligatory mention of http://www.clayloomis.com/Tetka.html - sorry for
the imagery.]
Federico
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? You just said "it's bloated" and did not state any specific problem you faced. So what exactly is the problem? ciao, --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? > I've been reading this thread since: http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00077.html Are you somehow implying that you outlined a problem ? That glib is "difficult to compile" on some platforms ? is that what irks you so ? Maybe you could help out by writing a howto or a tutorial for those who prepare platform binaries for thier distributions... Or maybe its more verbosity from the existing build scripts that is needed... Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 14:01 -0500, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? honestly, I still don't quite understand the problem you have, as you've been pretty vague about what problems you encountered in porting GLib on a 'non-linux' platform. dependencies? yes, they are an issue, but unfortunately stuff that is considered "core features" of GLib requires them. GLib maintainers have been very wary about adding dependencies, so you cannot accuse them to be "dependencies happy". if you want to target a specific system you can remove stuff from GLib yourself, by adding switches to configure.in; for instance, you can remove most of the main loop, gmarkup and gkeyfile without really creating much of an hassle; obviously, the resulting library would be completely useless on most of the platforms following the GMAE stack, so I don't think a patch introducing those switches would be applied upstream. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 15:01 -0400, Brandon Casey wrote: > On Mon, 23 Apr 2007, Murray Cumming wrote: > > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > > [snip] > >> What do we do? > > [snip] > > > > We wait until someone has an actual need for such a change, or an actual > > problem. > > Uh, I don't get it. Do you imply the problem and need I described are > not actual? Or are you saying the wait is over since I have described > such? What exactly is the problem you are trying to solve? "embedded" is not a problem statement. Nor is "to save size". "I need to run a glib-using app in 3mb and it doesn't fit" may be. > -brandon -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 of space. 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, 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 internally; we also expose a fixed point API to avoid using doubles altogether. is this hard? yes. is it necessary? yes. should it be a part of the initial design and implementation? hell, yes. because history teach us that starting with "well, we have 64-bit machines nowadays, what's a double going to do" is the perfect way to hit the wall of performance regressions. cairo and pango developers and contributors went all the lengths to reduce the floating point usage in their libraries; we shouldn't screw the developers on embedded devices *again*. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Murray Cumming wrote: > On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: > [snip] >> What do we do? > [snip] > > We wait until someone has an actual need for such a change, or an actual > problem. Uh, I don't get it. Do you imply the problem and need I described are not actual? Or are you saying the wait is over since I have described such? -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 11:46 -0500, Brandon Casey wrote: [snip] > What do we do? [snip] We wait until someone has an actual need for such a change, or an actual problem. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: is glib too bloated?
>For the record, I dont think glib is oversized or bloated at >all, I dont think its size is even a concern worth considering >even in embedded world, that being said... FYI Here is part of an "ls -la" off an ARM embedded device. (ARM being the x86 of embedded devices) 190260 Mar 14 2007 libdbus-1.so.3.2.0 193344 Mar 14 2007 libgmp.so.3.4.1 210240 Mar 14 2007 libcroco-0.6.so.3.0.1 227516 Mar 14 2007 libssl.so.0.9.8 241984 Mar 14 2007 libgobject-2.0.so.0.800.6 262660 Mar 14 2007 libcairo.so.2.2.4 275464 Mar 14 2007 libid3-3.8.so.3.0.0 300272 Mar 14 2007 libgcrypt.so.11.2.3 314996 Mar 14 2007 liboil-0.3.so.0.1.0 323176 Mar 14 2007 libsqlite3.so.0.8.6 360500 Mar 14 2007 libparted-1.7.so.1.0.0 370200 Mar 14 2007 libfreetype.so.6.3.8 549928 Mar 14 2007 libglib-2.0.so.0.800.6 623180 Mar 14 2007 libgstreamer-0.10.so.0.8.1 650416 Mar 14 2007 libasound.so.2.0.0 Libgobject is big but not lots of things are bigger. --David Moffatt. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 for example, and many other "Xlib leakages" such as how some of the events work. You'd want to be Cairo-only, use interfaces instead of objects for the core APIs (widget, container), rethink GtkContainer and its common subclasses (as HippoCanvas does), fix the theme system, blah blah. The list could get pretty long. The question is which of these are cosmetic cleanups that aren't really worth it and which add new capabilities, and how long is the new capabilities list. Probably not nearly as long as the cosmetic list. Replacing the core with a more canvas-ish solution would not have to be done all in one shot, though; the WidgetCanvasItem and CanvasWidget provide a lot of interoperability. You could also have some of the existing widgets implement the CanvasItem interface directly, for example GtkEntry could be both a GtkWidget and a CanvasItem. There's no real disruption to the current core while building a new canvas-style core either, in fact I'd suggest evolving the canvas stuff outside of GTK+ for at least a couple of years. It is probably also true that certain "heavy" widgets such as TextView and TreeView never benefit from conversion to a canvas-like model. New capabilities I can quickly think of, all of which might be possible to retrofit into GtkWidget/GtkContainer themselves: - better layout - overlapping/alpha-blending - reduced overhead / more lightweight objects (speculative) - better containers replacing [HV]Box/Misc (see HippoCanvasBox and xalign, yalign, padding, border properties) - printing trees of items - general ability to draw an item to stuff other than the screen - support for nonrectangular items (e.g. a diagonal line) - nicer event system (e.g. easier enter/leave tracking, remove only-useful-for-toplevels stuff from main item interface) In the end I'm guessing this is just too much work. At the same time, for some apps already we see that even a simple answer like HippoCanvas has important advantages over GtkWidget. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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, 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 HTML, the data part is edited in a dedicated app rather than written by hand or using templates. When I used Flash, I created a blank rectangle in the editor app, then did everything programmatically from ActionScript - but this is _clearly_ the thing that 0.01% of programmer freaks do, not something that would be common among people who use Flash. No Flash books or docs would suggest doing it this way. One of the big reasons Flash is popular is that graphic designers can use it without knowing how to program. The Flash API looks similar to GnomeCanvas or the DOM in that it's a tree of display objects. It's much simpler than either one of those though, there's no layout, there are only a few kinds of item, etc. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk.org about page
On Mon, 23 Apr 2007, Tshepang Lekhonkhobe wrote: > Hi, > > I wonder if gtk.org is still hosted at Berkeley as mentioned here: > http://gtk.org/about.html. I also wonder if we I should get rid of the > 2nd paragraph or write it in past tense. How about the third > paragraph? - Shawn T. Amundson is not anymore the website maintainer (for long) - gtk.org is hosted at berkeley currently - tony gale is not maintaining the tutorial anymore (for long) - damon chaplin does not anymore maintain the reference docs + web - i have no idea who receives [EMAIL PROTECTED] these days ;) --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: GtkCanvas requirements?
> >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 doubles without hardware support means software emulation and that is SLOW to the point of unusable. I wonder if there is a way of using a 64 bit int to get the fidelity of a double without the overhead. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk.org about page
Hi, I wonder if gtk.org is still hosted at Berkeley as mentioned here: http://gtk.org/about.html. I also wonder if we I should get rid of the 2nd paragraph or write it in past tense. How about the third paragraph? -- my place on the web: floss-and-misc.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 (instability > > issues). Mozilla converts css units in twips (an arbitrary integer > > unit, 1/20 of a point). That's a way to go about it I guess, though it > > requires conversions it in the canvas items. Better ideas? > > This is a very important aspect, right. Especially with the upcoming > *resolution independence* in MacOS X, people will start requesting this > feature in GTK+ as well. So we should really add resolution independence > to the feature list. This would at least satisfy the request for > increasing widget spacing if the resolution increases (so we can have > something like "1mm" between widgets). Sadly, I see a some problems here: 1) We don't control the hardware our software is running on. 2) Broken X servers reporting bad dpi values, relying just on modern/non-broken servers doesn't look very attractive either... 3) I bet there's still lots of people with 800x600 (or worse) screens Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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.:
>
> Havoc is on the right track here. You can pile an immense feature list
> on top of the canvas and still get a useless thing. We need use-cases.
>
> My use-cases for a canvas:
>
> - Interactive, pre-drawn graphical content which cannot be done with
> stock widgets. Think of "using Inkscape instead of Glade"; think of a
> poor man's Flash. People want to do this:
>
> canvas = new Canvas ();
> svg = canvas.load_svg ("foo.svg");
> handle = svg.get_object_by_id ("bouncing-ball");
> handle.animate (new BounceAnimation (1.5, 1.3, 2.0, 3.4));
I see this more as a higher level abstraction over the canvas rather
than an intrinsic feature.
>
> - Interactive diagrams, generated programmatically. Think of "the sexy
> call-graphs in kcachegrind". A static diagram is trivial, as you can
> just draw it with Cairo *once* and BitBlt() it when you need it. An
> interactive diagram is harder, since you need event handling, hit
> testing, painless redraw, etc.
>
> - Simple games are already covered by the points above.
>
> - I think we want to focus on simplicity and heavy use of SVG.
> Thousands of programmatically-generated items ("music editor", flyweight
> items, etc.) are not very interesting and could complicate the design a
> lot.
As I see it, with a higher abstraction on the latter you could get the
former.
>
> - Whoever does a canvas really really really needs to look at
> Piccolo.NET (http://www.cs.umd.edu/hcil/piccolo/). The animation API is
> lovely, and the support for "zoomable UIs" is lovely as well. If we had
> Piccolo.NET on top of Cairo and GTK+, we'd have 99% of our needs
> covered.
>
> [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 We Should Stop Writing
> Nontrivial Shit In C thing. People would be really really happy with
> the Piccolo.NET API implemented with pygtk or gtk-sharp.]]
There are already other pieces of complicate software in GTK+ (for
example, GtkTreeView), which have proved to be quite beneficial, and one
of the reasons is that they're implemented in C, and thus, they were
bindable to other languages. IMHO programming a potentially widely used
piece of software in a higher level language would cut down severely its
user base.
>
> > - when is a canvas item used vs. a widget? what current widgets would
> > be "replicated" as canvas items?
>
> If you have a stock canvas item for editable text, you already have 95%
> of the cases covered --- you can compose "editable" mega-items out of
> that text item plus decoration. That's what we do in the Evolution
> calendar, for instance: the calendar's appointments are just a bunch of
> boxes and lines plus text items.
>
> Putting GtkWidgets inside a canvas is a nice gimmick, but I don't think
> you need to make them fully zoomable/transformable/etc. If you want
> GtkFixed-like layout with canvas drawings underneath, you don't need
> exotic transformations.
>
> (People often do diagrams which need pushable buttons, and so they want
> to stick a GtkButton inside a canvas. For that it may be simpler to
> just create a CanvasButton object which you can decorate to your heart's
> content with SVG.)
>
> The canvas also needs to have performance goals defined up front. We
> don't want the case where people avoid using the canvas because it is
> too slow (like what happened with the antialiased GnomeCanvas).
hmm, right, what should be a reasonable/feasible goal? visualizing a
bunch of thousand items with little/no noticeable delay? moving a few
tenths/hundreds around? I guess that making performance studies on the
current canvases could help here.
Regards,
Carlos
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 a personal taste kind of thing that can > create > extra work. > > Then as you mention there's an item that can contain GtkWidget and a > GtkWidget that can contain an item. > > It definitely has the downside that you'd have to replicate large parts > of what's in gdk and gtk already. On the upside, if you're writing a new > "widget core," apps could avoid the old one entirely someday. It's a > "GTK 3.0 in parallel and interoperable with 2.x" sort of thing. Probably > at least a little bit insane. What are we missing in the current core? What benefits would bring a new one? would it be worth in the long term the pain of duplicating code paths? AFAIK, we're missing advanced layout properties like height-for-width, width-for-height and such, maybe they would be done differently if it all were done from scratch, but it seems doable for 2.x. Regards, Carlos ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Havoc Pennington wrote: > Michael L Torrie wrote: >> On the other hand I don't often use gobjects, the event loop, >> call-backs, or any other part of glib in many of these little utility >> programs. >> > > The real question of course is whether everyone's "use" and "don't use" > lists are similar or not. I'm thinking we should be asking whether the glib functions are similar enough to be included in the same library and whether they fit with the stated scope of glib as a "low-level core library". "use and "don't use" is just going to cause a lot of bickering since the intersection of "use" lists is pretty small. > It's a little bit academic, since splitting up the lib wouldn't be > ABI-compatible, so the bar for it to be worth it is extremely high. > Embedded systems can always split it up themselves in a custom way if > they really care. It's always easy to add new functionality. It's hard deciding where it's _appropriate_ to stop. Since ABI compatibility is _very_ important. What do we do? If we come to an academic agreement that developers would be better served by splitting glib into a base library and a higher level library, how do we accomplish that? And how do we avoid situations like this in the future? -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 canvas. Many moons ago he had the thankless job of implementing Evolution's calendar views on top of GnomeCanvas, so he's quite familiar with the problems which someone using the canvas may encounter. 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? > I spent quite a while reading through the Piccolo docs before writing > GooCanvas, but I'm afraid I didn't like it that much. The API is > horribly complicated: Heh. But remember that it was developed by academia, after all ;) Things that I liked from Piccolo: - The animation scheduler. You can say "when this bit of the animation is done, start this other one". - Being able to animate based on object properties. "Modify the 'size' property from 2.5 to 7.0, while you change the 'position' property from to , all during 300 milliseconds". - Having a concept of "scale" for zoomable UIs. - They actually implemented nontrivial zoomable UIs that work (a calendar, an image catalog, some PDA stuff). It would be instructive to see how these programs use the underlying APIs. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On Mon, 2007-04-23 at 10:02 -0400, Martyn Russell wrote: > > > What about refreshing gtk logo in the process ? > > I was thinking this too. > > > I gave it a shot but I'm sure many talented people could give a > better > > proposition. > > Actually, I quite like it - what do others think? Add some translucency? /me runs -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On 4/23/07, Martyn Russell <[EMAIL PROTECTED]> wrote: > I am thinking of doing this in 2 stages: > > 1. Remove all the unnecessary files and have a general clean up and > reorganise. > 2. Restyle the site. I can't wait for those updates. I also don't have too much time but please state if you want some help. -- my place on the web: floss-and-misc.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On 4/23/07, Martyn Russell <[EMAIL PROTECTED]> wrote: > Christophe Dehais wrote: > > On 4/23/07, Martyn Russell <[EMAIL PROTECTED]> wrote: > > > >> Questions: > >> == > >> • Does anyone else have any further suggestions at this stage? > >> > >> > > > > What about refreshing gtk logo in the process ? > > I was thinking this too. > > > I gave it a shot but I'm sure many talented people could give a better > > proposition. > > Actually, I quite like it - what do others think? Me prefers the old one (with those brushstrokes) but I agree that it needs an update. -- my place on the web: floss-and-misc.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Havoc Pennington wrote: > Brandon Casey wrote: >> And this has caused the dependency >> requirements of glib to grow, which makes it harder to build (think non >> linux platforms). > > OTOH, having all the portability goo in GLib makes all the *apps* easier to > build once you get GLib done. Most of the stuff in GLib _is_ needed by GTK+ > apps at least ... you can't write nonbroken apps without the Unicode bits, > for example. Oh, I definitely did not suggest getting rid of any of it. At the same time you don't need the Unicode bits to implement linked lists, hash tables, arrays, binary trees, memory slices, etc. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 11:28 -0400, Tristan Van Berkom wrote: > On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > > > It might be advantagous if alot of the glib data structures > > > were moved somewhere above libgobject in the stack (glibutils ?), > > > this way they could have the option of being gobject based, > > > opening a whole new world of possible code paths and also allowing > > > more generic access to these data structures through the gobject > > > api (hash tables and linked lists could possibly be serialized > > > by libglade and crammed through a network socket ? for an example of > > > a misc wild idea). > > > > I think you mean "below" the gobject stack, don't you? The data > > structure libraries are required by gobject after all, aren't they? > > > > Heh, yeah maybe my idea of gobject'ized glib data structs is a little > futile :) not sure just exactly what I'd do with a derivable GList, > I'm sure something random could come of it haha, maybe > GQueues/GAsyncQueues could be extended glists etc - I guess in the end > that sort of thing would just be libfancyobjects :) > > Might be an interesting thing from a bindings point of view... I dunno I've found myself wanting GObject derived GList. The idea is to have a "list of things with some GType", and make the API which modifies that list emit "changed", "deleted", "inserted" signals, etc. I coded a GObject derived class to do most of this. One thing missing with GList is type safety of course, but if you want, you can add run-time type safety with a class around it. Peter Clifton ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Ross Burton wrote: > On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: >> I think you mean "below" the gobject stack, don't you? The data >> structure libraries are required by gobject after all, aren't they? >> >> In any case, I think a future split out of the glib data structure api >> would be excellent. I pretty much use thinks like gslist, gstring, and >> ghash in *all* my C programs. I also frequently use the glib logging >> facility. >> >> On the other hand I don't often use gobjects, the event loop, >> call-backs, or any other part of glib in many of these little utility >> programs. >> >> It would be nice, though, to only have a small dependency, rather than >> the entire glib. >> >> That said, glib isn't that big. > > That is the current state: libglib only contains main loop, lists, > strings, hashes and so on. On top of that there is libgmodule, > libgobject, and libgthread. If you don't need objects and threads, you > don't need to use them. But we still need to compile glib with all of the dependency requirements that this additional functionality imposes. Think about why there is a libgmodule, libgobject, and libgthread. Why don't we compile all of that functionality into a single library? Linking would be easier. We group functionality with a similar focus together to make it more modular and easier to re-use; Re-use is encouraged and desirable. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Brandon Casey wrote: > And this has caused the dependency > requirements of glib to grow, which makes it harder to build (think non > linux platforms). OTOH, having all the portability goo in GLib makes all the *apps* easier to build once you get GLib done. Most of the stuff in GLib _is_ needed by GTK+ apps at least ... you can't write nonbroken apps without the Unicode bits, for example. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 23 Apr 2007, Emmanuele Bassi wrote: > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: >> On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: >>> >>> I am posting to suggest that glib has crossed a threshold >>> of size and functionality and that users would benefit from >>> a splitting of the library into two or more separate libraries. >> >> For the record, I dont think glib is oversized or bloated at >> all, I dont think its size is even a concern worth considering >> even in embedded world, that being said... > > for my experience, you're right: even GTK+ is not "bloated" in that > respect. I've seen my share of compressed filesystem images containing > the whole stack from X up to GStreamer in ~16MB, so everything could be > said about GLib but it being "bloated". There is nothing implemented in GLib that is not useful in some way to the GTK+ stack. So I agree that the functionality is not bloat. I only suggest that the inclusion of some of this functionality in GLib has increased the scope of GLib. It's no secret that GLib-2 is 4 times larger than GLib-1. The absolute number is still fairly small, but the change in size indicates that there is 4 times as much stuff in GLib-2. I suspect that a lot of the increase in size is due to i18n efforts in dealing with strings. And this has caused the dependency requirements of glib to grow, which makes it harder to build (think non linux platforms). I think there are developers out there who would benefit from a narrowing of the scope of glib, so that it only contains "base" data structures and functionality (yeah I know, define "base"). And move the more higher level functionality into another library. -brandon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > I think you mean "below" the gobject stack, don't you? The data > structure libraries are required by gobject after all, aren't they? > > In any case, I think a future split out of the glib data structure api > would be excellent. I pretty much use thinks like gslist, gstring, and > ghash in *all* my C programs. I also frequently use the glib logging > facility. > > On the other hand I don't often use gobjects, the event loop, > call-backs, or any other part of glib in many of these little utility > programs. > > It would be nice, though, to only have a small dependency, rather than > the entire glib. > > That said, glib isn't that big. That is the current state: libglib only contains main loop, lists, strings, hashes and so on. On top of that there is libgmodule, libgobject, and libgthread. If you don't need objects and threads, you don't need to use them. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 09:17 -0600, Michael L Torrie wrote: > On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > > It might be advantagous if alot of the glib data structures > > were moved somewhere above libgobject in the stack (glibutils ?), > > this way they could have the option of being gobject based, > > opening a whole new world of possible code paths and also allowing > > more generic access to these data structures through the gobject > > api (hash tables and linked lists could possibly be serialized > > by libglade and crammed through a network socket ? for an example of > > a misc wild idea). > > I think you mean "below" the gobject stack, don't you? The data > structure libraries are required by gobject after all, aren't they? > Heh, yeah maybe my idea of gobject'ized glib data structs is a little futile :) not sure just exactly what I'd do with a derivable GList, I'm sure something random could come of it haha, maybe GQueues/GAsyncQueues could be extended glists etc - I guess in the end that sort of thing would just be libfancyobjects :) Might be an interesting thing from a bindings point of view... I dunno Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
Michael L Torrie wrote: > On the other hand I don't often use gobjects, the event loop, > call-backs, or any other part of glib in many of these little utility > programs. > The real question of course is whether everyone's "use" and "don't use" lists are similar or not. It's a little bit academic, since splitting up the lib wouldn't be ABI-compatible, so the bar for it to be worth it is extremely high. Embedded systems can always split it up themselves in a custom way if they really care. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > It might be advantagous if alot of the glib data structures > were moved somewhere above libgobject in the stack (glibutils ?), > this way they could have the option of being gobject based, > opening a whole new world of possible code paths and also allowing > more generic access to these data structures through the gobject > api (hash tables and linked lists could possibly be serialized > by libglade and crammed through a network socket ? for an example of > a misc wild idea). I think you mean "below" the gobject stack, don't you? The data structure libraries are required by gobject after all, aren't they? In any case, I think a future split out of the glib data structure api would be excellent. I pretty much use thinks like gslist, gstring, and ghash in *all* my C programs. I also frequently use the glib logging facility. On the other hand I don't often use gobjects, the event loop, call-backs, or any other part of glib in many of these little utility programs. It would be nice, though, to only have a small dependency, rather than the entire glib. That said, glib isn't that big. > > The biggest advantage to this, and everyone will disagree , > is that it would require breaking api in the platform - which is a > thing the platform is in dire need of (how is all the needed > refactoring going to get done if we cant drop support for all the older > widgets and older deprecated functionalities ?), in the end this is why > something like this reorganization of the stack will never happen until > affirmative action is taken and a dream like gtk+-3.0 is realized. > > /me dreams on just for the sake of dreaming :) > > Cheers, > -Tristan > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk+ Volunteer tasks
On Thu, 19 Apr 2007, Clemens Eisserer wrote: > My idea would be to make backbuffer-handling more flexible: > - If several x-windows are repainted do not acquire a backbuffer for > every sub-window, instead acquire one (for the largest repainted are) > and share it. this is already the case, further refinements are handled in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=169544 > lg Clemens --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 your widget of course). In python, > deriving a widget not a big deal. In C, well I guess you need to grasp > some concepts but it's hardly rocket sience. > Ahem, yes, writing widgets is very hard - not because of language orientation but because of the long history of gtk+ - interestingly I've been away for a week since my internet is down and I see there's been alot of discussion on the lists... interesting points I've seen: Havoc pointed out that - if we were to view the canvas as a completely alternative widget system core, we would have the oportunity of having something lightweight (A gtk+ 3.0 without gtk+ 3.0 I think he said); this idea is very attractive at first sight... but be warned - in my limited experience - I've found that (in this corporation where I work), they went and trashed all the work that we did for 4 years to start a "new generation" that; in the eyes of the salesmen would solve all of our problems, in the end it was a huge game of appearences and worked out well to gain investments for the company etc... but from a developer point of view it was a big waste of time - we were already on our way to a huge refactoring phase that would have allowed us to reposition ourselves for future needs without trashing everything that was already written and was already good (this was already going to be a huge cost, but not nearly as huge as the "new generation" route)... sorry for the long winded analogy but it just goes to say that a technically complex problem requires alot of thought and we shouldnt shy away from trying to understand the code that people have written 5 years ago and improve upon it/refactor it. Another (Clemens Eisserer) in a seperate thread[1] pointed out an interesting way that things could be improved in gtk+, optimizing backbuffering etc, hell from my point of view; GtkWidgets could probably be simplified if the resource management (GdkWindow allocations etc for every damn widget that must support GTK_NO_WINDOW cases or not etc etc) were just deffered out of the typical GtkWidget context. Thats why I'm replying to THIS mail in the thread, GtkWidget's are complex and difficult to write because of the requirements that they meet, this doesnt mean we must sadly lose all hope in them and write something new for the sake of something new just because nobody has the balls to go and refactor the core, Clemens has balls and for that I salute him :) Canvases... thats right this thread is about canvases... canvases historically have been something great for highly customized application environments, but there are so very many applications that need widgets, just basic building blocks, a button here, a slider there, a nicely resizing container - and there you have a simple GUI tool frontend for your typical unix CLI program that is essential to your system. I think its clear we need canvases, and we need all the themable goodness that works out of the box that is gtk+ as well, personally I dont think those two things go in the same boat. A good day to you all, -Tristan [1]http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00074.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 10:05 -0400, Tristan Van Berkom wrote: > On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > > > > I am posting to suggest that glib has crossed a threshold > > of size and functionality and that users would benefit from > > a splitting of the library into two or more separate libraries. > > For the record, I dont think glib is oversized or bloated at > all, I dont think its size is even a concern worth considering > even in embedded world, that being said... for my experience, you're right: even GTK+ is not "bloated" in that respect. I've seen my share of compressed filesystem images containing the whole stack from X up to GStreamer in ~16MB, so everything could be said about GLib but it being "bloated". > It might be advantagous if alot of the glib data structures > were moved somewhere above libgobject in the stack (glibutils ?), > this way they could have the option of being gobject based, and how could gobject use those data structures if they are placed above gobject? they would become part of gobject - and *that* would "bloat" GLib (obviously, "bloat" is the whole point of having a separate gobject library is to avoid the runtime type system if you just want to data types. having said that, the only thing that I would like having is a (G)type safe container abstract class - but that can be built upon GList/GSequence and the GType API in less than 100 lines of code probably. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > > I am posting to suggest that glib has crossed a threshold > of size and functionality and that users would benefit from > a splitting of the library into two or more separate libraries. For the record, I dont think glib is oversized or bloated at all, I dont think its size is even a concern worth considering even in embedded world, that being said... It might be advantagous if alot of the glib data structures were moved somewhere above libgobject in the stack (glibutils ?), this way they could have the option of being gobject based, opening a whole new world of possible code paths and also allowing more generic access to these data structures through the gobject api (hash tables and linked lists could possibly be serialized by libglade and crammed through a network socket ? for an example of a misc wild idea). The biggest advantage to this, and everyone will disagree , is that it would require breaking api in the platform - which is a thing the platform is in dire need of (how is all the needed refactoring going to get done if we cant drop support for all the older widgets and older deprecated functionalities ?), in the end this is why something like this reorganization of the stack will never happen until affirmative action is taken and a dream like gtk+-3.0 is realized. /me dreams on just for the sake of dreaming :) Cheers, -Tristan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
Christophe Dehais wrote: > On 4/23/07, Martyn Russell <[EMAIL PROTECTED]> wrote: > >> Questions: >> == >> • Does anyone else have any further suggestions at this stage? >> >> > > What about refreshing gtk logo in the process ? I was thinking this too. > I gave it a shot but I'm sure many talented people could give a better > proposition. Actually, I quite like it - what do others think? If we are agreed a new icon would be accepted by the community, we should definitely see what we can come up with. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On 4/23/07, Martyn Russell <[EMAIL PROTECTED]> wrote: Questions: == • Does anyone else have any further suggestions at this stage? What about refreshing gtk logo in the process ? I gave it a shot but I'm sure many talented people could give a better proposition. Christophe gtk-logo.svg Description: image/svg ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
hey Martyn, what you say overall sounds good to me, so please get started on your ideas. i'll just comment on the sections where i see/find a slightly different angle. On Mon, 23 Apr 2007, Martyn Russell wrote: ÿÿ Can we remove these unused or unlinked (no href) top level .html files? ÿÿ setuid.html ÿÿ gtk_news.html ÿÿ gtk_news_top_10.html ÿÿ gtk_app_categories.html ÿÿ gtk_app_index.html ÿÿ announce.html ÿÿ books.html ÿÿ gtk+-1.2-NEWS.html ÿÿ glib-1.2-NEWS.html ÿÿ translations.html i'd guess so, unless someone actually objects... have you used google to search for any external references to these links that indicate they could be worth keeping? e.g. see: http://www.google.de/search?as_lq=www.gtk.org%2Fsetuid.html that is, the setuid page *definitely* has to be kept. that is an ever recurring question and documents an important design decision. No, I know that changing the site is likely to break some external links, but unless they are absolutely necessary I think that is OK to do, you have to at some point. For those that need to be kept we can always tidy up the module and provide a link to the new location so older locations still work. The setuid.html file looks like it should be in the FAQ to be honest. I would be inclined to put it there, create a link (i.e. gtk.org/setuid.html --> ). We could also update the source so it no longer points to the old location and phase the link out over time. putting/having this in the FAQ sounds good to me. however i think we should still maintain gtk.org/setuid.html as entrance link because it has shipped with Gtk+ for so long and also been referenced in quite some mailing list threads. also we may or may not want to put extra info there that goes beyond or besides the explanation in the FAQ. ÿÿ Can we remove these unused scripts: ÿÿ freshmeat_update.sh is it revivable? otherwise removing should be fine... Technically anything is if it is in Subversion. We should just remove it in my opinion. yes, i didn't mean to ask if it's history is lost. with "revivable" i meant: does it make any sense to look into updating the script and starting to utilize it for automated freshmeat announcement submissions upon future Gtk+ releases? (that prolly involves Matthias to some extend, because he currently throws out GLib/Gtk+ releases.) Regards, Martyn --- ciaoTJ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkCanvas requirements?
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 we don't want to do layout in floating point (instability > > > issues). Mozilla converts css units in twips (an arbitrary integer unit, > > > 1/20 of a point). That's a way to go about it I guess, though it > > > requires conversions it in the canvas items. Better ideas? > > > > > > > I agree that it would be really good to avoid floating point. Pixels are > > by far the most intuitive thing for people using or writing items, too > > (since as you say they avoid having to multiply everything). Pango does > > have the precedent though and for convenience we could just use the same > > units as Pango. > > I don't really think that pixels or fixed point integers are enough for > a general purpose canvas. If people want to write complex layout apps > like DTP/illustration packages they need more precise control over > coordinates (and in different units like points/millimeters/inches). > > e.g. the SVG spec says high quality viewers should use doubles for > calculations: > http://www.w3.org/TR/SVG11/types.html#BasicDataTypes 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; it matters whether a line is 1.5 pixels wide (a black line next to a gray line), or 2 pixels wide (a black line.) It was a deliberate design decision for the HippoCanvas that layout happens in integer pixels; a get_width_request() call returns 29px or 30px, never 29.5px. If you say that a box has a spacing of "10pt" you don't want to interpret that as 10 * (96 / 72.) = 13.33 pixels, you want to interpret that as 13 pixels. Don't forget the pixel! - Owen (This is, of course, different for a "widgety" use of a Canvas as compared to a WYSYWIG use of the canvas. I'm not sure what that implies for trying to use the same canvas for both. Maybe a global setting or the right layered design can give sufficient flexibility.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
Owen Taylor wrote: > On Mon, 2007-04-23 at 12:52 +0200, Tim Janik wrote: >> On Mon, 23 Apr 2007, Martyn Russell wrote: > >> i'd guess so, unless someone actually objects... >> have you used google to search for any external references to these >> links that indicate they could be worth keeping? >> e.g. see: >>http://www.google.de/search?as_lq=www.gtk.org%2Fsetuid.html >> >> that is, the setuid page *definitely* has to be kept. that is an ever >> recurring question and documents an important design decision. > > It also is linked to in a warning in the GTK+ sources that a user > gets if they try to run GTK+ setuid. Ah, good to know Owen, thanks for pointing that out. -- Regards, Martyn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
Tim Janik wrote:
> On Mon, 23 Apr 2007, Martyn Russell wrote:
>
>> I spent some time looking into the structure of the gtk-web SVN module
>> to familiarise myself and formulate some questions, so before I continue:
>
> rock, thanks for signiing up for the task at http://live.gnome.org/GtkTasks
> please coordinate with Tshepang who's also been doing some gtk-web
> shuffling
> recently.
:)
>> Cleanups:
>> =
>> ÿÿ Do we need to reference the GTK+ 1.2 tutorial now even though we
>> publicly state we don't support GTK+ 1.2?
>
> yes, some people are still running it, despite us not supporting the
> version. i'm also still linking to it when giving my standard replies
> to simple gtk questions.
> we don't need to prominently link to it at this point, but still have
> the content available and maybe linked to it from some "historic pre-2.0"
> page.
Yes, that makes sense, currently the pre-2.0 GTK+ stuff on the site is
too prominent for my liking.
>> ÿÿ The screen shots of GTK+ on BeOS are of v1.3 which is out of date
>> really, shouldn't this be removed?
>
> maybe, but maybe a note that these are outdated would suffice?
Something else that dawned on me when reviewing the site content was
that we seem to be a bit disorganised when it comes to target platforms
that GTK+ runs on, it would be nice to have a more collective place
showing all platforms we support and then have spurs form that for pages
with specific details.
>> ÿÿ Some of the .html files have executable attributes set, is this
>> intentional?
>
> no, that's bogus CVS attribs usually. nothing in the module needs to be
> executable.
> my homedir scripts on gtk.org contain an executable copy of
> gtk-web/install.sh
> so technically not even that file needs to be executable.
> (let me know in case you update that script and i need to update my copy.)
Good, that really bugs me :)
>> ÿÿ The faq/online_faq_fix script fixes up the .html files to remove the
>> header/footer .html files (site_top.html and site_bottom.html), we can
>> remove this if we restyle all the pages.
>> ÿÿ The faq/update_faq script operates on gtk-faq.sgml, but I can't find
>> that file anywhere? Anyone know where this is?
>
> that file results from processing the sgml:
> db2html -u gtk-faq.sgml
Ah, I see, it is in gtk+, i.e. not part of the gtk-web module. So this
requires some manual copying before running the script to create the
pages with docbook. I could probably write a quick script to prepare the
gtk-web file system so it downloads the latest version of that file
before running the docbook commands.
>> ÿÿ The gtk_app_{categories|index}.html files seem redundant and if they
>> are, so is the apps/ directory. Can this be removed?
>
> note, the one thing that definitely must be preserved is:
> http://www.gtk.org/api/2.6/
> (notice the PERMALINK-FOR-LSB file there). that subdir has to remain
> for LSB links to remain valid, everything else is theoretically changable.
OK thanks.
>> ÿÿ The beos/ pages are badly out of date, we should really update those,
>> especially things like the screen shots which make GTK+ look worse that
>> it really is.
>
> maybe we should really have some outdated/historic/etc section then where
> we can move all the stuff that becoimes irrelevant or unmaintained after
> a while.
Hmm, well I have thought about this. For some things like the GTK+ 1.2
API and tutorials, I think it probably makes sense to include somewhere
on the site, but for some other historical things it makes no sense to
include them. We always have Subversion if people are interested in
digging up really old stuff, but generally it isn't useful to have pages
like gtk_app_index.html which list GAIM 0.10.0 :) and images which are
not used any longer.
>> ÿÿ The news/ directory doesn't seem to have updated since 2005. Can we
>> remove this?
>
> dito.
This definitely isn't worth keeping in my opinion.
>> ÿÿ The images/freshmeat/ directory seems completely redundant now. Can we
>> remove this?
>> ÿÿ The images/pink/ directory seems completely redundant now. Can we
>> remove this?
>
> dito. (move to historic/ what seems worthe keeping, remove everything else)
None of these files are worth keeping based on the research I did.
>> ÿÿ The translations page has broken links
>> (http://www.gtk.org/translations.html), namely the Spanish, Chinese and
>> Italian links. Should we update this page? This page is not linked to
>> by any other, is it still required?
>
> linking it from somewhere could be interesting, beast also does this on the
> website (albeit it also needs its links to be updated since last january).
I think the translations page is purely for tutorials that have been
translated from what I saw. We could do that quite nicely on the same
page we list tutorials.
>> ÿÿ Can we remove these unused or unlinked (no href) top level .html
>> files?
>> ÿÿ setuid.html
>> ÿÿ gtk_news.html
>> ÿÿ gtk_news_top_10.html
>> ÿÿ gtk_app_categories.html
>
Re: GTK+ Web site overhaul
On Mon, 2007-04-23 at 12:52 +0200, Tim Janik wrote: > On Mon, 23 Apr 2007, Martyn Russell wrote: > i'd guess so, unless someone actually objects... > have you used google to search for any external references to these > links that indicate they could be worth keeping? > e.g. see: >http://www.google.de/search?as_lq=www.gtk.org%2Fsetuid.html > > that is, the setuid page *definitely* has to be kept. that is an ever > recurring question and documents an important design decision. It also is linked to in a warning in the GTK+ sources that a user gets if they try to run GTK+ setuid. - Owen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Web site overhaul
On Mon, 23 Apr 2007, 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 content and not have to worry about style. For a while now, I
have thought that the GTK+ web site is in dire need of updating, to give
it a more professional look and feel.
I spent some time looking into the structure of the gtk-web SVN module
to familiarise myself and formulate some questions, so before I continue:
rock, thanks for signiing up for the task at http://live.gnome.org/GtkTasks
please coordinate with Tshepang who's also been doing some gtk-web shuffling
recently.
Cleanups:
=
ÿÿ Do we need to reference the GTK+ 1.2 tutorial now even though we
publicly state we don't support GTK+ 1.2?
yes, some people are still running it, despite us not supporting the
version. i'm also still linking to it when giving my standard replies
to simple gtk questions.
we don't need to prominently link to it at this point, but still have
the content available and maybe linked to it from some "historic pre-2.0"
page.
ÿÿ We list some applications like GIMP, Dia, etc on the site front page,
shouldn't just link to the www.gnome-files.org? For one thing, Dia isn't
exactly one of the top applications I would list here, mostly because it
doesn't see as much action as GIMP or some of the others.
right. for beast for instance, i have a subpage with a section that lists
"related projects":
http://beast.gtk.org/related-links
that's whare similar app links can go, this is definitely not front page
matter...
ÿÿ The screen shots of GTK+ on BeOS are of v1.3 which is out of date
really, shouldn't this be removed?
maybe, but maybe a note that these are outdated would suffice?
ÿÿ Some of the .html files have executable attributes set, is this
intentional?
no, that's bogus CVS attribs usually. nothing in the module needs to be
executable.
my homedir scripts on gtk.org contain an executable copy of gtk-web/install.sh
so technically not even that file needs to be executable.
(let me know in case you update that script and i need to update my copy.)
ÿÿ The faq/online_faq_fix script fixes up the .html files to remove the
header/footer .html files (site_top.html and site_bottom.html), we can
remove this if we restyle all the pages.
ÿÿ The faq/update_faq script operates on gtk-faq.sgml, but I can't find
that file anywhere? Anyone know where this is?
that file results from processing the sgml:
db2html -u gtk-faq.sgml
ÿÿ The gtk_app_{categories|index}.html files seem redundant and if they
are, so is the apps/ directory. Can this be removed?
note, the one thing that definitely must be preserved is:
http://www.gtk.org/api/2.6/
(notice the PERMALINK-FOR-LSB file there). that subdir has to remain
for LSB links to remain valid, everything else is theoretically changable.
ÿÿ The beos/ pages are badly out of date, we should really update those,
especially things like the screen shots which make GTK+ look worse that
it really is.
maybe we should really have some outdated/historic/etc section then where
we can move all the stuff that becoimes irrelevant or unmaintained after
a while.
ÿÿ The news/ directory doesn't seem to have updated since 2005. Can we
remove this?
dito.
ÿÿ The images/freshmeat/ directory seems completely redundant now. Can we
remove this?
ÿÿ The images/pink/ directory seems completely redundant now. Can we
remove this?
dito. (move to historic/ what seems worthe keeping, remove everything else)
ÿÿ The translations page has broken links
(http://www.gtk.org/translations.html), namely the Spanish, Chinese and
Italian links. Should we update this page? This page is not linked to
by any other, is it still required?
linking it from somewhere could be interesting, beast also does this on the
website (albeit it also needs its links to be updated since last january).
ÿÿ Can we remove these unused or unlinked (no href) top level .html files?
ÿÿ setuid.html
ÿÿ gtk_news.html
ÿÿ gtk_news_top_10.html
ÿÿ gtk_app_categories.html
ÿÿ gtk_app_index.html
ÿÿ announce.html
ÿÿ books.html
ÿÿ gtk+-1.2-NEWS.html
ÿÿ glib-1.2-NEWS.html
ÿÿ translations.html
i'd guess so, unless someone actually objects...
have you used google to search for any external references to these
links that indicate they could be worth keeping?
e.g. see:
http://www.google.de/search?as_lq=www.gtk.org%2Fsetuid.html
that is, the setuid page *definitely* has to be kept. that is an ever
recurring question and documents an important design decision.
ÿÿ Can we remove these unused scripts:
ÿÿ freshmeat_update.sh
is it revivable? otherwise removing should be fine...
Improvements:
=
ÿÿ Can we update the look and feel here and give the site a fresh coat of
paint?
GTK+ Web site overhaul
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 content and not have to worry about style. For a while now, I
have thought that the GTK+ web site is in dire need of updating, to give
it a more professional look and feel.
I spent some time looking into the structure of the gtk-web SVN module
to familiarise myself and formulate some questions, so before I continue:
Cleanups:
=
• Do we need to reference the GTK+ 1.2 tutorial now even though we
publicly state we don't support GTK+ 1.2?
• We list some applications like GIMP, Dia, etc on the site front page,
shouldn't just link to the www.gnome-files.org? For one thing, Dia isn't
exactly one of the top applications I would list here, mostly because it
doesn't see as much action as GIMP or some of the others.
• The screen shots of GTK+ on BeOS are of v1.3 which is out of date
really, shouldn't this be removed?
• Some of the .html files have executable attributes set, is this
intentional?
• The faq/online_faq_fix script fixes up the .html files to remove the
header/footer .html files (site_top.html and site_bottom.html), we can
remove this if we restyle all the pages.
• The faq/update_faq script operates on gtk-faq.sgml, but I can't find
that file anywhere? Anyone know where this is?
• The gtk_app_{categories|index}.html files seem redundant and if they
are, so is the apps/ directory. Can this be removed?
• The beos/ pages are badly out of date, we should really update those,
especially things like the screen shots which make GTK+ look worse that
it really is.
• The news/ directory doesn't seem to have updated since 2005. Can we
remove this?
• The images/freshmeat/ directory seems completely redundant now. Can we
remove this?
• The images/pink/ directory seems completely redundant now. Can we
remove this?
• The translations page has broken links
(http://www.gtk.org/translations.html), namely the Spanish, Chinese and
Italian links. Should we update this page? This page is not linked to
by any other, is it still required?
• Can we remove these unused or unlinked (no href) top level .html files?
∘ setuid.html
∘ gtk_news.html
∘ gtk_news_top_10.html
∘ gtk_app_categories.html
∘ gtk_app_index.html
∘ announce.html
∘ books.html
∘ gtk+-1.2-NEWS.html
∘ glib-1.2-NEWS.html
∘ translations.html
• Can we remove these unused scripts:
∘ freshmeat_update.sh
Improvements:
=
• Can we update the look and feel here and give the site a fresh coat of
paint? I was thinking of something similar to other GNOME projects (e.g.
http://www.gnome.org/projects/evolution/). If we can, then we can
consider removing box_*.html in the top level directory and updating the
scripts that use them.
• Should we consider adding a blurb on the site about Maemo and the
N770/N800 products and how they use GTK+? So far on the site I have seen
little mentioned about GTK+ being usable on a mobile platform.
• It would be nice to put scripts all in a scripts/ directory too so we
keep the content separate, any objections?
• I would like to add MAINTAINERS and README files with all the
important information that is needed for the upkeep and running of this
module. Is there anything that people would want included in here?
∘ Processes that we follow when releasing?
∘ Files we continually update?
∘ Formatting that we should adhere to,
• I was thinking of moving all the announcement pages to a new directory
announcements/ so things are a little cleaner in the root, any objections?
Questions:
==
• Does anyone else have any further suggestions at this stage?
[1] http://mail.gnome.org/archives/gtk-devel-list/2007-April/msg00053.html
--
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
