Re: bumping clutter's external dependencies for 2.30
On Mon, 2010-03-22 at 10:28 +0100, Frederic Peters wrote: I am ok with it; especially as this will allow to run current gnome shell with the approved clutter. As for libchamplain use of Clutter, libchamplain 0.4.5 (soon to be released) shouldn't have any issues with Clutter 1.2, but that remains to be tested. Pierre-Luc 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: Appearance properties
On Tue, 2009-11-10 at 10:55 +0100, Ruben Vermeersch wrote: While I generally trust designers in their judgement and I agree that there was an icon overload, I now often feel a lack of icons. My menu usage has slowed down because I now have to read everything instead of being able to rely on icons. A good example of slowed down usage is Inkscape. Open the Path menu and you have to read most of them to actually find Division where it used to be a quickly identifiable by its icon (not to mention that the difference between Division and Exclusion was better served by an icon). Having a ton of icons is certainly not good, but is there anything that shows that having none at all is better? That's my 2 cents as a user: unless studies have generally identified a speed up in menu usage, I would think it was a move the opposite. Pierre-Luc 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: Adding a dependency to libchamplain
On Tue, 2009-11-10 at 14:08 +0100, Vincent Untz wrote: Since libchamplain is an external dep, you could actually do whatever you want, but it's great to see you asking :-) I want to make sure I am walking in the defined paths. :) As far as I can tell, this seems reasonable and it could even help a bit with accessibility. Unless anybody has an objection, I guess you could just go ahead. Yes, it is the first step to improve a11y, although this first step will not improve it. Pierre-Luc 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: Not proposing Emerillon as a Gnome module?
On Tue, 2009-10-27 at 00:08 +0100, Andre Klapper wrote: To the GNOME developers: If you have not commented yet, if there is anything to add, if you have questions to the maintainer: Please comment now. After discussing the question on IRC, the following facts have been highlighted: * It would be way too early to include Emerillon in Gnome. I entirely agree with that, I almost didn't send the previous email, but after all, how can you be too soon to not propose something? :) The idea was to start the discussion on whether we should include or not every software just because people demand it. * Applications should grow and have a little life out of Gnome before inclusion. * Adding every applications has the effect of limiting competition. I can point an exception but still their efforts seems useless because we already have such an application. Therefore, adding Emerillon would keep other people from possibly proposing better solutions. And we are not even approaching the itchy problem of removing apps. So I think the release team shouldn't even consider this email as a proposal. Thanks :) Pierre-Luc 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
Adding a dependency to libchamplain
Hi, I am slightly late for this but we'd like to add a dependency to libchamplain in the 0.6 cycle (which corresponds to 2.29/2.30 timeframe). Simon Wenner worked during his Google Summer of Code to add local rendering of maps to libchamplain. To do so, we selected a renderer that adds a little as possible dependencies to GNOME. Therefore, we selected Memphis. It depends only on Glib and Cairo. It is available under LGPL 2+. https://trac.openstreetmap.ch/trac/memphis/ Other renderer choices would have brought Earth and Moon and that wasn't considerable. Memphis has a release (0.1) as of yesterday. Simon Wenner will be maintaining it, and the local rendering branch (his actual SoC) in libchamplain will be merged soon. Memphis objects are exposed in the libchamplain API additions, meaning that making this optional at compile time would result in libchamplain having an unstable API. We'd rather go with non-optional dependency on Memphis. Thanks, Pierre-Luc 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
Not proposing Emerillon as a Gnome module?
Hi, Emerillon is a map viewer. Aiming at simple user interface, Emerillon is a powerful, extensible application. It features OpenStreetMap based maps. Use it to browse maps, search the map for places, placemark places for later quick access and more! Web Site: http://www.novopia.com/emerillon/ Over the past weeks, people have asked me over and over to propose Emerillon to be included in Gnome 2.30. While I do want to see it widely distributed and recognized, it is my understanding that in the future (based on GCDS presentations), Gnome would not accept general applications as modules. Emerillon uses Gnome technologies. Emerillon follows Gnome HIG and UI concepts. It would be a perfect fit. But is that why we should include it in Gnome? The same reasoning could apply to some of the latest additions in Gnome: should we include it in Gnome simply because it is good? AFAIR, the new www.gnome.org will make place for applications to be promoted. Such visibility could replace inclusion. A sort of blessed application set. That would be fine for Emerillon I think. On the technical side of proposing Emerillon in Gnome: * The following dependencies are not blessed Gnome dependencies: * Ethos http://git.dronelabs.com/ethos/ * librest http://moblin.org/projects/librest * Geoclue http://www.freedesktop.org/wiki/Software/GeoClue * It is already using Gnome resources (git, ftp, bugzilla, l10n) * Packages are already available for Debian, Ubuntu Karmic, Fedora Rawhide, Gentoo overlay, OpenSuse * It is 3.0 ready (Goal wise) * It is GPL 2+ with some files LGPL in case they'd be worthy of making part of a future lib. * Emerillon is quite young yet. It doesn't even have a release schedule or a stable release, but it can be made to follow Gnome's. * On the A11y side, it lags just like libchamplain does. Users will still be able to see the data in sidebars, but the map itself is opaque. * On the l10n side, thanks to the very efficient Gnome l10n teams, Emerillon is already available in 7 languages! So what does the community think? Pierre-Luc Beaudoin 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: What version of clutter should be used in 2.27/2.28?
On Wed, 2009-08-05 at 15:27 -0500, Brian Cameron wrote: The 2.27 external dependencies page still lists clutter 0.8.x as the supported version of clutter to be used with GNOME. I am pretty sure it'll be Clutter 1.0 and ClutterGtk 0.10 as the requirement for libchamplain to be accepted in Gnome 2.28 was that it had to be ported to them. Also, all new code (in gnome-games for instance) was written toward Clutter 1.0, it only make sens to ship 1.0. May be that page needs to be updated. Pierre-Luc 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: New module proposal: libdmapsharing
On Sat, 2009-06-27 at 12:30 -0400, W. Michael Petullo wrote: This would be completely satisfactory to me. If I may ask the list, what is the process for getting a project accepted into the GNOME infrastructure? Bugzilla, see To add a project to the bugzilla database in http://live.gnome.org/Bugsquad/ForMaintainers For git, see http://live.gnome.org/Git/NewRepository For the wiki, create a new page on http://live.gnome.org For the web space, see the note at the bottom of : http://projects.gnome.org/ (and mentally replace SVN by git hehe). For a mailing list, see http://live.gnome.org/NewListRequest Those are all available, even if your project is not yet an official Gnome module. Hope this helps, Pierre-Luc 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: Proposing libchamplain as an external dependancy for GNOME 2.28
Le mardi 05 mai 2009 à 11:49 +0200, Frederic Peters a écrit : Thanks for the detailed proposal, I updated the wiki page and added libchamplain to the jhbuild moduleset. I feel obliged to mention that libchamplain is a dep of eog-plugins, which has never been released yet and it not part of GNOME AFAIK. Pierre-Luc signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libchamplain as an external dependancy for GNOME 2.28
On Wed, 2009-05-06 at 10:12 +1200, John Stowers wrote: As the maintainer of osm-gps-map [1], a non-clutter mapping library with comparable features, I support libchamplain's proposal. Thanks for your support. I do not intend to add clutter support to osm-gps-map, it will remain a Gdk/Cairo only library as its intended, and my current, use of it is on embedded devices with no OpenGl support. Clutter is the new cool, so I support all ways to get this into the platform. Clutter will be supported on Maemo 5, I hope to make it useful on this platform at some point! However, looking over the libchamplain API (quickly, sorry if I mis-characterize something) I have a few comments * It is good to see you have added support for specifying map uri's. I would also like to see you support quadtree encoding, and randomization of hosts. See osm-gps-map for what I mean... I will have a look, but little code can be shared as osm-gps-map is GPL :) but if the method is generic enough method I'll see how to reproduce it. * Where is the simple API? It seems like quite a few lines of code are required to get something to show. Actually, you should be able to have something show up with: ChamplainView *view = champlain_view_new (); ChamplainViewEmbed *embed = champlain_view_embed_new (view); // put that embed in a GtkContainer That should bring a OpenStreetMap Mapnik centered at 0,0 at zoom level 0 in PUSH mode. Which are boring defaults for demos :) * What is the sqlite dependecy for? Cache? Did you feel that using a database for cache was a performance benefit? In osm-gps-map we use an in memory cache of the last N tiles + a border around what is already showing, and just load the rest of the tiles from disk. Performance of that approach is more than sufficient (on any of the embedded targets I have tried, for example) sqlite got introduced when we figured out that we'll need a place to save a 20 char string for every tiles downloaded. OpenStreetMaps send an ETag in their http headers along with the tile. You can reuse that ETag to validate your cache. The sqlite db is also used to maintain statistics about the tiles so that tiles that are the most used are not the first to be purged from the cache. Finally, it is used to determine the cache size, since all tiles are in the db anyway. -- Pierre-Luc 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
Proposing libchamplain as an external dependancy for GNOME 2.28
Hi, I would like to propose libchamplain as an external dependency to GNOME 2.28. If you never heard about this project, it is a Clutter based map widget for your application. It currently uses downloaded image tiles as map data but there is a Google Summer of Code project to render the tiles locally. More information available at: http://projects.gnome.org/libchamplain Libchamplain 0.3 (a development release) has just been released. A 0.4 stable release will be made before or in sync with GNOME 2.28. libchamplain follows Clutter numbering and API/ABI stability plan. Since it is a young project, errors in the API are corrected in the next even release until maturity is achieved and 1.0 is released. Libchamplain would not introduce any new dependencies. It currently depends on Clutter 0.8 but will be ported to Clutter 1.0 as soon as it is announced. Or depandancies include: libsoup(-gnome), cairo, sqlite and Gtk+. It doesn't depend on deprecated libraries for Gnome 3.0. libchamplain already use a lot of the GNOME infrastructure: bugzilla, mailing list, wiki and web hosting. Migrating the git repository from gitorious to git.gnome.org is planned. Releases are stored on libchamplain.pierlux.com for now but it is also planned to move to GNOME. libchamplain is already used by an EOG-plugin to display where an image has been taken. There are pending branches for Empathy (being reviewed, to be optionally available for 2.28) to display a map of where your contacts are. There is also an embryonic plug-in for F-Spot. Other non-GNOME applications are using it too but none have made releases using it so far. libchamplain has bindings for Perl, Python, C# and C++. You can find packages (or work has started) on Debian, Ubuntu, Gentoo, ArchLinux, RedHat and OpenSuse. There is a port to FreeBSD. While libchamplain isn't integrated with any of the GNOME sub-projects, it shouldn't feel alien to them either. There is little i18n to be done, no user documentation needed and I bugtriage myself. There has been some talk about A11y, but these plans will have to wait until the SoC is over. Developer documentation is very important and that's why a full API reference is available: http://libchamplain.pierlux.com/doc/unstable/ libchamplain would contribute to improve the User Experience desired in GNOME 3.0 by bringing blingy map information to the desktop. Teamed with GeoClue you get a geolocation framework to build tomorrow's location aware applications. 7 SoC projects were submitted in regard to geolocation in GNOME this year only (2 were accepted, 5 were releated directly to libchamplain). libchamplain is available under LGPL 2.1. The project started in August 2008 and has enjoyed a nice growth since. There is a good community starting to build on the IRC channel and we can count 16 different contributors to the code. See https://www.ohloh.net/p/libchamplain for more interesting stats. In this email, I hope I made my case that libchamplain could be a nice addition to the GNOME family. Best Regards, Pierre-Luc Beaudoin Maintainer of libchamplain signature.asc Description: Ceci est une partie de message numériquement signée ___ 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
2009/4/2 Vincent Untz vu...@gnome.org: - include new exciting technologies that we're starting to see used in our desktop. Some obvious examples are 3D effects (with Clutter) and geolocalization (with GeoClue and libchamplain). Thanks for mentionning libchamplain. Just in case anyone never heard of it: http://projects.gnome.org/libchamplain/ A proposed widget to display maps in your applications. Geoclue: http://www.freedesktop.org/wiki/Software/GeoClue A modular geoinformation service to make creating location-aware applications as simple as possible. With Geoclue, get your position and convert addresses into positions, with libchamplain display that information! Pierre-Luc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anti Theft Software
2009/3/23 Dr. Michael J. Chudobiak m...@avtechpulse.com: Hasanat Kazmi wrote: Geoclue and gnome-screensaver can be used, please pour in some ideas. You would probably want to modify gdm (the login manager), rather than gnome-screensaver, so that the thief doesn't have to log in to be tracked... It could even be a daemon, with Gtk+ configuration screens :) Pierre-Luc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
