Re: Proposed external dependency: PolicyKit/PolicyKit-gnome
On Fri, 2007-12-21 at 22:39 +0100, Luca Ferretti wrote: > PolicyKit-gnome needs libsexy :-( Is that a big problem? I think the only thing I'm using this for is SexyUrlLabel. I'd hate to copy-paste... (And why aren't the libsexy people actively working with the gtk people about merging at least some of the useful stuff like UrlLabel into gtk?) > BTW PK and PK-gnome are not in jhbuild. The rules are simple Thanks for looking after this! Cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Needed new HAL for gvfs [was: Proposed module: gvfs]
On Fri, 2007-12-21 at 22:44 +0100, Luca Ferretti wrote: > Alex, it seems that the HAL backend for volume monitoring needs > hal-0.5.10 (while the currently approved is 0.5.9). I've asked the release team to bump the requirement to 0.5.10. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Unifying name for Plugins/Extensions/etc.
On Thu, 20 Dec 2007 08:11:40 +0100 Matteo Settenvini wrote: > However, the problem is having a consistent translation for plugins > across the desktop. If you name that "extensions", translators will > write it in italian as "estensioni". > > If you leave that plugins, Italian translators could write that as (at > least): > * plugin (untranslated) > * estensioni > * ampliamenti > * moduli > * aggiunte > * spine (here I'm joking :-)) > > So it isn't guaranteed that everyone will use the same term as the > other, since "plugins" does not have a clear correspondence in it_IT. > > Not counting the problem of going on the Internet for finding the > solution to a problem, finding a tutorial in English wich refers to > "plugins", and figuring out that is the same of "estensioni" in your > Italian-translated UI. Whereas "extensions" is much more similar. Russian GNOME translation team uses own glossary exactly for this reason, and GNOME translators work closely with KDE translators to maintain consistent l10n in both environments. I think this is the way every translation team should go. -- Alexey "Ktirf" Rusakov ALT Linux Team GNOME project ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gvfs
On Dec 21, 2007 3:57 PM, Shaun McCance <[EMAIL PROTECTED]> wrote: > > The gio documentation itself could use some love (at least > according to what I'm seeing on library.gnome.org). That > is at least partially relevant to the discussion, because: > 1) gvfs is only relevant if we use gio, and > 2) gio should be well-documented if we expect developers > to switch to it. > On the other hand, it's not as if gnome-vfs has exemplary > documentation, and that's the status quo if we don't start > using gio. I don't know whats on library.gnome.org, but the api docs in the gio module are at 98% coverage right now. You can always do better, and the docs are still a bit light in terms of concepts, examples and migration instructions, but the API reference itself is in decent shape, I think. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Needed new HAL for gvfs [was: Proposed module: gvfs]
Il giorno gio, 20/12/2007 alle 16.40 +0100, Alexander Larsson ha scritto: > svn/git/bzr/...: http://svn.gnome.org/viewcvs/gvfs/ > > Short description: > == > gvfs is a userspace virtual filesystem implemented as a pluggable module > for gio (a new module in glib). The glib part of gio supports the > general APIs required for a virtual filesystem, but only has an > implementation for local files. GVfs is a unix-specific implementation > that uses out-of-process mount daemons and dbus for talking to the > daemon. > > gio is part of glib 2.15.0 and will be released on schedule for gnome > 2.22. Both eel and nautilus has been converted to use gio instead of > gnome-vfs. > > Requires new external dependencies: > === > A new optional dependency for gvfs is fuse. If this is installed then > applications not using gio can still access files on gvfs shares. > Alex, it seems that the HAL backend for volume monitoring needs hal-0.5.10 (while the currently approved is 0.5.9). Note that in order to build hal-0.5.10 you also need to update (both in external dep): * udev-105--> udev-115 (libvolume_id 0.77) * expat-1.95.7--> expat-1.95.8 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: PolicyKit/PolicyKit-gnome
Le vendredi 21 décembre 2007, à 22:39 +0100, Luca Ferretti a écrit : > But where I should add them waiting for approval? gnome-2.22.modules (as > any other proposed module) or freedesktop-2.22.modules (as any other > fd.org hosted project)? freedesktop-2.22.modules, I'd say. Thanks for rocking with the modulesets, Luca! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: PolicyKit/PolicyKit-gnome
Il giorno gio, 20/12/2007 alle 04.52 +0100, Vincent Untz ha scritto: > Short description: > == > In a nutshell, PolicyKit aims to provide an API for querying and > managing "authorizations" and answer the question "Is $PROGRAM allowed > to do $ACTION on $OBJECT". > Basically, PolicyKit-gnome provides an Authentication Agent that can > prompt the user for his credentials, a set of classes to make it very > easy to use PolicyKit from GTK+ applications, an the UI for managing > authorizations. > > Summary so far: > === > + PolicyKit-gnome might be proposed for inclusion in the desktop for >2.24 PolicyKit-gnome needs libsexy :-( BTW PK and PK-gnome are not in jhbuild. The rules are simple + +http://hal.freedesktop.org/releases/PolicyKit-0.7.tar.gz"; + md5sum="99e0cc588310656fa25f8f66a411c71f" size="1214032"/> + + + + + + + + +http://hal.freedesktop.org/releases/PolicyKit-gnome-0.7.tar.bz2"; + md5sum="978ccbe3c9426f4d59c7903f566f954b" size="990594"/> + + + + + + + But where I should add them waiting for approval? gnome-2.22.modules (as any other proposed module) or freedesktop-2.22.modules (as any other fd.org hosted project)? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: vinagre
Em Sex, 2007-12-21 às 14:31 -0600, Shaun McCance escreveu: > Vinagre doesn't appear to have any user documentation, and the > developers have not contacted the Gnome Documentation Team about > writing documentation. Hi. There is a bug about that: http://bugzilla.gnome.org/show_bug.cgi?id=503806 We have already the framework, and the content (manual) itself is going to be written by a student in a ghop task: http://mail.gnome.org/archives/gnome-love/2007-December/msg00017.html > If I'm not mistaken, Vinagre is the client to Vino's server. > If that is the case, we should probably have some coordination > between the documentation for these two packages. Yes, you're right. In the future we plan to extend vinagre to be a client for other systems, like Windows terminal service. Currently it is a VNC client, fitting the GNOME's server, Vino. (it's weird to have a server and not a client in the desktop, isn't it?) I am available to cooperate with the documentation team to have a manual for Vinagre. It's my pleasure! Cheers, -- Jonh Wendell www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: mousetweaks
At 2:19 PM -0600 12/21/07, Shaun McCance wrote: >On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: >> Homepage: https://launchpad.net/mousetweaks >> svn/git/bzr/...: >>http://codebrowse.launchpad.net/~lowfi/mousetweaks/trunk/files >> Proposal on d-d-l: >>http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00489.html >> >> Short description: >> == >> MouseTweaks is a set of special accessibility enhancements to >> controlling the mouse cursor. It provides: >>* a pointer capture area >>* a way to open the contextual menu with a left click and hold >>* a way to perform the various clicks (single -, double -, drag -, >> right click) by software without any hardware button, usually called >> dwelling. >> Particularly, this would fill the current accessibility gap in GNOME for >> users who can move the pointer, but are not able click with any hardware >> button. > > >This is an analysis of the documentation, made on behalf of the >Gnome Documentation Team. It does not necessarily reflect my >personal opinion of the module or its suitability for inclusion >in Gnome. In many cases, I have not made extension use of the >applications or libraries provided. Further insufficiencies in >the documentation may become more apparent with more use. > > >MouseTweaks currently has a user manual, and it appears to be >reasonably complete. The fact that it's not in Gnome SVN means >that it will be difficult for the Gnome Documentation Team to >assist with documentation, and that our translators will not >be able to translate the document. > >My understanding is that the community wanted the MouseTweaks >settings to be integrated into our Accessibility preferences, >but that this has not happened. If this were to happen (and, >perhaps, even if not), then MouseTweaks should be documented >in the Accessiblity Guide and/or the User Guide. As we are working with the people of gnome control center to turn the mousetweaks preferences (gui to enable and configure 2 of the 3 features) into the accessibility tab of the Mouse capplet, I enhanced the file /usr/share/gnome/help/control-center/C/config-mouse.xml with some documentation about the features provided by mousetweaks. Please have a look at comments 14, 15, 16 and 19 of the following thread: http://bugzilla.gnome.org/show_bug.cgi?id=503547 Based on what I explained in comment 19 of the preceding thread, should I add the documentation about the features provided by mousetweaks to goscustdesk.xml? Thanks in advance for the reply. Francesco ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gvfs
On Fri, 2007-12-21 at 14:57 -0600, Shaun McCance wrote: > On Thu, 2007-12-20 at 16:40 +0100, Alexander Larsson wrote: > > svn/git/bzr/...: http://svn.gnome.org/viewcvs/gvfs/ > > > > Short description: > > == > > gvfs is a userspace virtual filesystem implemented as a pluggable module > > for gio (a new module in glib). The glib part of gio supports the > > general APIs required for a virtual filesystem, but only has an > > implementation for local files. GVfs is a unix-specific implementation > > that uses out-of-process mount daemons and dbus for talking to the > > daemon. > > > > gio is part of glib 2.15.0 and will be released on schedule for gnome > > 2.22. Both eel and nautilus has been converted to use gio instead of > > gnome-vfs. > > > This is an analysis of the documentation, made on behalf of the > Gnome Documentation Team. It does not necessarily reflect my > personal opinion of the module or its suitability for inclusion > in Gnome. In many cases, I have not made extension use of the ^ s/extension/extensive/ I copied and pasted the same typo eight times, and on behalf of the documentation team no less. How embarrassing. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gvfs
On Thu, 2007-12-20 at 16:40 +0100, Alexander Larsson wrote: > svn/git/bzr/...: http://svn.gnome.org/viewcvs/gvfs/ > > Short description: > == > gvfs is a userspace virtual filesystem implemented as a pluggable module > for gio (a new module in glib). The glib part of gio supports the > general APIs required for a virtual filesystem, but only has an > implementation for local files. GVfs is a unix-specific implementation > that uses out-of-process mount daemons and dbus for talking to the > daemon. > > gio is part of glib 2.15.0 and will be released on schedule for gnome > 2.22. Both eel and nautilus has been converted to use gio instead of > gnome-vfs. This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. gvfs is a module for gio. As such, most of us programmers won't interact with it directly. Instead, we will use the gio APIs, which will be implemented by gvfs. Therefore, documentation for gvfs isn't strictly necessary. The gio documentation itself could use some love (at least according to what I'm seeing on library.gnome.org). That is at least partially relevant to the discussion, because: 1) gvfs is only relevant if we use gio, and 2) gio should be well-documented if we expect developers to switch to it. On the other hand, it's not as if gnome-vfs has exemplary documentation, and that's the status quo if we don't start using gio. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: vinagre
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://www.gnome.org/projects/vinagre/ > svn/git/bzr/...: http://svn.gnome.org/viewcvs/vinagre/ > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00548.html > > Short description: > == > Vinagre is a VNC client for GNOME. It fits well on the GNOME Desktop, by > following HIG and using technologies like Avahi and Keyring. > (Note: goal seems to be to also support RDP, SSH (X forwarding, I > guess?), NX in the future, according to one of the early mails) This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. Vinagre doesn't appear to have any user documentation, and the developers have not contacted the Gnome Documentation Team about writing documentation. (Reminder: proposing an undocumented module is not a problem. Hackers are often not good writers, and we don't expect that people bring fully documented programs to our doorstep. But if you need documentation help, you need to contact us early.) If I'm not mistaken, Vinagre is the client to Vino's server. If that is the case, we should probably have some coordination between the documentation for these two packages. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: swfdec-gnome
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://swfdec.freedesktop.org/ > svn/git/bzr/...: > http://gitweb.freedesktop.org/?p=swfdec/swfdec-gnome.git;a=summary > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-October/msg00200.html > > Short description: > == > swfdec-gnome's purpose is integration of Flash files into the Gnome > desktop. It currently provides a thumbnailer and a playback application > for local files similar to the stand-alone application Adobe ships on > Windows. > (Note: this is not about a flash browser plugin) This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. swfdec-gnome does not appear to have any user documentation. The developers have not contacted the Gnome Documentation Team about writing documentation. Furthermore, since swfdec-gnome isn't hosted in Gnome SVN, it will be difficult for use to help with the documentation. (Reminder: proposing an undocumented module is not a problem. Hackers are often not good writers, and we don't expect that people bring fully documented programs to our doorstep. But if you need documentation help, you need to contact us early.) -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: cheese
On Dec 21, 2007 9:06 PM, Shaun McCance <[EMAIL PROTECTED]> wrote: > On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > > Homepage: http://www.gnome.org/projects/cheese/ > > svn/git/bzr/...: http://svn.gnome.org/viewcvs/cheese/ > > Proposal on d-d-l: > > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00289.html > > > > Short description: > > == > > cheese is a photobooth-inspired GNOME application for taking pictures > > and videos from a webcam. it also includes fancy graphical effects based > > on the gstreamer-backend. further releases will include conduit support > > for exchanging pictures and videos and some opengl-love to speed things > > up > > > This is an analysis of the documentation, made on behalf of the > Gnome Documentation Team. It does not necessarily reflect my > personal opinion of the module or its suitability for inclusion > in Gnome. In many cases, I have not made extension use of the > applications or libraries provided. Further insufficiencies in > the documentation may become more apparent with more use. > > > Cheese has a manual, though it is largely a stub, and it hasn't > seen any commits in two weeks. The Cheese developers have not > approached the Gnome Documentation Team about the documentation. > > (Reminder: proposing an undocumented module is not a problem. > Hackers are often not good writers, and we don't expect that > people bring fully documented programs to our doorstep. But > if you need documentation help, you need to contact us early.) > I'm one of the developers of cheese and feel that cheese is not ready yet for inclusion because 1) We completely refactored the gstreamer backend and haven't had a release since. So I'm not sure if it works well for every webcam 2) Cheese needs more HIG love 3) Also feature wise it needs some more things for it to be 1.0 material (preference dialog, ability to select multiple items in the icon view 4) And as Shaun is mentioning, we need a manual I think it's better to wait for 2.24 Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: mousetweaks
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: https://launchpad.net/mousetweaks > svn/git/bzr/...: > http://codebrowse.launchpad.net/~lowfi/mousetweaks/trunk/files > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00489.html > > Short description: > == > MouseTweaks is a set of special accessibility enhancements to > controlling the mouse cursor. It provides: > * a pointer capture area > * a way to open the contextual menu with a left click and hold > * a way to perform the various clicks (single -, double -, drag -, > right click) by software without any hardware button, usually called > dwelling. > Particularly, this would fill the current accessibility gap in GNOME for > users who can move the pointer, but are not able click with any hardware > button. This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. MouseTweaks currently has a user manual, and it appears to be reasonably complete. The fact that it's not in Gnome SVN means that it will be difficult for the Gnome Documentation Team to assist with documentation, and that our translators will not be able to translate the document. My understanding is that the community wanted the MouseTweaks settings to be integrated into our Accessibility preferences, but that this has not happened. If this were to happen (and, perhaps, even if not), then MouseTweaks should be documented in the Accessiblity Guide and/or the User Guide. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: PolicyKit/PolicyKit-gnome
On Fri, 2007-12-21 at 12:31 -0700, Elijah Newren wrote: > On Dec 20, 2007 8:59 AM, David Zeuthen <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I actually asked the release team and got two replies saying external > > deps are fine and there was no need to bless/ditch such deps. So maybe > > we want to wait until the 2.24 proposal period for this discussion? > > I believe you meant to say "soft deps" rather than "external deps", > yes? If no one wants to add a hard dependency on PolicyKit, then yes > we don't need to worry about this right now. Right. It's a soft external dependency. Thanks. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: gimmie applet
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://www.beatniksoftware.com/gimmie/ > svn/git/bzr/...: http://svn.gnome.org/viewcvs/gimmie/ > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00441.html > > Short description: > == > Gimmie is a unique desktop organizer for Linux. It's designed to allow > easy interaction with all the applications, contacts, documents and > other things you use every day. > (Note: only the applet is proposed for inclusion) This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. Gimmie currently has no user documentation, and the Gimmie developers have not contacted the Gnome Documentation Team. (Reminder: proposing an undocumented module is not a problem. Hackers are often not good writers, and we don't expect that people bring fully documented programs to our doorstep. But if you need documentation help, you need to contact us early.) It is unclear to me exactly how we should proceed with Gimmie documentation. At the moment, it seems best for it to provide its own user manual. The sentiment among Gimmie fans, though, seems to be that this should, in time, be a central part of how we use our desktops. If we go in that direction, then it would be preferable to document Gimmie in the User Guide, at least partially. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [External Deps] Updated recommended popper version to 0.6.3
Il giorno ven, 21/12/2007 alle 01.39 +0100, Vincent Untz ha scritto: > Le jeudi 20 décembre 2007, à 12:37 +0100, Luca Ferretti a écrit : > > > > PS should we add poppler-data to jhbuild build and in ext deps list? > > >From poppler-data README: > > > > This package consists of encoding files for use with poppler. > > The encoding files are optional and poppler will automatically > > read them > > if they are present. When installed, the encoding files enables > > poppler to correctly render CJK and Cyrrilic properly. While > > poppler is licensed under the GPL, these encoding files are > > copyright Adobe and licensed much more strictly, and thus > > distributed separately. > > I think it's nice to use poppler-data, but it's not required as an > external dependency to have evince working. Let's say it's a bit like > some of the gstreamer plugins that we don't ship in the desktop, but > that people are still using. > > But I see no harm in adding it to the jhbuild build. poppler-data is in jhbuild now, added as dependence for poppler just to ensure to install it... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: cheese
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://www.gnome.org/projects/cheese/ > svn/git/bzr/...: http://svn.gnome.org/viewcvs/cheese/ > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00289.html > > Short description: > == > cheese is a photobooth-inspired GNOME application for taking pictures > and videos from a webcam. it also includes fancy graphical effects based > on the gstreamer-backend. further releases will include conduit support > for exchanging pictures and videos and some opengl-love to speed things > up This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. Cheese has a manual, though it is largely a stub, and it hasn't seen any commits in two weeks. The Cheese developers have not approached the Gnome Documentation Team about the documentation. (Reminder: proposing an undocumented module is not a problem. Hackers are often not good writers, and we don't expect that people bring fully documented programs to our doorstep. But if you need documentation help, you need to contact us early.) -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://live.gnome.org/Empathy > svn/git/bzr/...: http://svn.gnome.org/viewcvs/empathy/ > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00301.html > > Short description: > == > Empathy consists of a rich set of reusable instant messaging widgets, > and a GNOME client using those widgets. It uses Telepathy and Nokia's > Mission Control, and reuses Gossip's UI. The main goal is to permit > desktop integration by providing libempathy and libempathy-gtk > libraries. libempathy-gtk is a set of powerful widgets that can be > embeded into any GNOME application. This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. Empathy provides an application and two panel applets. There doesn't appear to be any user documentation for these, and the Empathy developers did not contact the Gnome Documentation Team about writing any documentation during this release cycle. (Reminder: proposing an undocumented module is not a problem. Hackers are often not good writers, and we don't expect that people bring fully documented programs to our doorstep. But if you need documentation help, you need to contact us early.) Empathy also provides two libraries. There does appear to be gtk-doc documentation for these libraries. These documents are on library.gnome.org. A quick glance indicates that these are only stubs, and that no useful documentation has been written. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: anjuta
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Homepage: http://anjuta.sourceforge.net/ > svn/git/bzr/...: http://svn.gnome.org/svn/anjuta/trunk/ > http://svn.gnome.org/svn/gdl/trunk/ > http://svn.gnome.org/svn/gnome-build/trunk/ > Proposal on d-d-l: > http://mail.gnome.org/archives/desktop-devel-list/2007-September/msg00252.html > > Short description: > == > Anjuta is an integrated development environment for GNOME. It's purpose > is to make developing applications for Gtk+/GNOME easier. It integrates > other GNOME technologies such as devhelp, glade and gtksourceview. This is an analysis of the documentation, made on behalf of the Gnome Documentation Team. It does not necessarily reflect my personal opinion of the module or its suitability for inclusion in Gnome. In many cases, I have not made extension use of the applications or libraries provided. Further insufficiencies in the documentation may become more apparent with more use. Anjuta's Manual seems reasonably complete and well-organized. An application as large and feature-rich as Anjuta can likely always use more documentation. In particular, tutorials for common tasks could be added. Nonetheless, the documentation is of a higher quality than much of the documentation in our other modules. I've noticed some cosmetic problems, such as incorrect markup for key sequences, and some non-standard themes in screenshots. If only all our documentation were this easy to fix. Anjuta also comes with libanjuta for developing Anjuta plugins. This library is fully gtk-doc-ified. At a cursory glance, it appears reasonably complete. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: PolicyKit/PolicyKit-gnome
On Dec 20, 2007 8:59 AM, David Zeuthen <[EMAIL PROTECTED]> wrote: > Hi, > > I actually asked the release team and got two replies saying external > deps are fine and there was no need to bless/ditch such deps. So maybe > we want to wait until the 2.24 proposal period for this discussion? I believe you meant to say "soft deps" rather than "external deps", yes? If no one wants to add a hard dependency on PolicyKit, then yes we don't need to worry about this right now. Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: vinagre
On Thu, 2007-12-20 at 04:52 +0100, Vincent Untz wrote: > Summary so far: > === > + some +1 (people are happy to replace tsclient) tsclient's UI is horrendous, and vinagre is a definite plus. > + seems to be a bit slower than vncviewer I blame gtk-vnc. Its first use case was to access Xen/KVM virtual machine's screens, so it's been optimised for high-quality rendering and fast links. Compressed encodings support is on the TODO list. So a solution to this use case is coming. vinagre is still great for local network use. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On Fri, 2007-12-21 at 10:21 -0600, Jason D. Clinton wrote: > Since you're patronizing me, I'll return the favor. Let's start with > the basic discussion topics: > > - How's the API? Stable yet? > - Committed maintainers? > - How's documentation? > - I10n? > > I think telepathy is good to go; I'm looking for dissenting opinions > here. I wasn't being patronising, I thought the Nokia/Collabora points were genuine so I explained it for anyone who didn't know the history. 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Since you're patronizing me, I'll return the favor. Let's start with the basic discussion topics: - How's the API? Stable yet? - Committed maintainers? - How's documentation? - I10n? I think telepathy is good to go; I'm looking for dissenting opinions here. On 12/21/07, Ross Burton <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-12-20 at 17:12 -0600, Jason D. Clinton wrote: > > So in summary, WTF is Telepathy and Topaz and why should I care? (Or > > for the tin-foil-hat brigade: why does Nokia/Collabora care about this > > so much?) > > From http://telepathy.freedesktop.org/wiki/: > > "Telepathy development is supported by Collabora Limited." > > From > > http://maemo.org/development/documentation/how-tos/4-x/implementing_custom_connection_managers.html > : > > "The messaging framework in Internet Tablet OS is based on Telepathy > framework architecture." > > I think that pretty much sums up why Nokia (they use it) and Collabora > (they wrote it) are about Telepathy. > > 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 > > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
On Thu, 2007-12-20 at 17:12 -0600, Jason D. Clinton wrote: > So in summary, WTF is Telepathy and Topaz and why should I care? (Or > for the tin-foil-hat brigade: why does Nokia/Collabora care about this > so much?) From http://telepathy.freedesktop.org/wiki/: "Telepathy development is supported by Collabora Limited." From http://maemo.org/development/documentation/how-tos/4-x/implementing_custom_connection_managers.html: "The messaging framework in Internet Tablet OS is based on Telepathy framework architecture." I think that pretty much sums up why Nokia (they use it) and Collabora (they wrote it) are about Telepathy. 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: empathy
Jason D. Clinton wrote: > I didn't say that I don't want Telepathy in. It's no secret that I don't > like Empathy but I DO like the goals of Telepathy. I just happen to think > that Empathy is a poor implementation of a Telepathy client. My question There are still UI bugs in Empathy that I find annoying, but I wouldn't call it a poor implementation, certainly not a poor implementation of a Jabber client (I don't really know what would be a Telepathy client, something that implement everything offered by Telepathy ?). > At some point in the previous discussion, Jeff mentioned how well "telepathy > fits in to the Topaz vision" (paraphrasing). Well, ok. Who's vision of Topaz > and where is this master document? And when were the rest of us going to > this a memo about this glorious vision? There is no memo, and you probably know it. Topaz is just an empty word, an occasion to start the discussion about the future we want. Bridging together applications and online services, this is all part of something I'd like to see, and there are different projects in this direction, they are not incompatible, telepathy, online desktop, etc. I have little implication in those, I filed a few bugs again empathy, I applied a few patches to JHBuild to help the online desktop effort, nothing much. > > Well. I didn't check the libempathy API, but my understanding is that > > you wouldn't see telepathy, but just libempathy. And if we accept > > empathy, it makes sense (at least to me) to integrate it wherever it's > > useful. If it helps improve the user experience for multi-player games, > > isn't this a feature you'd want to see? > > That seems backwards from the way I see it; I don't see why I would send > game I/O over to Empathy to have it pass the data on to Telepathy when I can > just talk to Telepathy directly... As I said I have very little knowledge about how all things fit together, but I know what libempathy-gtk offers, it is a set of widgets that can be useful when adding "presence" support, a combobox with available contacts for example. Note libempathy-gtk has all widgets in use by the Empathy client (which is just a thin shell) and I believe most of them wouldn't be useful out of Empathy. > Also, you seem to imply that empathy is going in to Platform in the future? > Telepathy I can see, but why Empathy? Wouldn't that be an unnecessary layer > of abstraction? libempathy(-gtk), not Empathy itself. > > Is there any important issue with telepathy? > > From the previous threads, it didn't seem very likely the Gossip devs would > relicense... But that's for them to say for themselves. As I understood things this relicensing issue is about stuffs in libempathy, libempathy-gtk and empathy itself, not in telepathy. So, what are the issues with Telepathy ? :) Regards, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Unifying name for Plugins/Extensions/etc.
> Changing terminology is always a bigger undertaking than > people think it is, and the end result is usually far less > comprehensive than people anticipated. Witness: > > * We recommend using "folder" over "directory", but the > term "directory" is still very prominent. > * We changed "shade" to "roll up", but among the shaders > I know, none of them ever say "roll up". > * We recommend against using "combo box". As if. > * We recommend using "point to" instead of "hover". Yet > another losing battle. > > I could go on. In general, I think "extension" is a far > better word than "plugin". The question is, is it worth > the bound-to-partially-fail effort? (Then again, it seems > we're partially failing at maintaining the status quo.) I understand that many recommendations are only partly followed, but at least recommending "extension" over "plugin" is better than still recommending the latter. Maybe we could draw attention to the terminology recommendation by making their application a GNOME goal? Cheers, Denis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.22 module inclusion discussions heat up.
Vincent Untz wrote: > Le jeudi 20 décembre 2007, à 11:33 +0100, Luca Ferretti a écrit : >> Also note that gdm trunk now requires the "gnome-settings-daemon" >> package, recently added to svn. Note also that gnome-control-center yet >> provides a gnome-settings-daemon program, but I don't know if and how >> those are related. > > It was my understanding that both gnome-control-center and gdm would use > the same g-s-d. Any control center people having more information about > this? That's the goal, yes. I expect we'll get there for 2.22, but contrary to gdm, current control center trunk still uses the internal copy (the stand-alone g-s-d is still rather fresh). Jens ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Unifying name for Plugins/Extensions/etc.
On Thu, 2007-12-20 at 11:23 -0600, Shaun McCance wrote: > > Well, since you mention working on Evolution, I just can't > resist this. Notice the extra ">" preceding "From" at the > start of the above paragraph? IIRC, this is used to escape > a line starting with "From" in mailbox files, since "From" > is used to start a new email. Why doesn't evolution strip > this escape when it displays the message to me? Bug. http://bugzilla.gnome.org/show_bug.cgi?id=475359 > > > > Changing the term Plugin means, All the dependent user-docs, wiki > pages, > > developer-docs, FAQ pages, screenshots should also be updated. Some > > distros ship plugins as seperate RPMs/packages. So these rpm/package > > names should also be changed. IMHO it is too much of an effort with > > lesser benefits. > > Changing terminology is always a bigger undertaking than > people think it is, and the end result is usually far less > comprehensive than people anticipated. Witness: > > * We recommend using "folder" over "directory", but the > term "directory" is still very prominent. > * We changed "shade" to "roll up", but among the shaders > I know, none of them ever say "roll up". > * We recommend against using "combo box". As if. > * We recommend using "point to" instead of "hover". Yet > another losing battle. > > I could go on. In general, I think "extension" is a far > better word than "plugin". The question is, is it worth > the bound-to-partially-fail effort? No, IMHO. And you gave a much better witness list than I could have :) -- Sankar P ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
