Re: desktop-devel-list Digest, Vol 48, Issue 35
- From: Michael Gauthier <mike silverorange com>
- To: desktop-devel-list gnome org
- Subject: Re: desktop-devel-list Digest, Vol 48, Issue 35
- Date: Tue, 22 Apr 2008 00:36:11 -0300
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]