GNOME.org
 

Re: desktop-devel-list Digest, Vol 48, Issue 35

Maria and I agree. We're also thinking maybe Ocicat as well.

On Mon, 2008-21-04 at 23:50 +0000, desktop-devel-list-request gnome org
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
> 	desktop-devel-list-request gnome org
> 
> You can reach the person managing the list at
> 	desktop-devel-list-owner gnome org
> 
> 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 <jdub bethesignal org>
> Subject: Re: install-module on master.gnome.org
> To: desktop-devel-list gnome org
> Message-ID: <20080421163306 GW10563 localhost>
> 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" <sadam clemson edu>
> Subject: Proposed (kind of) new module
> To: "desktop-devel-list gnome org" <desktop-devel-list gnome org>,
> 	"Gnome Release Team" <release-team gnome org>, 	"GNOME Documentation"
> 	<gnome-doc-list gnome org>, gnome-i18n gnome org
> Cc: Seahorse mailing list <seahorse-list gnome org>
> Message-ID:
> 	<8298be230804211056h55c9eb71n3ae35a66d1037eed mail gmail com>
> 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 <benoit placenet org>
> Subject: libgtop branched for GNOME 2.22
> To: release-team gnome org, desktop-devel-list gnome org,
> 	gnome-doc-list gnome org, gnome-i18n gnome org
> Message-ID: <1208451309 18905 11 camel ibook>
> 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 <guillaume fluendo com>
> Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
> To: Emmanuele Bassi <ebassi gmail com>
> Cc: desktop-devel-list <desktop-devel-list gnome org>
> Message-ID: <1208805690 10075 94 camel guijemont-devbox>
> 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 <elle uca libero it>
> Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
> To: Emmanuele Bassi <ebassi gmail com>
> Cc: desktop-devel-list <desktop-devel-list gnome org>
> Message-ID: <1208806670 22011 8 camel redrum>
> 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 <benjamin sipsolutions net>
> Subject: gtk-engines 2.14 branched
> To: release-team <release-team gnome org>,	desktop-devel-list
> 	<desktop-devel-list gnome org>,	gnome-i18n <gnome-i18n gnome org>,
> 	gnome-themes-list <gnome-themes-list gnome org>
> Message-ID: <1208810450 8510 6 camel localhost>
> 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 <vuntz gnome org>
> Subject: External dep version bump: desktop-file-utils
> To: desktop-devel-list gnome org
> Message-ID: <20080421214027 GX15432 vuntz net>
> 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 <Calum Benson Sun COM>
> Subject: Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
> To: Luca Ferretti <elle uca libero it>
> Cc: desktop-devel-list <desktop-devel-list gnome org>
> Message-ID: <83698A5B-A9B7-4146-8624-A0ED7FE1949E sun com>
> 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.
>
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]