Re: external dependency review
Seahorse and seahorse-plugins depend on gpgme. Adam On May 13, 2010 6:11 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Hey, once per cycle, we should go through the list of external dependencies [1], make sure they are in sync with the modulesets we use to build the release, weed out dead entries, and bump version numbers to the latest stable release (unless there is a good reason not to). I've gone through this excercise today, and propose the following changes. If any of this looks wrong, please complain. Otherwise, I'll work on getting these numbers into the list and the modulesets. If we need any changes to minimal required versions, please let me know as well. Matthias avahi no change bdb not mentioned in the moduleset at all - drop ? cairo 1.8.10 cairomm 1.8.1 clutter 1.2.8 clutter-gtk no change conduit 0.3.16 dbus 1.2.24 dbus-glib 0.86 dbus-python 0.83.1 desktop-file-utils0.16 DeviceKit-disks drop in favour of udisks ? enchant 1.6.0 expat 2.0.1 farsight2 0.0.12 fontconfig2.8.0 gamin only used by gnome-vfs - drop ? gmime 2.4.15 gnutlsno change gpgme not used by anything in moduleset - drop ? gtk-vnc no change hal used by tracker (?), suggested by others - drop ? hicolor-icon-themeno change icon-naming-utils no change intltool 0.41.1 iso-codes 3.9 libcanberra 0.24 libchamplain 0.4.4 libcolorblind no change libcroco no change llibgda 4.0.8 libgdata no change libggzdropped from gnome-games - drop ? libgpg-error 1.8 libgcrypt no change libgsf1.14.18 libical no change libmapi no change libmusicbrainzreplace by libmusicbrainz3 libnotify no change liboil0.3.17 libproxy 0.4.0 libtasn1 2.6 libxklavier no change libunique 1.1.6 libxml2 2.7.7 libxslt 1.1.26 Mono.Addins no change mozilla use xulrunner 1.9.2 ? ndesk-dbusno change ndesk-dbus-glib no change nspr 4.8.4 nss 3.12.6 opal 3.8.1 PackageKit2.30.1 pkg-configno change polkit-gtkcalled polkit-gnome now, 0.96 pulseaudiono change poppler 0.12.4 pycairo 1.8.8 ptllb 2.8.1 rarianno change shared-mime-info 0.71 sqlite3.6.23.1 startup-notification no change swfdecno change system-tool-backends 2.10.0 telepathy-glib0.11.5 telepathy-mission-control 5.4.0 tracker 0.8.6 (or 0.9.x ?) upower0.9.4 vala 0.8.1 webkitno change libatasmart 0.17 libdaemon 0.14 libnice 0.11 pixman0.18.2 samba4alpha11 [1] http://live.gnome.org/TwoPointThirtyone/ExternalDependencies ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
seahorse branched for 2.28
Seahorse has branched for 2.28. Development continues on master. Cheers, Adam Schreiber ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
seahorse-plugins branched for 2.28
seahorse-plugins has branched for 2.28 (gnome-2-28). Development continues on master. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
seahorse-plugins branched
seahorse-plugins has been branched for 2.26 (gnome-2-26) development will continue on master. There are no real development plans to report at this time. Cheers, Adam Schreiber ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git and trailing whitespace
On Tue, May 5, 2009 at 5:06 PM, Behdad Esfahbod beh...@behdad.org wrote: I personally always do a git diff before commit, and look for red-background blocks that represent trailing whitespace and fix them myself. Have your gnome terminal/bash preferences been tweaked? I did a test with git diff after adding some trailing white space and it didn't show up in red. It looked like normal terminal text. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Mon, May 4, 2009 at 11:22 AM, Alp Toker a...@nuanti.com wrote: And finally, are there any unported projects remaining? I helped port a few applications and the patches have been integrated, and you've kept things active on the Epiphany side. GIMP, DevHelp, Yelp, Epiphany, Epiphany Extensions, Blam, Conduit and externally various Mono applications, Lifearea. http://trac.webkit.org/wiki/ApplicationsGtk has a more complete list. But with so many projects, are there any we've missed? Any patches still waiting to be merged from a branch? Maintainers, please speak up! seahorse-plugins has an epiphany extension that will need to be ported from gtkmozembed to webkit. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sun, Apr 26, 2009 at 9:45 AM, Owen Taylor otay...@redhat.com wrote: Invalid foaf:mbox property should be a mailto: URL == seahorse Fixed in http://git.gnome.org/cgit/seahorse/commit/?id=897f192925404f63dd5fd60fb6b1bd6aed409a1f Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BillReminder waiting for git conversion
On Tue, Apr 21, 2009 at 8:26 AM, Og Maciel ogmac...@gnome.org wrote: I was wondering if someone could give me some feedback on how to get my BillReminder project converted to git. I was told there was a snag during the first import attempt... As most of the GNOME modules seem to have been converted, could someone take a look at it for me? Also, the special case repository of seahorse-plugins hasn't been converted yet. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: eggsmclient code syncing
On Wed, Apr 8, 2009 at 2:38 PM, Matthias Clasen matthias.cla...@gmail.com wrote: While this is not really important (it only breaks the use case that you can copy a .desktop file out of the session-state/ directory and use it to start the client in the exact same state), it might be a good idea to sync the eggsmclient code in the modules that use it for 2.26.1, which seems to be at least the following: seahorse Done in seahorse trunk. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 6, 2009 at 11:11 AM, Ted Gould t...@gould.cx wrote: On Thu, 2009-04-02 at 13:17 +0200, Vincent Untz wrote: There's one obvious question related to those potential changes: what will happen to the old way of doing things? For example, will we still make the GNOME Panel available if, for some reason, people are not immediately happy with GNOME Shell? There's no obvious answer to this, and this will have to be discussed. Some of us believe that it would be a good thing to keep providing the old elements for a limited time, to ease the migration. That being said, doing that would obviously take some development resources and slow down work on what should be the future. Not an easy choice, of course. However, it's worth noting that distributors and other community members using GNOME to build enterprise products will most certainly help maintain the GNOME 2.x shell for quite some time, and the project will support that to the greatest reasonable extent. I'm a little worried that this amounts to forking GNOME. Yeah, they'd all be in the same VCS, etc, etc, but at the end of the day there'd be two different user experiences. Currently, most distros that ship GNOME have it customized in various ways, but you can still spot a GNOME Desktop when you see one. You know it's GNOME. I'm worried that in the GNOME 3.0 world, for various technical and social reasons, that won't be the case. I'm worried that amounts to making GNOME a set of libraries and as recognizable on the Desktop of the Future(tm) as it is in a Nokia Tablet or a Garmin GPS today. I think there's a point at which owners of vintage hardware understand they will not be targeted for new development any longer. Granted there is hardware that doesn't have accelerated graphics support under GNU/Linux but let's encourage companies to add support by producing rocking software and encouraging users to buy hardware that has support already. Our focus on multiple platforms, especially on mobile ones, will keep us lean and mean so that we aren't encouraging hardware requirement creep. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, Apr 2, 2009 at 7:20 AM, Andre Klapper ak...@gmx.net wrote: a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The libglade/GtkBuilder transition is on the plan to begin at the end of this month. Currently the transition documentation is pretty pitiful. Has someone volunteered to update it/flesh it out between now and then? Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Schedule draft; Streamlining of the Platform.
On Thu, Apr 2, 2009 at 10:57 AM, Adam Schreiber sa...@clemson.edu wrote: On Thu, Apr 2, 2009 at 7:20 AM, Andre Klapper ak...@gmx.net wrote: a draft for the GNOME 2.27 2.29 schedule is now available at http://live.gnome.org/TwoPointTwentyseven . The libglade/GtkBuilder transition is on the plan to begin at the end of this month. Currently the transition documentation is pretty pitiful. Has someone volunteered to update it/flesh it out between now and then? I was refering to [1] linked from [2]. Cheers, Adam [1] http://library.gnome.org/devel/gtk/stable/gtk-migrating-GtkBuilder.html [2] http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoc- Nautilus: Add support to Google docs
On Wed, Mar 25, 2009 at 1:20 AM, Ajay ajay.kr@gmail.com wrote: 4). As native format is concern, i can download/upload in the ODT or DOC format and it will not create any issues. I would think ODT would be better on 2 fronts, encouraging freedom and avoiding any DOC import filter incorrectness. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
On Mon, Mar 23, 2009 at 5:31 AM, Hasanat Kazmi hasanatka...@gmail.com wrote: I want to make an anti thief software for Gnome. This project will be a part of GSoc That should read. This project will be proposed for GSoC. The student application window opens today and no proposals have been accepted yet. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME accepted as a Google Summer o Code project
GNOME has been accepted as a GSoC project for 2009. If you're interested in being a mentor and/or reviewing student applications, make your way to [1] and sign up. Cheers, Adam GNOME GSoC Admin [1] http://socghop.appspot.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Gnome Goals
On Wed, Feb 25, 2009 at 12:42 PM, Adam Schreiber sa...@clemson.edu wrote: In preparation for SoC, the Gnome SoC admins have decided that in order to help make decisions on proposals this year, we will be requiring links to bugs with patches the students have written be submitted with their proposals. In order to facilitate that process, we wanted to make sure there was plenty of low hanging fruit to grab. To that end, we would like to make several of the Next Gnome Goal Candidates [1] official Gnome Goals. Please look at these goals over the next week and reply with comments so we can improve the goals as needed. The proposals to be made goals are: * Update about dialogs: http://live.gnome.org/GnomeGoals/AboutDialog * distcheck: http://live.gnome.org/GnomeGoals/DistCheck * Replace gnome_help and gnome_open calls with gtk_show_uri: http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp * Remove markup in translatable messages: http://live.gnome.org/GnomeGoals/RemoveMarkupInMessages [1] http://live.gnome.org/action/login/GnomeGoals Following discussion on d-d-l and a one week comment period, Update about dialogs and Replace gnome_help and gnome_open calls have been moved to goals in progress. Cheers, Adam Schreiber ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Gnome Goals
On Wed, Feb 25, 2009 at 5:02 PM, Olav Vitters o...@bkor.dhs.org wrote: On Wed, Feb 25, 2009 at 12:42:52PM -0500, Adam Schreiber wrote: In preparation for SoC, the Gnome SoC admins have decided that in order to help make decisions on proposals this year, we will be requiring links to bugs with patches the students have written be submitted with their proposals. In order to facilitate that process, we wanted to make sure there was plenty of low hanging fruit to grab. To that end, we would like to make several of the Next Gnome Goal Candidates [1] official Gnome Goals. Please look at these goals over the next week and reply with comments so we can improve the goals as needed. The proposals to be made goals are: * Update about dialogs: http://live.gnome.org/GnomeGoals/AboutDialog I don't really see the importance. It can be added, but rather have other GNOME goals proposed/fixed first. Also potential string freeze breaker (have to wait until 2.26.0). Two out of the four would require freeze breaks to commit them at this point. However, it won't hurt to have patches in hand in a couple of months. * Remove markup in translatable messages: http://live.gnome.org/GnomeGoals/RemoveMarkupInMessages As specified in the bugreport, this depends on http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder, which isn't a GNOME goal. Further, you'd have to wait until after 2.26.0 (although is not far away). I propose the following additions: 1. http://live.gnome.org/GnomeGoals/RemoveGnomeOpenGnomeHelp 2. http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder #2 needs better instructions though. The migration instructions it links to is incomplete. Should be updated by someone who knows all details (saw in some bug that you had to specify a mime type in some file.. POFILES or something, this due to intltool) You're right #2 definitely needs better directions which is why adding it wasn't proposed. But removing the markup will have to be postponed. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Google Summer of Code 2009 Call for Ideas
Devs, Hackers, Code Monkeys, Lend us your ideas! The time is upon us once again to prepare for Google's Summer of Code. Pages have been prepared on the wiki for this event, but your ideas appear to be missing [1,2]. Students will be able to start proposing their projects on March 23, but we'd like to make sure there are plenty of projects from them to choose from and have mentors ready to volunteer their time. Please visit [2] and enter your project ideas under the New Untriaged Ideas section. A committee will be formed up later to triage the ideas prior to the opening of the proposal period. If you would like to volunteer your time to mentor but don't have a project idea, surf over and claim one. Mentoring is an awesome way to get more involved with the community and introduce someone to it. If you would like to throw your hat in the ring for the triaging or selection committees and other GSoC related tasks, pop on over to #soc-admin, join the soc-mentors-list and let one of the administrators for the program know you want to be involved in making GNOME rock. This year's administrators are Adam Schreiber, Daniel Siegel and Sandy Armstrong. Cheers, The GNOME Google Summer of Code Administrators [1] http://live.gnome.org/SummerOfCode2009 [2] http://live.gnome.org/SummerOfCode2009/Ideas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cleanup tasks
On Tue, Nov 4, 2008 at 3:47 AM, Richard Hughes [EMAIL PROTECTED] wrote: On Mon, 2008-11-03 at 12:26 -0500, Matthias Clasen wrote: - Adapt to the new single-include policy in GLib/GTK+: http://live.gnome.org/GnomeGoals/CleanupGTKIncludes Unless we get a new release of libnotify, we are going to get a ton of warnings like this: In file included from /usr/include/libnotify/notification.h:28, from /usr/include/libnotify/notify.h:27, from gpm-notify.c:50: /usr/include/gtk-2.0/gtk/gtkversion.h:28:2: error: #error Only gtk/gtk.h can be included directly. I understand it's fixed in svn. I ran into that yesterday. I was working with jhbuild check outs so I had to rerun./autogen.sh as $ PKG_CONFIGURE_PATH=/opt/gnome2/pkgconfig ./autogen.sh --prefix=/opt/gnome2/usr That took care of anything that was already fixed in svn, Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
seahorse and seahorse-plugins branched
seahorse and seahorse-plugins have been branched for 2.24. Development will continue in TRUNK. Plans for seahorse include: Continuing x509 integration Plans for seahorse-plugins includes: Updating epiphany plugin to work with webkit and gmail Adding signing-party and after-party (yet to be written) Cheers, Adam Schreiber ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed (kind of) new module
On Wed, Apr 23, 2008 at 10:12 AM, Vincent Untz [EMAIL PROTECTED] wrote: Hi Adam, Le lundi 21 avril 2008, à 13:56 -0400, Adam Schreiber a écrit : 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. Since it's a module split, there's no need to go through the new module process. I'm assuming you want seahorse-plugins to go in the desktop suite. Please just add a mention about it on http://live.gnome.org/TwoPointTwentythree/Desktop and, if possible, do the required changes in jhbuild modulesets. I've made the changes to the jhbuild modulesets and in order to make things work properly, renamed the svn repo from seahorse/plugins to seahorse/seahorse-plugins. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
On Mon, Apr 21, 2008 at 10:08 AM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Sun, 2008-04-20 at 18:59 -0500, Jason D. Clinton wrote: On Sun, Apr 20, 2008 at 6:33 PM, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: 1. It does not use Cairo; The implementation that I'm proposing will blit Cairo-rendered surfaces to textures using cluttermm. I couldn't make pretty, scalable 2D graphics without Cairo. So, they complement each other... Well, Cairo is not just a checkbox that you can check and make everyone happy; unless the entire output is Cairo, you cannot easily print the content with high quality vector graphics. You can't convert OpenGL graphics to PS or PDF... But I want to make clear that it is just a general comment I make about Clutter. In this specific case, gnome-games, it doesn't apply; I don't think people will care much about high quality printing of a chess game :) Unless you're writing a book or website where high ranking games of chess are recreated and commented on. Not that I want to do that, just a counter example. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed (kind of) new module
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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Seahorse branched for 2.22
Seahorse has been branched for 2.22. The branch can be found in gnome-2-22. Development continues in trunk. Plans for the next release involve removing dependence on libgnome and other deprecated libraries, a icon makeover and dbus interface improvements. Adam Schreiber ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Conduit for GNOME 2.24
I rather like the idea of conduit. I just set up some google calendar - evolution calendar syncs and it worked great. Since it's taking passwords and storing them, is it using a secure method like gnome-keyring? Also, to sync a second calendar on the same account it required me to add the authentication information again. The concept of persistent accounts probably needs to be introduced at some point to allow saying sync these 5 google calendars from the same acount with these matching evo ones without 5 separate conduit groups. Note: There's a proposed SoC project that wants to create persistent accounts in the About Me capplet. Cheers, Adam On Mon, Mar 31, 2008 at 6:35 AM, John Stowers [EMAIL PROTECTED] wrote: Hey Guys, On behalf of the Conduit [1] development team, I would like to propose Conduit for inclusion in GNOME 2.24 desktop suite. * Purpose: Conduit is a synchronization architecture for the GNOME desktop. It provides an intuitive GUI for synchronizing things and a DBus interface for external applications to do the same. * Justification: Our immediate benefits to the GNOME desktop are very well supported multi-site photo/upload and sync (from Fspot, eog and folder), tomboy synchronization to a number of places, file/folder sync (including intuitive removable volume support, and the ability to do all these things peer to peer. We also support many more than these listed, however at the cost of additional dependencies. See below for clarification. In implementing these diverse backends, I am confident our abstractions are sound, and we will be able to grow with the GNOME desktop and support synchronization with any device you can imagine. Applications using our DBus interface will get these benefits at no extra cost. * Dependencies: pygtk, gnomevfs, gnome-python-desktop 2.22, python-gtkmozembed, [NEW] pygoocanvas 0.9.0, [NEW] goocanvas 0.9.0, [NEW] Python 2.5 (for network sync support) * Resource usage: GNOME FTP, GNOME SVN, GNOME bugzilla, translations * Adoption: Packaged for all major distros, expressions of interest for more extensive use by Ubuntu [2], Mandriva [3] and Suse [4] * Gnome-ness: * We support Tomboy note sync and Fspot photo sync. In both cases we were instrumental in the development of DBus interfaces in the respective applications * We support evolution-data-server through the new python evolution bindings we contributed to GNOME last cycle. * Our file/folder sync uses gnomevfs * [WIP] We have developed an eog plugin for photo upload to a number of sites, directly from within the application * [WIP] We have developed a nautilus plugin to enable easy file/folder sync * Additional Information: Our focus for this cycle is the support of mobile devices through both libsyncml [5] and (python)gammu [6]. This will obviously introduce additional dependencies on these libraries. We are looking forward to, and will be adding support for GIO/GVFS as soon as it is available to be used from Python. We also support the following services although support for them comes at the cost of additional dependencies * Google contacts, [WIP] calendar, [WIP] documents (requires python-gdata [7]) * Backpackit.com (require python backpack [8]) * Facebook photos (requires pyfacebook [9]) * iPod photos (requires libgpod [10]) Conduit is translated into a number of languages, and features user help documentation. However both of these are WIP. We have had firm expressions of interest from Tomboy and Cheese about using conduit for Sync and Export respectively. Conduits presence in the desktop set would make their dependency on us for this functionality more palatable. Looking forward to hearing your thoughts John Stowers [1] http://www.conduit-project.org [2] https://wiki.ubuntu.com/SyncIntegration [3] http://wiki.mandriva.com/en/2008.1_What%27s_New [4] http://www.novell.com/brainshare/general-sessions-2008.html [5] http://libsyncml.opensync.org/ [6] http://cihar.com/gammu/python/ [7] http://code.google.com/p/gdata-python-client/ [8] http://bleu.west.spy.net/~dustin/projects/backpack/ [9] http://code.google.com/p/pyfacebook/ [10] http://www.gtkpod.org/libgpod.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME SoC Call for Ideas
GNOME is joining Google for the fourth annual Summer of Code program. We need your ideas and expertise as mentors to make this our best year yet and bring more awesome Free Software into existence. This year, we would like to see projects about the integration between various GNOME modules. Other types of projects are of course also welcome, like new programs, bling, etc. As long as there are mentors available, we are also taking SoC proposals for GNOME related technologies and projects such as GStreamer, Avahi, Beagle, Bluez and Telepathy so don't feel left out if your favorite project isn't part of GNOME or just isn't yet. We will also be collaborating with KDE to mentor freedesktop.org related projects. Please submit your ideas and volunteer to mentor on our wiki at http://live.gnome.org/SummerOfCode2008/Ideas. Ideas that are posted will be triaged by the GNOME SoC Admins based on mentor support and feasibility. Note that the student submission deadline is March 31st so get your great ideas up so students will have plenty of time to help our favorite desktop keep rocking! -- GNOME Summer of Code Admins ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy replacement
On Thu, Feb 21, 2008 at 9:07 PM, Mark Fink [EMAIL PROTECTED] wrote: On Thu, Feb 21, 2008 at 8:55 PM, Curtis Hovey [EMAIL PROTECTED] wrote: On Thu, 2008-02-21 at 20:41 -0500, Mark Fink wrote: I've just started a replacement for Tomboy. I think it (or another notes program if there already is one) should replace Tomboy ASAP in the GNOME desktop because Tomboy is poisoning GNOME distributions like Red Hat and Ubuntu with it's Microsoft patented MONO dependency crap as you can read about on http://boycottnovell.com/2008/02/15/mono-contamination-in-ubuntu/ I've never written a program before so I also need some help. Also I need a place to put it on the web. I've already gotten it so you can type stuff in a text field, so it already almost has all the functionality you need in a note taking program. If you don't want to run Tomboy, just add sticky notes to your panel--it predates Tomboy. Tomboy is popular because it rocks, not because it is Mono-based, or because distro chose to make it the default app over sticky notes (I'm not certain it is a default app in Ubuntu or Fedora). What you are setting out to do is create an extensible wiki-like gui editor. Good luck. Then sticky notes needs to replace Tomboy as the official GNOME notes program because it is stupid to allow MONO into GNOME. MONO programs CANNOT be allowed to be in GNOME! This only helps M$ destroy Linux! Don't you see!? You are just helping Microvell poison Linux so that they can control it and/or attack it with patents. Anyone who doesn't see this is a retard. Mark, That use of language is discouraged around here. If you would like to try a more civil tone, I'm sure people would be much more responsive. Calling the audience you wish to persuade is generally not a wise tactic. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing gnome-keyring-manager from desktop distribution
On Dec 13, 2007 6:00 AM, Fernando Herrera [EMAIL PROTECTED] wrote: Does Seahorse support all the g-k-m features (like editing ACLs, etc...). That would be the only problem I can see about removing g-k-m: usually distros don't like to remove features/funtionalities (i.e.: regressions!). Editing the R, W, and Delete properties was just checked in. I believe all other functionality is present. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About SSL Trick or Treat Dialogs
On Dec 5, 2007 9:51 AM, Owen Taylor [EMAIL PROTECTED] wrote: But that still leaves a basic premise here that I object to: that a self-signed certificate is worth something. Roughly speaking, the networking world is divided into two pieces: Maybe to alleviate some of the disharmony of self-signed certs with GNOME sites, the GNOME Foundation could run its own CA which sends a cert to each foundation member and issues certs to the GNOME family of sites as well. At that point Epiphany could install the GNOME Foundation CA's signing cert by default. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About SSL Trick or Treat Dialogs
On Dec 4, 2007 11:35 AM, Owen Taylor [EMAIL PROTECTED] wrote: On Tue, 2007-12-04 at 14:29 +, Stef Walter wrote: Dan Winship got me thinking about the unable to verify identify of this certificate dialogs we see in browsers when using self-signed or otherwise unverifiable certificates. I'm sure others have come to this conclusion: These are some of the most useless dialogs that exist, a major cop out. They basically asking the user something they can almost never possibly know. I'd like to propose [1] that we do away with these dialogs in GNOME. In my opinion if we cannot verify the certificate, then we should simply not show the UI elements that indicate a secure connection. We should just act as if the connection is like any other normal connection. Unfortunately, one of the main UI elements that indicate a secure connection is the https:// URL in the URL bar. Are you proposing to disguise that as well? Maybe just not shade it yellow. It will still be running over ssl like Stef said, just not securely. Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Web links integration in applications: bugs, translations, help...
On Nov 27, 2007 2:33 PM, Loïc Minier [EMAIL PROTECTED] wrote: I guess the problem of receiving can't send mail bug reports might be helped a little by having two different entries in Help; Ubuntu currently has Report a Problem (it's report a bug in French though), and Get help online (this points to the community support portal). If there were a Get help online menu item, it might be better to have them enter a support question that automatically searches the linked forum so that they are presented with a possible set of answers. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: strawman (Was Re: build systems)
On Nov 11, 2007 10:52 PM, Jeff Waugh [EMAIL PROTECTED] wrote: It would be great to release a suite of GNOME apps for Windows (maybe even OS X) along with our tarballs every six months -- to grow our audience and potential developer pool -- with the least amount of work possible. :-) While I agree this would increase the audience, I wonder about the feasibility. * Do enough maintainers/developers still run windows systems and have Windows developement experience? * Would this require a new pool of developers to be aquired before such a release? * Would this introduce new bugs that would be difficult to track down and kill without access to a Windows development environment? * Would there be an active group, similar perhaps to gnome-love (windows-love?) that would patrol windows related bugs? * There would probably have to be an easy and somewhat trusted method of installing binary packages for Windows. (Winbuntu?) Enjoy the thought experiment. :-P Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Seahorse Branched for GNOME 2.20
Stable releases will be made from branches/gnome-2-20. Development will continue in head. Plans for this developement cycle can be read at http://live.gnome.org/RoadMap/Seahorse. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status of gnome-keyring-manager for 2.22
On 9/23/07, Vincent Untz [EMAIL PROTECTED] wrote: Can we do this for 2.22? Is there any feature in gnome-keyring-manager that is not in seahorse? If yes, are those features important for our users? Finding time to finish implementing g-k-m features will largely depend on how my thesis is going. I think access control lists are the last important feature to migrate before deprecating g-k-m. I'm not sure how many users actively control which applications can read, write or delete each gnome-keyring secret. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Distributed SCM in Gnome (Was: Git vs SVN (was: Can we improve things?))
On 9/11/07, Vincent Untz [EMAIL PROTECTED] wrote: Hrm. I'm not sure that this statement (_very_ strong general opinion) is true. Some people feel this is the way to go, and some are pushing very hard for this, but there are also people who don't really care and wonder if we need this. As a maintainer for a smaller project where there are only 2 regular contributors (who are both maintainers), I count myself in the Why would we need this for our project category?. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/17/07, Claudio Saavedra [EMAIL PROTECTED] wrote: The error message area widget used by EOG (trunk), gedit, epiphany, and probably more applications, is other place where I'd like to see more consistency. Maybe this is something worth to be part of GTK+. We've discussed this widget needing to be a more generic curtain widget and possibly have some composited bling[1,2]. Cheers, Adam [1] http://sadamclemson.blogspot.com/2007/03/gedit-message-area.html [2] http://sadamclemson.blogspot.com/2007/03/message-area-redux.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFGTI0JjU1oaHEI4wgRAkP5AJ9K2ZQ9RWLfVciYQ459aFax9pXSUwCfRbrD Ysoop+51vB9525ExDZtgwbM= =yejc -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: are gnome-display-properties and gnome-keyring-manager going to be replaced?
On 3/19/07, David Prieto [EMAIL PROTECTED] wrote: I read in http://www.gnome.org/start/2.18/notes/C/ that seahorse is a part of Gnome now. Since it can handle keyrings, are there plans to have it replace gnome-keyring-manager? Will they coexist, or is seahorse just not gonna be installed by default? http://mail.gnome.org/archives/desktop-devel-list/2007-March/msg00120.html Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
On 2/6/07, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: * In Short: Wasabi is new project with the goal of creating a unified, platform independent, specification and api for desktop search engines (and later metadata services). We have worked together with several search-projects and now have a proposal ready for public evaluation. In short: we need feedback from application developers - that means you. Does Wasabi have any impact on data source providers? For instance, if the Seahorse Project wants to have GPG key data or other encryption related items show up in Beagle's results, we'd have to write a query based data source specifically for Beagle. Likewise, we'd have to write another one for tracker in which ever terminology they use or for whichever the indexing back end du jour is. Can or should Wasabi include a standard method to make data sources available and publish them with some sort of standard DBus interface? I ask this because after reading the specs it seems like Wasabi just sits between an indexer and a view of a users choice. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing Wasabi - Unifying Desktop Search - feedback needed
On 2/6/07, Mikkel Kamstrup Erlandsen [EMAIL PROTECTED] wrote: 1) You want your keys (and metadata) *indexed*. This is not a part of the Wasabi search spec (currently). I honestly don't know how feasible it is to have shared filters/extractors between engines - because that is what you would really need to avoid having to code up against the favored service du jour. I can only say that from an app developers point of view it would be really cool to only have to write on way to index the data. I think this approach would be my preferred way to implement it. There would be some kind of standard Wasabi source directory where different projects could place a .desktop style file (similar to DBus service publication) that points to their widget that implements the data source API and indicates what kind of data it provides including whether or not it should be further aggregated with First Class Objects(tm) like contacts, music or listed with other documents. There should probably be a way to install/specify new First Class Objects(tm) (fields, icon, etc.). 2) You actually want to *store* the keys right inside the service. This can fx be done with Tracker right now actually. In a Wasabi scope this would rely on the next-on-slate metadata spec+api. In the metadata api you would have methods to store metadata on arbitrary objects. Would this be a push or pull method of loading data into an indexer? How easy would it be to tell the indexer there's an updated portion of data and which set it is? Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: An idea about a webcam....
On 2/2/07, Jason Brower [EMAIL PROTECTED] wrote: I wanted a unified way of communicating with video with as many people in as many technologies as possible. I found this very hard so came to the idea of working around technology that almost everyone has on their computers. This came to 2 things A browser and JAVA. With that I was able to create a webcam web-page and people where able to see me without any problem. I can talk with my family and they can see me. Even a novice can use my webcam. They just click with a mouse. Of course there are better technologies. But google video has sucky video, we still use it because it is so easy to use. I use a combination of the following...(with notes) Camserv Works rather well considering it hasn't been developed sinces 2003. Very well built and able to do exactly what I want. Apache I am sure I could use something smaller and more streamlined for this use. All it has to do is provide at most maybe five connections and run under a designated port. CamServFront This is a Python, GTK, Glade Program I have made this last week that is a simple front end to camserv. It provides a nice way to turn of and on the cam and adjust a few settings to meet the needs of the you and the client. I'm not sure that all this is necessary. If the drivers are available, HAL should attach the webcam to /dev/videoX and then gstreamer should be able to attach the video source to anything on the desktop that needs it. At that point, the messenger clients simply need to handle the various protocol's quirks with respect to sending video. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: An idea about a webcam....
On 2/4/07, Jason Brower [EMAIL PROTECTED] wrote: On Sun, 2007-02-04 at 09:18 -0500, Adam Schreiber wrote: I'm not sure that all this is necessary. If the drivers are available, HAL should attach the webcam to /dev/videoX and then gstreamer should be able to attach the video source to anything on the desktop that needs it. At that point, the messenger clients simply need to handle the various protocol's quirks with respect to sending video. But it isn't done... I personally don't have the programming knowledge to use HAL and Gstreamer. Though I am sure I could learn. This is the first steps of making this work. Adn most messege programers have no intend on creating a video part for their clients. They jsut want the text. And let someone else do the video. That is why I am doing this. I'm not sure where your assertion that most messege programers have no intend[sic] on creating a video part for their clients comes from. While the merge has been delayed, I believe the plans for gaim still include adding the code from gaim-vv after 2.0 is finally released. While this is a solution for one client, the code for individual protocols should probably be pushed lower into libraries that all of the clients can use. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: recommended D-Bus version for GNOME releases
On 1/22/07, Peter Gordon [EMAIL PROTECTED] wrote: My guess at the moment is that it's probably the RSS feed integration extension, as that is the only one I can think of offhand that actively uses D-Bus stuff. The seahorse epiphany extension also uses dbus if you have it installed. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: seahorse
On 1/11/07, Vincent Untz [EMAIL PROTECTED] wrote: As to the seahorse/gnome-keyring-manager question: it might really be confusing to have both of them in the long term. Is removing gnome-keyring-manager a goal we can set for 2.20? I would need to talk with Nate about it to say something for certain, but we can certainly work on implementing a good bit of the remaining gnome-keyring functionality. I'll add that to my summer To Do list. Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: seahorse
On 1/8/07, Vincent Untz [EMAIL PROTECTED] wrote: You can learn about seahorse here: http://www.gnome.org/projects/seahorse/ +1 from me, but I'm biased as I'm a developer. However, I would like to note that several of the concerns posted when Seahorse was first proposed have been addressed. Bastien Nocera and Ross Burton wanted to see a web browser plugin for text fields quote Wouldn't a better integration be a web browser plugin, that allows people to encrypt what's in a text field? Agreed. That would be a great Epiphany extension in the context menu of a text entry. /quote Such a plugin now exists in plugins/epiphany. It provides context menu support for encryption operations in text fields and on general pages. Wouter Bolsterlee suggested integration with gnome-keyring. gnome-keyring items are now loaded on the passwords tab of the seahorse application. There are a few outstanding requests for things by d-d-l members for things like evolution integration and x.509 certs that we weren't able to get to in this cycle. However, the architecture is in place to easily add these extensions at a future date. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Software installation using gnome
On 1/3/07, Chris Vaughan [EMAIL PROTECTED] wrote: What I am trying to do is create an installer for a software tool I have been developing. I would like something that sounds relatively simple to happen. For every user that is created on the system i would like 2 icons which are shortcuts to the application to appear on their desktop. So if a new user is created he gets 2 default icons every time. Does anyone know of a clean and easy way to do this? In GNOME, icons or launchers on the desktop are simply .desktop files placed in the ~/Desktop directory. Drag an item out of the applications menu to see the format of the file or look at freedesktop.org. Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+ Printing backend HowTo
On 12/9/06, Ghee Teo [EMAIL PROTECTED] wrote: I also welcome suggestion as to where I can post this document once it is completed :) live.gnome.org is probably a good place since the material at developer.gnome.org is being migrated there. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for Seahorse inclusion in GNOME 2.18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ross Burton wrote: On Sun, 2006-09-10 at 12:55 +0100, Bastien Nocera wrote: The panel applet was created because a lot of my friends indicated that a barrier to using encryption for their email was that they use web mail a significant amount of the time. The panel applet allows the user to copy text perform an encryption operation on it and paste the new text to a field or in the case of reading mail display the text in a window via a preference setting. In any case the applet has to be added by a Wouldn't a better integration be a web browser plugin, that allows people to encrypt what's in a text field? Agreed. That would be a great Epiphany extension in the context menu of a text entry. Such an extension now exists in HEAD. 2006-09-17 Adam Schreiber [EMAIL PROTECTED] * configure.in: * libcryptui/cryptui.h: * m4/epiphany.m4(added): * m4/gecko.m4(added): * plugins/Makefile.am: * plugins/epiphany(added): * plugins/epiphany/Makefile.am(added): * plugins/epiphany/eel-gconf-extensions.h(added): * plugins/epiphany/ephy-debug.h(added): * plugins/epiphany/seahorse-extension.c(added): * plugins/epiphany/seahorse-extension.h(added): * plugins/epiphany/seahorse.c(added): * plugins/epiphany/seahorse.ephy-extension.in.in(added): * plugins/epiphany/mozilla/Makefile.am(added): * plugins/epiphany/mozilla/mozilla-helper.cpp(added): * plugins/epiphany/mozilla/mozilla-helper.h(added): Initial commit of Epiphany plugin. Allows encryption of text fields. #355386. Epiphany extension code by Jean-François Rameau(jfr). See also: http://sadamclemson.blogspot.com/2006/09/epiphany-goodness.html Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFDbHJjU1oaHEI4wgRAt8WAJ0RGl92do7d2huGJLYgVleJhWQL1gCfQhHm 2B61TyjIwsUrjqAI1m96Sfk= =SSXw -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nine Months in Six Months
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BJörn Lindqvist wrote: To me, that makes sense. An untranslated string is just as annoying as a frequently segfaulting program. So lets treat the problems the same. Code that changes behaviour shouldn't be committed unless the documentation is updated. User visible strings shouldn't be changed unless the translations are updated. Something like that? I agree with the first part because updating the C locale documentation should be doable by any programmer capable of changing the behavior of the documented program. However, any programmer doesn't have the capability of updating all of the translations. I think that requiring translated strings before a check-in then becomes an onerous task. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAjoqjU1oaHEI4wgRAu0CAJ9Bm7qPH9ASsHQKqIl+/BGp6jycYACg3Lx4 yY9XL5Ce+rIyZo+taIQvfRY= =3scE -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Global keybindings in GNOME
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Clasen wrote: Alternatively, we could punt to the users by allowing them to set up custom keybindings in the keybinding capplet, which of course requires them to know the appropriate commandline magic for e.g. adding a tomboy note... I like the idea of pushing it into the keybinding capplet. Could the trouble of knowing the command line magic be handled by some schema installed by the application in question? That way to the user it would appear as: |Create New Note: | ctrl-*| or some such. Adam - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4OqXjU1oaHEI4wgRAqIGAKCjRMyze+AmrM47GAOS2Zt4sGSiMQCdGdq4 3x3BX3j9tP2ZD9zFzxAECzE= =vxWu -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Deskbar Applet, NewStuffManager, 2.16, Installing New Plug-Ins, AutoUpdate, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason D. Clinton wrote: On Wed, 2006-08-02 at 18:31 +0100, Mike Hearn wrote: Is it really that hard to check a digital signature? I'd have thought there'd be APIs in Python/C/Mono that make this trivial by now. And that's all you have to do to protect against the files are changed by evil people case. gpg has well documented exit codes which can be suitably used for this. It's not high performance to invoke lots of sub-processes if you have a lot of files you are verifying, but it get's the job done. Seahorse CVS HEAD contains a modification to how detached signatures are verified in nautilus. The new program is called seahorse-tool, moving the functionality out of seahorse proper. It could be modified if it doesn't already return adequate exit codes. It might also be possible to add a VerifyFile D-Bus method that takes a URL and a buffer containing the detached signature and returns a flag code. Adam - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE0PLMjU1oaHEI4wgRArZLAKDae3gPeyZiWs9mbSjnkbLvqcyurACgzj0c PwzJT3hBr30gQjISpG54qmM= =p0i4 -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2 infinity and beyond [was Re: Tango and 2.16]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Elijah Newren wrote: I have been writing 'Gnome' correctly all along. It's you who writes it wrong. ;-) Not according to the many graphics at http://gnome.org. It should correctly be capitalized since it stands for GNU Network Object Model Environment. Adam - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER+TNjU1oaHEI4wgRAld+AKCFMa3RrZxSAC0HTZl7Sxbo5Yt5PACg0vGA 6Qz6+4Zuch4V2mzhbNWgckk= =bxCU -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Supporting po/LINGUAS in 2.16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Behdad Esfahbod wrote: Completely agreed. As someone who wrote one of the current goals, I was a bit scared by how the goal went live with review from only three people, and it could have been flawed seriously. In this case (AppIcons) it probably is not, but the PoLinguas raised the internal this-is-a-nasty-hack signal of me too. It indeed works *for now*, but I too think that we should not spent this massive effort on things we know should change soon. Behdad, While we're on the topic of the AppIcon goal, could you respond to the question raised earlier today? Can I ask for a little bit of clarification on this goal? Is this only supposed to apply to the application icon? What about apps that provide different icons (toolbar icons, etc.)? Are these expected to still be installed to $datadir/pixmaps? or should they follow the same pattern described for app icons? Jonner Thanks, Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net http://live.gnome.org/Seahorse -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3rc2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEOvOsjU1oaHEI4wgRAlNTAKCd4SbeSiHWY09GLCOJS7/DmSe0yACgvIS1 ibOUnq/sfS/CEObE3kO3WIo= =UT4q -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mime-type globbing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: I'd like to add a program which can be launched from the right-click menu, similar to Create Archive or Encrypt How do you add a mime type for *ANY* kind of file? All the examples I've seen have a line like this: mime-type type=application/bluefish-project glob pattern=*.bfproject/ I want to change it to glob pattern=*/, but this doesn't seem to work. Take a look at seahorse_nautilus_get_file_items() in http://cvs.gnome.org/viewcvs/seahorse/plugins/nautilus-ext/seahorse-nautilus.c?view=markup There's some code for doing various things based on mime types there. Adam Schreiber - -- Why isn't all of your email protected? http://gnupg.org http://enigmail.mozdev.org http://seahorse.sourceforge.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDys3rjU1oaHEI4wgRAgDtAJ4tXSAINEZyl4PHEYjP9YafgH3P3gCfUFAu r+SevOD0jMShgp/dwKsC26Y= =+EGE -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
