Re: Management Tools used by Gnome project
On Sat, 2013-04-13 at 04:26 +0300, אנטולי קרסנר wrote: On ו', 2013-04-12 at 18:05 -0700, Germán Póo-Caamaño wrote: On Sat, 2013-04-13 at 03:59 +0300, אנטולי קרסנר wrote: Hello everybody, I'm gathering information about how free software projects are managed and I'll be thankful if someone can explain briefly which technologies are used by Gnome. I think that Producing Open Source Software: How to run a successful Free Software project by Karl Fogel is a good starting point. http://producingoss.com/ Thanks, it is very useful indeed. But I'd like to hear some more: How and where is the release cycle managed? How does cross-module communication and management happen? also have a look at my thesis which covers most of your questions: http://www.dgsiegel.net/foss-development-processes daniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F encrypted email preferred signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Musings on the contacts user experience
On Fri, 2011-04-29 at 16:13 +0200, Alexander Larsson wrote: On Fri, 2011-04-29 at 13:19 +0100, Allan Day wrote: In general, then, my current position is that, despite it not being the primary way in which people will access messaging, we do still need a dedicated contacts app. I am open to being convinced that an integrated IM/contacts app would work, but I would want to see the 3 issues I've identified above resolved. to me it seems that it is not a question of what, but more like where. to me personally it doesn't matter if i can access my contacts through evolution, a dedicated app or a gnome-shell panel. it is more important to access my contacts where ever i am, be it my laptop, my computer at home, my phone or an internet cafe. an amazing thing would be to have them stored and synchronised (for example with couchdb) on my computer, my phone and on contacts.gnome.org as a web-app. as long as all the data stays accessible and synchronised from all places the ui and user experience is more a question of what the device and input methods can allow me on that device. daniel Yeah, this, and the fact that Gnome 3.0, with gnome-shell and the non-spatial nautilus is very much going in the app-centric direction convinces me that you are right. That means we should probably not have the people tab, which is a good thing too as i kinda agree with matthias fear of piling all sorts of cruft into overview tabs. Also, we should probably not allow contacts on the dash. Until I'm convinced otherwise, this is my vision for how the different GUI parts of our contacts framework, then: * An add contacts dialog that can be used by different applications. This would, for instance, provide a graphical means to easily add recent or favourite contacts to an email. This GUI would probably be similar to the contacts app, and would probably share the same code base. * A dedicated contacts app for when you need it. * Contacts search (but no contacts tab) in the shell overview, which will provide a quick way to initiate conversations. * In the future - a conversation focused IM app, and possibly even a conversation focused email app Yes, I like this. The conversation focused IM app is especially nice, as it makes the difference between the contacts app and the chat app much more obvious. It also means that some of the concept design on the contacts app needs a bit of rethinking, as they focus quite a bit on initiating IM communication (via shortcuts on the main window, etc). Additionally I'd like to have an easy-to-integrate widget that lets apps pop up contact information on hover/click on any address shown in the ui (like all visible email addresses in evo). That would show contact info, current im status, last tweet, etc. My main fears in a setup like this is: * Conceptually a chat app needs to be running all the time when you're online (as you might get a message), but generally you don't want to see it all the time. With us not having a good solution to minimize, and not liking minimize-to-systray-icon we don't have a good way to represent this running in background state. The one way to fit this into the shell design is to just put the IM window on some other desktop, but I think that might still be a bit too visible. * I fear as we add more kinds of hits into the overview search it will eventually become useless (giving too many hits). We need to be consious about this and limit the number for items we search. For instance, if we search in all files on your system its likely that almost all words you type matches a bunch of files, making the typeahead to launch an app feature less useful. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
another very important point is synchronisation. together with salomon sickert we thought about how to solve this problem. basically we came up with the idea of a self-replicating backend, like couchdb. if we then could add support to the contact apps of other computer/devices like a n900 or android, we would get synchronisation and conflict management for free. then there is also the idea of having a webservice for the gnome contacts app, where you can access your contacts over the internet. we are very interested in your opinions about this! daniel On Tue, 2011-04-19 at 10:27 +0200, Alexander Larsson wrote: On Mon, 2011-04-18 at 09:29 -0700, Travis Reitter wrote: http://lists.freedesktop.org/archives/telepathy/2011-March/005369.html [4] This seems to talk about querying contacts from slow social web services. Additionally if this is to be our story in evolution too we need to be able to efficiently handle ldap contacts, which are really important for enterprise deployments of email. This also needs a live search approach, because we can't rely on a local copy of all ldap data. -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: On 19 April 2011 11:27, Alexander Larsson al...@redhat.com wrote: On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: another very important point is synchronisation. together with salomon sickert we thought about how to solve this problem. basically we came up with the idea of a self-replicating backend, like couchdb. if we then could add support to the contact apps of other computer/devices like a n900 or android, we would get synchronisation and conflict management for free. then there is also the idea of having a webservice for the gnome contacts app, where you can access your contacts over the internet. we are very interested in your opinions about this! I don't know really. Synchronization is a tricky subject, with complex protocols and risk for merge problems. Its almost always a source of weird problems. I don't think we want to have synchronization as some core part of the design. On the other hand, its important that there is some level of support for synchronizing contacts with e.g. phones. So, I guess we need to think about where it fits in. If you start to talk about synchronisation, please talk to Patrick Ohly patrick.o...@gmx.de. He maintains SyncEvolution that is probably the only working PIM syncing tool that I know of, and it's totally non-trivial. you mean kinda-working? ;) indeed, synchronisation with todays devices over syncml is extremely hard. i really don't want that in the core design neither. i was more thinking about a backend like couchdb, which has a synchronisation solution already built in. ubuntu does that for example with evolution and ubuntu one. daniel Ross -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
and right here i think we shouldn't base on bad formats (vcard) and sucking protocols (syncml). using json is a much better option. see for example the desktopcouch specification for contacts http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact On Tue, 2011-04-19 at 14:11 +0300, Jens Georg wrote: Can we make synchronisation not suck? Achieving good and non-breaking sync is really hard and sometimes next to impossible, given that the formats used in PIM sync (vCard, I'm looking at you) are really weird and broadly interpreted differently by different devices out there (Like e.g. the intepretation of the FN field) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
On Tue, 2011-04-19 at 13:21 +0200, Rodrigo Moya wrote: On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote: On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote: On 19 April 2011 11:27, Alexander Larsson al...@redhat.com wrote: On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote: another very important point is synchronisation. together with salomon sickert we thought about how to solve this problem. basically we came up with the idea of a self-replicating backend, like couchdb. if we then could add support to the contact apps of other computer/devices like a n900 or android, we would get synchronisation and conflict management for free. then there is also the idea of having a webservice for the gnome contacts app, where you can access your contacts over the internet. we are very interested in your opinions about this! I don't know really. Synchronization is a tricky subject, with complex protocols and risk for merge problems. Its almost always a source of weird problems. I don't think we want to have synchronization as some core part of the design. On the other hand, its important that there is some level of support for synchronizing contacts with e.g. phones. So, I guess we need to think about where it fits in. If you start to talk about synchronisation, please talk to Patrick Ohly patrick.o...@gmx.de. He maintains SyncEvolution that is probably the only working PIM syncing tool that I know of, and it's totally non-trivial. you mean kinda-working? ;) indeed, synchronisation with todays devices over syncml is extremely hard. i really don't want that in the core design neither. i was more thinking about a backend like couchdb, which has a synchronisation solution already built in. ubuntu does that for example with evolution and ubuntu one. evolution-couchdb provides that already, so if folks has an e-d-s backend, it should already be available. Also, replication/conflict management in couchdb is quite good indeed The problem with this is that for couchdb to be really useful, the best thing is to run a local instance that then syncs to a remote instance, and while it's entirely possible (as you said, Ubuntu One does it) some people showed their concerns when I proposed couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a local instance of couchdb. But yes, should be perfectly possible. Maybe we should revisit the discussion again? imho couchdb is just one way of many, but certainyl the right direction. you guys showed, that it is possible to have a working synchronisation quite easily with couchdb. so yes, let's re-evaluate possible backends? -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
On Tue, 2011-04-19 at 14:38 +0300, Jens Georg wrote: On Tue, 2011-04-19 at 13:21 +0200, daniel g. siegel wrote: and right here i think we shouldn't base on bad formats (vcard) and sucking protocols (syncml). using json is a much better option. Well as soon as you talk about sync, someone says device. And devices come with vCard. there is no problem in providing an import function for vcards see for example the desktopcouch specification for contacts http://www.freedesktop.org/wiki/Specifications/desktopcouch/contact Looking at this - do you realise how much very much that matches the vCard spec? That's basically a vCard translated to JSON. Personally, I'd rather have a root canal treatment than couch db hammering my computer, but I like the auto-replication idea. you are right. but i just wanted to show this as an example. personally i am not totally happy with the specification, as there are for example legacy items, like pager and others. but it is a good start. -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: ThreePointOne: Contacts
what do you mean by 'backends'? Backends of what? As I said, evolution-couchdb already provides an e-d-s backend for accessing contacts in CouchDB databases, so IMO, what we need is: so my question is basically: why do we need e-d-s if we have our contacts in couchdb? -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: how to apply to be Summer of Code mentor?
On Wed, 2011-04-06 at 17:26 -0300, Juan Pablo Ugarte wrote: On Wed, 2011-04-06 at 09:27 +0200, Johannes Schmid wrote: Hi Adam! Am Dienstag, den 05.04.2011, 17:08 -0700 schrieb Adam Dingle: A couple of weeks ago, Vincent wrote: Good news: GNOME has been accepted as a mentoring organization for GSoC 2011, woo :-) If you want to be a mentor, please apply with the following form: http://www.google-melange.com/gsoc/mentor/request/google/gsoc2011/gnome That link has been broken for a while now. I just looked around a bit on both the Google and GNOME summer of code pages, but couldn't immediately find answers to the following: See http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2011 From GNOME's mentoring organization page http://www.google-melange.com/gsoc/org/google/gsoc2011/gnome the link to register as a mentor is http://www.google-melange.com/gsoc/profile/mentor/google/gsoc2011?org=gnome BTW what do mentors have to do donate the mentoring money to GNOME? nothing. this will be handled automatically by the soc admins and the gnome foundations. daniel greets Juan Pablo Regards, Johannes ___ 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 -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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 master.gnome.org
sounds great! i guess http://live.gnome.org/MaintainersCorner/Releasing should be updated too. is there a wiki page explaining the new ftpadmin script? daniel On Sat, 2011-03-26 at 19:15 +0100, Olav Vitters wrote: Read this if you make use of install-module on master.gnome.org. I've made 2 changes: 1. Switched machines SSH will complain about this. Just edit ~/.ssh/known_hosts to make these warnings go away. The new SSH key fingerprints are: RSA: 00:b6:71:1a:a6:c8:43:30:6c:08:9d:8e:01:43:24:ef DSA: 8b:c6:f7:7b:cb:ff:77:6a:7b:33:d7:27:e7:0a:f3:85 2. New script to install tarballs Usage: ftpadmin install TARBALL [TARBALL ...] Please add a description (not just shortdesc) to your DOAP file! See: http://live.gnome.org/MaintainersCorner#doap Regarding the new 'ftpadmin' script: - It does all kinds of consistency checks on the tarball e.g. everything in one directory, no extra data in the tarball (gtk+-2.12.6.tar.bz2 is twice as big as it should be), etc - NEWS/ChangeLog diffs against the previous version will work even if the it is 2.91.93 vs 3.0.0 - It uses information from the DOAP file See http://live.gnome.org/MaintainersCorner#doap Due to this, you could theoretically use different names for everything: git module: foo tarball: bar bugzilla product: baz Please do not do this though! Tarball names are determined from: download-page rdf:resource=http://download.gnome.org/sources/gnome-shell/; / (MUST be download.gnome.org!) Bugzilla products are determined from: bug-database rdf:resource=http://bugzilla.gnome.org/browse.cgi?product=gnome-shell; / (MUST have product=something) - Announcement mails are a bit nicer If you have a description in your DOAP, it is used. Falls back to shortdesc. It'll also use the name (so in the mail it'll use 'GNOME Shell instead of 'gnome-shell') - Announcement mails are bcc'ed to the maintainers So make sure the maintainer info is up to date - Supports tar.xz (ONLY uploads tar.bz2 and tar.gz) == won't put tar.xz on ftp.gnome.org! Limited upload bandwidth? Just generate a tar.xz and upload that. It'll be converted to tar.bz2 and tar.gz. It will NOT put a tar.xz on ftp.gnome.org. A switch to tar.xz is planned, but at this time only tar.bz2 and tar.gz are uploaded! - In case of multiple tarballs on the command line, sorts the tarballs correctly on version number and installs them in the right order. This is important when you're switching from one place to ftp.gnome.org for your tarballs. - Contains releng release_set_scripts as well If anything breaks or you have an enhancement request, file a bug at: https://bugzilla.gnome.org/enter_bug.cgi?product=sysadmincomponent=Other PS: Currently the drawable databases are running on the same machine. So it can be slow at times. PS2: If anything breaks, please file a bug and I'll look at it and I'll also install your tarball. That said, you can still ssh to 'window.gnome.org' and use the old 'install-module' script. PS3: New script lives in the sysadmin-bin module. PS4: More changes are planned. See https://bugzilla.gnome.org/show_bug.cgi?id=613033 -- Regards, Olav -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0xDB8E409F fingerprint: F9DD 693C 9E8B 9121 B20B 202E C7D3 3397 DB8E 409F encrypted email preferred 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: Google Code-In for GNOME: We Need Tasks!
thanks a lot andre for organizing this! to all others: i really encourage you to prepare some nice tasks for your project, as it can only result in a win-win situation: you get a task done and maybe a new contributor, and the student has a possibility to gain a lot of expertise. so, what are you waiting for? daniel On Thu, 2010-10-21 at 16:27 +0200, Andre Klapper wrote: [Please strip the CC list in case of category specific answers!] Hi, some might remember Google's GHOP contest in 2007/08. This year it will take place under the name Google Code-In (GCI) from November 2010 to January 2011. GCI is a small sibling of Google Summer of Code for highschool students (13-18yrs) and with much smaller tasks in several fields (like docu, code, translation, etc). The average amount of time to be spent for a task should be about three days. For more info please see http://live.gnome.org/GoogleCodeIn If you have an idea about a possible task, want to guide a student to fulfil it and perhaps also want to get new contributors for your project/area, please read http://live.gnome.org/GoogleCodeIn/HowToWriteAGoodTask and propose your tasks at *** http://live.gnome.org/GoogleCodeIn/Tasks *** For an idea of tasks that were available in 2007 see http://code.google.com/p/google-highly-open-participation-gnome/issues/list?can=1q=sort=id Also some old (unused) tasks from 2009 are available at http://live.gnome.org/GoogleCodeIn/OldTasks . Mentors are encouraged to update them and move them to the Tasks wikipage if they are still applicable/available. (Google will announce the participating organizations after application closing on Fri, 29th of October. Afterwards tasks will likely be moved to Google's issue tracker.) Happy Code-In hopefully, andre -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: GNOME Moduleset Reorganization vs. L10N
On Sat, 2010-10-16 at 03:05 +0200, Kenneth Nielsen wrote: 2010/10/15 daniel g. siegel dgsie...@gnome.org: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel In the case of clutter core, which I believe was the module that got this discussion started again, Emmanuele said the following: now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. I think especially the, is not just used by GNOME, argument will be difficult to circumvent. right, but in that case there is no problem to have it hosted on freedesktop.org, like many other dependencies of gnome. Regards Kenneth Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred ___ 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 -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 22:15 +0200, Claude Paroz wrote: Le vendredi 15 octobre 2010 à 13:29 -0500, Diego Escalante Urrelo a écrit : El vie, 15-10-2010 a las 08:29 -0700, Sandy Armstrong escribió: I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Agree, how could we shorten that difference? I think this is the real issue, at least for this part of the proposal. We are already rich: We have the bug tracker (bugzilla), we have the VCS (Git/cgit), we have translation stats (D-L), we have build bots, we have a documentation library, an FTP server, ... What's missing IMHO is some glue which could integrate those various quality components in a comprehensive Web platform. Well, if I'm relieved from D-L, I might look one day into this :-) do you mean, to have all those services on the project pages, instead each of it on it's own subdomain? if so, maybe it is worth a try to integrate it. But we are digressing from the initial thread. Claude -- www.2xlibre.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: GNOME Moduleset Reorganization vs. L10N
On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. daniel Anyway, just everybody following the thread: We haven't yet decided if we move to something different than damned-lies or allow non git.gnome.org modules at all! We are just discussing how everything could look like. Regards, Johannes ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Moduleset Reorganization -- Take two
On Wed, 2010-10-13 at 09:21 -0400, Matthias Clasen wrote: On Wed, Oct 13, 2010 at 3:15 AM, Murray Cumming murr...@murrayc.com wrote: Then I think your proposal will be a complete disaster. I'm horrified that we must again justify the existence of a shared release schedule and of a release-team that keeps modules on that schedule. This is little more than killing the GNOME release process just because you have forgotten why we needed it in the first place. A bit dramatic today, are we ? See, what we have today is an ever-growing set of modules (200 !), that is almost impossible to get to build at any given time. And many of these modules have very little to do with each other and very little reason to be forced into the same schedule. It is time to cut back and focus on the core desktop a bit more, and let the wider set of apps run a little more freely. the problem which could arise here is, that many apps could loose some of their quality, be it translations, documentation or also programming issues and use of deprecated stuff. have a look at gnomefiles.org or any other conglomeration of gnome-style software and compare that quality to what we have inside gnome. of course, it does not have to come like this, but there is a possibility which i personally would like to avoid. daniel If we didn't want to make any changes, we could just continue to do GNOME 2.x until we all retire... Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: GNOME 2.91/3.0 Schedule Draft
On Sun, 2010-10-10 at 13:30 +0200, Andre Klapper wrote: Am Sonntag, den 26.09.2010, 18:39 -0500 schrieb Jason Clinton: On Sun, Sep 26, 2010 at 16:10, Andre Klapper ak...@gmx.net wrote: A first draft for the GNOME 2.91/3.0 schedule is now available at http://live.gnome.org/TwoPointNinetyone . Can we make the UI freeze two weeks longer? The Marketing team needs more time to post-produce the 3.0 launch videos and get translations at least started. Currently UI Freeze starts at Feb 21 (together with 2.91.90 release) which would mean six weeks until 3.0.0 is released. The request is to move it to Feb 09, 2011 (which would be after the 2.91.6 release) to have eight weeks. Any comments from others on this? do you mean march 09? andre -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese module split-up
On Mi, 2010-08-04 at 10:20 +0200, Luca Ferretti wrote: Il giorno gio, 29/07/2010 alle 17.31 +0200, daniel g. siegel ha scritto: you can find the effect files in the gnome-video-effects git repository on the usual place [1]. Daniel, do you have the time to provide a page on live.gnome.org showing each effect applied to same image? It could be helpful to choose the most appropriate translation. i just created a wiki page for the module: http://live.gnome.org/GnomeVideoEffects i dont think one image is enough, as many effects live through the movement of objects. anyway, i am adding comments to each effect anyway, which describe the effect in a human readable way. do you think that could be enough? daniel Cheers, Luca -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese module split-up
thanks a lot gabor! On Mi, 2010-08-04 at 00:43 +0200, Gabor Kelemen wrote: 2010-08-03 23:15 keltezéssel, Kenneth Nielsen írta: Here you go: http://l10n.gnome.org/module/gnome-video-effects/ Translators: try msgmerge your existing cheese translation into the new pot file of this module, about half of the strings can be copied over. Regards Gabor Kelemen It would be really nice, if someone *cough cough* would whip up a little scripting magic and do this for all the languages. Since the original project is already under the GNOME umbrella there should be no risk of losing quality. Houston, we have 59 new po files in the project! Also, for future reference, the non-obvious part sounds like: $ for i in `ls -1 *po | cut -d . -f1`; do echo $i; intltool-update $i; msgattrib --no-obsolete $i.po -o $i.po; done Regards Gabor Kelemen ___ gnome-i18n mailing list gnome-i...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
cheese module split-up
hi there! as already announced several times this week during guadec, we will rip out the awesome cheese effect files and put them into a separate GNOME module. this way, other GNOME modules and applications, such as pitivi or empathy are able to use the same effects as we do. i copied over also the already done translations, so some effect files are already (partially) translated. mostly, these are the following languages: de, es, gl, he, sv, zh_CN, zh_HK, zh_TW. you can find the effect files in the gnome-video-effects git repository on the usual place [1]. i will update the jhbuild moduleset and the wiki page soonish, as we get a new bugzilla component for gnome-video-effects. the cheese mailing list [2] will stay the main mailing list for this new module. cheers, daniel [1]: http://git.gnome.org/browse/gnome-video-effects [2]: cheese-l...@gnome.org -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese module split-up
On Do, 2010-07-29 at 17:43 +0200, Bastien Nocera wrote: On Thu, 2010-07-29 at 17:31 +0200, daniel g. siegel wrote: hi there! as already announced several times this week during guadec, we will rip out the awesome cheese effect files and put them into a separate GNOME module. Why did you start from an empty repo, instead of starting from the cheese module? That would have allowed you to keep the correct authorship, and history in the git logs. indeed. however, the effect files were introduced a month ago and written by me anyway. fyi, gnome-video-effects just contains effect files and nothing more. See 2. here: http://live.gnome.org/Git/NewRepository this way, other GNOME modules and applications, such as pitivi or empathy are able to use the same effects as we do. Cheers -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
clutter-gst as external dep?
as we are using clutter-gst heavily in our new, shiny, awesome, amazing, blinky, brilliant cheese rewrite, we are wondering, whether clutter-gst could be approved as external dep? cheers, daniel -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Modulesets Reorganization
On Mi, 2010-06-02 at 10:29 +0200, Vincent Untz wrote: Le mercredi 02 juin 2010, à 10:15 +0200, Patryk Zawadzki a écrit : On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. What if suddenly cheese gets promoted on the www.gnome.org frontpage? Or it's one highlight of the release notes for GNOME X.Y? Wouldn't this be a similar magic moment? And yes, we should do this for the great applications. this wouldnt be the same: we, and probably all desktop modules, worked very hard to accomplish all the features and requirements of the gnome inclusion. it then makes people proud when a module gets *officially* accepted and included in the gnome module set. promotion of apps can be done right now, without kicking out desktop applications. to be honest: when i install a gnome application like tomboy, gedit, cheese, ... i _know_ that this module is a good piece of software, as it is a gnome module. this is not the case with other apps you can find on the net, even if they base on gtk/gnome. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. Huh. There's really a misunderstanding here. We *do* encourage people to follow our best practices, which includes following our release schedule. Take banshee: they use our release schedule. The six-months schedule won't disappear. Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Module Proposal: Zeitgeist
i really feel sorry for that decision, i would have loved to see zeitgeist as a growing project inside the gnome infrastructure. furthermore i hope that the gnome community does not loose interest in this project, even if such a decision makes it harder to track whats going on. at last i hope, that you guys at least consider making zeitgeist a freedesktop.org project. daniel On Mo, 2010-05-03 at 00:37 +0200, Seif Lotfy wrote: Dear GNOMErs, GNOME Activity Journal is being moved to the GNOME Development Infrastructure... However after some heavy discussion within the Zeitgeist team, we decided to keep Zeitgeist in Launchpad, and not move it to the GNOME Development Infrastructure. While Zeitgeist has been developed for GNOME it doesn't heavily depend on any GNOME modules. Thus Zeitgeist could also gain adoption outside the GNOME ecosystem if it remains slightly independent, which would only serve to strengthen its reliability and usefulness on the GNOME desktop too. Our current workflow and teamwork has adopted perfectly to Launchpad. We don't intend to move to Git now or in the foreseen future, since it will disturb our organizational and development habits. So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Cheers Seif ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gnome.org http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: List translators script
On Mi, 2009-05-20 at 14:59 +0200, Vincent Untz wrote: Le lundi 18 mai 2009, à 23:01 +0200, daniel g. siegel a écrit : i have also working list_translators.sh here, which i enhanced to my needs. please find it attached. You're missing -- $1 in diff_files. and youre right ;) fixed version is attached daniel Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gmail.com http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred list_translators.sh Description: application/shellscript 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: List translators script
i have also working list_translators.sh here, which i enhanced to my needs. please find it attached. daniel On Mo, 2009-05-18 at 17:31 -0300, Jonh Wendell wrote: Hi, folks. I did a small script to list translators since a specified commit ID. I used to use the list_translators.sh scripts listed at http://live.gnome.org/MaintainersCorner/Releasing . With git, that script doesn't work anymore. Hope this is useful to some maintainer. Put that on ~/bin (which is in my PATH) and just run: translators.sh COMMIT_ID. It will output both UI and Doc translations in the format Author name (language_code). I use it in vino and vinagre for instance. Feel free to improve the script and share it ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel dgsie...@gmail.com http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred list_translators.sh Description: application/shellscript 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: gnomeweb-wml projects svn changes
On Mi, 2008-11-12 at 11:49 +0100, Murray Cumming wrote: If you have project pages in gnomewb-wml, make sure you do an svn update before making changes. gnomeweb-wml/www.gnome.org/projects/ has moved to gnomeweb-wml/projects.gnome.org/ . You should also link to projects.gnome.org/yourproject/ rather than www.gnome.org/projects/yourproject/ in future. Note that developer.gnome.org/projects/ has already moved to projects.gnome.org. it seems like links without the real name of a html file do not work anymore, e.g. http://projects.gnome.org/cheese/tour produces a 404 while http://projects.gnome.org/cheese/tour.html is working. (this actually was working on gnome.org/projects) could someone fix that? thanks a lot! daniel This is all part of making www.gnome.org simpler so we can improve it easily. -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
cheese branched
i just branched cheese for 2.24. feature development should continue on trunk, gnome-2-24 is for translations and bugfixes only. thanks! daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: GNOME 2.24 Showstopper Review
On So, 2008-08-31 at 23:51 +0200, Andre Klapper wrote: GNOME 2.24.0 release is on September 22 (see [1]), and we still have enough 2.24 blocker bugs (and other bugs of course) to fix for everybody! Take a look, test help out, clean up our platform, make 2.24 better! -andre EPIPHANY The favicon Python extension still imports and uses GnomeVFS http://bugzilla.gnome.org/show_bug.cgi?id=516844 chpe set the target milestone here, and I assume he is going to work on this to remove epiphany's gnome-vfs dependency for 2.24... Component registration sometimes lost at runtime http://bugzilla.gnome.org/show_bug.cgi?id=535127 Dataloss bug. crash in IA__gtk_tree_model_get_valist http://bugzilla.gnome.org/show_bug.cgi?id=512313 Patch available, but probably not the right way to fix this. EVOLUTION Error Summary and folder mismatch / Message list mismatch http://bugzilla.gnome.org/show_bug.cgi?id=213072 Was already fixed several times, but still happens in Evolution 2.23 which was ported to use sqlite. Hopefully completely fixed in .91. GNOME-APPLET crash in Keyboard Indicator (gtk_widget_set_tooltip_text) http://bugzilla.gnome.org/show_bug.cgi?id=523583 Comment 40 and 68 have useful traces. There has been much activity to fix this though the bug has been existing since 2.18. GNOME-PANEL crash in gtk_rc_reset_styles() http://bugzilla.gnome.org/show_bug.cgi?id=446183 986 duplicates and still happening in 2.22, related to theme problems. Any investigations and more comments appreciated! GNOME-SETTINGS-DAEMON Exit due to unhandled X error when updating resolution http://bugzilla.gnome.org/show_bug.cgi?id=537592 svu has problems reproducing this, more input and help tracking this down very appreciated, as we expect lots of users running into this. GVFS nautilus does not display samba shares for machines inside an ADS network http://bugzilla.gnome.org/show_bug.cgi?id=524485 This is a regression from 2.20.x. A patch is available and one commenter has stated that the patch fixed the issue for him. Unable to browse smb shares http://bugzilla.gnome.org/show_bug.cgi?id=547597 This has come up lately and so far there has been no activity to fix this. VINO program won't restart even set X-GNOME-AutoRestart=true http://bugzilla.gnome.org/show_bug.cgi?id=546747 This has a patch attached and Jonh is going to fix this for 2.24. GNOME GOALS not yet completed: * http://live.gnome.org/GnomeGoals/PoLinguas : atk * http://live.gnome.org/GnomeGoals/PoptGOption : GnomePython * http://live.gnome.org/GtkPrintPort : gnome-python-desktop, anjuta, gnome-devel-docs (update), GnomePython * http://live.gnome.org/GioPort : PATCHES: alacarte, gnome-applets, gnome-utils, gnome-build, gdl, TODO: gnome-python-desktop, gnome-utils, sabayon, anjuta a bit offtopic: in cheese we still need gnome-vfs because of gnome thumbnail. is there anything replacing it already? thanks! daniel Changes/Fixes since the last review[2]: Fixed issues for 2.24: 515948 Not a blocker anymore (less dups or change of importance): 504600, 529971, 528902 [1] http://live.gnome.org/TwoPointTwentythree [2] http://mail.gnome.org/archives/desktop-devel-list/2008-June/msg00119.html [3] http://live.gnome.org/Bugsquad/ShowstopperReviews -- mailto:[EMAIL PROTECTED] | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
Re: indentation of c code
indent was not enough for me, i found some corner cases where it just did not work. but i found a great alternative: uncrustify [1] it really works great and i can recommend it to anyone as it has also some aligning features. i created a config file for cheese, which uses some quite gnome standard whatever ;) you can find that config here [2] daniel [1]: http://uncrustify.sourceforge.net/ [2]: http://home.cs.tum.edu/~siegel/files/cheese-indent.cfg On Mo, 2008-08-18 at 08:52 +0200, BJörn Lindqvist wrote: 2008/8/17 daniel g. siegel [EMAIL PROTECTED]: hi all! i just wanted to know if someone out there has already an option file or a small script for gnu indent to indent c code to the gnome standard? There is no GNOME standard for indenting C code -- every project use their own indentation style (unfortunately). But to reformat a file to an indentation style many projects use, you can just run indent without any arguments. -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: indentation of c code
i tried to play with gnu indent but i dont like some specific parts, e.g. some_function_with_a_very_long_name (GtkWidget *widget, GdkEvent event, gpointer data) - either i would put every argument on its line or all of those on just 1 line.. primary = g_strdup_printf (_ (some long text %s), list_length); - sorry, but no sane programmer would do stuff like that... command_line = g_strdup_printf (gnome-open mailto:?subject='%s', _(Media files)); - same as above gtk_action_group_set_sensitive (cheese_window-actions_flickr, TRUE); gtk_action_group_set_sensitive (cheese_window-actions_fspot, TRUE); gtk_action_group_set_sensitive (cheese_window-actions_account_photo, TRUE); - why should the last TRUE be on a separate line if those above arent? and so on.. mostly the problems are with long lines, where the logic is more important than a strict rule, which says you dont have to go above a certain limit (as the -l parameter does) my settings to get the above were: indent file.c -i2 -psl -di0 -bl -bli0 -nce -d0 -cli0 -pcs -nfc1 -nut -lp -hnl -nbbo --ignore-newlines -T GtkWidget -T GtkWindow -T CheeseWindow would be great if someone could help me with this! daniel On Mo, 2008-08-18 at 08:52 +0200, BJörn Lindqvist wrote: 2008/8/17 daniel g. siegel [EMAIL PROTECTED]: hi all! i just wanted to know if someone out there has already an option file or a small script for gnu indent to indent c code to the gnome standard? There is no GNOME standard for indenting C code -- every project use their own indentation style (unfortunately). But to reformat a file to an indentation style many projects use, you can just run indent without any arguments. -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
indentation of c code
hi all! i just wanted to know if someone out there has already an option file or a small script for gnu indent to indent c code to the gnome standard? best regards, daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: maintainer scripts
On Mo, 2008-07-28 at 09:48 +0100, Martyn Russell wrote: daniel g. siegel wrote: another quick question: maintainer.py seems to pick up all bug fixes, but what about features, or other enhancements, which are no bugs? how do i get those into the NEWS file? This is something I really have been trying to figure out actually. The only 2 ways about it I can think of are either. 1. Manually adding them 2. Having some sort of keyword in the ChangeLog so the maintainer script can pick it up (the way we do bugs). For example, Adds feature: bla bla. Would then list it as: - bla bla I can work on this if people think it is a good idea. that would be awesome! ;) you know, most of the gnome developers are lazy.. daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: maintainer scripts
thanks! it was exactly that what i needed. i modified it a bit, mostly to have the changelog and news style of older release notes of cheese. btw: we have another cool script, which basically is a wrapper around svn commit, which updates the ChangeLog file with the commit message before actually commiting. you can find it here: http://home.cs.tum.edu/~siegel/files/cicl daniel On Mi, 2008-07-23 at 18:17 -0400, Claudio Saavedra wrote: El mié, 23-07-2008 a las 23:35 +0200, daniel g. siegel escribió: i just found some scripts like maintainer.py, list-translator.sh and so on.. does anybody use them for rolling your own tarballs? We use maintainer.py to prepare most of the stuff that should go into NEWS before rolling tarballs. It makes it way easier! Claudio -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: maintainer scripts
On Sa, 2008-07-26 at 14:11 -0400, Thomas Thurman wrote: Ysgrifennodd daniel g. siegel: thanks! it was exactly that what i needed. i modified it a bit, mostly to have the changelog and news style of older release notes of cheese. Metacity also has a release script, which I'd also like to merge: http://svn.gnome.org/viewvc/metacity/trunk/tools/release-wrangler.py?revision=3625view=markup Brad Fitzpatrick produced a grand unified release script called ShipIt once; I took a look at merging it with that. It's written in Perl, which is a shame because most GNOME scripts are written in Python or shellscript. However, it did have one really important and useful feature, which was that any project could contain a file which overrode one or more steps of the standard procedure. That way, you didn't have to write a new release script every time, or fork a standard one, but you could modify it in just the way you needed. I didn't end up using ShipIt in the end, because there were some finer-grained modifications needed than it seemed worth making and keeping the same system. The design is rather lovely, though, and I believe it would be worthwhile to adopt in any generalised maintainer script. could you tell me where to find it? btw: we have another cool script, which basically is a wrapper around svn commit, which updates the ChangeLog file with the commit message before actually commiting. you can find it here: http://home.cs.tum.edu/~siegel/files/cicl Funnily enough, Metacity also has such a script :) http://svn.gnome.org/viewvc/metacity/trunk/tools/commit-wrangler.py?view=markup Maybe we should all be pooling effort. totally! it would be great to have a development kit, which unifies all the effort which is done to create releases of the gnome modules... of course we could add all that to the buildsystem, at least the release process. waf would be a good example to experimentate on peace T -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: maintainer scripts
another quick question: maintainer.py seems to pick up all bug fixes, but what about features, or other enhancements, which are no bugs? how do i get those into the NEWS file? daniel On Mi, 2008-07-23 at 18:17 -0400, Claudio Saavedra wrote: El mié, 23-07-2008 a las 23:35 +0200, daniel g. siegel escribió: i just found some scripts like maintainer.py, list-translator.sh and so on.. does anybody use them for rolling your own tarballs? We use maintainer.py to prepare most of the stuff that should go into NEWS before rolling tarballs. It makes it way easier! Claudio -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: maintainer scripts
On So, 2008-07-27 at 11:46 +1200, John Stowers wrote: On Sun, 2008-07-27 at 01:08 +0200, daniel g. siegel wrote: another quick question: maintainer.py seems to pick up all bug fixes, but what about features, or other enhancements, which are no bugs? how do i get those into the NEWS file? Check out http://svn.gnome.org/viewvc/conduit/trunk/NEWS?view=markup and http://www.conduit-project.org/wiki/MakingARelease If I make a commit, that adds a feature, not related to a bug # I add it to NEWS directly. When maintainer.py makes the NEWS file any things I had added to the current version section of the file get prepended to the top of NEWS.new i see. but wouldnt it be better then, to analyze the svn log until the last release? daniel John daniel On Mi, 2008-07-23 at 18:17 -0400, Claudio Saavedra wrote: El mié, 23-07-2008 a las 23:35 +0200, daniel g. siegel escribió: i just found some scripts like maintainer.py, list-translator.sh and so on.. does anybody use them for rolling your own tarballs? We use maintainer.py to prepare most of the stuff that should go into NEWS before rolling tarballs. It makes it way easier! Claudio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
maintainer scripts
hello! i just found some scripts like maintainer.py, list-translator.sh and so on.. does anybody use them for rolling your own tarballs? im just too lazy to prepare the NEWS file by hand every time and then write that announce mail... daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6
hi! * clutter could bring some bling into many gnome applications * clutter did a nice job in the last months and provides a usable interface * clutter is already known in gnome-related projects and therefore would not necessarily mean something totally new +1 daniel On Sun, 2008-04-20 at 16:36 -0500, Jason D. Clinton wrote: Hi, For Gnome Games 2.24, I would like to have an optional hardware-accelerated Gnometris theme. This would be enabled by default on installations where glxinfo reports Direct Rendering: Yes. All of the old themes will continue to be present and used as fall-backs when the hardware is not there. After much research, clutter appears to be the most Gnome-friendly, stable, and active canvas-like project. Others which may come up in this discussion are largely inactive (goocanvas) or sufficiently incomplete (hippocanvas) as to make them unusable for implementation of a Tetris-like game animation. pigment is out because it's Python-only (or so I am told). I'm not saying anything bad about any of the above: just that they don't meet my requirements, right now. I considered other non-Gnome canvas options too such as QGraphicsView and Webkit canvas and decided against both due to very difficult implementation details. I suspect that this will make Gnometris more attractive for embedded use since many mobile devices now support OpenGL--though, no one has said they will use it for embedded use. I solicited objections to using clutter on our gnome-games mailing list and on my blog which is aggregated on Planet. There were no objections. Yes, it's yet another canvas. But, it appears to be widely available in distributions and no one is (yet) proposing it for inclusion in the Gnome officially. With a little work, the new rendering engine will add a lot of bling for very little coding investment. It will probably be something--at least--worth mentioning in the release notes. The fact that some drivers do not yet have OpenGL support is irrelevant as there are no plans to deprecate the existing theme engines. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Module proposal: Empathy for GNOME 2.24
i like empathy ;) it still has some things, which should get cleaned up in the user interface (e.g. group sorting, buddy icon preview, ...) but still i would love to see it in GNOME 2.24. +1 a very interesting idea is to integrate the buddy icon somehow with cheese, so that a user can set his so called avatar by using cheese if he has a webcam. i already have some ideas for that and i would like to put that feature into GNOME 2.24. still some months left ;) daniel On Di, 2008-03-25 at 11:50 +0100, Xavier Claessens wrote: * Proposal: Include Empathy in GNOME 2.24 desktop. * Purpose: Empathy [1] 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. * Dependencies: glib-2.0 = 2.16.0 gconf-2.0 = 1.2.0 libxml-2.0 libtelepathy = 0.3.2 telepathy-glib = 0.7.3 libmissioncontrol = 4.53 gtk+-2.0 = 2.12.0 libglade-2.0 = 2.0.0 libebook-1.2 libpanelapplet-2.0 = 2.10.0 * Resource usage: Already using GNOME FTP, GNOME SVN and GNOME bugzilla. * Adoption: It is packaged at least for debian, ubuntu, mandriva, gentoo and fedora. There is patches for Totem and nautilus-send-to [2] to make use of libempathy(-gtk). There is a gtetrinet branch which uses libempathy-gtk to play with contacts. There is also a python plugin for epiphany using pyempathygtk [3]. Empathy is also used by Soylent [4]. * GNOME-ness: The community reports bugs in GNOME bugzilla and attach patches, I review and commit in GNOME's SVN. GNOME translation teams are already translating empathy. The UI is build with GNOME spirit in mind, empathy inherit from Gossip's excellent UI. * Miscellaneous: - Audio/Video support is still disabled by default but most problems comes from other telepathy layers and are being worked. I'm pretty sure it will be enabled soon. That means Empathy will be able to do audio/video calls over SIP and Jabber, MSN will surely come at some point too. Empathy is the only program capable of that AFAIK. - libtelepathy is now deprecated, empathy is moving to telepathy-glib. If we finish the transition we'll drop libtelepathy dependency. - Empathy's part for file-transfer is almost done, but the telepathy spec is likely to change soon. I hope it will be ready in time for 2.24. - API is still not documented and likely to change, I know this sucks. - There is no user documentation yet, I'll write an email to ask documentation team to write one base on Gossip's doc. - Empathy was proposed for GNOME 2.22 but got rejected because it was not considered stable/mature enough. Lots is already fixed and I hope to fix more during the 6 months coming. Help from the community is of course welcome! Thanks, Xavier Claessens. [1] http://live.gnome.org/Empathy [2] http://www.barisione.org/blog.html/p=100 [3] http://blog.senko.net/2007/07/19/emphatic-epiphany [4] http://live.gnome.org/Soylent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: install-module on master.gnome.org
On Do, 2008-03-20 at 22:39 +0100, Olav Vitters wrote: On Thu, Mar 20, 2008 at 05:33:38PM -0400, Andrew Cowie wrote: On Thu, 2008-03-20 at 22:26 +0100, Olav Vitters wrote: - checking of sane versions (no 'rc1' 'beta1' etc) Why not? If a project wants to do that, that's their business. Because it confuses the ordering. There is no reliable way to determine the latest versions. isnt there ls -v, which we could use for that? daniel So I cannot get e.g. the .0 case right. Currently it is (IMO hackishly) done by assuming the versions are installed in order, but that breaks down whenever a new module is added (often permissions are delayed until there have been a few releases.. then install-module shouldn't be too confused if versions are installed out-of-order). -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: how to take screenshots of cheese
On Mi, 2008-01-16 at 10:49 +, Bastien Nocera wrote: On Tue, 2008-01-15 at 20:50 -0500, Dan Winship wrote: Alan wrote: Hoping I'm not stating the obvious, but a GNOME? Maybe borrow a garden gnome from the neighbors if you don't have one? :) And then, after taking its picture, mail it to someone else on the docs team who lives in another country so they can take a picture too... You sentimental you [1]. [1]: http://en.wikipedia.org/wiki/Travelling_gnome_prank i think i got the solution. news coming in the next days ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: how to take screenshots of cheese
On Mi, 2008-01-16 at 10:49 +, Bastien Nocera wrote: On Tue, 2008-01-15 at 20:50 -0500, Dan Winship wrote: Alan wrote: Hoping I'm not stating the obvious, but a GNOME? Maybe borrow a garden gnome from the neighbors if you don't have one? :) And then, after taking its picture, mail it to someone else on the docs team who lives in another country so they can take a picture too... You sentimental you [1]. [1]: http://en.wikipedia.org/wiki/Travelling_gnome_prank i would like that ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
how to take screenshots of cheese
hi guys! as gnome 2.22 gets ready, we probably need some screenshots of cheese. as other programs, like eog or tomboy can show just some sample media, i cannot show just a sample face. any idea how i could make screenshots without having my face all over the gnome website? well, i would like that too, but i dont know if you guys want that ;) daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: how to take screenshots of cheese
On Di, 2008-01-15 at 15:03 -0500, Diego Escalante Urrelo wrote: On 1/15/08, Bastien Nocera [EMAIL PROTECTED] wrote: On Tue, 2008-01-15 at 20:50 +0100, daniel g. siegel wrote: hi guys! as gnome 2.22 gets ready, we probably need some screenshots of cheese. as other programs, like eog or tomboy can show just some sample media, i cannot show just a sample face. any idea how i could make screenshots without having my face all over the gnome website? well, i would like that too, but i dont know if you guys want that ;) If it's just screenshots, can't you use a source other than v4l(2)src in your hacked version with a picture with a nice license (say, some creative commons license). You could even add that as an option in Cheese itself if passed a particular command-line option, so that other people can do mock screenshots too. Or you could use your nice puppet :) Puppet +1 and if it's a wanda puppet even better. can anyone send a nice puppet to me, my address is ;) -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: how to take screenshots of cheese
On Di, 2008-01-15 at 15:03 -0500, Diego Escalante Urrelo wrote: On 1/15/08, Bastien Nocera [EMAIL PROTECTED] wrote: On Tue, 2008-01-15 at 20:50 +0100, daniel g. siegel wrote: hi guys! as gnome 2.22 gets ready, we probably need some screenshots of cheese. as other programs, like eog or tomboy can show just some sample media, i cannot show just a sample face. any idea how i could make screenshots without having my face all over the gnome website? well, i would like that too, but i dont know if you guys want that ;) If it's just screenshots, can't you use a source other than v4l(2)src in your hacked version with a picture with a nice license (say, some creative commons license). You could even add that as an option in Cheese itself if passed a particular command-line option, so that other people can do mock screenshots too. Or you could use your nice puppet :) Puppet +1 and if it's a wanda puppet even better. of course we could fake the picture and put there an image of a beach or vuntz with an ice cream.. *waiting for ideas* ;) -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese
On Sa, 2007-12-22 at 22:22 +0100, Jaap A. Haitsma wrote: 4) And as Shaun is mentioning, we need a manual there is a bug! ehm somewhere... hmm.. http://bugzilla.gnome.org/show_bug.cgi?id=480628 jaap: should we forward that to the doc team? I've filed an issue at GNOME GHOP http://code.google.com/p/google-highly-open-participation-gnome/issues/detail?id=81 nobody yet? Let's see if we can get new contributors. If that doesn't work we can ask GNOME doc team 5) vincent needs some more ice to be convinced ;) I think it's better to wait for 2.24 i dont want to take that decision. but in my opinion its getting close: feature freeze is on january 17th. that means we would have to finish our feature list by that date. is that possible? A lot is possible, but realistically I don't know. Problem I set is that by that time we won't have had widespread testing we had a release about one week ago. i would like to hear some comments from proper gnome developers, if they feel if cheese is ready for inclusion. jaap and myself already made a decision, but i actually would like to hear some comments from you guys! daniel Jaap -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
happy cheese and a happy new cheese!
our christmas gift for you: http://home.cs.tum.edu/~siegel/index.php?page=news#20071224 have fun with our gift and i wish you a happy christmas and a peaceful time! daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese
On Fr, 2007-12-21 at 21:21 +0100, Jaap A. Haitsma wrote: 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 disclaimer 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. /disclaimer 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 thats absolutely right. we dont have a clue at the moment, on how many webcams cheese actually works. for now, we got about 10 reports of different webcams, where cheese actually worked. 2) Cheese needs more HIG love you are right. im not really convinced with the ui at the moment and we can do better for shure. 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 sorry, but if we think in that way, we will never reach a 1.0 version. a software is never finished and you can always add more and more features. on the other hand its true that we are missing some features, that would really enhance the workflow with cheese. 4) And as Shaun is mentioning, we need a manual there is a bug! ehm somewhere... hmm.. http://bugzilla.gnome.org/show_bug.cgi?id=480628 jaap: should we forward that to the doc team? 5) vincent needs some more ice to be convinced ;) I think it's better to wait for 2.24 i dont want to take that decision. but in my opinion its getting close: feature freeze is on january 17th. that means we would have to finish our feature list by that date. is that possible? daniel Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese
On Do, 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 hey you stole that! ;) Summary so far: === + there used to be a build system issue (and intltool integration issues), but it now uses waf or autotools exactly, you can find both waf and autotools in the src-tree and everyone can use his favourite. unfortunately, just autotools is supported by jhbuild at the moment. + people generally seem to like cheese (not something visible on the d-d-l thread, though) sorry, vincent! but i dont have enough ice cream to pay your work hours for replying to cheese related mails ;) + we had a 4 month development phase without any release, and we think cheese should be enough stable to not destroy peoples desktop. there are a few bugs remaining, but we really think, we could do a release on christmas. daniel Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese
On Do, 2007-12-20 at 12:51 +, Gustavo J. A. M. Carneiro wrote: On Thu, 2007-12-20 at 13:17 +0100, daniel g. siegel wrote: On Do, 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 hey you stole that! ;) Summary so far: === + there used to be a build system issue (and intltool integration issues), but it now uses waf or autotools exactly, you can find both waf and autotools in the src-tree and everyone can use his favourite. unfortunately, just autotools is supported by jhbuild at the moment. jhbuild now supports waf: http://bugzilla.gnome.org/show_bug.cgi?id=503907 awesome ;) -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
build systems
;) daniel -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese for 2.22, realistic?
On So, 2007-09-23 at 12:16 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 17:42 +0200, daniel g. siegel a écrit : On Sa, 2007-09-22 at 17:13 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. I'm not quite sure what you mean about the development cycle. We have lots of unstable release during those 6 months. could you tell me more about that? http://live.gnome.org/TwoPointTwentyone i thought, you would point me to something else ;) the problem i see, is unstable releases... i mean: cheese has many new features at each release and this would be then invisible for the end user, as it is always an unstable release. Oh, and see http://live.gnome.org/ReleasePlanning/ModuleProposing if you want to have a complete proposal :-) isnt my proposal complete? http://live.gnome.org/ReleasePlanning/ModuleProposing Everything is in the wiki ;-) yeah, but what was missing? ;) Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
cheese for 2.22, realistic?
hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. cheers, daniel * purpose: 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 * target: desktop * dependencies: * glib-2.0 * gobject * gtk+ * libglade * gdk * dbus * gstreamer-0.10 * gstreamer-plugins-base-0.10 * gstreamer-plugins-good-0.10 * gstreamer-pango-0.10 * gnome-vfs * cairo * libgnomeui * xf86vidmodeproto * resource usage: * svn: http://svn.gnome.org/viewcvs/cheese/ * bugzilla: http://bugzilla.gnome.org/buglist.cgi?product=cheese * release hosting: live.gnome.org/Cheese/Releases ;( * homepage: live.gnome.org/Cheese * adoption: * ubuntu (both feisty and gutsy) * PLD linux * arch linux * working on a maemo port * GNOME-ness: hey, it started as a GNOME-soc project ;) * miscellaneous: building with jhbuild is not possible atm. -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese for 2.22, realistic?
On Sa, 2007-09-22 at 16:55 +0200, Claude Paroz wrote: Le samedi 22 septembre 2007 à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. cheers, daniel (...) * GNOME-ness: hey, it started as a GNOME-soc project ;) * miscellaneous: building with jhbuild is not possible atm. It doesn't seem to be intltool compatible right now, so that would be a blocker right now. Shouldn't be so much difficult to add, though. indeed, it uses toc2 as build system. if you want to update the po-files do this: cd po/; make updatepo But for a GNOME-soc project, I'm a little surprised that intltool support is not implemented from start. Who was the mentor :-) ? i will not put the finger on him, but he speaks french and eats tribes. that should say all ;) daniel Regards, Claude -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: cheese for 2.22, realistic?
On Sa, 2007-09-22 at 17:13 +0200, Vincent Untz wrote: Le samedi 22 septembre 2007, à 16:38 +0200, daniel g. siegel a écrit : hey! im not shure at all, how to begin this mail.. and im even more unshure if i should propose cheese for 2.22 ;) my biggest concern is the development cycle, which is much faster than the gnome one atm (2 weeks to a month vs. 6 months). anyway, here is my proposal for including cheese in 2.22. I'm not quite sure what you mean about the development cycle. We have lots of unstable release during those 6 months. could you tell me more about that? Oh, and see http://live.gnome.org/ReleasePlanning/ModuleProposing if you want to have a complete proposal :-) isnt my proposal complete? daniel Vincent -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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: Why have a ChangeLog file if you already have commit messages?
useful or not.. i think it doesnt matter. i mean, some people need it, want it, whatever and some wont ever read it (like me for example ;) ). anyway, in order to please the first group and not to have too much work on something i hardly need (svn log does that for me), etienne and me hacked a little wrapper around svn commit, which updates the ChangeLog file with the commit message before actually commiting. that means, that the same commit message will be used in the svn log as in your Changelog file. if you are interested, have a look at [1]. (and if you are wondering why the above is the same text as you will find in the file itself.. yeah im THAT lazy ;) ) cheers, daniel [1]: http://home.cs.tum.edu/~siegel/files/cicl -- this mail was sent using 100% recycled electrons daniel g. siegel [EMAIL PROTECTED] http://home.cs.tum.edu/~siegel gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred 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
