Maria and I agree. We're also thinking maybe Ocicat as well. On Mon, 2008-21-04 at 23:50 +0000, [EMAIL PROTECTED] wrote: > Send desktop-devel-list mailing list submissions to > desktop-devel-list@gnome.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of desktop-devel-list digest..." > > > Today's Topics: > > 1. Re: install-module on master.gnome.org (Jeff Waugh) > 2. Proposed (kind of) new module (Adam Schreiber) > 3. libgtop branched for GNOME 2.22 (Beno?t Dejean) > 4. Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > (Guillaume Emont) > 5. Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > (Luca Ferretti) > 6. gtk-engines 2.14 branched (Benjamin Berg) > 7. External dep version bump: desktop-file-utils (Vincent Untz) > 8. Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > (Calum Benson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Apr 2008 02:33:06 +1000 > From: Jeff Waugh <[EMAIL PROTECTED]> > Subject: Re: install-module on master.gnome.org > To: desktop-devel-list@gnome.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > <quote who="Vincent Untz"> > > > > Some apps also have an icon installed in there basedir. How to get that > > > there? > > > > No idea. > > You can just copy one in. They were used for planet.gnome.org/news and were > intended to be used for other automated things (ie. based on tarball name, > you can reliably get an icon), but I don't think there has been much use for > them. :-) > > - Jeff > > -- > OSCON 2008: Portland OR, USA http://conferences.oreilly.com/oscon/ > > GDK (acronym): GNU's Not Unix Image Manipulation Program Tool-Kit > Drawing-Kit. > > > ------------------------------ > > Message: 2 > Date: Mon, 21 Apr 2008 13:56:03 -0400 > From: "Adam Schreiber" <[EMAIL PROTECTED]> > Subject: Proposed (kind of) new module > To: "desktop-devel-list@gnome.org" <desktop-devel-list@gnome.org>, > "Gnome Release Team" <[EMAIL PROTECTED]>, "GNOME Documentation" > <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Cc: Seahorse mailing list <[EMAIL PROTECTED]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=UTF-8 > > All, > > Recently the Seahorse maintainers decided to divide our current module into > two. > > * seahorse - This module contains code pertaining to managing OpenPGP > and SSH keys, Passwords and other stored secrets, and soon > Certificates. > > * seahorse-plugins - This module contains seahorse-agent, our panel > applet and plugins we've developed to extend other applications. > > There is currently some code duplication between the two in the way of > the libseahorse directory. This split was to allow some refactoring > in the seahorse module to properly support X509 certificates and other > encryption key stores. > > seahorse remains in the same repository > http://svn.gnome.org/svn/viewvc/seahorse > > seahorse-plugins resides in > http://svn.gnome.org/svn/viewvc/seahorse/plugins because we haven't > yet recieved a svn dump of the old repository to place in a new > module. A new module has been created in bugzilla already and we're > in the process of reassigning bugs. > > Cheers, > > Adam > > > ------------------------------ > > Message: 3 > Date: Thu, 17 Apr 2008 16:55:09 +0000 > From: Beno?t Dejean <[EMAIL PROTECTED]> > Subject: libgtop branched for GNOME 2.22 > To: [EMAIL PROTECTED], desktop-devel-list@gnome.org, > [EMAIL PROTECTED], [EMAIL PROTECTED] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I've branched libgtop. > > The stable releases will now happen in the /branches/gnome-2-22 branch. > > Developpement happens in /trunk. > > Ciao, > -- > Beno?t Dejean > GNOME http://www.gnomefr.org/ > LibGTop http://directory.fsf.org/libgtop.html > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Ceci est une partie de message > =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?= > Url : > /archives/desktop-devel-list/attachments/20080417/2aabb347/attachment.bin > > ------------------------------ > > Message: 4 > Date: Mon, 21 Apr 2008 21:21:30 +0200 > From: Guillaume Emont <[EMAIL PROTECTED]> > Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > To: Emmanuele Bassi <[EMAIL PROTECTED]> > Cc: desktop-devel-list <desktop-devel-list@gnome.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=utf-8 > > > Le lundi 21 avril 2008 ? 17:10 +0100, Emmanuele Bassi a ?crit : > > On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: > > > > > Dear Emmanuele, > > > > > > Thank you for your opinion. > > > As for the facts you mentioned, yes, there is stuff implemented in > > > pigment-python that is not available in pigment: > > > - The only animation framework available for pigment is indeed the one > > > of pigment-python. That sucks, I agree with you, and that's why I've > > > been working on a new project: the PAF Animation Framework[1], that aims > > > at being a standalone generic animation framework; it will be used by > > > pigment in the future, and is designed to work well with other > > > libraries: GTK+, clutter, any GObject library, or even any non GObject > > > library. For the moment, it is in a "code skeletoning" and API > > > definition stage, anyone interested is welcome to participate or simply > > > give ideas. As for dates, I think a first version of PAF should be > > > available in less than a month, and pigment 0.5 will make use of it > > > (that should be available at the end of summer or at worst in autumn). > > > > > - The scene graph-like grouping system is part of pigment-python as > > > well. There won't be any solution for that in pigment 0.3/0.4, but > > > pigment 0.5 will provide a scene graph API in C (again, end of summer or > > > autumn). > > > > I'm actually kind of fuzzy on why you're not developing Elisa on top of > > Clutter; I understand that the PyClutter bindings might be too near to > > the C API and lack python-esque qualities - but bindings are still > > bindings: I'm not overly attached to PyClutter, actually, and if I > > somebody came up with a better implementation (and was willing to > > maintain it) I would gladly "pass the torch"[1]. > > I don't know that, I am a Pigment and PAF developer, not an Elisa > developer. > > > > > it seems to me that Pigment is trying really hard to get in twelve > > months to the point where Clutter already is now; > > Again, thank you for your opinion, but I don't want to feed any troll. > > > in six month we're > > probably going to release Clutter 1.0, or an approximation of it[2]. > > Clutter is already providing a (portable) integration with GTK+, Webkit, > > Cairo, GStreamer and event a physics engine - and we are committed to > > release the current trunk as 0.8 before GNOME 2.24 is API frozen[3]. > > > > don't get me wrong: the PAF project is very nice, but reading from the > > wiki[4] it looks a lot like a collection of pats in the back from the > > Pigment development team, taking the Python API as a model[5] instead; > > not to mention the fact that there's not only hardly any code, but no > > API design except from what looks like a clone of the Pigment python > > API. > > > > This is a work in progress, and for the moment the only API definition > is in the UML file (misc/paf.xmi in lp:paf). I am currently working on > writing the code skeleton and code documentation in order to have a > clean and clear gtkdoc describing the API. > The main models for the design of the API are the animation part of > Apple's CoreAnimation[1] and the java timing framework[2]. The big > common point between pigment-python's animation layer, PAF and > CoreAnimation is that they try to address the problem of interactive > animations. Implicit animation is therefore a strong common point, but > that doesn't make these APIs equal. > Also, the wiki you cite is not a definition of PAF. It is only a quick > study I did on existing animation frameworks with a few use cases, to > help me find out the features that PAF needs to rock. In short: that > document precedes PAF and the PAF API. > > > I'm also not saying that Clutter is perfect: we have our share of warts > > that we want to address, first and foremost the ability to create > > dynamic layouts[6] in a 3D space. in any case, I have the distinct > > feeling that the Elisa developers did not even try to look at Clutter as > > a way to achieve their goals, save for inspiration. > > > > and that's a real shame, at least for me, because I would have been more > > than happy to help and contribute. > > Again, I don't know, but I think you can ask these questions on the > mailing list of Elisa. Also, I think that Elisa is quite modular, and > that a Clutter front-end could be written for it (I think there was a > GTK+ front-end for Elisa at some point, but I don't know if it still > exists/is maintained). > > Cheers, > > Guillaume > > [1] > http://developer.apple.com/documentation/Cocoa/Conceptual/CoreAnimation_guide/ > [2] https://timingframework.dev.java.net/ > > > > ciao, > > Emmanuele. > > > > +++ > > > > [1] it's not a secret to anyone the fact that I don't really like > > CPython and the current facilities needed to generate python bindings > > from a GObject library. > > > > [2] at which point we'll guarantee API and ABI stability for the whole > > 1.x series. > > ? > > [3] the API differences between 0.6 and 0.8 are going to be minimal at > > best: for this cycle we focused a lot on the low-level GL/GLES > > abstraction layer called COGL, which will be exposed as part of the > > public API and subject to the same guarantees we make for the Clutter > > API and ABI. > > > > [4] https://code.fluendo.com/pigment/trac/wiki/ExistingTimingFrameworks > > > > [5] as far as my experience goes, this is never a good way to design a C > > API, which is the goal in this case; you either end up with a poor copy > > of the translatable concepts from a high level languages or to something > > that's not really reimplementable in other languages and requires many > > more iterations to be considered usable. > > > > [6] http://bugzilla.openedhand.com/show_bug.cgi?id=815 > > > > -- > > Emmanuele Bassi, > > W: http://www.emmanuelebassi.net > > B: http://log.emmanuelebassi.net > > > > _______________________________________________ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > > > > ------------------------------ > > Message: 5 > Date: Mon, 21 Apr 2008 21:37:50 +0200 > From: Luca Ferretti <[EMAIL PROTECTED]> > Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > To: Emmanuele Bassi <[EMAIL PROTECTED]> > Cc: desktop-devel-list <desktop-devel-list@gnome.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > Il giorno lun, 21/04/2008 alle 17.10 +0100, Emmanuele Bassi ha scritto: > > On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: > > > > it seems to me that Pigment is trying really hard to get in twelve > > months to the point where Clutter already is now; in six month we're > > probably going to release Clutter 1.0, or an approximation of it[2]. > > Clutter is already providing a (portable) integration with GTK+, Webkit, > > Cairo, GStreamer and event a physics engine - and we are committed to > > release the current trunk as 0.8 before GNOME 2.24 is API frozen[3]. > > Emmanuele, IMHO the better and faster way to show everyone the Clutter > goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4 > weeks ;-) > > [1] http://www.apple.com/itunes/jukebox/coverflow.html > [2] if you want a bonus, provide both docked and fullscreen mode > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: Questa =?ISO-8859-1?Q?=E8?= una parte del messaggio > firmata digitalmente > Url : > /archives/desktop-devel-list/attachments/20080421/906ad0a9/attachment.bin > > ------------------------------ > > Message: 6 > Date: Mon, 21 Apr 2008 22:40:50 +0200 > From: Benjamin Berg <[EMAIL PROTECTED]> > Subject: gtk-engines 2.14 branched > To: release-team <[EMAIL PROTECTED]>, desktop-devel-list > <desktop-devel-list@gnome.org>, gnome-i18n <[EMAIL PROTECTED]>, > gnome-themes-list <[EMAIL PROTECTED]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="us-ascii" > > gtk-engines has been branched for 2.14. The branch is gtk-engines-2-14, > development for GNOME 2.24 will happen in trunk. > > Benjamin > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 189 bytes > Desc: This is a digitally signed message part > Url : > /archives/desktop-devel-list/attachments/20080421/faa5bfaa/attachment.bin > > ------------------------------ > > Message: 7 > Date: Mon, 21 Apr 2008 23:40:27 +0200 > From: Vincent Untz <[EMAIL PROTECTED]> > Subject: External dep version bump: desktop-file-utils > To: desktop-devel-list@gnome.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=iso-8859-1 > > Hi, > > We currently use desktop-file-utils 0.10, which is quite old, with a few > bad bugs. I'd like to use desktop-file-utils 0.15, which is much > cleaner, better, etc. Some big parts were rewritten in version 0.13 > (iirc), but since then the code is quite stable and distros are shipping > the new versions without problems. > > Anyone against this change? > > Vincent > > -- > Les gens heureux ne sont pas press?s. > > > ------------------------------ > > Message: 8 > Date: Tue, 22 Apr 2008 00:49:56 +0100 > From: Calum Benson <[EMAIL PROTECTED]> > Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6 > To: Luca Ferretti <[EMAIL PROTECTED]> > Cc: desktop-devel-list <desktop-devel-list@gnome.org> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; delsp=yes; format=flowed; charset=US-ASCII > > > On 21 Apr 2008, at 20:37, Luca Ferretti wrote: > > > Il giorno lun, 21/04/2008 alle 17.10 +0100, Emmanuele Bassi ha > > scritto: > >> On Mon, 2008-04-21 at 16:46 +0200, Guillaume Emont wrote: > >> > >> it seems to me that Pigment is trying really hard to get in twelve > >> months to the point where Clutter already is now; in six month we're > >> probably going to release Clutter 1.0, or an approximation of it[2]. > >> Clutter is already providing a (portable) integration with GTK+, > >> Webkit, > >> Cairo, GStreamer and event a physics engine - and we are committed to > >> release the current trunk as 0.8 before GNOME 2.24 is API frozen[3]. > > > > Emmanuele, IMHO the better and faster way to show everyone the Clutter > > goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox > > whitin 4 > > weeks ;-) > > And then try to find anyone who actually finds it more useful than > what was there before :P > > Cheeri, > Calum. >
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list