Re: Wrapping up Bugzilla migration
RIP old buddy! On Mon, May 17, 2021 at 7:45 AM Bartłomiej Piotrowski wrote: > Hi all, > > I have been looking at Bugzilla migration requests today and have some > related announcements. > > First of all, if for some reason you are still using Bugzilla, you > should stop and move to GitLab. I hope it's not a surprise to anyone. > > Infrastructure team will be accepting bugs migration requests till the > end of May 2021. After this date, we intend to turn bugzilla.gnome.org > to static HTML page and decommission its infrastructure. A specific date > will be announced in June. > > I know some of these requests are not resolved for years, but I'm slowly > going through the queue. Please let me know if we should prioritize > specific migrations or if you have any questions. > > Thanks, > Bart > ___ > foundation-list mailing list > foundation-l...@gnome.org > https://mail.gnome.org/mailman/listinfo/foundation-list > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
'social desktop'/open collaboration project?
I've not seen anyone here talking about this: http://www.freedesktop.org/wiki/Specifications/open-collaboration-services (discussed here: http://dot.kde.org/2009/05/01/social-desktop-starts-arrive ) Has anyone from GNOME talked with them/looked at this/etc.? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
On Fri, May 8, 2009 at 4:32 AM, Patryk Zawadzki pat...@pld-linux.org wrote: It's not like suddenly gnome.org will start providing all of these [web] services. Why not? http://tieguy.org/blog/2006/07/05/guadec-thoughts-3-where-is-gnome/ Mind you, it would not be easy, but there is no reason why it couldn't be done. Unless, of course, we prematurely lock ourselves/our users into other solutions/platforms/APIs. If we didn't do it ourselves, of course, others are starting to do web services in an open way (see for example mozilla's weave, libre.fm, identi.ca, elgg, (sadly defunct) mugshot, and Ubuntu's (quiet) online services). GNOME, imho, should be looking at supporting those (and perhaps getting them to work together on common APIs like gdata?) before supporting standards that (regardless of their patent status) essentially connect us only to proprietary services. Luis (who personally would love to see Conduit or something like it pick up enough momentum, and point at enough Libre services, to become a central theme of 3.0) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
I guess a fairly obvious question I should have asked earlier: what things are there that you want to access via gdata that aren't systematically available via other protocols (rss, pop, imap, http, etc.)? That might help clarify a bit what kinds of risks are being run here. (As I point out later, I use google stuff, like everyone, but I've never once thought 'man, I wish I could access this via gdata instead of pop/imap/web browser'.) On Fri, May 8, 2009 at 2:32 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Thu, 2009-05-07 at 19:22 -0400, Luis Villa wrote: Lets not fall into the lazy trap of pretending that because something is no-cost that it is effectively the same as being libre-free (or even the same as being pragmatically open.) I didn't mean to suggest any of Google's services were libre-free; I was merely saying that they're free-as-in-beer and a lot more well-documented than other protocols. Bad wording on my part. Or to put it a different way: feel free to argue for it as a necessary evil; that has been and will continue to be the kind of compromise that GNOME has to make sometimes. But please don't pretend that because it is no-cost that that somehow makes it OK. I personally think that Google's services are fine; a necessary evil, if you will. They may not be libre-free, but they're in wide use, and having access to Google services from the desktop will consequently be useful to many people. Windows is in wide use; is practically free to the vast majority of computer users; and their APIs are very well documented. Lets just use that! ;) I'm only slightly exagerrating; obviously cross-platform gtk, gimp, etc. are all very good and healthy for us. So we shouldn't ignore these factors. But the difference is that if you use gimp on windows, you're one step closer to using a free operating system. That doesn't appear to be the case here. (If I use IMAP to access gmail, OTOH, I'm fine, freedom-wise.) Specifically to this point, things like flash and other codecs that we have worked out support for are broadly used by hundreds of thousands (millions?) of people and data providers. gdata... not so much. So work with me here: * is there any reason to believe that there is a trend towards adoption here that we should be aware of? In other words, is this soon going to be well beyond Google, and we should be ready for it? that would be a good argument here; that's basically why we're OK with libswf. Data points that one might muster to prove this would include that open source CMSs (or other open source web-based software) has libraries or plugins that publish gdata endpoints. If GData is adopted well beyond Google's services, I think it will take a while. I've just trawled the web for examples of non-Google services which publish GData APIs, and all I could find were these: * http://wiki.apache.org/lucene-java/GdataServer * http://drupal.org/node/60490 both of which look dead. There were a few attempts to revive the Drupal GData project in 2008; I don't know what became of them. That is too bad; I'd be curious to know more about why these fizzled out. (Frankly, though, this doesn't surprise me too much- my sense of it technically when I looked at it in 2006 was that it was a solution in search of a problem.) * if it isn't going to spread beyond google (or we have no reason to believe so, at any rate) is there a reason to think that google is special/important enough that we should compromise our values here? Is there a good tactical reason for it? (I'd say that this, roughly, is our relationship to SMB.) (There may be; I'm open to that possibility but don't see it argued for yet.) As I said above, Google services are very widely used, but I can't speak for everyone and say whether that's a good enough reason for adoption. Obviously there have been a few people giving unconditional +1s to moving libgdata into the desktop set; but there have also been the same number raising concerns such as yours. I'm a google service user as well, so I understand the argument, but I only give them data if I can get it out in fairly standardized formats. * alternately, are there ways to make this more general and support alternatives? In other words, should this be a general purpose web-data library (perhaps an atompub library?) in which gdata is but one mode? Should it be integrated with some other, pre-existing network connection or data protocol library? In its current state, it would take quite some work to make libgdata more generalised, if it would work at all. I haven't really looked into other web APIs enough to be able to say whether a general approach would work sufficiently well. Nor have I. :) I'd suggest that this would be the best approach, from a freedom perspective, but obviously technically it might not be feasible at this time. I'm not saying there is any clear right or wrong answer overall, but I really think both you and GNOME
Re: Proposing libgdata as a new desktop module
2009/5/8 Josselin Mouette j...@debian.org: I think libgdata should be welcome as an optional dependency; having a youtube plugin in totem is great, and it doesn’t make totem almost useless without youtube. Having iPod support in rhythmbox is essential, and it doesn’t make it useless with other MP3 players. But requiring something like this? This is frightening. Not necessarily; I mean (for example) f-spot supports both gallery and flickr. If there was a library to make this easier on the flickr side, that wouldn't necessarily be a bad thing. But of course in that case there are free alternatives like gallery. So it is probably important to understand what things this is going to be used for, and whether there are alternatives for those services; you can evaluate the protocol on its own but it will inevitably be incomplete. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
On Thu, May 7, 2009 at 3:07 PM, Philip Withnall phi...@tecnocode.co.uk wrote: 2009/5/7 Johannes Schmid j...@jsschmid.de Hi! While I certainly agree that accessing Google services is important for our desktop I kind of think that it would be a bad signal to include a module whose purpose to support a closed-source/non-free service. Or are there any free services using the API? I'm not going to argue this too strongly, since I have no strong opinions either way and I think the community should decide whether they want this sort of thing in the desktop set. However, I will point out that plenty of our modules implement proprietary protocols, codecs, etc. which are more closed than GData. Valid point. There aren't currently any free services using the protocol (and I can't foresee many appearing any time soon, though it's not beyond reason), but Google services are mostly free, if not open-source. Lets not fall into the lazy trap of pretending that because something is no-cost that it is effectively the same as being libre-free (or even the same as being pragmatically open.) Or to put it a different way: feel free to argue for it as a necessary evil; that has been and will continue to be the kind of compromise that GNOME has to make sometimes. But please don't pretend that because it is no-cost that that somehow makes it OK. Specifically to this point, things like flash and other codecs that we have worked out support for are broadly used by hundreds of thousands (millions?) of people and data providers. gdata... not so much. So work with me here: * is there any reason to believe that there is a trend towards adoption here that we should be aware of? In other words, is this soon going to be well beyond Google, and we should be ready for it? that would be a good argument here; that's basically why we're OK with libswf. Data points that one might muster to prove this would include that open source CMSs (or other open source web-based software) has libraries or plugins that publish gdata endpoints. * if it isn't going to spread beyond google (or we have no reason to believe so, at any rate) is there a reason to think that google is special/important enough that we should compromise our values here? Is there a good tactical reason for it? (I'd say that this, roughly, is our relationship to SMB.) (There may be; I'm open to that possibility but don't see it argued for yet.) * alternately, are there ways to make this more general and support alternatives? In other words, should this be a general purpose web-data library (perhaps an atompub library?) in which gdata is but one mode? Should it be integrated with some other, pre-existing network connection or data protocol library? The bottom line is that if we adopt this, we're implicitly encouraging developers to use it, and we shouldn't do that unless there is a strong case that it promotes freedom in some way, shape, or form. I don't see that case made yet, but it certainly shouldn't be an impossible case to make. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Thu, Apr 2, 2009 at 8:14 AM, Andre Klapper ak...@gmx.net wrote: Am Donnerstag, den 02.04.2009, 14:06 +0200 schrieb Johannes Schmid: What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? No decisions yet, but definitely should be discussed after desrt and/or robtaylor have posted a follow-up mail describing the current state of dconf. I might suggest that the rule of thumb should be 'if a platform is ready for the 2.28 timeframe, then it can be required in 3.0, otherwise it has to wait.' This would allow six whole months to port, debug, etc. But (among other things) gtk is not going to be ready in that timeframe. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Thu, Apr 2, 2009 at 8:14 AM, Andre Klapper ak...@gmx.net wrote: Am Donnerstag, den 02.04.2009, 14:06 +0200 schrieb Johannes Schmid: What about gconf/dconf? Or in other words - does GNOME 3.0 depend on dconf and is gconf deprecated (soon!) or not? No decisions yet, but definitely should be discussed after desrt and/or robtaylor have posted a follow-up mail describing the current state of dconf. I might suggest that the rule of thumb should be 'if a platform is ready for the 2.28 timeframe, then it can be required in 3.0, otherwise it has to wait.' This would allow six whole months to port, debug, etc. But (among other things) gtk is not going to be ready in that timeframe. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Luis [1] Despite the slight tinge of NIH in many of the efforts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 7:28 PM, Brian Nitz brian.n...@sun.com wrote: Luis Villa wrote: On Wed, Mar 11, 2009 at 6:46 PM, Andre Klapper ak...@gmx.net wrote: Am Mittwoch, den 11.03.2009, 23:28 +0100 schrieb Juan Jesús Ojeda Croissier: Apport[1] is a system which is able to send a very complete crash log to a bug tracker system (not necessary the Ubuntu's one). This is working with the one from Ubuntu, but also Fedora and OpenSuse. Can be used agoinst email based interface and more. Fedora has Crash Catcher: https://fedorahosted.org/crash-catcher/wiki I always wonder if this isn't all about duplicating efforts. No need to wonder; it definitely is duplicated and wasted effort. Not intentional, of course[1], but painful no matter how you slice it. Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? My own ideas are: - has to work with non-GNOME apps. - capture more complete distro and component revision information. This is pretty complete in modern versions of bug-buddy, I believe. - optionally passes bug first to a distribution maintained bug database. (to filter distro specific bug pollution) This is the default behavior distros tend to want... which makes it hard for upstream to do anything useful, since the distros are historically pretty bad at getting this data upstream. (By 'pretty bad' I don't think any distro which does this has ever systematically/programatically moved that data upstream, though I'm certainly out of touch and may have missed something.) Mind you, it isn't clear to me that upstream has been doing much useful with the data we do have of late, but like the uncoordinated re-inventions of bug-buddy, that is a symptom of the general underinvestment in QA by GNOME partners. - callable by user from application (window manager?) menu, captures user comments as well as application context info. - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Wed, Mar 11, 2009 at 8:53 PM, Brian Nitz brian.n...@sun.com wrote: - plug-ins for distro specific capture tools (strace, ktrace, truss, dtrace, mdb, pstack, gdb, dbx,...) I'd note that this data is actually overrated. Useful, yes, but even the primitive information we used to get was very useful when we got it in volume and we had eyes poring over it for clues. I have a sense that the current emphasis on all these various tools (with their attendant complexities) makes perfect data collection the enemy of good data collection. I agree that too much information in the capture can be at least as much of a problem as too little. Still, it would be nice to capture enough to have a unique 'bug/crash fingerprint'. Everyone tells me this is impossible, but I'm an optimist. To be clear, it isn't that I object to the extra information; it is terrific if you can get it. It's just that if I could choose between a system that gets me low-quality data tomorrow, or high-quality data 2-4 release cycles from now, I'd choose the timely low-quality data in a heartbeat, and I think that many other people are instead opting for the latter because they believe the low-quality data is not useful. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Desktop Testing team
On Tue, Feb 10, 2009 at 4:14 AM, Ara Pulido a...@ubuntu.com wrote: Hello, We are proud to announce that a new GNOME team has been created, focused on desktop testing automation. If you have ever wondered how could you test your application writing scripts that mimic what a normal user would do, join us in this new effort. We have a mailing list [1], a wiki page with documentation[2] and a SVN module [3] with the initial work that we have done, but we need more people to get involve to make GNOME better and better. Please, join now the GNOME Desktop Testing team! Still not sure? Here [4] you will find a small how-to on how to run the available examples. Just give it a go! This is really terrific news! Has been needed for a long time. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Fwd: New Desktop Testing team
FWIW, this was originally on gnome-announce; for those who aren't on that list (1) you should be (2) here is the version with all the links included ;) -- Forwarded message -- From: Ara Pulido a...@ubuntu.com Date: Tue, Feb 10, 2009 at 4:14 AM Subject: New Desktop Testing team To: gnome-announce-l...@gnome.org Hello, We are proud to announce that a new GNOME team has been created, focused on desktop testing automation. If you have ever wondered how could you test your application writing scripts that mimic what a normal user would do, join us in this new effort. We have a mailing list [1], a wiki page with documentation[2] and a SVN module [3] with the initial work that we have done, but we need more people to get involve to make GNOME better and better. Please, join now the GNOME Desktop Testing team! Still not sure? Here [4] you will find a small how-to on how to run the available examples. Just give it a go! Cheers, Ara. P.S. The initial work is using LDTP (http://ldtp.freedesktop.org) as testing framework. Thanks to Nagappan Alagappan nagappan AT gmail DOT com for releasing and maintaining such a great tool. [1] http://mail.gnome.org/mailman/listinfo/desktop-testing-list [2] http://live.gnome.org/DesktopTesting [3] http://svn.gnome.org/viewvc/gnome-desktop-testing/ [4] http://live.gnome.org/DesktopTesting/InitialWork ___ gnome-announce-list mailing list gnome-announce-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-announce-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Desktop Testing team
On Tue, Feb 10, 2009 at 9:09 AM, API apinhe...@igalia.com wrote: From: Luis Villa l...@tieguy.org On Tue, Feb 10, 2009 at 4:14 AM, Ara Pulido a...@ubuntu.com wrote: Hello, We are proud to announce that a new GNOME team has been created, focused on desktop testing automation. If you have ever wondered how could you test your application writing scripts that mimic what a normal user would do, join us in this new effort. We have a mailing list [1], a wiki page with documentation[2] and a SVN module [3] with the initial work that we have done, but we need more people to get involve to make GNOME better and better. Please, join now the GNOME Desktop Testing team! Still not sure? Here [4] you will find a small how-to on how to run the available examples. Just give it a go! This is really terrific news! Has been needed for a long time. So the idea is add this Team to the current Testing section on GNOME Live?: http://live.gnome.org/JoinGnome#head-5fe33d37a35959b484d52ee0fb0d6d642d3730d1 Probably a good idea, could be a kind of integration with build-brigade, if possible (although I don't know if possible, I miss some information). Integration with build-brigade would be terrific. I did some work on automating the use of 'make check' in the build system ages ago, but for a variety of reasons it never took off. If something similar were to happen now that would be a huge boon for the project. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
[Let me preface this by saying that I respect the work the doc team has done, but given that their goals were to help users, I think we can best respect their work by asking the real and hard question of whether or not the docs, as they currently stand, are helping users, and not just glibly dismissing that question out of hand.] On Mon, Feb 9, 2009 at 10:25 AM, Dave Neary dne...@gnome.org wrote: Dan Winship wrote: Dave Neary wrote: - Should we just ditch the docs and declare the UI self-explanatory ? Definitely not. Why not? Because (a) the docs are pretty good, merely outdated, That statement just can't be true. Outdated docs not only don't help users, they *actively confuse* users. If they don't help users, and actively confuse, they are not 'pretty good' in any meaningful sense of the word, since one measures good docs by whether or not they help users, not by whether they helped users c. GNOME 2.2, or by how comprehensive the confusing coverage is. and (b) it would send a terrible message about the priorities of the project. Depends on how you did it. The message could be 'our software is so easy to use it doesn't need docs', which is a pretty damn good priority. Or the message could be 'we know our limits.' Or it could be 'we don't want to insult our users by pretending the docs, in their current state, are useful.' Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
2009/2/9 Natan Yellin aan...@gmail.com: On Mon, Feb 9, 2009 at 5:00 PM, Dan Winship d...@gnome.org wrote: Dave Neary wrote: - Should we just ditch the docs and declare the UI self-explanatory ? Definitely not. Why not? Seems like no one has ever bothered to file bug reports about the fact that they're wrong... Maybe there are as few people reading the docs as there are writing them. In a corporate setting, people will call their help desk when they have problems, and in a home setting, they'll either ask a friend/family member, or ask on a forum. (If people RTFMed first, we wouldn't need an acronym for it.) This is a moot point unless it can be proven. If we want to get rid of the docs, we need to run a survey/study first and determine how many people read them. Lack of bug reporting[1] about obviously broken things is the closest thing we've got to proof, and has in the past contributed to (IMHO) fairly sound decision making. Generally, we've never required stricter 'proof' than bug data, for a couple reasons: (1) we've got strict (unnecessary?) taboos about data collection from user machines (2) implementing valid survey-like data collection is hard. (3) the alternative, user 'studies', are also hard, time-consuming, and expensive to do right. (4) given all of the above, if we required Hard Proof for every design decision we'd never make any design decisions, because we don't have any real Hard Proof. That said: (1) some other projects are starting to do data-collection-driven UI studies (Eclipse, OOo, Moz) and perhaps now is the time to start thinking about doing the same here. We've even got some examples about how this can be done with very little privacy risk and little interference in user experience[2] so perhaps the taboos are less relevant as well. (2) since bug reporters are almost by definition experts, and docs are almost by definition useful for non-experts, the lack of bug reports may be a lot less useful than normal in informing a decision about docs. Luis [1] I'm taking for granted that there are in fact no bug reports; I really don't know and haven't looked in a long time, though certainly virtually no reports were filed about docs by regular users when I was active. [2] the principles informing the design of http://www.cs.wisc.edu/cbi/ could, IMHO, easily be applied to UI data collection. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Mon, Feb 9, 2009 at 11:39 AM, Matthias Clasen matthias.cla...@gmail.com wrote: On Mon, Feb 9, 2009 at 11:17 AM, Luis Villa l...@tieguy.org wrote: [1] I'm taking for granted that there are in fact no bug reports; I really don't know and haven't looked in a long time, though certainly virtually no reports were filed about docs by regular users when I was active. There are a couple of gnome-user-docs bugs complaining about some of the things I listed. I don't know if they were filed by 'regular users'. FYI, I emphasized 'regular users' since reports by the doc team, while useful, are not indicative (one way or the other) about usage patterns. Anyway, a simple alternative to a prolonged discussion about dropping docs and similar drastic measures is to just chime in and help making GNOME 2.26 the best documented GNOME since 2.2. I have done patches for about half the problematic capplets this weekend. I'm sure if some more people are willing do update one section each, we can have 100% accurate docs by the end of the month. +1 to that solution! :) As Jon McCann pointed out to me, sitting down and trying to write docs for a piece of software is a valuable excercise for developers, since it teaches you just how bad some of our UIs are... Amen. I've often felt developers should be required to document their own UI changes :) Heck, simply asking 'what does this dialog mean' would be useful a lot of the time...[1] Luis [1] ahem: http://tieguy.org/screenshots/terrible_dialog.png ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Mon, Feb 9, 2009 at 11:52 AM, Luis Villa l...@tieguy.org wrote: [1] ahem: http://tieguy.org/screenshots/terrible_dialog.png Actually, you know, up now. You can stop throwing tomatoes at me... Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
On Thu, Dec 4, 2008 at 11:00 AM, Olav Vitters [EMAIL PROTECTED] wrote: The GNOME Bugzilla is still using 2.20. Current stable upstream is at 3.2. The stable version has several benefits, but overall: * no crappy table locking, while still allowing full text indexing (table locking causes many performance problems) * Upstream supported XMLRPC (not perfect, but various things can be done, see WebService stuff at http://www.bugzilla.org/docs/3.2/en/html/api/) * Supported by upstream (security bugs) * bla bla see http://www.bugzilla.org/releases/3.2/new-features.html http://www.bugzilla.org/releases/3.0/new-features.html http://www.bugzilla.org/releases/2.22/new-features.html There is a proposal to upgrade the GNOME Bugzilla by: * having an external party do it (not me) * deliver the functionality in multiple stages (hard requirement) -- Means that not all the current functionality will be available! For that the proposal is that the following is not part of the initial upgraded bgo: * The points system * index.cgi UI mods * Making a new favicon * The infomessages on show_bug.cgi * Layout modifications for attachment table and the login box * duplicates.cgi modifications * Fixing the comment headers * Patch and keyword emblems * delete-keyword.pl, mass-reassign-bugs.pl, and year-end-stats.pl * describeuser.cgi Possibly even: * Canned responses (this would be a priority immediately after the upgrade) (the javascript stuff to say things are a dupe etc) * show_bug.cgi UI re-ordering float-right box * simple-bug-guide.cgi * Grouping products in a dl by classification when displayed * Asking people if they've provided the NEEDINFO info. * Boogle enhancements to QuickSearch (or maybe just implement the most important ones first and theno implement the rest later?) -- this is the GNOME specific 'simple search' Is above acceptable? IMO I find the following very important: * attachment table * describeuser.cgi * canned responses * Boogle but please focus on what you use: Is the reduced functionality trade-off acceptable if in the end we get a newer Bugzilla and the feature back? Note that likely some things will work in different ways etc. One question I'd have: are there any steps that can be/will be taken to minimize the pain during the inevitable next upgrade? Commitment to getting changes upstream, use of DVCS, etc.? Getting back to trunk bugzilla is a good goal and worth sacrificing features for, but it would be terrific if we could both stay near trunk and add new features without going through this whole painful cycle again next time we decide to upgrade. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
On Thu, Dec 4, 2008 at 11:51 AM, Olav Vitters [EMAIL PROTECTED] wrote: On Thu, Dec 04, 2008 at 11:31:28AM -0500, Luis Villa wrote: One question I'd have: are there any steps that can be/will be taken to minimize the pain during the inevitable next upgrade? Commitment to getting changes upstream, use of DVCS, etc.? Getting back to trunk Upstream: I'll check again. I wanted to have as much upstream as possible, but seems our BGO diff is a bit large and it would take even longer to push things upstream. As the external party is paid, there is a limitation on what can be done (would get too expensive). Oh, I'm fully aware that getting our current full set of patches upstream would be hard; they were a nightmare years ago, and our feature set and the pace of upstream's development and refactoring work have only accelerated since then. I meant more for new features we might develop after moving to 3.2- what steps will we take to make sure that we don't end up yet again with a gigantic mess of unmaintainable and/or non-upstreamable patches? Due to non-agreement yet the external party is private for now, so I'll try and provide more concrete answers when I get them. DVCS: Upstream uses CVS. There is a Bzr mirror, not sure how to use that effectively. Ewww. I had assumed that they moved primarily to Hg when the rest of mozilla did. Perhaps this is a good time to lobby them to move to a DVCS. ATM most of the problems are caused by combination of * lots of differences * lots of changes upstream (don't see how a DVCS would make things any easier with 2.20 - 3.2 ... but for future should be a good idea) Right. Again, the problems 2.20-3.2 are unsolvable and the result of lots of (ugly) history, much of it my fault. I'm not asking for miracles there. (Miracles would be nice! ;) The question is how do we avoid it in the future- hopefully part of the plan is 'do the next upgrade from 3.2-3.4 instead of 3.2-4.20' :) but I imagine other steps could possibly be taken as well. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reduced Bugzilla functionality for 6+ months -- acceptable?
On Thu, Dec 4, 2008 at 2:17 PM, Cosimo Cecchi [EMAIL PROTECTED] wrote: - simple-dup-finder Suggest we move crashes out of Bugzilla and into a separate database (like Socorro). Bugzilla should only be for hand-written input from technical people. Technically, bug-buddy is already capable of creating minidumps and push them to a crash.gnome.org server, and this would be great indeed, but AFAICT it requires a lot of coordination between us and distributions to provide: - a way for distributors to automatically push debug information to a centralized server for every package/update. - an unified way to get the version of a package, as distributors often ship two or more updates for the same upstream version. You don't need full symbols for crash information to be useful. It certainly helps, but we shouldn't let the perfect be the enemy of the good there. To be honest, I like more the way Ubuntu handles this, i.e. has its own crash server and pushes upstream only the good/unique traces. The crash information is (well, should be) the most important bug-related information GNOME has. Relying on the judgment of others to handle them should only be a last resort used if we're absolutely incapable of handling it ourselves. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Teaching GNOME to students...
Very cool! Good luck with the project, Emmanuel. Luis On Sun, Nov 2, 2008 at 11:57 AM, Emmanuel Fleury [EMAIL PROTECTED] wrote: Hi all, I'm associate professor at Bordeaux University and since few years I'm running a course with few other teachers about 'reading, understanding and managing _real_ code'. Since 2007, we chose to focus on the GNOME project because it matches everything we ever wanted to have for such a course: - A large amount of code, - Enough complexity to get the students over-helmed with it, - Highly documented, - A skilled and reactive community, - A bug and feature-request database (see later on), Our course is composed of a few theoretical courses and (mainly) three small projects: 1- Dig a part of GNOME and extract some technical understanding of it. Make some slides out of it and present it in front of all other students. 2- Take a bug from the issue list and dig it (bug resolution is not mandatory but at least have a deep explanation of the bug). 3- Take a feature-request from the issue list and implement it. Last year we chose the bugs almost on our own (thank a lot Vincent Untz who did provide his precious help to us when we had to sort a bit the bugs and the feature-requests). Here is the result (in French, I'm afraid): http://www.labri.fr/perso/fleury/courses/EMC07/projects.html For this year course it is now time for us to select bugs (not yet feature-request) and we would like to strengthen our link with the GNOME community by letting GNOME's developers suggest some bugs for our list. Benefit will be for all of us (you, students and my teachers team). First, it will let you choose bugs that you are interested to get solved (or a least... explored). Second, we noticed that our way of choosing last year made a lot of students very disappointed because nobody did get immediate interest in looking at the solution they proposed on the bugzilla (not all of them did post a patch but at least a few did). Having somebody interested in the resolution of the bug means that this shouldn't happen again. Third, browsing all these bugs, trying to evaluate their complexity, if they might be just too stupid or too difficult cost us a lot of time... where GNOME's developers could already have this knowledge. Now, let me describe the kind of bug we are looking at: - It MUST involve programming skills (fixing the spelling of a documentation is not our focus). - It MUST be confirmed, 100% reproducible and architecture independent. - It SHOULD have a medium complexity (meaning that it requires at least to browse and understand at least several hundred lines of code in the application to get a deep understanding of it... remember that our course is about reading and understanding a code which is not theirs. On the other hand, don't expect the student to be good at it, so if the difficulty is too high this might be risky). - It SHOULD not be in a high priority to fix it (if so, the students would be in concurrence with others and won't learn anything). We know by experience that choosing unsolved bugs is quite awkward because, indeed, they are 'unsolved'. So what if: - The difficulty you did expect for this bug is the wrong one: Well, this is the game. If you got misled and our team, when looking at the bug, did the same, it is up to the student to show us in his report that we did a wrong evaluation. - The bug get solved before the student give his report back: Still, he has to understand it, describe and evaluate the solution of the bug. This is not a problem. What do we expect from you... Well, submit bugs (several if you wish) that you think are relevant in this context. We need the bug ID in the bugzilla database and maybe few lines to explain why do you think this bug is relevant. The list of the bugs which will be selected will appear here: http://www.labri.fr/perso/fleury/courses/EMC08/projects.html We need about 12-15 bugs. If some students select your bug(s), just take a look at the discussion about this bug on the bugzilla from time to time. I insist on the fact that you are NOT requested to reply to the students (they are on their own concerning their relation with GNOME community). Do reply only if you want to. If a patch is posted, just do as usually... take a critical look at the patch and do what you want with it (hopefully, accept and merge it). But, you are not requested to give a mark on it (we do this internally and with our own criteria). Concerning the feature-request, the constraints will be about the same (but later... :)). Thanks in advance for your help ! Regards -- Emmanuel Fleury Associate Professor, | Room: 261 LaBRI, Domaine Universitaire | Phone: +33 (0)5 40 00 69 34 351, Cours de la Libération | Email: [EMAIL PROTECTED] 33405 Talence Cedex, France | URL: http://www.labri.fr/~fleury ___
Re: GSD should not housekeep the thumbnails
On Tue, Sep 16, 2008 at 8:59 AM, Dr. Michael J. Chudobiak [EMAIL PROTECTED] wrote: Right now .thumbnails grows without limit, which isn't good. The average user is surprised to find a 100 MB thumbnail cache in a hidden directory. Mine is 800M, which is 10% of my entire /home partition. And this is only after I've deleted it wholesale in the past when it grew past 1G. The current situation is insane. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Debian-specific patches for the GNOME packages
On Thu, Sep 11, 2008 at 7:48 AM, Vincent Untz [EMAIL PROTECTED] wrote: Le jeudi 11 septembre 2008, à 10:54 +0200, Josselin Mouette a écrit : Hi guys, it was already requested by a few people in the GNOME community to have a quick access to all patches distros apply. Since we now have a much better interface than the direct access to our svn repository, I think this might be of interest. So in short, what you might be looking for is here: http://patch-tracking.debian.net/email/[EMAIL PROTECTED] Awesome! I added a link to the (clearly outdated) http://live.gnome.org/VendorPatches wiki page Is anybody regularly reviewing/triaging those? I assume no, right? 'twould be a great project for somebody. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Debian-specific patches for the GNOME packages
2008/9/11 Josselin Mouette [EMAIL PROTECTED]: Le jeudi 11 septembre 2008 à 09:01 -0400, Luis Villa a écrit : Is anybody regularly reviewing/triaging those? I assume no, right? 'twould be a great project for somebody. We are trying to forward all those that are relevant for upstream in bugzilla, but given this is a manual process, we often forget some. I was thinking more on the GNOME side- if the distributors are doing an inevitably mixed job of getting things back upstream, maybe we should encourage a person or team of people to pull/review regularly. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
And login times? Impacted, not impacted? Application performance?
(Granted this last one is probably hard to get at, but it still seems
important to measure- we are, after all, considering something here
that could impact every single application.)
Tangentially, I'm disappointed with the 'a user can spend 10 seconds
to just turn it off' school of thought- that is not how we are
supposed to do things around here. We *fix* problems instead of
requiring users to somehow magically find the right set of options to
fix it for themselves. We know it'll take far longer than 10 seconds
to discover how to turn it off and stop paying the price. In fact, we
know most users will never discover how to do it. They'll just assume
GNOME is slow, if this does in fact slow GNOME down. So to say
'they'll just spend 10 seconds to turn it off' is not a GNOME-y way of
thinking at all.
Luis
On Thu, Jul 31, 2008 at 3:29 AM, Mark Doffman
[EMAIL PROTECTED] wrote:
Hi everyone,
Rob Taylor wrote:
Hmm, my take here is that the current AT-SPI is possibly a little too
heavy to enable by default. I'd suggest we look at enabling a11y by default
when the new AT-SPI DBus is ready (2.26 at current estimations)
I'll take my best guess about what happens when a11y is turned on:
1. The atspi registry daemon needs to be running.
'top' has the data memory usage at 550kb and the code size at 40kb. The
cpu utilization is exactly zero.
2. All gtk applications are going to load accessibility modules.
I'm not sure which modules are going to be loaded. I would say libgail
and libatk-bridge (including libspi). Perhaps not gail, isn't it now
included in gtk? Are liborbit and libbonobo loaded for other reasons on
gtk_init?
So the test program:
int main(int argc, char* argv[])
{
gtk_init(argc, argv);
gtk_main();
}
It uses 15464kb virtual memory and 596kb of data when accessibility is
turned on.
When accessibility is turned off it uses 13660kb of total virtual memory and
456kb of data.
So there is 150kb odd of data initializing the atk-bridge and libspi.
3. Accessible objects are created for gtk widgets / other UI elements.
Finding how an ATK object is created feels very much like jumping down a
rabbit hole. In the end though Gail objects and Bonobo servants are only
created on-demand. This means that there will be very little additional
memory usage if accessibility is turned on but not accessed.
This is the important part really. Bonobo servants might be very large, and
this, I think, is where ORBit/Bonobo gets its reputation for being heavy.
However, if a11y goes unused there shouldn't be any created.
I've cc'd Mark Doffman for his imput as he's probably got the most
experience profiling current AT-SPI behaviour.
Rob
Willie Walker wrote:
The way accessibility support works is that GTK+ loads accessibility
modules (gail and atk-bridge) if it detects that accessibility support is
enabled.
If accessibility support is not enabled when an application starts, I
don't believe there is a way to indicate to a running GTK+ application to go
ahead and load the accessibility modules retroactively. As such, one needs
to quit running applications and restart them in order for changes to the
accessibility setting to take effect.
The current user experience is very bad and kind of a Catch 22 situation:
in order to enable accessibility, they often need to use assisitve
technologies. In order to use assisitve technologies, they often need
accessibility enabled. So, what we do now is tell users to find some way to
enable accessibility for their session, then log out and log back in. It's
really embarrassing as far as I'm concerned.
I'll see if we can dig up some metrics on the costs of enabling a11y. If
anyone has good suggestions for how to do this and how to get numbers that
people will trust, I'd like to hear them. :-) Even if the numbers are not
favorable, however, I think I'd still argue to turn a11y on by default: it's
far easier for someone without a disability to turn it off than it is for a
person with a disability to turn it on.
Will
Mathias Hasselmann wrote:
Am Mittwoch, den 30.07.2008, 13:11 -0400 schrieb Willie Walker:
Alexander Jones wrote:
Isn't this a distro decision?
Ultimately, I guess the value for any gconf setting in
schemas/desktop_gnome_interface.schemas can be whatever a distro wants it
to
be. What I'm proposing, however, is that the default value that we choose
for GNOME is that accessibility will be enabled by default. If distros
want
to revert this back to disabling accessibility, I guess it would be their
choice.
What is the motivation for enabling accessibility by default?
Anecdotally
I have had 'assistive technologies' turned on now for a year. I am not a
user. My fairly modest computer (IBM T43 512mb of ram) hasn't had any
difficulties. I haven't seen any detrimental effect.
Having assistive technologies
Re: Proposal: enable accessibility by default for GNOME
On Thu, Jul 31, 2008 at 8:27 AM, Luis Villa [EMAIL PROTECTED] wrote: And login times? Impacted, not impacted? Application performance? (Granted this last one is probably hard to get at, but it still seems important to measure- we are, after all, considering something here that could impact every single application.) Tangentially, I'm disappointed with the 'a user can spend 10 seconds to just turn it off' school of thought- that is not how we are supposed to do things around here. We *fix* problems instead of requiring users to somehow magically find the right set of options to fix it for themselves. We know it'll take far longer than 10 seconds to discover how to turn it off and stop paying the price. In fact, we know most users will never discover how to do it. They'll just assume GNOME is slow, if this does in fact slow GNOME down. So to say 'they'll just spend 10 seconds to turn it off' is not a GNOME-y way of thinking at all. By the way, read this as opposition to turning it on by default. But I'd rather see the problems fixed and it eliminated as a run-time option altogether than for us to say 'we're shipping a broken user experience, but hey, the users have an option to unbreak it.' Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
On Thu, Jul 31, 2008 at 8:41 AM, Luis Villa [EMAIL PROTECTED] wrote: On Thu, Jul 31, 2008 at 8:27 AM, Luis Villa [EMAIL PROTECTED] wrote: And login times? Impacted, not impacted? Application performance? (Granted this last one is probably hard to get at, but it still seems important to measure- we are, after all, considering something here that could impact every single application.) Tangentially, I'm disappointed with the 'a user can spend 10 seconds to just turn it off' school of thought- that is not how we are supposed to do things around here. We *fix* problems instead of requiring users to somehow magically find the right set of options to fix it for themselves. We know it'll take far longer than 10 seconds to discover how to turn it off and stop paying the price. In fact, we know most users will never discover how to do it. They'll just assume GNOME is slow, if this does in fact slow GNOME down. So to say 'they'll just spend 10 seconds to turn it off' is not a GNOME-y way of thinking at all. By the way, read this as opposition to turning it on by default. But Gah! *don't* read this as opposition, sorry. I'd rather see the problems fixed and it eliminated as a run-time option altogether than for us to say 'we're shipping a broken user experience, but hey, the users have an option to unbreak it.' Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
On Thu, Jul 31, 2008 at 9:37 AM, Mark Doffman [EMAIL PROTECTED] wrote: Hi Everyone, Luis, Luis Villa wrote: And login times? Impacted, not impacted? Application performance? (Granted this last one is probably hard to get at, but it still seems important to measure- we are, after all, considering something here that could impact every single application.) Tangentially, I'm disappointed with the 'a user can spend 10 seconds to just turn it off' school of thought- that is not how we are supposed to do things around here. We *fix* problems instead of requiring users to somehow magically find the right set of options to fix it for themselves. We know it'll take far longer than 10 seconds to discover how to turn it off and stop paying the price. In fact, we know most users will never discover how to do it. They'll just assume GNOME is slow, if this does in fact slow GNOME down. So to say 'they'll just spend 10 seconds to turn it off' is not a GNOME-y way of thinking at all. I apologize for the '10 second' comment, especially as it might have taken away from my point. GNOME should be about fixing things, and as Willie pointed out, its currently broken for accessibility users. I agree that this is broken for a11y users, and that it is important that we do the right thing for those users. But the right solution then is to fix it for everyone, not to accept breakage for the other 99% of users. I believe that there is very little detrimental effect for the majority of users to turning accessibility on by default. I'd love to see hard performance numbers before we reach that conclusion. (I really don't care about memory numbers. Geeks look at top; my fiancee just sits and taps her fingers waiting for GNOME to log in.) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: project hamster
On Mon, Jul 28, 2008 at 9:36 AM, Dave Neary [EMAIL PROTECTED] wrote: motivating reason for rejection, also... most of the apps we ship are mostly useless to most of our users. Do you think so ? It may be I almost perfectly matched GNOME apps till today :) Looking in Utilities: I rarely use Calculator, Character map, or Disk Usage Analyser. You don't see me advocating they be dropped :) I'll go ahead and advocate dropping them, if it'll help ;) This is exactly the kind of app that makes me think we should have certification for non-core applications- a way to say 'this is great and useful and GNOME-y' (which it is) without saying 'this a part of the core of GNOME which is tied to our release cycle and QA standards.' Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
On Sat, Jun 21, 2008 at 11:26 AM, Havoc Pennington [EMAIL PROTECTED] wrote: Hi, 2008/6/21 Jason D. Clinton [EMAIL PROTECTED]: In my opinion, whatever The Next-Gen Gnome is, it isn't going to happen until we really, really have a deep maintenance cycle going on here. That means fixing a Handful of Giant Warts on our maintenance process: I bet the next-gen gnome will happen when someone writes it. I would suggest people think in terms of getting something going by themselves, and once it's at least roughly usable, think about recruiting 2 or 3 or 5 other people to the project. But getting hundreds of people to agree up front isn't too likely. Think 5 not 500. +1. This is not a gigantic company- you don't have to persuade the management to get permission to innovate. You have the code, and potentially you have the idea. So JFDI. If it is worthwhile, more people will come. git wouldn't hurt- anything that makes innovation by one person /easier/ (like DVCS) gets us closer to the day someone runs off and does Something Really Interesting. But like Havoc said the lack of it isn't an excuse either. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Project Hamster for GNOME 2.24
Looks cool. Not really related to 2.24 at all, but have you looked at the 'timeline' stuff nat wrote some years back[1]? Might be interesting to integrate that idea somehow. (Timeline has been on my mind, since I find the shell history meme that is all the rage on planet.gnome to be supremely ironic on a project which once had it as a goal to end shell usage.) Luis [1] http://cvs.gnome.org/viewcvs/timeline/ very little about it on the web, but search for timeline in this page http://nat.org/2004/august/ On Wed, Apr 16, 2008 at 7:36 AM, Toms [EMAIL PROTECTED] wrote: Hi guys! I would like to propose Project Hamster[1] for inclusion in Gnome 2.24 desktop suite I'm CCing gnome-doc-list since hamster has no documentation except for what's on the web site. * Purpose: Project Hamster is a nifty time tracking applet for the Gnome desktop. It helps to keep track on how much time has been spent during the day on set up activities. * Dependencies: pygtk python-cairo python-pysqlite2 * Resource usage Currently hosted on code.google.com. Willing to fully migrate * Adoption: None * GNOME-ness, community: Slightly integrated with evolution-data-server to get currently active TODO list items. All strings are translation-ready * Additional info: For building, standard Gnome autotools chain is used (used Deskbar Makefiles to sort those things out). Hamster has been recently exposed to Gnome Files, that allowed to verify it's readiness for desktop. Not being a native speaker, and this is my first time writing a proposal, so don't beat me hard. Looking forward for your feedback! Toms [1] http://projecthamster.wordpress.com/ [2] http://code.google.com/p/projecthamster/ ___ 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
Re: Module proposal: Conduit for GNOME 2.24
On Mon, Mar 31, 2008 at 7:02 AM, Bastien Nocera [EMAIL PROTECTED] wrote: I'd like to see the UI reviewed before giving it a +1, as I've had very hard times understanding how to actually make it work. Something a bit more like iSync (at least for the core PIM data) would be nice. +1. I tried to use Conduit (the version in F8, whatever that is) and couldn't figure out how to make it do *anything*, much less what I wanted it for (to sync my class readings folder to my Nokia.) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: communication/information between forward-looking projects [was Re: Some info (Ref: GSOC 2008 advice)]
On Fri, Feb 29, 2008 at 9:35 AM, natan yellin [EMAIL PROTECTED] wrote:
First of all, I'd just like to point out that I've only been using Linux for
about eight months. If anything I say is incorrect, corrections are more
than welcome.
On Fri, Feb 29, 2008 at 12:34 AM, Luis Villa [EMAIL PROTECTED] wrote:
On Thu, Feb 28, 2008 at 3:03 PM, Ketil Wendelbo Aanensen
[EMAIL PROTECTED] wrote:
Hi, I'm new on this list.
Luis Vila encouraged me to send some info to this list, so here goes:
Disclaimer: I'm not a developer, just an avid user of Gnome and
various eye candy. I especially follow Screenlets and AWN closely.
I firmly believe that people who communicate information between
developers can be just as useful as the developers themselves, so I'm
really glad Ketil posted this here. I for one certainly didn't know
some of this stuff (though admittedly I don't follow development
nearly as closely as I used to.)
Natan's post here ( http://theesylum.com/2008/02/01/desktop-20/ ) was
sort of eye-opening to me; I don't agree with everything he said but I
thought this was uncool:
I'm curious to know what you disagree with. I'm open to new ideas about how
universal applets should work.
It wasn't actually about the universal applets stuff, which I don't
really feel qualified to comment on. It was the comments about GNOME
3.0:
The GNOME community is strongly against anything that can be thought
of as GNOME 3.0.
I don't think that's correct, for a number of reasons. First, it
assumes that the broad GNOME community has one opinion on GNOME 3.0,
which is anything but the case- there is a lot of disagreement on the
issue. Second, if there is any one thing which is agreed on, I think
it would be less 'no GNOME 3.0' and more 'no 3.0 for the sake of 3.0'.
In other words, if someone can come up with something that truly
improves the *user* experience (*not* the developer experience) then
that should at least be considered as the core of a new GNOME.
But many reasonable minds might disagree on that :)
Probably the important thing is less what I think and more that if you
really can improve the user experience, then you're more than welcome
to and people will (and should) get excited about that. So don't let
what you've seen or read about GNOME 3.0 discourage you from getting
involved.
[T]here are multiple GNOME Desktop 2.0 apps that are being developed
independent of GNOME. There needs to be a common vision, goal, and
plan ***The communication between the different projects is
virtually nonexistent.*** (emphasis mine)
Like I said, I really don't follow development all that much any more;
if it isn't on planet or d-d-l I don't really know about it. So it's
possible that this claim isn't accurate. But if this last sentence
('communication ... is virtually nonexistent') is true, that's a big
problem for GNOME, no? (I did think it was somehow telling that
Natan's blog refers to this as being posted to gnome-love rather than
desktop-devel, which is nominally the center of desktop discussion for
us.)
I wasn't aware that d-d-l existed until today. As I said, I'm new.
Then clearly we're failing to get people on the same page. Problem for us. :)
Natan, I'm curious if you have any ideas on how to encourage
communication between the various projects which are looking at
radical change (besides the obvious one of Writing Code, which you're
obviously trying to do.)
Let's start with a planet blog for all Desktop 2.0 related projects. We may
want to even consider including KDE (and maybe even OS X and Windows)
developers.
I can set it up myself, if no one else feels like doing it.
I'd personally prefer to just get everyone involved onto an existing
planet, instead of fragmenting things more. If the problem is that
people are not feeling involved in GNOME then get them onto planet
gnome, not create another planet :) But I'm not doing the work so I
don't get much say :)
Luis
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSOC 2008 advice
One followup, one other suggestion, one followup. On Tue, Feb 26, 2008 at 2:49 PM, Luis Villa [EMAIL PROTECTED] wrote: * widgets: Vista, OSX, and KDE4 all have widgets/gadgets/Kthingies that are pretty, very easy to use, very easy to develop (since they are web-based), and which display more information when needed while staying hidden when not needed (both unlike our panel applets.) Some work has already been done on doing this with gtk-webkit[1]- perhaps that could be built on? (It seems to me that from a user perspective this approach is really superior to applets and what we should be focusing on long-term instead of reworking applets, but YMMV.) Both screenlets and gdesklets have been pointed out to me offlist. I was aware of both of them, but I didn't mention them here because I don't think writing our own custom widgets is the way to go- we should (at least to start) join the html-based widget bandwagon everyone else is already on so that we can benefit from that base of applications. Perhaps adding HTML widget support to one of them is the right thing, though. Suggestion: * backup: Apple's Time Machine is the greatest thing since sliced bread. Sadly, as is common with Apple apps, Linux has had all the pieces in place for this for ages (rdiff-backup, etc.) but never put it together in one sweet package. You could do that. caveat/advice: This is Summer of Code; changes building on established codebases are (IMHO) most likely to be sucessful. It may be appealing to take on big projects, but be careful not to bite off more than you can chew. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
communication/information between forward-looking projects [was Re: Some info (Ref: GSOC 2008 advice)]
On Thu, Feb 28, 2008 at 3:03 PM, Ketil Wendelbo Aanensen
[EMAIL PROTECTED] wrote:
Hi, I'm new on this list.
Luis Vila encouraged me to send some info to this list, so here goes:
Disclaimer: I'm not a developer, just an avid user of Gnome and
various eye candy. I especially follow Screenlets and AWN closely.
I firmly believe that people who communicate information between
developers can be just as useful as the developers themselves, so I'm
really glad Ketil posted this here. I for one certainly didn't know
some of this stuff (though admittedly I don't follow development
nearly as closely as I used to.)
Natan's post here ( http://theesylum.com/2008/02/01/desktop-20/ ) was
sort of eye-opening to me; I don't agree with everything he said but I
thought this was uncool:
[T]here are multiple GNOME Desktop 2.0 apps that are being developed
independent of GNOME. There needs to be a common vision, goal, and
plan ***The communication between the different projects is
virtually nonexistent.*** (emphasis mine)
Like I said, I really don't follow development all that much any more;
if it isn't on planet or d-d-l I don't really know about it. So it's
possible that this claim isn't accurate. But if this last sentence
('communication ... is virtually nonexistent') is true, that's a big
problem for GNOME, no? (I did think it was somehow telling that
Natan's blog refers to this as being posted to gnome-love rather than
desktop-devel, which is nominally the center of desktop discussion for
us.)
Natan, I'm curious if you have any ideas on how to encourage
communication between the various projects which are looking at
radical change (besides the obvious one of Writing Code, which you're
obviously trying to do.)
Luis
P.S. threads all time on d-d-l mentioning before yesterday:
screenlet[s]: 1
AWN: 2
gimmie: 16
online-desktop: 30
This is particularly shocking for screenlets, which AFAICT has had
more screenlets written for it in the past year than the panel has had
applets written for it in nearly a decade. There's a fairly large
community there- and it doesn't seem to touch GNOME much at all.
My inbox, which is where I'm drawing these counts from, suggests that
there have been 110 threads on d-d-l in the past year, so take these
with a grain of salt.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy replacement
On Fri, Feb 22, 2008 at 5:36 AM, Étienne Bersac [EMAIL PROTECTED] wrote: Hi, Just rewrite sticky note using Vala, you will make some users happy rather than poisoning d-d-l with flames. :) Don't port sticky notes. It's so 1980s. Tomboy is teh awesome. Seriously, I am very suprised that no one from the less central languages has tried to port Tomboy to their suggested language of choice (hello, Java people?) as a proof of concept to demonstrate that their language is as useful as C#/Mono. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy replacement
On Fri, Feb 22, 2008 at 7:23 AM, Patryk Zawadzki [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 1:16 PM, Luis Villa [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 5:36 AM, Étienne Bersac [EMAIL PROTECTED] wrote: Hi, Just rewrite sticky note using Vala, you will make some users happy rather than poisoning d-d-l with flames. :) Don't port sticky notes. It's so 1980s. Tomboy is teh awesome. Seriously, I am very suprised that no one from the less central languages has tried to port Tomboy to their suggested language of choice (hello, Java people?) as a proof of concept to demonstrate that their language is as useful as C#/Mono. Why would one rewrite something that works perfectly? ;) I would presume the people working on Java, Vala, etc. feel that their language could do it better and/or with fewer legal encumbrances, so given that Tomboy is indeed completely awesome I'm surprised no one has previously tried to port it, even if the functionality is indeed perfect. Even more seriously, language is a tool and you are free to pick the best tool for each job. It's better to have multiple lanugages crossed in GNOME than to use the same old hammer to put everything in place (even if a screwdriver would do a better job). That particular issue has been discussed to death here before, so I won't get into it, but suffice to say the question is not so clear cut; look into the archives for extensive discussion why. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy replacement
On Fri, Feb 22, 2008 at 10:43 AM, Sandy Armstrong Don't port sticky notes. It's so 1980s. Tomboy is teh awesome. Seriously, I am very suprised that no one from the less central languages has tried to port Tomboy to their suggested language of choice (hello, Java people?) as a proof of concept to demonstrate that their language is as useful as C#/Mono. Why would one rewrite something that works perfectly? ;) I would presume the people working on Java, Vala, etc. feel that their language could do it better and/or with fewer legal encumbrances, so given that Tomboy is indeed completely awesome I'm surprised no one has previously tried to port it, even if the functionality is indeed perfect. People have attempted ports and from-scratch replacements in languages ranging from C++ to Vala to Python. Some of these have been publicized, and sometimes we just get folks in #tomboy letting us know they're working on a Tomboy replacement in their chosen language. We never really hear from them again. Interesting. I think it's hard, when there is already a working and maintained application, to drum up excitement and motivation to work on a replacement. Of course. The most successful Tomboy replacements are apps like Zim and Basket that have a different approach to note-taking, and thus meet some users' needs better than Tomboy does. They focus on features and results instead of politics. I wish it were just politics. Microsoft making very public threats to sue our users and distributors is a very real problem which chills uptake of Linux generally, and I think belittling that threat as 'just politics' seriously understates the impact. Shipping Mono, which obviously is strongly associated (and at this point heavily funded by) Microsoft, does increase that chilling effect by giving them another talking point about Linux's inability to be innovative without copying from Microsoft's IP. This chilling effect is real whether or not the legal threat would hold up in court- if someone points a gun at you and says 'I'll shoot', most people will not sit down to quibble over whether or not the gun is loaded. I think once Microsoft made the public threats to customers and users of Linux (combined with Sun's admittedly imperfect move to GPL Java and the superior momentum behind Free tooling in the form of Eclipse) I *personally* moved from neutrality on the issue to being pro-Java. But obviously it is in the end for developers to decide, and you're right that an installed application base of highly polished applications like Tomboy is a big hurdle to overcome. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME's testing strategy for GUIs
On Feb 16, 2008 5:00 PM, Luis Villa [EMAIL PROTECTED] wrote: On Feb 16, 2008 4:50 PM, Willie Walker [EMAIL PROTECTED] wrote: I'd like to see documentation on 'GNOME recommended automated testing' for all the kinds of projects we see in GNOME (including for the various languages). I think this thread is a great way to try and get community consensus and to collect information on what various projects use. I suspect a lot of projects use none or very little (sadly, including GOK). IMHO this needs to change. Agreed. We tried to get some momentum back at GNOME Boston 2006 (http://live.gnome.org/TestingUsingAtSpi), but we never really gained traction. It may that the community wasn't ready then, but it might be ready now. As I suggested to Willie earlier in private mail, I think the key is getting something actually used. Get someone to run whatever tests there are on a regular, automated basis, and file bugs as a result. It will be imperfect (very imperfect to start with, owing to issues with the tools, lack of test coverage, etc.) but it will be better than nothing. That will: * create general developer awareness * encourage people to write tests, because they will know that the tests will be executed/used * encourage developers of the test harnesses to improve based on real-world feedback, which is obviously pretty lacking right now (though there appear to be some hints that it is happening) The rest (documentation, etc.) falls out of actually using it, IMHO. I might add that, when I last looked at the problem (a looong time ago, so take with a very large grain of salt) I felt that the right thing to do was to integrate this with 'make test' and run it as part of the jhbuild/tinderbox process, so as to get it the broadest possible use. But there may be other approaches that make the most sense. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME's testing strategy for GUIs
On Feb 16, 2008 4:50 PM, Willie Walker [EMAIL PROTECTED] wrote: I'd like to see documentation on 'GNOME recommended automated testing' for all the kinds of projects we see in GNOME (including for the various languages). I think this thread is a great way to try and get community consensus and to collect information on what various projects use. I suspect a lot of projects use none or very little (sadly, including GOK). IMHO this needs to change. Agreed. We tried to get some momentum back at GNOME Boston 2006 (http://live.gnome.org/TestingUsingAtSpi), but we never really gained traction. It may that the community wasn't ready then, but it might be ready now. As I suggested to Willie earlier in private mail, I think the key is getting something actually used. Get someone to run whatever tests there are on a regular, automated basis, and file bugs as a result. It will be imperfect (very imperfect to start with, owing to issues with the tools, lack of test coverage, etc.) but it will be better than nothing. That will: * create general developer awareness * encourage people to write tests, because they will know that the tests will be executed/used * encourage developers of the test harnesses to improve based on real-world feedback, which is obviously pretty lacking right now (though there appear to be some hints that it is happening) The rest (documentation, etc.) falls out of actually using it, IMHO. And by the way, I'm glad this discussion is happening- it is a *hugely* critical issue, I believe, and if the various distros/OSes collaborated to make this happen, would pay off at at least that 1:100 ratio mentioned earlier in terms of improved quality and robustness. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Feb 12, 2008 12:58 PM, Kalle Vahlman [EMAIL PROTECTED] wrote: There's people determined to make this work and working hard to do that, let's rather support them than make them feel rejected. That was absolutely not my intent; if the problem is as bad as was originally implied (that the .0 would not 'really' be .0) then those people are the most important people in the project for the next month :) They (and the QA people working with them) need to be making the decisions, with r-t as the organization putting the pieces together and responding to the needs/opinions of those subject experts, not as the decision maker. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Feb 12, 2008 11:15 AM, Matthias Clasen [EMAIL PROTECTED] wrote: On Feb 12, 2008 10:01 AM, Alexander Larsson [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 16:13 +0200, Lucas Rocha wrote: I can't say I'm happy about something like that though, since I spent the last 1.5 years or so trying to make this happen for 2.22. And if it gets postponed the code will get little or no testing and little use by apps, so I'm not sure it will be in a much better shape once 2.24 comes around. Yeah, I fully agree here. One thing we have seen with gio is that it is fine to work on something in your own little branch, and give talks about it, etc, etc, but real review and feedback only happens when the new stuff actually appears on the trunk, and people are forced to deal with it. The consequence of this is that the 6 month release cycle is a bit tight to go all the way from getting api feedback to stable without any end-user visible regressions... cranky old guy In the past, we from time to time discussed doing occassional nine-month cycles for major API changes like this one. Maybe it is time to have that discussion again, esp. if we intend to do any significant changes (online desktop integration? clutter/3D stuff?) in the near future. /cranky old guy Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Feb 12, 2008 8:53 AM, Murray Cumming [EMAIL PROTECTED] wrote: On Tue, 2008-02-12 at 08:42 -0500, Luis Villa wrote: On Feb 12, 2008 8:36 AM, Murray Cumming [EMAIL PROTECTED] wrote: Despite all the hard work, it doesn't look like the new Nautilus will be ready for GNOME 2.22 without regressions. Why aren't we talking about punting it until GNOME 2.23/24? We've never allowed this kind of thing before - punting would be entirely normal. We once delayed delays are generally very disruptive to other projects (distros, mostly) who have aligned with our schedule. Reverting would have to be really impossible. It isn't just that they are impossible, it is that they are also time-consuming- you have to separate them out from all the other changes made during the cycle, and that is not effort-free. If the delays are that big a deal to the distros, then they should lend some QA and development resources to the final sprint. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Feb 12, 2008 8:36 AM, Murray Cumming [EMAIL PROTECTED] wrote: Despite all the hard work, it doesn't look like the new Nautilus will be ready for GNOME 2.22 without regressions. Why aren't we talking about punting it until GNOME 2.23/24? We've never allowed this kind of thing before - punting would be entirely normal. We once delayed a release for a gtk release which wasn't yet stable, IIRC- the porting was too far along to revert the porting work in a timely manner (which I'm guessing is also the case here) and the regressions were too large to do a .0 (which also seems to be the case here, though I haven't followed it closely.) But agreed that the right thing to do is to delay the release rather than release a .0 with substantial regressions (as I ranted on a bit at my blog and on gnome-bugsquad.) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: State of gvfs in Gnome 2.21
On Feb 12, 2008 9:24 AM, Olav Vitters [EMAIL PROTECTED] wrote: On Tue, Feb 12, 2008 at 04:13:45PM +0200, Lucas Rocha wrote: I agree. We shouldn'd discard the possibility of either postponing the gvfs-based Nautilus or delaying the .0 release if needed. Obviously, releasing Nautilus with too many or some big regressions is not a good plan. More for release-team to decide, not d-d-l. Devs should code. Bzzt. Also wrong answer. r-t's role is in large part to reflect the will of devs, so devs should definitely be discussing how to prioritize and deal with this problem. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About SSL Trick or Treat Dialogs
On Dec 4, 2007 11:35 AM, Owen Taylor [EMAIL PROTECTED] wrote: On Tue, 2007-12-04 at 14:29 +, Stef Walter wrote: Dan Winship got me thinking about the unable to verify identify of this certificate dialogs we see in browsers when using self-signed or otherwise unverifiable certificates. I'm sure others have come to this conclusion: These are some of the most useless dialogs that exist, a major cop out. They basically asking the user something they can almost never possibly know. I'd like to propose [1] that we do away with these dialogs in GNOME. In my opinion if we cannot verify the certificate, then we should simply not show the UI elements that indicate a secure connection. We should just act as if the connection is like any other normal connection. Unfortunately, one of the main UI elements that indicate a secure connection is the https:// URL in the URL bar. Are you proposing to disguise that as well? Mozilla has proposed disposing of the protocol signifier altogether, in part (IIRC) for security reasons. http://weblogs.mozillazine.org/gerv/archives/2007/02/location_bar_proposal.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring has SSH, X.509 certificate and key support
On Dec 3, 2007 2:26 PM, Stef Walter [EMAIL PROTECTED] wrote: Luis Villa wrote: Comment 1: this is awesome. I'm very psyched to finally see proper ssh support, and in general to see better identity/key management in GNOME. This is hugely important- I think much more so than people seem to realize. Yes. I hope that with a solid modern PK infrastructure, applications will be able to use encryption in a way that doesn't stomp on users toes. Absolutely. Very exciting. Comment 2: will I still be required to re-auth post login with this release? or will access to the default keyring now be automatic with login? (You make reference to a 'login keyring', so I'm optimistic this is what you mean, but I wanted to double-check.) Yes, this is probably the most compelling reason for GNOME having a real certificate and key store: The integration with the users login. gnome-keyring 2.20 included support for unlocking the user's keyrings with the user's login password. And the current certificate store builds on that functionality. The 'login' keyring is a keyring that is unlocked by PAM upon successful authentication. When a private key needs to be unlocked (for example when using it to do an SSH login), the 'login' keyring is checked for a relevant password. Hrm. Will applications need to be modified to store to this keyring instead of the default keyring? Comment 3: have you talked to the Novell guys working on the Bandit Project aka DigitalMe? I just installed their linux build and firefox plugin[1] and got a really great authentication experience with two sites that use the CardSpace aka InfoCard standard.[2] It seems to already interoperate with the keyring, which is great, but it seems like it would be good if GNOME made sure to reach out to them and make sure that we're providing what they need. Interesting. I'll drop them a note [1]. [1] ... once I can manage to figure out access their mailing list without giving them an insane amount of personal info and '[x] we can spam you and yours' in order to create a 'Novell' account. Ah, Novell. Two steps forward, one step back. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-keyring has SSH, X.509 certificate and key support
On Dec 1, 2007 2:59 PM, Stef Walter [EMAIL PROTECTED] wrote: gnome-keyring 2.22 will include: * A proper SSH agent integrated with the user's login keyring * An X.509 key and certificate store than applications can use and share, and integrated with the user's login. I wanted to announce this well in advance of the release so that anyone who wants to coordinate features, or give advice, suggestions can do so. Comment 1: this is awesome. I'm very psyched to finally see proper ssh support, and in general to see better identity/key management in GNOME. This is hugely important- I think much more so than people seem to realize. Comment 2: will I still be required to re-auth post login with this release? or will access to the default keyring now be automatic with login? (You make reference to a 'login keyring', so I'm optimistic this is what you mean, but I wanted to double-check.) Comment 3: have you talked to the Novell guys working on the Bandit Project aka DigitalMe? I just installed their linux build and firefox plugin[1] and got a really great authentication experience with two sites that use the CardSpace aka InfoCard standard.[2] It seems to already interoperate with the keyring, which is great, but it seems like it would be good if GNOME made sure to reach out to them and make sure that we're providing what they need. Comment 4: wicked awesome. Luis (thinking about digital identity this morning in context of a paper I'm writing) [1] http://www.bandit-project.org/index.php/Digital_Me_Download [2] A Microsoft-proposed standard, but one that (as far as I know) has no competing open standard, and which (importantly) is covered by Microsoft's Open Specifications Patent Promise, discussed here: http://www.consortiuminfo.org/standardsblog/article.php?story=20060912140103877 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Royal National Institute for the Blind low-vision fonts now under GPL v3 - include in GNOME?
This is quite nice, Peter. With the proliferation of free fonts of late, we should definitely look into shipping/bundling some 'recommended' GNOME fonts, particularly this one, since (I assume) it has accessibility benefits. It is interesting to note that (as far as I can see from [1]) these fonts are under a 'pure' GPL v3, and do not carry the standard v2-based font exception.[2] Do you know if this was intentional, or just an oversight? There is an explanation of the font exception here: http://www.fsf.org/blogs/licensing/20050425novalis but it has not been updated for the v3. Luis [1] http://www.tiresias.org/fonts/fonts_download.htm and also from peeking inside the zip files [2] http://www.gnu.org/licenses/gpl-faq.html#FontException On Nov 23, 2007 12:35 PM, Peter Korn [EMAIL PROTECTED] wrote: Hi gang, I just received word (see attached) that the Tiresias family of fonts, designed by the Royal National Institute for the Blind for clarity and ease of recognition by folks with vision impairments are now available under GPL v3. The family includes fonts recommended and tested for use in signage, print, television, and computer use (the latter is PCFont - see http://www.tiresias.org/fonts/pcfont/about_pc.htm for details). I would like to recommend we consider redistributing these fonts with GNOME (or at least link to them so that UNIX distros that include GNOME might become aware of and potentially include this font). Regards, Peter Korn Accessibility Architect, Sun Microsystems, Inc. Dear Colleague, Free downloads are now available for the Tiresias fonts (LPFont, PCFont, InfoFont, SignFont, KeyFont) from www.tiresias.org/fonts/fonts_download.htm Work has continued on extending the list of standards which relate to accessibility of information and communication technology systems and on linking them to the committee responsible for each standard. Also, we now have a quarterly report on the current status of standards under development. The standards section is at www.tiresias.org/standards/ New and updated Guidelines Transport - Now covers air, rail, road and sea. This can be found at www.tiresias.org/guidelines/transport/ e-Voting - Now includes a new section on current voting practices for people with disabilities. This can found at www.tiresias.org/guidelines/e_voting.htm Household appliances - This new guideline can be found at www.tiresias.org/guidelines/household_appliances.htm Accessible tourism - These guidelines have been extensively revised and extended and can be found at www.tiresias.org/guidelines/accessible_tourism/ The website has been modified to make it easier to navigate with features such as breadcrumbs. What else would make it easier for you to use? Regards, Dr John Gill OBE FIET Chief Scientist Scientific Research Unit RNIB 105 Judd Street London WC1H 9NE Tel +44 20 7391 2244 Web: www.tiresias.org -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com ___ 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
Re: [gimmie] Re: Proposing Gimmie applet for 2.22 -- check out 0.2.8
On Oct 31, 2007 5:18 PM, Alex Graveley [EMAIL PROTECTED] wrote: * There is an experimental standalone panel version of Gimmie. This can be branched into a sub-project, or simply not installed by default. I am *not* proposing to expose this panel alternative as part of GNOME. There are many other interesting panel alternatives which are seeing a lot of love. Left the standalone dock in for now, as no one weighed in either way on hiding/removing it. My two cents on this: a panel that treats people and documents as true top-level objects (like gimmie does) is an exciting and innovative future that GNOME should be actively pursuing. It would be a shame if this great experiment got dropped out of gimmie. [If I were GNOME BDFL, the question I would ask would not be 'should the gimmie applet be in GNOME', but rather 'how can GNOME replace the panel with the gimmie dock (and/or o-d?), and drop applets altogether in favor of widgets/gadgets/plasma-like technology.' And I'd be begging njp to make gimmie dock (and/or o-d?) as shiny as awn, but without the crack-y gnome-1.0-y prefs panel ;) ] Luis (pulling on the flame-proof suit) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Agnubus?
On 11/1/07, J French [EMAIL PROTECTED] wrote: Thanks, I'll certainly have a look at those. Offhand (and I really haven't looked at any code yet), I'm thinking it'll probably be easiest to use GIMP as a base and then throw a word processor on top of that (or maybe Inkscape or something else that does vectors) with some nice database connectors (at least for MySQL). it seems to me that everything's there and just needs to be trimmed down and brought together. Thoughts? Frankly, I'd like to see an s5 editor (inc. themes): http://meyerweb.com/eric/tools/s5/ a format I can display (not necessarily edit) on any machine anywhere, and publish to the web, is vastly more useful than any other format. Luis ___ 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.22
On 9/27/07, Andrew Cowie [EMAIL PROTECTED] wrote: On Thu, 2007-09-27 at 10:03 +0100, Martyn Russell wrote: I wouldn't re-license it [there is tons of both context and history here, which the rest of this thread covers. On the topic of licencing, however:] I must admit that as an advocate of software freedom and as someone who works for a firm that releases its work under the GPL, I am not adverse to the idea of a GNOME library being licenced under the GPL only. I realize full well that there is a certain fraction of the wider universe of people who use the GNOME platform who are using it under the pragmatic terms of the LGPL to write their proprietary software. Some of those companies contribute to our community their IP and their employees' time, and that's fantastic. I hugely respect, however, the expression that has been made by people who wrote software under the GPL that they wish it to remain so licenced. That's their call, and it is effectively final. It is of course their call. And likewise it is the GNOME community's call not to accept libraries licensed as such. We have a very longstanding and very deliberate policy to license our libraries LGPL, and it has served us well. This is not the time to change it, *especially* since we want these libraries to be deeply embedded into all of GNOME, not just some applications. Luis ___ 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.22
On 9/27/07, Mikael Hallendal [EMAIL PROTECTED] wrote: 27 sep 2007 kl. 15.32 skrev Luis Villa: Hi, On 9/27/07, Andrew Cowie [EMAIL PROTECTED] wrote: On Thu, 2007-09-27 at 10:03 +0100, Martyn Russell wrote: I wouldn't re-license it [there is tons of both context and history here, which the rest of this thread covers. On the topic of licencing, however:] I must admit that as an advocate of software freedom and as someone who works for a firm that releases its work under the GPL, I am not adverse to the idea of a GNOME library being licenced under the GPL only. I realize full well that there is a certain fraction of the wider universe of people who use the GNOME platform who are using it under the pragmatic terms of the LGPL to write their proprietary software. Some of those companies contribute to our community their IP and their employees' time, and that's fantastic. I hugely respect, however, the expression that has been made by people who wrote software under the GPL that they wish it to remain so licenced. That's their call, and it is effectively final. It is of course their call. And likewise it is the GNOME community's call not to accept libraries licensed as such. We have a very longstanding and very deliberate policy to license our libraries LGPL, and it has served us well. This is not the time to change it, *especially* since we want these libraries to be deeply embedded into all of GNOME, not just some applications. I'm a bit unsure about how useful libempathy-gtk would be for third party applications? Do we have any use cases for this as a library. From the way I suggested at the time of the fork was to make Empathy run on top of Telepathy and create the required applications for integrating with mission control etc. This doesn't require an external library though. For example I can't see the chat dialog widgets to be all that useful to other applications as they should preferably message Empathy to show a chat dialog for a specific user. The same with most of the other widgets, roster widget and possibly vcard/info dialogs excluded. It is entirely possible that this libempathy is one of those extraneous libraries that is at the wrong level to make LGPL relevant- I'm even less of an expert on this stuff than I was when I was active :) My point was that the choice to include a GPL library should be made based on the project's policy, not based on the preferences of the authors of the library. In other words, the decision tree should go something like (obviously simplified and cutting out all the personal/technical/political choices/negotiations): 1) project decides if it wants the library; if the project wants the library then... 2) project decides if the library needs to be LGPL; if the project thinks the library should be LGPL then... 3) library copyright holders decide whether or not to relicense. If they won't want to relicense, the library doesn't go in. Andrew seemed to be suggesting skipping step 2, and I wanted to kill that idea quickly- the project's long-standing strategy and preferences are extremely important and can't just be casually ignored. Luis ___ 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.22
On 9/27/07, Mikael Hallendal [EMAIL PROTECTED] wrote: 27 sep 2007 kl. 16.00 skrev Luis Villa: Hi, It is of course their call. And likewise it is the GNOME community's call not to accept libraries licensed as such. We have a very longstanding and very deliberate policy to license our libraries LGPL, and it has served us well. This is not the time to change it, *especially* since we want these libraries to be deeply embedded into all of GNOME, not just some applications. I'm a bit unsure about how useful libempathy-gtk would be for third party applications? Do we have any use cases for this as a library. From the way I suggested at the time of the fork was to make Empathy run on top of Telepathy and create the required applications for integrating with mission control etc. This doesn't require an external library though. For example I can't see the chat dialog widgets to be all that useful to other applications as they should preferably message Empathy to show a chat dialog for a specific user. The same with most of the other widgets, roster widget and possibly vcard/info dialogs excluded. It is entirely possible that this libempathy is one of those extraneous libraries that is at the wrong level to make LGPL relevant- I'm even less of an expert on this stuff than I was when I was active :) My point was that the choice to include a GPL library should be made based on the project's policy, not based on the preferences of the authors of the library. Yes, I completely agree. My fault for using your mail to reply to even though I was replying more in general and not to your comment. No, my fault, I wasn't clear in my response, and frankly hadn't completely realized the libempathy/libtelepathy distinction. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New clock applet for 2.22
On 9/25/07, Ross Burton [EMAIL PROTECTED] wrote: On Tue, 2007-09-25 at 09:20 -0400, Matthias Clasen wrote: The screenshot of the calendar does not show the week number (it's useless clutter, relaly). I think the week number is there in the released versoin due to the way the GtkCalendar widget works. Those can (and should be) be turned off. The calendar should maybe be made a bit more useful in general, maybe adding some decorations to show which days have appointments, deadlines or birthdays, Currently, it is just a field of numbers that takes up quite a bit of room. Nooo, please keep week number. For some people it's actually really useful! New d-d-l rule: no one gets to say 'it is useful' without explaining their use case :) Luis (I believe you that you use it, but I can't for the life of me figure out why) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop integration ideas
On 7/22/07, Alexander Boström [EMAIL PROTECTED] wrote: sön 2007-07-22 klockan 10:26 -0400 skrev Havoc Pennington: I think when possible, it can be nicer to store stuff online via the online app that edits it - e.g. store photos on Flickr, rather than store photos in a remote filesystem or something. I thought OD really wasn't at all about moving the home directory to a server, but about making the desktop integrate nicely with the services that are already out there. +1 for clarification on the motives/interest there. I really don't grok the desire to move all my settings to a server; SunRay has done that for years and has gotten exactly zero traction with it. It seems like the least interesting part of the o-d discussion, so it seems odd for that to be the first thing to focus on. But then again, I'm one of the many, many millions who has solved the problem by carrying my laptop everywhere so maybe I'm not the target market ;) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop integration ideas
On 7/22/07, Havoc Pennington [EMAIL PROTECTED] wrote: Luis Villa wrote: On 7/22/07, Alexander Boström [EMAIL PROTECTED] wrote: sön 2007-07-22 klockan 10:26 -0400 skrev Havoc Pennington: I think when possible, it can be nicer to store stuff online via the online app that edits it - e.g. store photos on Flickr, rather than store photos in a remote filesystem or something. I thought OD really wasn't at all about moving the home directory to a server, but about making the desktop integrate nicely with the services that are already out there. +1 for clarification on the motives/interest there. Hmm, well in my slides the mission-statement thingy was: The perfect window to the Internet: integrated with all your favorite online apps, secure and virus-free, simple to set up and zero maintenance thereafter. Integration with online apps is more part of window to the Internet while syncing a few of your homedir files is more the zero maintenance part. If we aim for zero or low maintenance, one goal might be no manual backup/restore headaches. snip good discussion Fair. I understand it much better now. Still think you'd do well to focus on the window to the internet portion at first, though, given that (as Jeff points out) file sync is sort of dull. It is a real problem, but if you solve it for most people they will say 'eh' right up until they need it. Drive good integration with the internet and people will go 'ooh' as soon as they see it, and be reminded every day how interesting/useful it is. The dull parts you can build later. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME's license and Apache? (Adding Simpy to epilicious)
[I think you probably meant desktop-devel-list instead of gnome-devel list; am cc'ing d-d-l.] On 4/11/07, Magnus Therning [EMAIL PROTECTED] wrote: (I'm not entirely sure where to send this so pardon the cross-posting.) I'm looking into adding support for Simpy[1] to epilicious (an extension to Epiphany, part of epiphany-extensions since 2.18). There is a Python module that makes it easy to deal with Simpy, which is great. However that module is licensed under Apache License version 2 and [2] says that license doesn't play nice with GPL2. Your [2] is correct; GPL2 and Apache do not play nicely together. For what it is worth, I have noted to the FSF/SFLC today that we are seeing an increased interest in linking Apache licensed code into GNOME code, and that GNOME would be very appreciative if Apache and GPLv3 were interoperable. The responses I got from the various lawyers involved was positive, so it is possible that this may happen. What are my options in this case? Is dual-licensing a possibility (given that I can convince the author of course)? Absolutely, if you can convince them to do it. This would almost certainly be the best route to take. Would there be a problem at all from a GNOME POV to simply include the Python module in question? (It would make it into GNOME SVN at some point.) Historically GNOME doesn't really care what license you use to put things in SVN, but we have typically required GPL/LGPL for things which are in project releases. Additionally, I'd hope we never put anything in the release with a conflicting license problem. Writing a small Python module tailored for epilicious needs is of course always an option, but I'd like to avoid that if possible ;-) Of course. But realize that it is likely a better option than flaunting the licenses. :) Before someone else mentions it, I'm not sure how Ephy's extensions work; it isn't completely impossible that some combination of liberal reading of the GPL + specific behavior of the extensions means that the extension + plugin is not a covered work and hence the conflict doesn't matter. (This is similar to how Ubuntu distributes proprietary kernel modules, even though the kernel is GPL v2.) I would not recommend following this route, though; down that route lies pain. HTH- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discussion for a more robust panel layout
On 3/20/07, Manu Cornet [EMAIL PROTECTED] wrote: Hi! Recently the problem of changes of resolutions has been raised [1] on the usability list. I would like to start a discussion about how to manage the effect of resolution changes on the panel layout better than what we do today. This implies another way of storing the panel layout. I know Vincent Untz already thought a bit about this and there were a few short talks on this matter, but I'd like to make a proposal and try to start a discussion about this. Here is the wiki page I set up for this: http://live.gnome.org/GnomePanel/RelativeLayout Does this seem sane to you? How would you do otherwise? How would you enchance the current proposal? I'd just make sure that one of the use cases which the final design covers is devices which rotate, like tablet PCs and iphone-like devices. It seems likely that they will become more common, and while I can't think of any situations offhand where they are substantially different from merely changing resolution, it should be kept in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating our list of GNOME contributors
On 3/6/07, Vincent Untz [EMAIL PROTECTED] wrote: Hi, Do you all remember that we list our contributors in About GNOME? The list of GNOME contributors is probably outdated: many people contributed a lot of stuff in recent years and are not there. It's a shame to not thank them, so we have to fix this! It would be really great if all maintainers could take 10 minutes and check that all of their main contributors are listed in there. To do so, open this URL and look for the name of your contributors: http://svn.gnome.org/viewcvs/gnome-desktop/trunk/gnome-about/contributors.h?view=markup If there are some missing contributors, send me a private reply with the names of those contributors. I'll make sure to add them before 2.18.0. It'd be great to have the non-ascii characters in hexa, so for example: Mariano Su\xc3\xa1rez-Alvarez instead of Mariano Suárez-Alvarez. I'll ask for a hard code freeze break to get this in (yes, this is code ;-)). And I'll buy a $BEVERAGE_OF_CHOICE for anyone who makes the dang thing sexy and less slow in 2.19.0. This is 2007; if our about box doesn't optionally utilize GL, surely we've failed. :) Bonus points for making it take less than, ya know, about a million hours to go through the whole list :) [And a full case of $BEVERAGE_OF_CHOICE to whoever goes through the list of top bugsquad contributors and makes sure they are all in there for 2.18.0. Unsung heroes and all that.] Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for a Gnome Media Center
[I'll note that the direction the rest of this thread has gone is indicative of why I'm very, very pessimistic about the long-term health of GNOME right now. Take this as a mild attempt to get back on track by talking about users and user experience instead of capitalization of directories which users should never see anyway, and which has previously been discussed repeatedly, endlessly and without resolution.] On 2/13/07, Christian F.K. Schaller [EMAIL PROTECTED] wrote: I guess from our point of view we would be interested in hearing what requirements/expectations people have for something like a media center solution to be included as a 'part of GNOME'. I'd suggest that the requirement ought to be something like 'the interaction with existing GNOME systems provides a good experience for GNOME users and experienced GNOME developers.' i.e., don't be GNOME; be something that plays nicely with the existing GNOME Desktop. That means something like: * interoperates smoothly with the desktop user experience. Focus here on good user experience, not which technologies are used. This means you need to figure out first in what ways the desktop user experience and the media center user experience interact, before you can figure out whether or not something is GNOME-y. (The mentions of nautilus, specific music players, etc., in this thread were probably a mistake- the focus should have been on the user experience. My mistake in starting that.) * GNOME developer knowledge transfers over decently, with reasonable reasons and replacements for technologies that aren't used. For example, you're probably right that the GNOME Enterprise Desktop HIG doesn't make sense for a GNOME Media Player; but perhaps it should be a requirement that a GNOME Media Center have its own written, documented HIG. Similarly, it probably makes sense to toss a lot of API, but the release team might require that the new API surface be documented. Note that this sort of presumes that we have a good developer experience for the core desktop, which may not be true, and so we should not construe this to be a high bar. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
prioritization [was Re: Call for a Gnome Media Center]
On 2/14/07, Murray Cumming [EMAIL PROTECTED] wrote: On Wed, 2007-02-14 at 11:27 -0500, Luis Villa wrote: [I'll note that the direction the rest of this thread has gone is indicative of why I'm very, very pessimistic about the long-term health of GNOME right now. Take this as a mild attempt to get back on track by talking about users and user experience instead of capitalization of directories which users should never see anyway, and which has previously been discussed repeatedly, endlessly and without resolution.] It's not just about Capitalization. It's about localization. Getting it wrong will upset significant amounts of people for a long time. The answer is not to ignore the difficult decision. It needs to be presented as a choice between various pros and cons, with a decision being made for one choice or the other, clearly stating that we believe one set of disadvantages is not as bad as another. Then moving on. Dealing with complex issues properly doesn't mean that we are incapable of deciding. Quick decisions often lead to pain and misunderstanding. We are somewhere in the middle. The discussion is of course important, which is why we've had it repeatedly, and it is hard, which is why we've had it repeatedly and not solved it. But we've devoted something like thirty emails in this thread alone to it, with no signs of it slowing, plus (IIRC) something like seventy emails the last time, and who knows how many prior to that. And we've devoted less than ten emails to the topic that started the thread- an idea which would massively and substantively improve our user experience and broaden our impact, and *which Christian has correctly pointed out will have failed if people ever see a file heirarchy*. So... fine. I'll grant that it is important. Go ahead, discuss it. My problem is in continuing to discuss it 5-10 times as much as we're discussing actually moving us forward, helping our users, and striking at our competitors. While we're busy having that discussion, and not discussing media centers, Apple and Microsoft are busy developing Apple TV and Xbox and kicking our asses in yet another area. Luis P.S. To put it another way, I recall from our last discussion of this that Apple hasn't solved it either. And I agree that it sucks. And in the meantime, while it has sucked, they've settled on ~/Music, moved on, worked on iTunes, and iTunes has taken over the world. The localization (or lack thereof) of ~/Music has not hurt them, because they are writing awesome software. This discussion is completely failing to help us write awesome software. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: prioritization [was Re: Call for a Gnome Media Center]
On 2/14/07, Christian F.K. Schaller [EMAIL PROTECTED] wrote: the Elisa hackers are not sitting on their hands Of course. I didn't mean to belittle them, or the mugshot team, or any of the various other teams who are working on furthering GNOME while avoiding desktop-devel. I had written a much longer response, but if I continue this thread, I'll be again distracting from discussion of goals and vision, which would defeat the whole point. So I'm going to drop it now and get back to Con Law... Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call for a Gnome Media Center
On 2/11/07, Étienne Bersac [EMAIL PROTECTED] wrote: Hi, It's more usable that your proposal (get someone to start something from scratch) as it exists, so I don't see your point. Elisa has exactly the same goals as the Apple and Microsoft media centres. Hi, my proposal was just a braindump, useful in case no project were up. Since Elisa is on, and pigment seems very nice, my proposal worth nothing ! However, it seems Elisa is not Gnome enough. Is there plan to integrate it ? There are three ways something can be more gnome-y: (1) interoperates well with existing GNOME technologies (2) uses GNOME UI metaphors/HIG. (3) uses GNOME libraries. I'd suggest that (1) is critical for a 'GNOME-y' media center, and that the other two are at best likely problematic. To elaborate a bit on (1): What I'd like is that when I get a new laptop and a new media player box, to download two CDs (ignore the underlying OS for now): one that is a 'desktop' and the other a 'media center'. When I install the desktop, I get what we all know and love: something fairly easy to use, powerful, etc. GNOME 2.x. When I install the media center, I want it to immediately interoperate with that desktop- no setup, no thinking, I want it to Just Fucking Work. That to me is what I mean to be GNOME-y. My f-spot should have 'publish to the TV' option; my rhythmbox should immediately read music files from the media box, and vice versa; all my file dialogs should suddenly offer a save location on the media server (inc. my bittorrent client, which maybe should automatically offer to save to a video directory?); my ipod plugged into my desktop should allow me to get music files from my media server (my media server is under a desk so I can't plug the ipod into it), etc. Potentially it should offer to be the automatic backup server for my regular desktop files, since presumably my media box has tons of free space. (In my dream world, my N800 also immediately does smart things.) To me, that level of automatic, seamless interoperation with existing GNOME apps is what it means for a media center to be 'GNOME-y'. Note that in many cases this probably means hacking on the desktop apps as well, but such is life- we can't just expect to have a good user experience by hacking on one code base. There may be some (3): * muine does a great job thinking about albums and album covers; elisa currently does not do that as far as I can tell. Sharing that code (instead of reinventing that wheel) would be great. * elisa already does use pango, I believe? (maybe I'm confusing it with opened-hand's clutter?)(I see that it uses cairo through 'pigment'; I'm sort of surprised that pigment and clutter seem to be substantially overlapping.) Hard to see (2): * radically different resolutions and font needs, not to mention wanting more visually pleasing (aka non-gtk themed) UI * not wanting file/edit/view menus everywhere; heirarchical menus being crappy, etc. I do agree that it is *critical* that we have a GNOME-y media center like this- Apple is going to do this with their Apple TV; Microsoft is doing this with XBox. We must push forward and innovate in this space if we want to remain interesting/relevant in home spaces in the future. But we shouldn't hobble it by being any more 'GNOME-y' than good, seamless integration requires. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: slab menu
On 2/6/07, Alex Graveley [EMAIL PROTECTED] wrote: Please constrain useless comments like this to private email. Yeah. That was not constructive. Things that might have been constructive: * here is how slab clones windows, and here is some usability reasoning on why that particular cloned functionality is bad * here is how slab clones windows, and here is some discussion of an alternate path that some other GUI took, and why we might want to do that instead etc. 'windows bad, cloning windows bad' is value-free. (I'm not personallly sold on the slab, but that has more to do with things like the apparent lack of tarball releases and (at least in the version that is in Feisty) the lack of very basic things like obeying fitts' law when in the panel. But those are concrete problems that can be discussed and addressed; 'it clones windows' is not, and hence isn't useful.) Luis P.S. Despite not being sold on slab for the desktop, I'm *desperately* awaiting the day it is ported to the N800 ;) Alex Jones wrote: Let's face it, slab was conceived out of Novell's desire to make SuSE a drop-in for Windows. I don't think this is the direction we want to be taking GNOME, personally. ___ 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
Re: slab menu
On 2/6/07, Luis Villa [EMAIL PROTECTED] wrote: the lack of very basic things like obeying fitts' law when in the panel. FWIW, this is now bug: http://bugzilla.gnome.org/show_bug.cgi?id=404978 I assumed it was known, but apparently not (because it is a semi-edge case). Lesson: never assume a bug is already filed. :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Boston Summit 2006 is on Echelon's radar
I know a couple folks were talking about something like this a few months ago, and I believe some code was even written- Shaun? There were even some less creepy names- heartbeat, maybe? :) [Speaking as someone who wants to observe GNOME from afar, I'm intensely interested in seeing this go forward, so good luck.] Luis On 10/10/06, Patrick Wagstrom [EMAIL PROTECTED] wrote: Howdy Folks, Does it sometimes feel like managing all your GNOME related information is like drinking from a firehose? Are you disappointed with how difficult it can be to find that marble of interesting projcet information in the swimming pool of oatmeal that is the constant chatter of GNOME worldwide? Are you looking for a better way to understand what's hot in email, CVS, blogs, bugzilla, and still get all the useless links off #gnome-hackers? Fortunately, there's creepy folks like me who have been tracking a lot of that information. The problem has been how do we expose all this information to everyone in a method that is beautiful and makes sense. The answer, Echelon for GNOME. Echelon for GNOME is a project to make sense of all this data. What's hot on Planet GNOME? Has there been a really cool CVS commit in the past few days that you just need to check out? With all the mailing list threads, wouldn't it be nice if I could just see the ones that other people think are interesting? After discussing a myriad of ways that we could rip off KDE's English Breakfast Network, we concluded that a digg like interface that can bring all these things together would be a great innovation. That, is the premise of Echelon for GNOME. Is it ambitious, probably. Is it cool, yes! Can we actually use the term digg for when we find something cool, probably not. Instead, we'll VERB it (where verb is something like excavate, drill, stomp, flag, shimmy, dance, shake, etc). Interested? Me too. I've put a brief wiki page with some of the discussion notes at http://live.gnome.org/Boston2006/EchelonForGnome Feel free to look and modify it. --Patrick -- devel-announce-list mailing list devel-announce-list@gnome.org http://mail.gnome.org/mailman/listinfo/devel-announce-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ToPaZ, anyone?
On 9/22/06, Alex Jones [EMAIL PROTECTED] wrote: Hey, Brian! Please don't take this the wrong way, but from what I can see, you might as well not even call this GNOME! Not having seen the mockups at all, but... so? I believe we call that 'thinking outside the box'. Luis On Fri, 2006-09-22 at 16:49 +0300, brian muhumuza wrote: http://live.gnome.org/BrianMuhumuza/ToPaZ -- Alex Jones [EMAIL PROTECTED] ___ 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
Re: Contribution
On 8/25/06, Maxim Udushlivy [EMAIL PROTECTED] wrote: Johan Dahlin wrote: I'm not sure I see the point of one more ui designer and one more ui loader... Johan I dare to say that I am offering a Porsche 911 while you are talking about broken bicycles ;) You might want to explain *why* you think that :) Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Fwd: [iCommonslab] APC CHRIS NICOL FOSS PRIZE IN 2007
Sounds like this is *right* up GNOME's alley- $4K for projects/people doing usability/accessibility work. Luis -- Forwarded message -- From: Fouad Riaz Bajwa [EMAIL PROTECTED] Date: Aug 24, 2006 5:20 PM Subject: [iCommonslab] APC CHRIS NICOL FOSS PRIZE IN 2007 To: [EMAIL PROTECTED] === ANNOUNCING THE APC CHRIS NICOL FOSS PRIZE IN 2007 Making it easy to use free and open source software === The APC Chris Nicol FOSS Prize recognises initiatives that are making it easy for people to start using free and open source software (FOSS). The prize will be awarded to a person or group doing extraordinary work to make FOSS accessible to ordinary computer users. The APC FOSS Prize has been established to honor Chris Nicol, a long time FOSS advocate and activist who for many years worked with APC. We are looking for initiatives that: * improve the accessibility to, knowledge of and/or usability of FOSS * are user-oriented * are documented so that others can learn from and replicate the model * have demonstrable impact and have increased the number of people using FOSS on a day-to-day basis THE PRIZE IS OPEN TO: Any person or group anywhere in the world who supports or promotes user-oriented free and open source software. The application form must be completed in either English or Spanish however there are no language restrictions regarding the language of the project. Small-scale activities are encouraged to apply. THE PRIZE: US$ 4,000.00 may be shared by up to two initiatives at the jury's discretion. DEADLINE FOR NOMINATIONS: March 30 2007 MORE ABOUT THE APC CHRIS NICOL FOSS PRIZE: http://www.apc.org/english/chrisnicol http://www.apc.org/espanol/chrisnicol or write to [EMAIL PROTECTED] ABOUT THE ASSOCIATION FOR PROGRESSIVE COMMUNICATIONS (APC) http://www.apc.org The Association for Progressive Communications is an international network of civil society organisations dedicated to empowering and supporting groups and individuals through the strategic use of information and communication technologies, especially internet-technologies. === Courtesy of ___ APCNews mailing list [EMAIL PROTECTED] http://lists.apc.org/mailman/listinfo/apcnews Forwarded for information by --- Fouad Riaz Bajwa General Secretary - FOSS Advocate FOSSFP: Free Open Source Software Foundation of Pakistan (r) Secretariat Cell: 92-333-4661290 Tel: 92-42-5030039 E-Mail: [EMAIL PROTECTED] URL: www.fossfp.org ; www.ubuntu-pk.org Disclaimer: This e-mail message is intended for its recipient only. If you have received this e-mail in error, please discard it. The author of this e- mail or FOSSFP: Free and Open Source Software Foundation of Pakistan (R) takes no responsibility for the material, implicit or explicit. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.11.5/426 - Release Date: 8/23/2006 ___ iCommonslab mailing list [EMAIL PROTECTED] http://lists.ibiblio.org/mailman/listinfo/icommonslab ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/26/06, Brian Nitz [EMAIL PROTECTED] wrote: Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. Also because GNOME does not take the time to make the benefits clear. I believe part of the job of a distro-focused bugmaster would be to say 'you filed X bugs upstream this quarter; Y percentage of them were fixed by the community', or other such numbers that would clarify the value to the distro. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. All distros should be pushing for this :) Would it perhaps be useful to have a QA summit at the Boston Summit, where the various distros could compare notes on upstreaming technique, and see if there are ways they could collaborate? What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) bug-buddy is inching in this direction, but yeah, tied to gdb right now. Would be great to see some investment in this by the distros (who are, after all, the ones directly financially impacted by crashes.) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. I believe bug-buddy already does this, no? An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) I like this idea, but would consider it a secondary priority until we can better handle crashes. Baby steps :) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. Latest bug-buddy does this now, I believe. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. We're getting there ;) A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing
Re: Putting the 'Mono debate' back on the rails
On 7/24/06, Andy Wingo [EMAIL PROTECTED] wrote: Hi, On Mon, 2006-07-24 at 16:11 +0100, [EMAIL PROTECTED] wrote: parallel-instabllable is the worst idea of software development. See http://ometer.com/parallel.html for the reasons why GNOME does it this way. And forgive me if I mis-remember, but isn't versioning and parallel installability a Sun ARC requirement? I seem to remember much sun-sourced kvetching circa 2002 that .gnome should really have been .gnome-1.4 and .gnome-2.0, which seemed very reasonable to me at the time. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
what happened to the build discussion?[was Re: dbus building pains]
Tangential to this, there was an awesome BOF at GUADEC about continuous build integration, which hopefully would avoid problems like this. Has there been any news on that front that I missed? :) Thanks- Luis On 7/24/06, Jason D. Clinton [EMAIL PROTECTED] wrote: After bludgeoning jhbuild to get it to build the latest CVS checkouts, I have reached a point I can't get past. The dbus developers on Freenode can't seem to help either. An informal poll on #gnome-hackers says that GNOME has been unbuildable for at least the past few days. Anyone who can shed some light on this would be much appreciated. make[2]: Entering directory `/home/jclinton/cvs/gnome2/dbus-glib/tools' DBUS_TOP_BUILDDIR=.. dbus-send --system --print-reply=literal --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.Introspectable.Introspect dbus-bus-introspect.xml.tmp mv dbus-bus-introspect.xml.tmp dbus-bus-introspect.xml Failed to open connection to system message bus: Failed to connect to socket /home/jclinton/var/run/dbus/system_bus_socket: No such file or directory make[2]: *** [dbus-bus-introspect.xml] Error 1 make[2]: Leaving directory `/home/jclinton/cvs/gnome2/dbus-glib/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jclinton/cvs/gnome2/dbus-glib' make: *** [all] Error 2 So apparently, dbus-glib is attempting to contact the dbus server built in the previous module. Some googling came up with this build log: http://home.rubberturnip.org.uk/jhbuild-logs/20050726-01/dbus.html Which seems to imply that, at least at one point, the build attempted to start a temporary instance of the dbus server. Is this not the case now? Has anyone built GNOME in the past few days? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQBExSRttSqjk42zvwkRAmqkAJ42PJ+cZPlpQDwcnnJ76TSFNqtv/QCdGY85 SjugblEorMs5KTY440uWf8E= =B1fS -END PGP SIGNATURE- ___ 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
Re: what happened to the build discussion?[was Re: dbus building pains]
On 7/24/06, Frederic Peters [EMAIL PROTECTED] wrote: Luis Villa wrote: Tangential to this, there was an awesome BOF at GUADEC about continuous build integration, which hopefully would avoid problems like this. Has there been any news on that front that I missed? :) Things I know: Thomas looked at issues with coverage support in GCC 4 and got it working[1], igalia guys[2] have been hacking on jhbuild to get different checkout behaviours and D-Bus integration[3]. As for me I added a few features to jhautobuild so Prashanth[4] can integrate LDTP test results and not much else, hacking habits suffered from summer weather. CC'ing to build-brigade@ Ah, I didn't see the announcement of the list. I guess further discussion should go there. Totally understand about the summer weather- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Legal) advice needed
On 7/21/06, Rouquier Philippe [EMAIL PROTECTED] wrote: Hi, Here is the problem I've run into. I'm the author of bonfire, an app for burning CD/DVD (http://gnomefiles.org/app.php?soft_id=1158). Recently I've been given a CVS account to import it into GNOME CVS. Before I did it, a user reported that bonfire was a name used by a Canadian site selling music to be downloaded (http://bonfire.puretracks.com/). Apparently they had trademarked this name (see http://strategis.ic.gc.ca/app/cipo/trademarks/search/tmSearch.do?language=eng and search for bonfire). Application # 1218927 and 1218917 for those wondering. So, my question is: Is it still OK to import bonfire into GNOME CVS or should I change the name before? We don't have a formal policy on such things, but obviously we'd prefer to avoid known legal problems. Of course I'm reluctant to change the name for many reasons, being: - the site is Canadian, I'm French and GNOME servers are in the USA, so maybe trademark doesn't apply in this case IANAL(Y)* but some things to consider: (1) trademarks can be extended; i.e., it is likely that if Best Buy wanted to file to use this mark in the US or France, they would get it and could cause you legal problems in a completely traditional, valid way. (Though you have been using it in the US and France longer than they have, so you might win the case, but it would be expensive, a PITA, etc.) (2) GNOME does try to distribute in Canada; it would be irritating if a Canadian court told us we had to block ftp.g.o from being seen by Canadians :) This is a very messy area of the law, with very little settled precedent, but again, they could try to make life irritating/expensive/not fun. - bonfire just started to get included in some major distribution and changing the name will postpone everything - it's a new application and changing the name would confuse many people You should ask the Ekiga guys about that- it would seem that their name change went pretty smoothly. - above all, Bestbuy (the trademark holder) won't really care about my app having the same name This is a legal and strategy decision for them, but they are probably *required* by trademark law (if Canadian law is anything like American law) to care about your app having the same name, at least in Canada. If they don't defend it against you, they can lose the right to use the mark to describe software, which presumably is a big problem for them. What I thought was: import bonfire into GNOME CVS and wait and see. If Bestbuy reacts (which I doubt but who knows) I would change the name. But I really want to make sure that it's not an issue for GNOME. I'd certainly suggest being proactive, changing the name now, and getting it over with instead of letting it hang over your head- if bonfire is incredibly successful, someday this *will* be a problem. Whether or not it is a problem for GNOME should probably be left to a real lawyer- if the only legal penalty is 'you have to change the name', then it probably shouldn't be a problem for GNOME; if the potential legal penalty is 'change the name and fork over a lot of cash', then the board should probably think about it :) Luis * Hi Dave! Hi Jeff! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mac shipments up 12% [Was: focus!]
Gartner has the overall PC market up 11% last quarter, so this isn't as impressive as it sounds. http://www.macsimumnews.com/index.php/archive/gartner_apple_sees_154_percent_in_year_over_year_mac_sales/ Still, the 4.6% overall market share in that article is the highest I've seen cited for Apple in years. Luis On 7/20/06, Jeff Waugh [EMAIL PROTECTED] wrote: quote who=Jeff Waugh quote who=Christian Fredrik Kalager Schaller Actually I have to say we should stop idealizing Apple that much, they are a company which basically has gone from being the desktop leader to today being a fringe player. They have survived partly by clinging onto a couple of niches like graphical design and to some degree education. That was true five years ago. Good timing: Macintosh shipments were up 12 percent compared with last year, Apple said on Wednesday during its third-quarter earnings call. ... Macs accounted for 55 percent of Apple's revenue during the third quarter, ended July 1, said Peter Oppenheimer, the company's chief financial officer. Notebook shipments and revenue both increased by 61 percent, and Apple believes it doubled its share of the notebook market in retail channels, he said, citing data from research firm NPD. About half the Macs sold at Apple's own retail stores during the quarter were bought by people who had never owned a Mac before, Oppenheimer said. ... Gartner and IDC reported PC market share numbers on Wednesday, and overall shipment growth was only around 10 percent worldwide. Apple's 12 percent shipment growth outpaced the market during what is considered the slowest quarter of the year. http://www.zdnet.com.au/news/hardware/soa/Macs_see_growth_spurt/0,261702,39264094,00.htm - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ What did the sausage say to the tomato at breakfast? There's not mushroom this morning, is there? ___ 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
Re: Mac shipments up 12% [Was: focus!]
On 7/20/06, Jeff Waugh [EMAIL PROTECTED] wrote: quote who=Luis Villa Gartner has the overall PC market up 11% last quarter, so this isn't as impressive as it sounds. Still, the 4.6% overall market share in that article is the highest I've seen cited for Apple in years. It's the growth and potential that worries me. :-) They've had better software and better hardware than Windows for a full five years, and have still not cracked 5% market share, so I don't see why you're scared now- they've had good quarters before, and they end up getting lost in the noise. This doesn't mean they suck, but I think it does speak strongly to Havoc's point- just being differentially better will not win big market share; we need to think about how to change the game completely if we're going to 'win' in any meaningful way- i.e., more than 5% market share. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On 7/19/06, Ben Maurer [EMAIL PROTECTED] wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. Bt. Wrong. A couple things we know right now: * without what bug-buddy gives us currently, GNOME would be nigh-unusable. * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. Now, many things could be done to improve this, of course- most concretely, I firmly believe the payoff on investment would be multiplied many times for the distros if they invested in a full-time bugmaster whose responsibility was coordination for getting bug information upstream and downstream. *If* they did that, or otherwise committed more thoroughly to getting their data upstream in a manner that was timely and useful, it might make sense for stack traces to go to the distros- as you point out it, it is easier for them to provide complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the tools to get bugs upstream, even if they did get better stack traces) this feature should be taken away over the dead bodies of the QA team. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
On 7/19/06, Alex Graveley [EMAIL PROTECTED] wrote: Respectfully, I don't agree. There is a big set of missing frameworks that stops rich interop in Gnome applications, and generally make applications much harder to write well. All other desktop platforms include at least a subset of these... * Document framework Provides document loading/saving/printing/etc abstractions, window/tab management, automatic recently used, scripting hooks, etc. * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. * Rich Extension/Plugin framework Common UI for installing/removing plugins and checking for updates and downloading, common hooks for menu/toolbar integration and UI event integration. * Undo framework Almost no applications in Gnome support good Undo. Should provide both reliable desktop-wide interaction for text widgets as well as at an abstract object level. * Rich DND/CopyPaste framework Undocumented DND targets, poor support, and manual data parsing abound in our applications. Could provide structured data interop to make doing this loads easier. * Persistence framework Saving and indexing application-internal data, optionally exposing to search engines like beagle. I'd add: * collaboration framework (though maybe the Abi guys are pushing in this direction in a way we can all use) * web integration framework- we know that MS is going to make all their apps backend to various web services in the not-too-far future, and we know that we can make our apps much more compelling if (for example) f-spot integrated seamlessly with web-based picture sharing, or gourmet integrated seamlessly with web-based recipe sharing. * search framework. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: vino
Hi, Ted: Judging from the changelog: http://cvs.gnome.org/viewcvs/vino/ChangeLog?rev=1.133view=markup and this bug: http://bugzilla.gnome.org/show_bug.cgi?id=159874 development might best be described right now as 'very slow' :) You can find the primary maintainer's email in there by skimming a bit; it does look like he is willing to take patches and give advice if one can be patient. Sorry, that's the best I can say right now- Luis On 4/21/06, Ted Shab [EMAIL PROTECTED] wrote: I'm trying to find out if anyone is actively developing vino at this point in time. I had a few questions for them on what would be involved in introducing true RSA key encryption. Thanks. --Ted ___ 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
Re: Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
[Andrew responded off list, and got it just right, so I'm forwarding.] On 4/21/06, Andrew Sobala [EMAIL PROTECTED] wrote: Alex Graveley wrote: HELLO?! Check 1-2-3? The discussion *was* about Tomboy. An small app I wrote that people like, and which could benefit from adoption in GNOME. Thanks for throwing any chance for productive discussion out the window. Running the risk of putting words into other people's mouths, I don't think that's what Luis meant. The question of Should Tomboy be integrated into the GNOME Desktop spawned the question of Should Mono applications be integrated into the GNOME Desktop - and that question shouldn't be answered just with reference to Tomboy, it should be answered with awareness of the fact that there is a huge wealth of mono applications out there, and we are shooting ourselves in the foot if people whine about the implementation language. But otherwise the conversation would go Why are we adding a dependency on Mono for a notes application - and stop right there. On 4/21/06, Andrew Sobala [EMAIL PROTECTED] wrote: Alex Graveley wrote: HELLO?! Check 1-2-3? The discussion *was* about Tomboy. An small app I wrote that people like, and which could benefit from adoption in GNOME. Thanks for throwing any chance for productive discussion out the window. Running the risk of putting words into other people's mouths, I don't think that's what Luis meant. The question of Should Tomboy be integrated into the GNOME Desktop spawned the question of Should Mono applications be integrated into the GNOME Desktop - and that question shouldn't be answered just with reference to Tomboy, it should be answered with awareness of the fact that there is a huge wealth of mono applications out there, and we are shooting ourselves in the foot if people whine about the implementation language. But otherwise the conversation would go Why are we adding a dependency on Mono for a notes application - and stop right there. Yeah, that's exactly what I meant. Alex, if you read Murray's response, it was of the form 'no tomboy, because no C#, because doing c# just for tomboy is dumb'. That line of logic is what I was trying to stop. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re:Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
On 4/20/06, Murray Cumming [EMAIL PROTECTED] wrote: On Thu, 2006-04-20 at 22:38 +0200, David Neary wrote: Hi, Elijah Newren said: But, a more important question: We currently only allow apps using the python bindings into the desktop. Is this true, or is it just because no-one's ever asked? We've had extensive discussions about it on this list. Python is the only one that almost nobody objects to, and a lot of people would prefer us not to use too many programming languages in the official Desktop modules. But luckily, not everything needs to be in the Desktop. I certainly wouldn't want to add the political, technical, and strategic baggage for just a note taking utility. But lets be honest here. This discussion isn't about tomboy. We need built in search; we're getting some of our best reviews in ages because of our (currently optional) built in search: http://www.eweek.com/article2/0,1759,1948842,00.asp?kc=EWRSS03129TX1K616 If this discussion is about any app in particular (it probably shouldn't be, but it probably will be) this discussion is really about beagle, not tomboy. Luis (why, what a big pink elephant you have in your pants^Wroom) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
On 4/20/06, Glynn Foster [EMAIL PROTECTED] wrote: On Thu, 2006-04-20 at 22:28 +0200, Vincent Untz wrote: Le jeudi 20 avril 2006 à 14:19 -0600, Elijah Newren a écrit : So, new question we have to address before addressing Alex's proposal: Should Mono be a valid dependency and C# a blessed language? I believe the answer should be yes. We're starting to see a lot of projects in C#, and I think all the major distributions are shipping mono now. Ahem, not quite true [1]. Neither JDS nor RHEL are yet. No idea if RHEL will. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
(temporary) RETURN OF TINDERBOX MAN
Ahem. (picture a burning box on my chest) (also imagine that I am flying, sticking my fist out) (also, imagine that I'm not me, but rather I'm some mild-mannered Belgians. Still flying, though.) http://jhbuild.bxlug.be/builds/2006-04-16-0002/logs/gnome-icon-theme/#install A bit of googling turned up the culprit here, but it would be nice if the non-installation of icon-naming-utils caused a more interpretable error condition than this. Remember, we want to make it easy for people to build this stuff reliably. More like this coming soon, I'm sure ;) Anyway, if you've got a non-standard OS/architecture that you'd like tinderboxed, you too can put on the cape of the supertinderboxer: http://jhbuild.bxlug.be/participate FYI- Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Overall State of Documentation [was Re: Gnome is a problem for OEMs]
On 4/12/06, Brent Smith [EMAIL PROTECTED] wrote: Scott J. Harmon wrote: Too bad that documentation is horribly out of date. Seems like nobody wants to contribute to documentation these days... Updated PDFs for 2.14 at http://www.gnome.org/~bmsmith/gnome-2-14-pdfs/ Check out system-admin-guide.pdf for information on how to edit menus. we should really get these on the main site Where is library.gnome.org going these days? Completely stalled? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-applets branched
Plans! Plans! On 4/13/06, Davyd Madeley [EMAIL PROTECTED] wrote: gnome-applets has been branched for active development towards GNOME 2.16. --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ 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
Re: Proposal to add Orca to GNOME 2.16
Willie- This sounds awesome. How does it fit with gnopernicus? Should we retire gnopernicus from the release, or do they play nicely together, or...? (Forgive me if this has been discussed before and I missed it.) Luis On 4/10/06, Willie Walker [EMAIL PROTECTED] wrote: Hi: I'm writing this to propose that Orca becomes an official module of GNOME 2.16. Orca is a scriptable, extensible, AT-SPI-based screen reader that provides access to the graphical desktop for people with visual impairments. Orca has been part of the GNOME CVS repository for over two years, and has undergone a substantial overhaul in the past 10 months, with blind people being involved in the design each step of the way. The Orca team recently outed Orca at CSUN '06, which is the California State University Northridge, Center on Disabilities, Annual International Conference on Technology and Persons with Disabilities. The response to Orca at CSUN was outstanding, and the activity and comments on the [EMAIL PROTECTED] (archives at http://mail.gnome.org/archives/orca-list/) have been very positive. More information on Orca can be found here: http://www.gnome.org/projects/orca/ http://live.gnome.org/Orca Sincerely, Willie Walker, Project Lead, Orca ___ 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
Re: Proposal to add Orca to GNOME 2.16
On 4/10/06, Willie Walker [EMAIL PROTECTED] wrote: Hi Luis: As with gpdf/evince and galeon/epiphany and others, Orca and Gnopernicus provide the same high level reason for being, and you typically would use one or the other. As the lead for Orca and friends of the Gnopernicus team, however, it find it hard for me to make an unbiased comparison between Orca and Gnopernicus. What I would feel very comfortable saying is that two approaches to screen reading are different, and giving people with disabilities a choice of which to use is a good thing. So, in those cases, we have tended to prefer that the experts involved pick one, so that (for example) the translation teams and QA teams spend their time and effort improving the 'best of breed' app, instead of doing both. You'll note that is what we did with gpdf/evince (the lead gpdf hacker now hacks on evince, I believe) and what we did with galeon/epiphany (galeon is now folding itself into epiphany, though I have no idea how far along this is.) This is not necessarily the best procedure- it certainly means we have to pick a winner/loser (which sucks), and means we typically have to do it prematurely (even worse.) And I'm sure in the a11y case, this is even worse, since most feature needs are non-negotiable. But this approach does reduce duplication of effort from outsiders (good for us), focuses core developers on one tool (usually good for us), and gives clear signals to our users about what they should typically use (which is good for them). So... dunno. We've always made it a fairly strict rule to keep apps that have substantial duplication out of the desktop. This might be the right time to break that rule, or throw it out altogether and consider alternatives, like certification. I think on balance, though, there are some very good reasons for it and we'd do well not to toss it lightly just because we're faced with a difficult choice that the experts appear reluctant to do for us. Luis On Mon, 2006-04-10 at 16:10 -0400, Luis Villa wrote: Willie- This sounds awesome. How does it fit with gnopernicus? Should we retire gnopernicus from the release, or do they play nicely together, or...? (Forgive me if this has been discussed before and I missed it.) Luis On 4/10/06, Willie Walker [EMAIL PROTECTED] wrote: Hi: I'm writing this to propose that Orca becomes an official module of GNOME 2.16. Orca is a scriptable, extensible, AT-SPI-based screen reader that provides access to the graphical desktop for people with visual impairments. Orca has been part of the GNOME CVS repository for over two years, and has undergone a substantial overhaul in the past 10 months, with blind people being involved in the design each step of the way. The Orca team recently outed Orca at CSUN '06, which is the California State University Northridge, Center on Disabilities, Annual International Conference on Technology and Persons with Disabilities. The response to Orca at CSUN was outstanding, and the activity and comments on the [EMAIL PROTECTED] (archives at http://mail.gnome.org/archives/orca-list/) have been very positive. More information on Orca can be found here: http://www.gnome.org/projects/orca/ http://live.gnome.org/Orca Sincerely, Willie Walker, Project Lead, Orca ___ 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 ___ 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
Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
On 4/9/06, Andrew Sobala [EMAIL PROTECTED] wrote: Jaap Haitsma wrote: Richard, As far as I understand the code of GPM splitting up GPM in a daemon and a notication area icon/applet would not be so hard. They are pretty independent from each other. The daemon just has to watch batteries, laptop lid, hardware keys and take appropriate actions etc. If people run the daemon then they get all the power management features. The applet/notification area icon just needs to watch the batteries (code of the daemon can be reused :-) )and show the status by changing it's icon and displaying notifications. The only message I see that the daemon might want to send to the applet is a message that the system is going to suspend/hibernate and that is already something we want to do to notify other apps that the system is going to suspend/sleep and that they need to take appropriate actions if necessary. So in my opinion it's not that difficult, or am I missing something? But what's the point? 1. It's good design to split up parts which are doing different things ( You can also put all your code in one source file, but that's not good design ) 2. An applet would be much more consistent with how GNOME works at the moment. If I want to add something to the panel I just add there by doing Add to panel and if I want to remove it I choose Remove from panel. GNOME unlike windows luckily doesn't put many stuff automagically in the panel :-) It's worth pointing out that gnome-power-manager is very much a notifier rather than an interactive applet. If your power cable falls out, it pops up a message saying you've lost power. If you're working away from a power source, there's a battery indicator with how much power you've got left... that disappears when you're fully charged. (At least, that's how it's configured on my system.) This isn't the default, FWIW. I do agree that making this the default behavior would be the best approach- better, IMHO, than a regular panel applet. I only want to know about power when something bad is going wrong, which is exactly what the notification area is for. An applet is all the time, and so is the current default behavior in the notification area- both of which are broken. Luis Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager
On 4/9/06, Corey Burger [EMAIL PROTECTED] wrote: On 4/9/06, Luis Villa [EMAIL PROTECTED] wrote: On 4/9/06, Andrew Sobala [EMAIL PROTECTED] wrote: Jaap Haitsma wrote: Richard, As far as I understand the code of GPM splitting up GPM in a daemon and a notication area icon/applet would not be so hard. They are pretty independent from each other. The daemon just has to watch batteries, laptop lid, hardware keys and take appropriate actions etc. If people run the daemon then they get all the power management features. The applet/notification area icon just needs to watch the batteries (code of the daemon can be reused :-) )and show the status by changing it's icon and displaying notifications. The only message I see that the daemon might want to send to the applet is a message that the system is going to suspend/hibernate and that is already something we want to do to notify other apps that the system is going to suspend/sleep and that they need to take appropriate actions if necessary. So in my opinion it's not that difficult, or am I missing something? But what's the point? 1. It's good design to split up parts which are doing different things ( You can also put all your code in one source file, but that's not good design ) 2. An applet would be much more consistent with how GNOME works at the moment. If I want to add something to the panel I just add there by doing Add to panel and if I want to remove it I choose Remove from panel. GNOME unlike windows luckily doesn't put many stuff automagically in the panel :-) It's worth pointing out that gnome-power-manager is very much a notifier rather than an interactive applet. If your power cable falls out, it pops up a message saying you've lost power. If you're working away from a power source, there's a battery indicator with how much power you've got left... that disappears when you're fully charged. (At least, that's how it's configured on my system.) This isn't the default, FWIW. I do agree that making this the default behavior would be the best approach- better, IMHO, than a regular panel applet. I only want to know about power when something bad is going wrong, which is exactly what the notification area is for. An applet is all the time, and so is the current default behavior in the notification area- both of which are broken. Luis I completely disagree. There are a few good reasons why an icon should be displayed all the time 1. What state the battery is in is always relevant. Power is the single most important thing on a laptop. Without it, you are going nowhere. Wrong. It only matters when you're getting so low you are in danger of losing work, or when the status changes, or in a couple other corner cases which can be designed for. It is *not* the most important thing- the most important thing is whatever work I'm actually *doing*. I strongly recommend reading 'Designing From Both Sides of the Screen', where one of the simple design heuristics is to make software that acts like a butler (or in this case, a chauffeur.) As you drive around town, does your chauffeur say 'by the way sir, the gas tank is now 59% full.' (minutes pass) 'oh, now 58% full sir.' No. If your chauffeur did that, you'd fire him for being an irritating idiot. A good chauffeur tells you 'Sir, the tank is very nearly empty- shall I find a station?', and a great chauffeur asks you once 'how early would you like me to warn you about the gas, sir?' and then remembers that in the future. When you pull the plug out of the wall, I mean, when you come upon the sign that says 'huge desert- no gas for a long way', a good chauffeur says 'Sir, we only have enough gas for 299 miles at current consumption- would you like me to turn around?' A good chauffeur, of course, does allow you to ask 'how much gas do we have?' whenever you get nervous, and admittedly we don't have a great way of doing that right now when the icon is purely in notification mode. It would be better to figure that out, though, than to needlessly put the information on the screen all the time. Relevant sections of the book, by the way, in google book search: http://tinyurl.com/qtuwn 2. A hidden icon is impossible to view. Unlike Windows, you cannot expand a slider to see hidden icons. They are merely gone. Unless we fix this bug, icons like power and network state should not be hiding themselves. As noted above, it should only hide itself when necessary. 3. Consistency. Now this is normally not an argument I think holds any weight, but in this instance I think it does. Without a compelling reason to break consistency with other operating systems/desktop environments, I don't see why we should. When discussing the design of notification icons and applets, there are few things more compelling than
Re: release notes: first draft
On 3/7/06, James Henstridge [EMAIL PROTECTED] wrote: Edward Hervey wrote: revised version 0.3.a-beta-pre25-coma-7: Gstreamer 0.10 will also give users the possibility to use, where patents apply, multimedia plugins distributed by 3rd party vendors to offer support for licensed codecs for which no legal plugins are available. Does that make more clear the *freedom of choice* offered to users ? Apart from the freedom issue (which is important), is this actually a new feature for Gnome 2.14? GStreamer 0.8 also used plugins, so surely codec vendors had the same ability to offer plugins back then as with 0.10. Has anything actually changed here other than a vendor (Fluendo) making use of this ability? If not, then this probably isn't appropriate for the release notes. This issue has been a big, ongoing issue for the linux desktop for years. It certainly seems appropriate to talk about the results now that our long-term strategic choices have blossomed. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module decisions [was Re: gnome-screensaver]
On 2/16/06, Rodrigo Moya [EMAIL PROTECTED] wrote: On Thu, 2006-02-16 at 13:33 -0700, Elijah Newren wrote: On 2/16/06, Danilo Šegan [EMAIL PROTECTED] wrote: Hi Vincent, Today at 8:24, Vincent Untz wrote: We'll be trying something new for new modules in 2.16. I think most of us agree that it didn't turn out well for this cycle. Like: lets remove all desktop modules, and reevaluate them again? Not that it would bring any concrete results, but I'd love the flamefest (d-d-l is seriously lacking these days :) Now, seriously, can you at least give us a hint of what you have in mind? And who is we dammit? :) There are a couple of ideas floating around, so there's no concrete change to propose yet. But you'll note that we have sucked at new module decisions in all release cycles for the past who-knows-how-long. I personally think part of the problem is that the end date for new module proposals coincides with the date for the final decision. The discuss it period is also way too wide open making it hard to keep on top of. One of the suggestions is to have the cut-off date for new module proposals be sooner, have a focused and relatively short (a week or so?) discussion period after that (though still allowing the open ended discussion period that currently exists, just making it in some sense less official than the focused one), and then followed by an actual date by which decisions need to be made. I brought this up at a recent release-team meeting and other ideas were also brought up that were somewhat similar in nature (read: I don't remember the details). We didn't have anything concrete and were running out of time, and besides, 2.14 is taking precedence right now. So we agreed to discuss more later and get some community input maybe near or after 2.14 is out. But now that it has come up... Anyone else have any ideas on making us not suck at getting module decisions done two months before the release as specified on the schedule as opposed to one month like we usually achieve? one thing I don't like is how the decisions get done. That is, if someone raises some concerns about a proposed module, then some people don't like it is the reason given for not accepting the module (ie, see gnome-power-manager/screensaver thread). Of course, there would always be someone who doesn't like something about a proposed module. So, what if we just set a list of things a module has to conform with to get accepted and base our decisions on that? For instance, we could have: * uses at least basic platform libs (GTK mainly) * uses existing platform libraries for everything possible (that is, does not use libs implementing an already existing feature in GNOME platform) * follows GNOME standards (coding standards, freedesktop specs, HIG, documentation, licensing, release dates and freezes, etc) * is source in GNOME CVS? I tried to create such a list in a GEP, ages ago: http://developer.gnome.org/gep/gep-10.html Bottom line: * there are some obvious ones (licensing, CVS, etc.) but those are easy and no one (to the best of my knowledge) has ever proposed anything that didn't meet them, or wasn't trivially moved to them. * you must include evaluations of quality/completeness that are necessarily subjective until the project is evaluated by a wider crowd, and ideally on others, like a11y, that we should include but that realistically no one has time/ability to make the assessments on. So you're always going to have the subjective components, even on reasonably subjective things (is the quality good? is it accessible?) * if the desktop is to remain at all coherent, you must include evaluations of target market/etc. that frankly, as a group, we're basically unable to handle right now. There is no simple, easy, list, unless you have no meaningful standards. Software isn't simple and easy, unfortunately. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: UI Review
On 2/8/06, Calum Benson [EMAIL PROTECTED] wrote: On Tue, 2006-02-07 at 10:25 -0700, Elijah Newren wrote: On 2/7/06, Calum Benson [EMAIL PROTECTED] wrote: Uh, we're just over a week *past* UI freeze. ;-) I know, but didn't we always do UI reviews after the freeze, with s/the freeze/a freeze/ maintainers having special release team dispensation to change stuff after that that the UI review recommended? Yes, but didn't we used to have a soft UI freeze + a hard UI freeze, with the UI review coming in between? (e.g. see http://www.gnome.org/start/2.5/). We're almost to the time of what would have been the hard UI freeze in such a schedule. Anyway, I think it'd make sense to probably approve stuff that was changed in response to UI review recommendation, if done soon, but given that it is later in the release cycle we do need to weigh it against possible work caused to the documentation or release notes writers as well as possibility for instability if the changes are not small. So, I'd probably lean towards approving such stuff, but I think it's too late to give blanket approval to changes made in response to UI review at this point. Ok, well... what I'd suggest then is that we[1] maybe try and do a UI review of the components whose maintainers have expressed an interest in being reviewed (or who express such an interest in the next day or two), and just seek approval for those changes. And then do it properly again next time :) Just wanted to say, Calum (and perhaps others listening in) that I firmly believe that, done right, the UI reviews can be very, very useful. It is clear that we're not doing it very well, though- perhaps it needs to be more proactive, and earlier in the cycle? I'm not sure exactly what an ideal process would look like, but it is clear that we need one- this is really critical, important, sadly vasty underappreciated work. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: On Tue, 2006-02-07 at 10:43 +, Jono Bacon wrote: Hi all, Just a quick question to anyone who may be in the know. After seeing the NLD10 videos, it seems the GNOME in there is rather similar to the mockups shown at http://www.flickr.com/photos/gamehack/sets/1506658/ Indeed, these mockups were made internally at Novell by the UI team (same guys that brought you betterdesktop). I made a comparison in a blog post at http://www.jonobacon.org/viewcomments.php?id=637 to outline the point. Do we know if these radical changes to GNOME have been implemented, and if so, are the changes coming back to the community? The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: NLD10 and GNOME
On 2/7/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: On 2/7/06, JP Rosevear [EMAIL PROTECTED] wrote: The changes that were implemented were not as radical as the mockups. Basically what Nat F. showed in Paris is what was implemented. The code will be released to the community soon. To ask the obvious question, why not now, and why not discussed publicly earlier? I should have been not quite so hasty and added 'and if the answers are real problems (which I think they probably are) any suggestions on how to solve them?' I'm swamped at work, so I can't go into much detail ATM, but it seems like these are very real issues we need to solve... Luis So here's my (ie, not Novell's) answer. Two words: bike shed[1]. Or actually, stop energy[2] works too. Your pick. Although the changes aren't nearly as radical as the original mockups, they are a big change from the current GNOME panel menu. If we had proposed the changes on the mailing lists, it would have started a huge discussion about what people hated about the design (you can't make the panel menu depend on beagle!!!) and how it should be different. And then we could have either (a) completely ignored everyone and done it ourselves anyway, or (b) had a long conversation about the merits of the design and then not actually finished the code in time for NLD10. So we did it ourselves, and now either GNOME will like what we did, in which case, yay, free code for GNOME, or GNOME won't like what we did, in which case, no harm no foul for GNOME, and yay, brand differentiation for Novell. (And anyone who yells fork deserves to get one stuck in them.) An equivalent answer to the question is because you can't do design by committee. Everything good in GNOME is good because one person or a small number of people working closely together made it good. Much of what is bad in GNOME is bad because lots of people have contributed without having a single vision of what the end result is supposed to be. I mean, look at the stuff John Williams has been blogging about the last week[3]: * Evolution's UI blocking on I/O SUCKS. Due to lack of design in the early stages of development * Evolution's integration with gaim and tomboy RULES. Both of these happened because specific people (ChipX86, orph) made them happen. * Multimedia integration SUCKS. No one has ever sat down and tried to fix the big picture. (Although I think the gstreamer team is in the process of doing this now?) * Apps not remembering their window size and position SUCKS. Again, needs someone to take this problem and make it their own. I remember xkahn was trying to fix this a few years ago, but never finished. * Bug-buddy SUCKS. Jacob's original UI was simple and brilliant. But as more and more people added more and more features without looking at the big picture, it got unwieldy. (But now a small team is putting the simplicity back in again.) * Deskbar applet RULES (kikidonk), dashboard RULES (Nat), and beagle RULES (trow and joe). None of these was done *exclusively* by those people, but each of them reflects one person's (or a few people's) vision, as opposed to the current state of bug buddy, which just sort of happened. This is just another aspect of the UI simplicity thing. We like UIs that try to do the right thing (metacity, epiphany/firefox, evince) rather than UIs that try to make every possible user happy (enlightenment, mozilla, gpdf/acroread). If you try to design something by committee, you either have to end up with the latter sort of messy does-everything UI, or you ignore and hence piss off a large chunk of the committee. And that's where we are with NLD. There is no way that everyone in the GNOME community is going to like the changes we wanted to make. But we did the user testing, and we believe in it, and we want to make the changes anyway. So we're doing it. Maybe it will turn out good, and maybe it will turn out bad. Either way, the GNOME community learns from it. Think of it like this: wouldn't it have been cool if we could have tried out spatialus on our users, found out that they hated it, and then reverted back to browserlus, without ever having to actually piss off our users? This is essentially what is going to happen with NLD10. If Novell's customers like the NLD changes, then GNOME can adopt them. If Novell's customers don't like the changes, then GNOME can stand off to the side and say yeah well, we never liked that UI anyway. Not at all like how we would have done it. :-) But some people will still say But couldn't you have discussed it with the community before doing it? No, we couldn't. If we had, it would either not have happened, or it would have sucked. It's inevitable. It's not a problem with the GNOME community, it's a problem with communities in general
Re: control-center 2.13.90 released
On 2/2/06, Rodney Dawes [EMAIL PROTECTED] wrote: If the hope is to change it back when things get faster then this current change is inflicting unnecessary software churn on users. The hope is to fix all of the problems. Not following the HIG is something that I would consider a problem. I fixed the dialog to follow the HIG. Rotely following the HIG (rotely following any guidelines) because they are guidelines, instead of working to fix underlying problems, is the height of idiocy. Or laziness. Or both. Luis (thinking maybe the HIG should have a note: 'If your software used to be fast enough for 'OK', and now it isn't, you should get out the profiler and fix the performance instead of getting out glade.' Or maybe the first page of the HIG should say, in bold print, 'Fix the problem, not the symptom.' I'd say it should say 'don't be an idiot' but maybe that isn't clear enough.) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Splash screen + desktop background + gdm theme for 2.14
On 1/21/06, Jaap Haitsma [EMAIL PROTECTED] wrote: Hi, There is always a competition for the splash screen of a new GNOME release. Wouldn't it be nicer to make this a bit wider such that it includes a desktop background and a GDM theme? That way users get a more visually consistent startup process. I know that many distros change the art to their own art, but there are also distros that just use the default GNOME art. Good idea. Could also make it a requirement that there be a 2.14 and a 'version-free' version- i.e., that the theme be good enough that it could stand on its own and be added to the package after the release, without the version references. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
On 1/16/06, Elijah Newren [EMAIL PROTECTED] wrote: On 1/16/06, Vincent Untz [EMAIL PROTECTED] wrote: They could use basic triaging in the sense that someone should go through them and see what applies to the 0.10 version. I think that you'd find most GStreamer bug triagers to mark them as obsolete if they apply only to the 0.8 backend though, and I don't know if that's what you want in this case. I don't think marking them as obsolete is okay right now. I'd use the status whiteboard so we can easily know they're only happening with the 0.8 backend. (Or maybe create a gstreamer0.8 component, but this is ugly). See http://blogs.gnome.org/view/newren/2005/09/30/0 for more details where I'm coming from, but I'm basically going to disagree with Vincent here -- I think it should be perfectly fine to mark all those bugs as obsolete and tell the reporter they are free to reopen if they experience the same issue under 0.10. I think which versions are considered obsolete ought to be up to the maintainers (though we'd appreciate a note in the product specific guidelines, linked to from the browse page in bugzilla, so that triagers can help). There is a tradeoff that needs to be made and we don't want to be too agressive just closing out 'old' bugs, but I think we tend to err far on the side off keeping too many bugs open that just aren't helpful. This is basically the case we created obsolete for (as opposed to wontfix) so while it isn't perfect, I'm generally in agreement with Elijah here. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
