Re: how to apply to be Summer of Code mentor?
On Wed, Apr 6, 2011 at 2:12 PM, daniel g. siegel dgsie...@gnome.org wrote: On Wed, 2011-04-06 at 17:26 -0300, Juan Pablo Ugarte wrote: BTW what do mentors have to do donate the mentoring money to GNOME? nothing. this will be handled automatically by the soc admins and the gnome foundations. Point of clarification: mentors are not paid by Google. Mentor *organizations* are paid by Google. GNOME has never paid mentors, and has always used the money as a source of income for the Foundation itself. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: how to apply to be Summer of Code mentor?
On Wed, Apr 6, 2011 at 2:22 PM, Juan Pablo Ugarte juanpablouga...@gmail.com wrote: On Wed, 2011-04-06 at 14:19 -0700, Sandy Armstrong wrote: On Wed, Apr 6, 2011 at 2:12 PM, daniel g. siegel dgsie...@gnome.org wrote: On Wed, 2011-04-06 at 17:26 -0300, Juan Pablo Ugarte wrote: BTW what do mentors have to do donate the mentoring money to GNOME? nothing. this will be handled automatically by the soc admins and the gnome foundations. Point of clarification: mentors are not paid by Google. Mentor *organizations* are paid by Google. GNOME has never paid mentors, and has always used the money as a source of income for the Foundation itself. Ok cool, I never participated before. I just hope its 500 per mentor :) Technically, it's $500 per student (one mentor could have multiple students). ;-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On Mon, Mar 21, 2011 at 6:42 AM, Ghee Teo ghee@oracle.com wrote: On 21/03/2011 12:29, Olav Vitters wrote: On Mon, Mar 21, 2011 at 09:55:05AM +, Ghee Teo wrote: I hope this does not imply or infer that all the source tarball for GNOME will be uploaded in .xz format only. Solaris is *not* supporting .xz by default yet. This means, anyone who want to compile source code modules will have difficulties. That is exactly what I meant. So: How do Solaris users get GNOME packages? Via ftp.gnome.org? Yes. We download them from ftp.gnome.org. By we, do you mean end users or packagers? Aren't only packagers (and distro build servers, etc) and advanced users impacted by the change to .xz? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using .tar.xz only on ftp.gnome.org (was: install-module / ftp.gnome.org / master.gnome.org)
On Mon, Mar 21, 2011 at 10:01 AM, Ghee Teo ghee@oracle.com wrote: On 21/03/2011 17:02, Sandy Armstrong wrote: On Mon, Mar 21, 2011 at 6:42 AM, Ghee Teoghee@oracle.com wrote: On 21/03/2011 12:29, Olav Vitters wrote: On Mon, Mar 21, 2011 at 09:55:05AM +, Ghee Teo wrote: I hope this does not imply or infer that all the source tarball for GNOME will be uploaded in .xz format only. Solaris is *not* supporting .xz by default yet. This means, anyone who want to compile source code modules will have difficulties. That is exactly what I meant. So: How do Solaris users get GNOME packages? Via ftp.gnome.org? Yes. We download them from ftp.gnome.org. By we, do you mean end users or packagers? My we refers to users. Aren't only packagers (and distro build servers, etc) and advanced users impacted by the change to .xz? No. packagers are the source codes providers. Users are the source code consumers. I was assuming this model: Maintainers are source code providers. Packagers consume and produce binary packages. End-users consume those binaries and don't care about how the packagers get the source code. GNOME requires both groups of users to exist meaningfully :) Sure. I guess I just didn't realize that Solaris end users were consuming GNOME source tarballs. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libpanel-applet-3 and gtk 2
On Wed, Feb 9, 2011 at 1:56 PM, Colin Walters walt...@verbum.org wrote: On Wed, Feb 9, 2011 at 4:46 PM, Frederic Crozat f...@crozat.net wrote: 2011/2/9 Matthias Clasen matthias.cla...@gmail.com: - make it a real application Which make the application undiscoverable by new users (I don't expect them to know about keybinding) and not easily activable with mouse only. If it has a .desktop file etc. then it's just as discoverable as the rest of the apps. Right, that's the approach we've decided on for Tomboy. We'll ship the panel applet code (disabled by default) for distros that want to keep using it, and the status icon will still be available as an extension for users that want it, but in general it will act just like any other app. At Summit we discussed ways to replace the whole tray menu with jumplists in gnome-shell, but as far as I know nobody (certainly not me) has had time to implement that for 3.0. Actually there was some disagreement about how to show recent documents in such a list, so although it would be cool to work on it for 3.2, there isn't a solid plan in place yet afaik. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Jump Lists / Quick Lists / Dash Embellishments in GNOME 3
On Wed, Feb 9, 2011 at 2:12 PM, John Stowers john.stowers.li...@gmail.com wrote: Hi All, I see that Ubuntu has merged [1] their implementation of 'quick lists' [2], and also offer ways to embellish their application launcher icons with numbers and progress bars. Is there a plan describing how these things might fit with gnome-shell (or not)? [5] leaves this part unspecified. As I understood it, quick lists were meant to be supported upstream via exported GApplication actions [4], gtk offers GtkNumerableIcon [5] (but nothing in the dash), and there is no progress bar equivalent. Is this a correct summary, and is there a recommendation to application authors how similar things might be done in GNOME3? We discussed several options at Boston Summit 2010, but I'm not sure any solid conclusions were reached. Having jumplists in the shell overlay was desired by pretty much everybody, though it was not specified whether they would be implemented as right-click menus on application icons, or something else. My takeaway from the session was that we would use a combination of static verbs (specified in .desktop) and dynamic actions (specified using GApplication actions) to build the action list in an application's jumplist *and* in the application menu in the top panel of the shell. But after talking to Ryan Lortie later, it seemed that he and Owen preferred using GApplication actions only for the application menu, and that all actions in the jumplist would be specified using the .desktop file. The reason for specifying actions in the .desktop file was so that you could execute actions without requiring the application to be running. For example, clicking New Note in Tomboy or Play in Banshee (why should you have to launch the app first for those options to appear?). Everybody agreed that documents needed to be in the jumplist as well, with the ability to star documents (like pinning notes in Tomboy's note menu), but there was much disagreement about what document API to use. Emmanuele Bassi was happy to accept additions to GtkRecent* API, but many people felt that a real document tracker would be necessary to pull off a really nice UX, and at that point there was disagreement about whether the shell should have a built-in document tracker, or if Zeitgeist should be used. It's possible that Owen, Jon, and Federico have more to say about this, as I believe they chatted a bit more after the session. I apologize for never blogging my summary of this session, and as I haven't been very involved in shell development lately I do not know if this represents the very latest information. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: two choices dangerous for Gnome 3
On Wed, Feb 9, 2011 at 1:53 PM, Gendre Sebastien ko...@romandie.com wrote: Le mercredi 09 février 2011 à 22:39 +0100, Johannes Schmid a écrit : BTW, I doubt that a discussion on desktop-devel-list will change anything. Yes, but where? As Johannes said in his email, bugzilla is the right venue. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
On Mon, Feb 7, 2011 at 5:36 PM, C.J. Adams-Collier c...@colliertech.org wrote:
On Mon, 2011-02-07 at 18:37 -0500, William Jon McCann wrote:
Hi,
Howdy!
On Mon, Feb 7, 2011 at 5:58 PM, C.J. Adams-Collier c...@colliertech.org
wrote:
On Tue, 2011-02-08 at 01:04 +0530, Nirbheek Chauhan wrote:
On Tue, Feb 8, 2011 at 12:22 AM, Andre Klapper ak...@gmx.net wrote:
On Sun, 2011-02-06 at 19:19 +0530, Nirbheek Chauhan wrote:
Is there a place where IRC logs of discussions from the various
channels can be found?
I am not aware of any automated GimpNet IRC channel logging and
publishing.
It would be very useful to have a bot around which logs conversations
on #gnome-{shell,design,os}
done, done and done.
et al
You'll have to be more specific.
and puts it up somewhere.
http://ilbot.colliertech.org/gnome-shell/today
http://ilbot.colliertech.org/gnome-design/today
http://ilbot.colliertech.org/gnome-os/today
A number
of GNOME channels already have bots to manage chanops, those could
probably be put to this use as well, if possible.
Poke me if things go offline. My web server isn't the most stable thing
in the world.
To cover the conversations that have already happened; maybe people
can put up their logs of these channels of the past year (or whatever
they have). We can then patch up the various logs to make a full log.
Let me know when you've got them and I'll post them in the same place.
bebot has been logging for some time. I'd prefer it if we have only
one mechanism in place. We haven't had a chance to figure out what to
do with the logs (including where to post them, how to present them,
and how to search them). Another issue is that I want to ensure that
it is well known that the channels are logged (I consider it impolite
to post logs from folks that don't know they are being logged) and
that we make some assurance that sensitive information doesn't
accidentally get published (at least until you can change that
password you accidentally typed into IRC).
Would you mind disabling your bot until we do that?
Thanks,
Jon
From one of my fellow gimpnet IRC operators:
16:28 CyBeR cj: you should inform them that we (gimpnet) have no logging
service nor the intent to create one
16:28 CyBeR cj: and that open (as in, not +i or +k) channels should be
regarded as public
16:29 CyBeR and one should assume one's writings are logged and public when
conversing in one
That said, I'll put on my GNOME Foundation member hat and say that I'm
willing to help develop a logging facility for channels that the
foundation considers part of the core infrastructure.
You would probably need multiple bots to fill the needs of the GNOME
community. Gimpnet has a fairly low max join limit, iirc.
I'd definitely be interested in this. One of the main reasons I run
irssi on my server is so that I have logs of channels that matter to
me.
BTW, combining this with an op bot like Rupert would be nice.
Sandy
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Question about GNOME 3.0 bindings plans
On Fri, Jan 21, 2011 at 9:31 AM, Andre Klapper ak...@gmx.net wrote: On Fri, 2011-01-21 at 18:19 +0100, Juanjo Marin wrote: AFAIK, one of the cornerstone components of GNOME 3 is GObject Introspection. I'd like to know which libraries are supposed to support GObject Introspection. http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport has a list, not necessarily up-to-date. Another question is which bindings/language will be officially endorsed by the GNOME project. The new, yet-to-release developer.gnome.org will focus on C, C++, Python, Javascript, and Vala. Is C# not a focus of the site because the bindings are behind, because of lack of volunteers to help, or for some other reason? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Question about GNOME 3.0 bindings plans
On Fri, Jan 21, 2011 at 11:01 AM, Shaun McCance sha...@gnome.org wrote: On Fri, 2011-01-21 at 09:46 -0800, Sandy Armstrong wrote: On Fri, Jan 21, 2011 at 9:31 AM, Andre Klapper ak...@gmx.net wrote: On Fri, 2011-01-21 at 18:19 +0100, Juanjo Marin wrote: AFAIK, one of the cornerstone components of GNOME 3 is GObject Introspection. I'd like to know which libraries are supposed to support GObject Introspection. http://live.gnome.org/GnomeGoals/AddGObjectIntrospectionSupport has a list, not necessarily up-to-date. Another question is which bindings/language will be officially endorsed by the GNOME project. The new, yet-to-release developer.gnome.org will focus on C, C++, Python, Javascript, and Vala. Is C# not a focus of the site because the bindings are behind, because of lack of volunteers to help, or for some other reason? Actually, I think we're somewhat confusingly conflating the focus of developer.gnome.org with what we initially focused on for the developer demo tutorials. We talked about languages at the developer documentation hackfest. We weren't trying to exclude any. We just needed to set priorities. We decided not to focus on C# and Mono only because it seems to already have a healthy developer community of its own. If any C# developers want to port any of the demos, or write new demos, I'm not going to turn down contributions. Same for Java and any other language for which we have reasonably up-to-date bindings. There is the slight issue of tools. We've been writing tutorials assuming you use Anjuta, because using an IDE is a more attractive entry point for new developers. I don't think the Anjuta developers even try to target C# or Java, because there's no point competing with MonoDevelop and Eclipse. So for specific languages, we should probably just have the tutorials use other IDEs. That all makes sense to me, thanks! Maybe once the Mono binding guys get their next gen stuff released, some folks in that community will want to contribute a bit to developer.gnome.org. :-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tiling in mutter
On Wed, Jan 5, 2011 at 8:40 AM, Colin Walters walt...@verbum.org wrote: On Tue, Jan 4, 2011 at 4:54 AM, Christopher Roy Bratusek zang...@freenet.de wrote: No it's not. Other WMs provide extra functionality besides bling-bling. Compiz does tabbed-windowing, will Mutter do? Sawfish provides EdgeActions and Viewports, will Mutter do? Other WMs provide Tiling, will Mutter do? I think for a lot of these, particularly tiling, would be much better as extensions. I looked into this briefly after this year's Boston Summit. Existing tiling-like features in mutter (drag window to side to take up half of screen, etc) are not implemented as extensions. Rather, they are right in the mutter core, and overriding that behavior with extensions seems like it would be a pain. What's the best mailing list to discuss mutter stuff like this? gnome-shell-list? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Blocker Report for week 01
On Tue, Jan 4, 2011 at 10:10 AM, Andre Klapper ak...@gmx.net wrote: Tomboy: Get rid of bonobo dependency: Applet DBUS migration GnomeGoal https://bugzilla.gnome.org/show_bug.cgi?id=620829 I've removed the GNOME target from this bug, since we disabled building the panel applet by default in the previous cycle. Porting to the D-Bus applet API is still welcome work, but doesn't block Tomboy in GNOME 3.0 and probably won't happen this cycle anyway. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, Jan 4, 2011 at 11:58 AM, Christopher Roy Bratusek zang...@freenet.de wrote: Just one last thing for now: Most of those who disagreed with me are developers, most of them who agreed with me are users. Somehow I suspect that non-developer users on desktop-devel-list do not represent a majority of GNOME users. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
On Wed, Dec 29, 2010 at 12:43 AM, Carlos Garcia Campos carlo...@gnome.org wrote: If I couldn't use gnome-shell, I would still want to upgrade all other modules to 3.0 and use a fallback mode without loosing the weather applet, for example. The standard answer here seems to be: -- You may lose features in 3.0 *with* gnome-shell, and you may lose even more features in 3.0 *without* gnome-shell. These features will take time to return in 3.2, 3.4, etc. Folks who don't want to lose features like this should hold off on upgrading. -- This is paraphrasing what I've read from Jon McCann and others, hopefully without putting words in their mouths, and makes sense to me. It would be nice to see an official statement like this from the release team if it's accurate. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
On Sat, Dec 25, 2010 at 1:34 AM, Frederic Crozat f...@crozat.net wrote: for nvidia, gnome-shell is not usable with proprietary driver What do you mean by this? Every time I've tested on nvidia hardware with the proprietary driver, shell performance has been totally usable. It's not lightning fast, but I don't think any hardware change would fix that. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
On Mon, Dec 27, 2010 at 6:46 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: What do you mean by this? Every time I've tested on nvidia hardware with the proprietary driver, shell performance has been totally usable. It's not lightning fast, but I don't think any hardware change would fix that. Usable is a rather hard to quantify thing. Not lightning fast to some people (me included) for example is not particularly usable. For me it took until about Fedora 11/12 before even the compositing was efficient enough on intel video to leave it turned on without making gimp unpleasant to work with. I don't disagree. My point was merely that I was not aware of any performance issues unique to Nvidia hardware. I've seen gnome-shell on Intel and ATI hardware as well, and performance is essentially the same as on my Nvidia. Your response seems to confirm that to some degree. I thought maybe Frederic was referring to some specific bug that I'd be curious to learn more about. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
On Thu, Dec 23, 2010 at 3:12 PM, Juanjo Marin juanjomari...@yahoo.es wrote: Though I agree that we must planning the future, we also need to give a migration path for our users. There are big deployments out there, and sometimes they need _time_ for evaluating the new features, updating their hardware if necessary, adapting their configurations, etc. Then they should wait to upgrade to GNOME 3 until they are ready. Nobody is forcing these big deployments to upgrade every six months (in fact, for most big deployments that would never have been a reasonable policy). In most circumstances, they are probably using enterprise distributions or conservative stable distributions that wouldn't be deploying GNOME 3 immediately anyway. I agree heavily with Jon's response in this thread, specifically that People who don't desire such changes are not obligated to make them. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (not) proposing Snowy for GNOME 3.0
On Fri, Oct 22, 2010 at 3:27 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Thu, 2010-10-21 at 21:35 -0700, Sandy Armstrong wrote: == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app. I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. yes, maybe it would make sense to have a generic sync API, so that the same API and server could be used for syncing notes, contacts, calendar events, etc. I don't think that would make a monster app, if it's just a syncing server implementing a single API, wouldn't it? I disagree. Not every app has the same sync needs. I think most apps could get away with a simpler sync than what Tomboy currently uses. And even if we had a generic sync API, we'd end up being forced to either store giant JSON strings in the database, or be forced to use an unstructured DB like Couch, or have the model for each data type defined in one app. All of these have potential downsides. But my experience is limited to sync for one app, so I could certainly be wrong here. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
(not) proposing Snowy for GNOME 3.0
Hey Folks, == Intro == I think it's a bit premature to propose an entirely new type of module and moduleset in GNOME, but I think it is not a bad time to discuss what a web app moduleset might be like. I expect I'll propose Snowy for real for 3.2, after we have dogfooded our hypothetical Tomboy Online release plan (see below). As a reminder, if you are interested in joining the current Tomboy Online alpha, you are welcome to fill out our survey here: https://spreadsheets.google.com/viewform?formkey=dFZleG05V196b3g4VUFSTHhzcTRFMmc6MQ == Draft Proposal == Purpose: Snowy [0] is a Python/Django web app for synchronizing your Tomboy notes. It provides read access to your note collection through your browser, and will soon have note editing and sharing functionality as well. While it can be deployed by users on their own servers, the primary focus is a GNOME-hosted version called Tomboy Online, providing free note sync for all Tomboy users. Sync is achieved through a RESTful API [1] designed with feedback from Rodrigo Moya and Stuart Langridge from Canonical, who have implemented the same API in Ubuntu One. Tomboy and Conboy (third-party Maemo client) have been syncing over this API for over a year now, and recently Tomdroid (third-party Android client) released sync support as well. Target: hypothetical web release set Dependencies: Django and various third-party Django libraries, a web server, a database (TODO: Fill in with actual deps when actually proposing) Resource Usage: Snowy is fully GNOME-hosted, including git, ftp, bugzilla, mailing list, and even Tomboy Online is hosted on GNOME infrastructure. Adoption: N/A GNOME-ness: We have work to do to get translations hooked into GNOME infrastructure. I'm not entirely sure yet how documentation should be handled. Snowy development is closely tied to Tomboy development (same maintainer, same initial userbase). What GNOME-ness means for a web app is something that still needs to be determined, imho. 3.0-readiness: N/A License: AGPL == Tomboy Online Release Plan == In initial conversations about how we plan to manage releases for Tomboy Online, we have come up with this plan: * Snowy follows the GNOME release schedule. * Tomboy Online will only ever run official released code. * Because of the above, we may find it necessary to release more frequently than typical modules. * In the VM provided by GNOME, we run two instances of Tomboy Online: www.tomboy-online.org and edge.tomboy-online.org . These instances have completely separate user/note databases. * www.tomboy-online.org will only run stable releases. * edge.tomboy-online.org will run the latest development release (except in the case where stable is newer/edgier). * Because of the above, we may find it necessary to very actively maintain the stable branch. * Probably, we will run a new .0 stable release for a couple of weeks on edge.t-o before deploying to www.t-o. There shouldn't be any need for such a delay for point releases after .0. We think this will work well. Users who want to try the latest features can use edge.t-o, and users who want stability and don't mind waiting 6 months for new features can use www.t-o, but can still rest assured that they will receive timely fixes for security and stability issues they may encounter. == GNOME Web Platform == There is no GNOME web platform. There are no new libraries being proposed for use by all GNOME web modules. It feels way too early to try to make those sorts of decisions. We need another module or two before we discover what can and should be shared. I will say that even if we end up with an Online Desktopish goal, we should not strive for one big monster web app.I think it makes sense to focus on smaller, single-purpose web apps with sensible integration points. For example, we could have a Mugshot-like identity app for Teh Social, and have it aggregate info from apps like Snowy. We could tie apps together with existing standards like OpenID and OAuth. We could come up with conventions for building RESTful APIs, standardize on JSON, etc etc. We could build standard GTK+ widgets for authenticating with GNOME web services. Whatever makes sense to make integration between the GNOME desktop and the GNOME web easy on developers and users. Clearly, if we want to succeed on the web, we'll need to have a defined web platform. But I don't think we're there yet. I'm getting sleepy and feeling kind of rambly, so I'm just going to send this and go to sleep. Any and all feedback is welcome. Sandy [0] http://live.gnome.org/Snowy [1] http://live.gnome.org/Tomboy/Synchronization/REST ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Moduleset Reorganization vs. L10N
On Fri, Oct 15, 2010 at 8:02 AM, daniel g. siegel dgsie...@gnome.org wrote: On Fri, 2010-10-15 at 16:47 +0200, Johannes Schmid wrote: Hi! As much as I'd like to claim it, I don't think we can achieve everything with a single shot. :-) Maintainers of GNOME modules hosted outside of git.gnome.org don't always feel comfortable with raw commits to their VCS (security, noise in the vcs history etc). Whether translations should be committed directly to a repo is a big discussion, and I believe maintainers are the ones with the final word on this. Well, we are currently defining the requirements for modules not hosted on git.gnome.org (if we allow them at all). If people are so keen on not hosting on git.gnome.org they will probably have to allow automatic commits. it would be interesting to know _why_ some modules do not like to be hosted on gnome.org. knowing that would make it so much easier to find the best way for all of us. I think this has been well-covered in the past. The typical example is Launchpad, which offers a lot more features in project hosting than we do. Projects get used to using things like blueprints, answers, integrated PPAs, etc. I'm not a fan myself, but I can see how once a project was already hooked on a Launchpad-oriented process, it would be work to migrate to GNOME infrastructure. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 5:59 AM, Vincent Untz vu...@gnome.org wrote: Le jeudi 07 octobre 2010, à 07:32 -0700, Sandy Armstrong a écrit : On Thu, Oct 7, 2010 at 4:38 AM, Vincent Untz vu...@gnome.org wrote: Moreover, we encourage maintainers of applications that are part of the Desktop today and that are not core applications to consider helping with the bootstrap efforts of this application set by moving their applications there. What are the downsides, if any, of moving your application out of Core? Perceived loss of status/importance to GNOME? Any practical differences? The goal is to not have any downside :-) snip satisfying answer Alrighty then, let's do it. Let me know what I need to do to move Tomboy to this new suite and we'll call it a day. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 1:31 PM, Murray Cumming murr...@murrayc.com wrote: On Tue, 2010-10-12 at 15:03 +0200, Vincent Untz wrote: Good point. It's fair to expect projects not using the GNOME development cycle to publish a schedule with freezes. You would allow modules in the module sets that don't follow the GNOME schedule? Then it loses all meaning. Once again, the purpose of the release schedule (of which the module sets are just a part) is to release software. I agree here. I'm not sure how the i18n and docs teams are supposed to do their jobs if they have to track dozens of different schedules. Maybe those teams should only devote resources to an application on the occasion that a release matches up with the GNOME schedule? This would allow for apps to have more or less frequent releases, but at the same time encourage them to have their releases match up with the GNOME schedule whenever possible. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Tue, Oct 12, 2010 at 2:07 PM, Holger Berndt bern...@gmx.de wrote: On Di, 12.10.2010 14:59, Vincent Untz wrote: For example, if Tomboy moves out of Core, then we will still talk about it the way we talk about it today. We would want to keep mentioning cool new features in the release notes, and I guess that should address concerns about the perception. Maybe it's just me, but I'm afraid that the release notes might end up delivering unwanted messages. Say there is videoplayer 1, with new features A,B and C. Then there is videoplayer 2, with new features D and E. Maybe it had features A and B before anyways, but not C. So, if a user is interested in all that cool stuff in the release notes - what's he supposed to use? So what message does this convey about a GNOME release? That it offers a consistant, tightly integrated desktop user experience? Or that it's a loose collection of somewhat related, partly overlapping applications? Yes, I'm curious how coherent the release notes will be when they list the latest greatest features from Tomboy, and then the slightly different but generally overlapping set offered by Gnote, in the hypothetical situation where both apps were in the app moduleset. That's only the most extreme example, but Banshee/Rhythmbox sends an equally confusing message. I'm really not sure what the answer here is. I don't think that deemphasizing app features in the release notes would help any, as it would make for increasingly boring reading for users (who tend to care more about apps than core stuff). But it's also a problem if we have longer, conflicting, confusing release notes. Splitting out apps makes sense in a lot of ways, but clearly there are a few sticking points that we need to figure out. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Thu, Oct 7, 2010 at 4:38 AM, Vincent Untz vu...@gnome.org wrote: Moreover, we encourage maintainers of applications that are part of the Desktop today and that are not core applications to consider helping with the bootstrap efforts of this application set by moving their applications there. What are the downsides, if any, of moving your application out of Core? Perceived loss of status/importance to GNOME? Any practical differences? Tomboy seems like a pretty obvious choice to move to Applications, but I don't want to end up regretting later if there's something I'm missing. ;-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 1.4.x is the stable series corresponding with GNOME 2.32.x. Are we good or am I missing something? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
On Tue, Oct 5, 2010 at 11:09 AM, Andre Klapper ak...@gmx.net wrote: Am Dienstag, den 05.10.2010, 10:55 -0700 schrieb Sandy Armstrong: On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 2.29 of what? If it's GNOME you'd need a time machine. ;-) I'm pretty sure there's a 2 and a 9 and a 0, and very confident there is no 3, in the version number I meant. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
On Sun, Oct 3, 2010 at 2:48 AM, Emmanuele Bassi eba...@gmail.com wrote: *if*, on the other hand, you want a ChangeLog because it makes your life as a packager easier (for some unknown reason) then you should probably ask for a Gnome Goal to add the autogeneration of the ChangeLog from the Git commit log to every GNOME project. the patch is trivial and I'm pretty sure it could also teach people a thing or two about auto-tools. Instructions for adding ChangeLog generation when rolling tarballs are here: http://live.gnome.org/Git/ChangeLog Emmanuele, I like your interpretation of the GPL requirements. I would love to dump my useless and slow-to-generate ChangeLog if NEWS is sufficient. Would be great to get firm advice on this topic. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing GnomeDesktopItem API from gnome-desktop
On Fri, Jul 2, 2010 at 5:41 AM, Vincent Untz vu...@gnome.org wrote: Hi, I want to remove the GnomeDesktopItem API from gnome-desktop. It's an old API that is not needed anymore in our world with GKeyFile and GDesktopAppInfo. Thanks to Andre, here's a list of modules using it. I've put them in some categories: With patches: - gnome-applets https://bugzilla.gnome.org/show_bug.cgi?id=623369 - gnome-control-center: https://bugzilla.gnome.org/show_bug.cgi?id=623380 - nautilus-open-terminal https://bugzilla.gnome.org/show_bug.cgi?id=623371 For what it's worth, I was just about to start using this API in Tomboy as part of https://bugzilla.gnome.org/show_bug.cgi?id=580422 (see comment 21, and comments 45 and below). Bindings (shouldn't be an issue): - gnome-python-desktop - vala Add gnome-desktop-sharp here. So it all looks good. Unless there's a good objection, I'll remove the API from master, even though it wasn't marked as deprecated earlier. No good objection, it's not directly GNOME's fault that non-C apps always have a bit more trouble when API is removed without much warning. I believe there are some unofficial gio-sharp bindings floating around, so I'll look into using those. Thanks for the heads up, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing GnomeDesktopItem API from gnome-desktop
On Fri, Jul 2, 2010 at 6:26 AM, Vincent Untz vu...@gnome.org wrote: Le vendredi 02 juillet 2010, à 06:12 -0700, Sandy Armstrong a écrit : On Fri, Jul 2, 2010 at 5:41 AM, Vincent Untz vu...@gnome.org wrote: Hi, I want to remove the GnomeDesktopItem API from gnome-desktop. It's an old API that is not needed anymore in our world with GKeyFile and GDesktopAppInfo. [...] For what it's worth, I was just about to start using this API in Tomboy as part of https://bugzilla.gnome.org/show_bug.cgi?id=580422 (see comment 21, and comments 45 and below). As far as I understand, you don't really need this API. You just need to add/remove a file in the autostart dir. Is there any reason to not do it with the usual API for that? Ah, I see you need to change the Exec key. GKeyFile can do that, no idea if it's wrapped in mono, though :/ It also has unofficial bindings floating around. But you're right that since we control our .desktop file we could easily achieve this without use of the API at all. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, Jun 12, 2010 at 5:49 AM, Bastien Nocera had...@hadess.net wrote: On Fri, 2010-06-11 at 18:36 +0200, Xavier Claessens wrote: Once they are all released and parallel installable (we would like to not lose gtk2 compatibility), we are ready to make the move :-) Why is losing GTK2 compatibility a problem? It shouldn't matter. You could create a gnome-2-32 branch and make changes there if you wanted. I can't speak for Xavier, but some of us maintain applications for which the latest version is commonly in demand from users of older distros, and maintaining a separate branch is a fair amount of work if you're the only one doing testing, QA, and release management. There's no way I can consider dropping GTK2 compatibility from Tomboy for the next year or so, for example. I don't have the resources to maintain two versions. A separate but related issue is that unless somebody plans to update gtk-sharp, Tomboy may not be GTK3 compatible this cycle (I don't know off-hand what parts of gtk-sharp may be incompatible with GTK3). Do other non-C apps have similar issues, or is this just a problem with the Mono bindings? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Sat, Jun 12, 2010 at 7:36 PM, Michael Terry m...@mterry.name wrote: On 12 June 2010 11:31, Xavier Claessens xclae...@gmail.com wrote: Ubuntu told me that Maverick (the next ubuntu release) is not going to ship GTK3 I don't think that's true. I was at the planning session for coming changes in GNOME at UDS Maverick, and the plan of record was to include GTK+ and GNOME 3.0. https://blueprints.launchpad.net/ubuntu/+spec/desktop-maverick-gnome Hmm, a Canonical employee approached me just the other day. He was told not to include in Maverick packages that depended on GTK3, and wanted to check with me that Tomboy would remain GTK2-compatible this cycle, so that he could get our latest unstable releases into Maverick. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal for 3.0: Déjà Dup Backup Tool
On Thu, May 6, 2010 at 10:24 AM, Michael Terry m...@mterry.name wrote: 2) I'm still curious to get feedback on other maintainers' experience with pulling in other regular developers once they became a GNOME module. Frankly, I'm leery of the extra burden it would put on me in terms of bug reports and expectations-of-service. Though since the initial proposal, DD has been put in Fedora 13 by default and become a featured app in Ubuntu. I suppose I'm already on the hook pretty hard, and what's one more avenue of exposure. Then you're already screwed. ;-) Being part of GNOME doesn't mean much (in terms of user adoption) unless the distros also decide to include you. If you're already being included in Fedora and Ubuntu, then you're already going to have the problem of more users and more bug reports. At that point, being an official GNOME module actually becomes helpful. You get the GNOME bug squad helping you triage your bugs, you get gnome-love n00bs looking for ways to help and finding your project, and you get awesome translation and documentation teams contributing to your app. You may or may not get consistent code contributions...but again, since you're already in the position of being included in popular distros, you're already screwed, and being part of GNOME only makes contributions and early testing easier for everyone. ;-) Hope this answers your question, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 25, 2010 at 10:59 AM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Official is an interesting word, but Splinter is integrated directly in GNOME bugzilla and supports line-by-line code review. http://blog.fishsoup.net/2009/09/23/splinter-patch-review/ Combined with git-bz, patch submission and review becomes much easier. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed magnifier DBus names
On Tue, Apr 20, 2010 at 2:30 PM, Joseph Scheuhammer cl...@utoronto.ca wrote: Anyone, A group of us have been discussing names for a DBus magnifier service. We have come to a consensus. Service names: org.gnome.magnifier Should be org.gnome.Magnifier org.gnome.magnifier.zoomregion org.gnome.Magnifier.ZoomRegion Object names: /org/gnome/Magnifier /org/gnome/Magnifier/ZoomRegion Looks good! I think http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions leaves some room for interpretation, but my advice complies with the spec and with most GNOME d-bus names that I see. Sandy Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Thu, Apr 22, 2010 at 10:34 AM, Germán Póo-Caamaño g...@gnome.org wrote: On Thu, 2010-04-22 at 19:01 +0200, Seif Lotfy wrote: Our current development is heavily based on launchpad. We are discussing the issue and we don't see a problem to have our trunk from launchpad ported to git with every release. However we do want to keep our development branches in bzr+launchpad. So with every branch merge with our launchpad trunk we can sync it with the gnome trunk. The bigger issue will be bugzilla. We will have to tackle both launchpad and bugzilla simultaneously. We really like the way our workflow works now, and we'd like to ensure that this work can be synced with gnome thus we are trying to come halfway here. Also as a crossdesktop project we intend to integrate with other projects such as KDE and Meego. This makes launchpad a good neutral ground. In such case, should not it be a freedesktop project and be proposed as an external dependency for the Activity Journal? The Activity Journal is in Launchpad and would have the same issues as we've been discussing (except moreso due to translator requirements). Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings and you
On Wed, Apr 21, 2010 at 3:24 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Wed, Apr 21, 2010 at 6:04 PM, Shaun McCance How do I use the keyfile backend? 'export GSETTINGS_BACKEND=keyfile' gives me this: Can't find GSettings backend 'keyfile' given in GSETTINGS_BACKEND environment variable I don't have anything under $libdir/gio/modules. Did I miss something? The keyfile backend is built in, that is why it doesn't show up in the modules dir. But it is not really meant to be used in that 'global' fashion by setting the env var. Instead, you can use it for selected schemas, by doing the following: g_settings_backend_setup_keyfile (blah, filename); settings = g_settings_new_with_context (org.bla.bla, blah); After that, settings that you get or set with that settings object will be backed by the keyfile named filename. Note that you still need to have an installed schema for org.bla.bla. Is the intent of the keyfile backend (at least, in a typical GNOME desktop) to have us store application state separate from settings? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MouseTrap Proposal
(Please avoid sending HTML mail to the list) On Tue, Mar 30, 2010 at 1:56 AM, Flaper87 flape...@gmail.com wrote: 3.0 readiness: MouseTrap (as it does now) will allow users on GNOME 3.0 to access the desktop environment. Have you tested with at-spi2, and the latest pyatspi2? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: MouseTrap Proposal
On Tue, Mar 30, 2010 at 7:08 AM, Flaper87 flape...@gmail.com wrote: 2010/3/30 Sandy Armstrong sanfordarmstr...@gmail.com (Please avoid sending HTML mail to the list) On Tue, Mar 30, 2010 at 1:56 AM, Flaper87 flape...@gmail.com wrote: 3.0 readiness: MouseTrap (as it does now) will allow users on GNOME 3.0 to access the desktop environment. Have you tested with at-spi2, and the latest pyatspi2? Great :-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need more tarballs for 2.30.0
On Tue, Mar 30, 2010 at 5:05 AM, Vincent Untz vu...@gnome.org wrote: Modules that are still with a 2.29 unstable tarball: at-spi2-atk at-spi2-core Mike Gorse and I released new tarballs for these two modules (and pyatspi), versioned 0.1.8. Without Mark Doffman around today, we weren't sure if we should bump all the way to 0.2.0. I'm not a developer of these modules so I don't know what the exact plans were with regard to GNOME 2.30. This release fixes some pretty serious bugs from 0.1.7 that were causing hangs in various GNOME desktop apps. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Last call for SoC Ideas! (was Re: Google Summer of Code 2010 Call for Ideas)
Howdy, On Sunday a small group of SoC mentors will sort through the list of ideas on the wiki, clean them up, remove those we don't want to recommend to students, and highlight those we find especially alluring. If you have ideas for your project, you have today and tomorrow to add them to the wiki before our meeting. Please place new ideas in the Other Ideas section: http://live.gnome.org/SummerOfCode2010/Ideas#Other_Ideas The student proposal period starts Monday. If you want to help review student proposals, please sign up as a mentor. If you don't use your full name and include details when applying to be a mentor, we may not know who you are, so if you choose to do that please email me, Ruben, or Daniel with your link_id so we don't reject you. :-) We have to be careful because there are some sneaky or confused students out there who try to sign up as mentors. The ideas page will be under tight control after our meeting on Sunday, but it will still be possible to add ideas if you check with folks in #soc-admin or on the GNOME soc-mentors-list first. Thanks for your time, Sandy On Tue, Mar 9, 2010 at 2:26 PM, Ruben Vermeersch ru...@savanne.be wrote: Hiya GNOME lovers! It's that time of the year again: Google's Summer of Code is approaching. We are in the midst of preparing it all [1] but we need your help by submitting great project ideas. Student proposals will start to roll in on March 29, but we'd like to make sure there are plenty of projects from them to choose from and have mentors ready to volunteer their time. So what should you do? Please visit [2] and enter your project ideas under the New Untriaged Ideas section. A committee will be formed up later to triage the ideas prior to the opening of the proposal period. If you would like to volunteer your time to mentor but don't have a project idea, surf over and claim one. Mentoring is an awesome way to get more involved with the community and introduce someone to it. If you would like to throw your hat in the ring for the triaging or selection committees and other GSoC related tasks, pop on over to #soc-admin, join the soc-mentors-list and let one of the administrators for the program know you want to be involved in making GNOME rock. This year's administrators are Ruben Vermeersch, Christophe Fergeau and Daniel Siegel (and Sandy Armstrong, for as long as his time doesn't get stolen by the upcoming kid :-)) Cheers, The GNOME Google Summer of Code Administrators [1] http://live.gnome.org/SummerOfCode2010 [2] http://live.gnome.org/SummerOfCode2010/Ideas -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ 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: GtkNotebook scrolling usability
On Wed, Mar 10, 2010 at 4:20 PM, Luca Ferretti elle@libero.it wrote: Il giorno mer, 10/03/2010 alle 16.50 -0600, Cody Russell ha scritto: Just wanted to post on the lists and see if people have thoughts on this, otherwise I'm probably going to file a patch to either rip the feature out or at the very least make it so we can disable it. :) I'm a big fan of this feature, it allows me to quickly switch between tabs without move the pointer. It's really useful when I don't know/remember which tab I actually need or want to activate. It helps you to be more streamlined, so I can't understand why it should be an issue for novice users... I also happen to be a fan of this feature. I use it in my web browser of choice, in gnome-terminal, in gedit, and similar applications. I don't find it as handy in preferences dialogs. If there ends up being a bug report about this, please share the bug number. And hopefully we can get some usability nerds involved in this decision. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Google Summer of Code 2010 Call for Ideas
On Tue, Mar 9, 2010 at 5:20 PM, Brian Cameron brian.came...@sun.com wrote: Ruben: At the GNOME Usability Hackfest, it was discussed that there is a real need to develop some free software to help the GNOME Usability team better collaborate. Máirín Duffy discusses this in some detail in her blog: http://mairin.wordpress.com/2010/03/01/the-one-where-the-designers-ask-for-a-pony/ Could this project be a part of the Google Summer of Code project? That would be a great project, as long as somebody is willing to mentor it. ;-) That's usually the only limiting factor, as long as it's GNOME-related. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Wed, Jan 13, 2010 at 8:07 AM, Luca Ferretti elle@libero.it wrote: Il giorno mer, 13/01/2010 alle 08.38 -0500, Dan Winship ha scritto: On 01/13/2010 07:47 AM, Luca Ferretti wrote: Il giorno dom, 22/11/2009 alle 16.32 -0800, Sandy Armstrong ha scritto: Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Ctrl+PgUp/Down can be invoked with only the _right_ hand using right Ctrl key. Right, but when browsing the web, you'll generally have one hand on the mouse for clicking/scrollwheeling, and so for right-handed people, having the important keyboard operations be left-hand-only is nice. This case seems excessive to me. If you've one hand on your mouse, use the mouse to change tab, clicking or using the scroll wheel :P And yet, I was about to respond identically to you before I saw that Dan beat me to it. I believe that right hand on mouse, left hand on keyboard is extremely common. Consider selecting text and copy/pasting, or using ctrl+tab to change tabs, with the mouse in the content area so you can scroll, select text, etc. So while I don't have any data outside my own usage and intuition, I really don't think it's excessive, as you say. I suppose the scenario for keyboard shortcuts here is both hands on keyboard (or no ability to use the mouse). I think that's a bit limiting, but even if we were to accept it as true, we can still say that on a full keyboard, ctrl+page up/down requires you to shift your right-hand considerably away from home row, making it fairly inconvenient. Fun fun fun, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Sun, Nov 22, 2009 at 4:23 PM, Joanmarie Diggs joanmarie.di...@gmail.com wrote: Hi Behdad. On Sun, 2009-11-22 at 18:57 -0500, Behdad Esfahbod wrote: As a user, I tend to agree with that sentiment. While I understand the usefulness of ctrl+tab, it's not as handy and useful as rotating between tabs. So, what can we do about it? Doesn't Ctrl + PageUp/PageDown accomplish the same thing? That's what I use to switch from tab to tab. Most users I've spoken to about this prefer ctrl+tab because it is similar to alt+tab, and can be invoked with only the left hand. Also, what Behdad said. :-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Backup
On Wed, Nov 18, 2009 at 3:47 PM, Michael Terry m...@mterry.name wrote: 2009/11/18 Tristan Van Berkom t...@gnome.org: Usually what is best is for you to make an official proposal and explain why you think your module should be included in GNOME releases - personally I think if we dont have any backup mechanism I would probably give it a thumbs up. Fair enough, and I would be willing to go through that process for my own pet project, but I was interested in taking the temperature. My own project may not necessarily be the best fit (though of course I think it's the best thing since sliced bread). If you intend to propose your app for 2.32 (aka 3.0), note that the proposal period has not yet opened, but you can get a head start by trying to follow the GNOME release schedule, and potentially migrating your code and bug tracking from launchpad to gnome.org. Infrastructure things like this help to reduce some of the hurdles in module proposals. Planning your next stable release to synchronize with GNOME 2.28 is definitely a good idea, along with getting some development releases out during the 2.27.x cycle. I wanted to make a 'fill-in-the-blank backup module proposal'. Unless such a discussion would best take place in the context of a concrete module proposal? Yup, that's usually how it works. More people become interested in joining the discussion when there's a specific module proposal. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Backup
On Wed, Nov 18, 2009 at 5:03 PM, Bastien Nocera had...@hadess.net wrote: On Wed, 2009-11-18 at 17:30 -0600, Michael Terry wrote: Is GNOME interested in shipping an official backup program? I (as a long-time lurker) haven't ever noticed discussion about it. Where's the code? :) https://launchpad.net/deja-dup Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Thu, Oct 29, 2009 at 3:59 PM, Martyn Russell mar...@lanedo.com wrote: On 29/10/09 22:49, Sandy Armstrong wrote: On Thu, Oct 29, 2009 at 3:06 PM, Patryk Zawadzkipat...@pld-linux.org wrote: On Thu, Oct 29, 2009 at 10:51 PM, David Zeuthenda...@fubar.dk wrote: Not to sound like an asshole or anything but, I mean, didn't distros try including Tracker by default in previous releases? AFAIR, it didn't really work well. So if GNOME included Tracker in the next release and core parts of GNOME started depending on it in a way that couldn't be turned off... then distros would be in a lot of trouble if Tracker didn't work well. This would probably end up reflecting badly on the GNOME project. Are we talking about the tracker crawler or tracker itself (index and metadata storage)? I can understand how including the crawler is not the best idea (especially until we get ourselves recursive inotify support) but what can go wrong with tracker itself? What can go wrong introducing a brand new barely-used technology and set of APIs as something we call GNOME? I think that question answers itself. ;-) I already said which applications use it. Tracker is not brand new and it is not barely used. To be clear, I was speaking about the store as opposed to the indexing. Where is it used on the desktop? The 0.7.x APIs are brand new and barely used, if I've understood this thread correctly. So the most pragmatic approach seems to be to wait until Tracker matures and people are using it in ways that make including it as part of the GNOME desktop an easy choice. Right now, we're still at the imagine the possibilities stage with Tracker on the desktop. Are we? Have you tried it yet? Looking a few dozen emails back at your list of how Tracker is currently used, everything currently implemented is related to indexing, not the store (unless you look at Maemo). Also, your list was a list of applications that somehow use or integrate with Tracker. It was not a list of use cases, and did not describe in detail how those applications are integrating with Tracker. Is it just more indexing stuff? And no, I have not tried Tracker in a long time. An indexer is not something useful to me (though I agree it is useful to many people), and the store has (at this time) nothing to offer me as a user, from what I understand. I'd rather wait until some compelling use cases are actually implemented. What use cases would you like to see? I think this is kind of the core of the problem here. I get the feeling that the Tracker developers are proposing a technology because they want to enable application developers, and that it is expected that application developers will come up with and implement compelling use cases. Like others in this thread, I think this is just backwards. I feel like the applications and use cases should shape the Tracker API, and it's in everyone's best interest not to bring it in prematurely. I'm not trying to knock Tracker at all, because I think it's cool stuff. I just would rather we bring it in when our applications are using it in ways that will provide clear benefits to our users. Right now, the only clear benefit I see is better search thanks to the indexer. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Oct 27, 2009 at 1:37 PM, Jamie McCracken jamie.mccr...@googlemail.com wrote: Whatever shell is used in Gnome 3 will at some point likely provide an out of process applet system (especially if enough people scream!) This is simply not consistent with what the gnome-shell developers have been saying all along (in-process javascript-based extensibility like firefox extensions). However, that's getting off-topic, and realistically search-type actions will probably make the most sense in the overlay's search box, so my guess is that tracker developers would be encouraged to integrate there instead of adding arbitrary search UI in the shell. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 7:10 AM, Ryan Lortie de...@desrt.ca wrote: On Wed, 2009-10-14 at 14:00 +0200, Rodrigo Moya wrote: if dconf listens to changes in gconf, 3rd party apps would just need to link to glib/GSettings instead of libgconf, and their migration would be done automatically, right? dconf won't be made to listen to GConf. One alternative, though, is that a GSettings backend could be written that uses GConf (and its existing database) instead of dconf. This would allow applications to use the new API to access their existing settings in the existing database. dconf could be brought in later. That doesn't fix anything; it just delays an identical migration. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 7:07 AM, Ryan Lortie de...@desrt.ca wrote: On Tue, 2009-10-13 at 13:34 +0200, Rodrigo Moya wrote: I think it makes sense to do the migration for all the apps at once. Also, the migration from gconf can be done directly from dconf, the first time it starts, or even it could be clever enough to synchronize changes from gconf every time it starts, to cover apps that migrate to dconf later. That would remove the apps' responsibility to do the migration, which would be a lot of code to have that in all applications. I personally think migration is less critical than a lot of people think. Here's why (for me at least): - I often reinstall my distro when the new release comes out If it would help we could get numbers from distros on how many users do upgrades vs clean installs. Also keep in mind users with a separate /home partition who do clean reinstalls but keep the same home directory. I really hope that our general user experience is better than completely wipe and reinstall every [six] months, but I don't have hard statistical data about what actually happens. - GConf (and GSettings) are not used to store important things like emails, bookmarks, contacts, cookies, passwords, ... Let me take a quick look at what Tomboy stores: * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * Formatting/linking preferences * List of pinned notes that always show up in tomboy tray menu * Global keybindings * Some keys used to determine if it's the first run So we can see that in the case of the application I maintain, the user would lose a few minutes fixing all of this. In the case of pinned notes, it could be a very frustrating thing since it's easy to forget what you had pinned, and while you could argue that this should not be stored in gconf, the fact of the matter is that right now it is. - we're changing how our entire desktop looks/feels at the same time anyway, so the user will need to reconfigure that stuff (if they please) I'm don't agree with this; how many of our user-facing applications are making drastic changes for 2.30? The only thing I can think of is the gnome-shell migration. - it never takes me more than a few minutes of fiddling to get stuff back to how i like it in terms of settings. As shown above, this is not true for every application. If there are other applications in a similar situation to Tomboy, these minutes add up. - doing some sort of automated migration encourages application developers to base their new settings schemas on the way they did things with GConf, rather than giving them a chance to have a 'clean break' and take full advantage of the new API (and also remove years of cruft). Good point. I hadn't even considered this. Could you please list the new features we can use? I did not see them in your original proposal. It certainly makes sense to provide some mechanism for applications using GConf to continue to function (note: this mechanism might be continue using GConf). For applications that get ported, though, *shrug*. As long as this is clearly communicated, it's not a big deal. I will not freak out if I have to do the migration myself, but I do think it's worth looking into a mass migration. I'm open to disagreement on this point :) Excellent ;-) Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: dconf
On Fri, Oct 16, 2009 at 10:19 AM, Iain i...@gnome.org wrote: While not disagreeing with you on the need for migration * A bunch of metadata related to synchronization that, if lost, requires you to start over, which an upgrading user might find to be a hassle * List of pinned notes that always show up in tomboy tray menu * Some keys used to determine if it's the first run were the sort of things that were never meant to be stored in GConf because write access to the GConf DB is not guarenteed so the user cannot set anything. In these cases the keys used to determine if it's the first run could never be set, so it would always be the first run for the user, pinned notes would never be pinned and synchronization would always require you to start over. These things should have been stored with a GKeyFile in the ~/.config/Tomboy directory, IMO If that's the case, I'll happily migrate them there. Thanks for the info! Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
What does gnome-shell give us?
Hey folks, Taking a step back from the excitement over shiny new things, I was just wondering if somebody could give a few bullet points that explain what gnome-shell gives us over our current desktop experience. I feel like there's a lot of stuff that's different or missing but I'm not sure I'm understanding where it's better. But then again, I haven't been able to try it out for months because I'm stuck on GNOME 2.24 right now and I can't build gnome-shell there or run it in a VM, so all I have to go on lately are fairly superficial articles on the web. ;-) So really, this is not meant to start a flamewar, or to criticize shell at all. I just want to see a list of what we hope to gain from it, so that I can understand why the move makes sense to so many people in the community. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What does gnome-shell give us?
On Fri, Oct 2, 2009 at 11:12 AM, Colin Walters walt...@verbum.org wrote: On Fri, Oct 2, 2009 at 3:04 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: Hey folks, Taking a step back from the excitement over shiny new things, I was just wondering if somebody could give a few bullet points that explain what gnome-shell gives us over our current desktop experience. I feel like there's a lot of stuff that's different or missing but I'm not sure I'm understanding where it's better. I see it as twofold: * A visual refresh, using animations and graphics capabilities to enable new UI that we couldn't do before. * Fixing some design problems in the old UI, a few prominent ones of which are: - Make recent documents much more prominient - Search for applications/docs - Application based system Thanks, this is the exactly the sort of thing I was looking for. It gives me some good context for evaluating gnome-shell. Much appreciated, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Answering why gnome-shell might not work for me (was Re: What does gnome-shell give us?)
I really don't want to have a thread that devolves into gnome-shell bashing, but then again this is not an inappropriate venue to answer your question. I've changed the subject because I think it's a different discussion from the rest of the thread. On Fri, Oct 2, 2009 at 11:37 AM, Colin Walters walt...@verbum.org wrote: On Fri, Oct 2, 2009 at 3:04 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: Hey folks, Taking a step back from the excitement over shiny new things, I was just wondering if somebody could give a few bullet points that explain what gnome-shell gives us over our current desktop experience. I feel like there's a lot of stuff that's different or missing but I'm not sure I'm understanding where it's better. Also, I would subdivide better into better right now, better once bug 12345, bug 12346... are fixed, and i don't see how this could ever work for me. Sure, bugs/regressions are to be expected, so what I was asking about (and what you answered) was more along the lines of how will gnome-shell 2.30 be better, or maybe why should convince the release team to include gnome-shell in GNOME. We certainly have some serious regressions right now, the application browse in particular is really unloved, but it's also among the things we'll be working on quite soon. I could absolutely understand if you were saying not better right now (for me personally it's in the middle state, a few bugs are fairly bad). But if you're saying something closer to the latter that's more of a concern. Well, since you're asking, I am certainly concerned that gnome-shell might fall in the latter category for me. Again, I haven't used it since before GUADEC due to dependency issues, but from what I can tell it is still the same basic workflow, so I don't feel completely unjustified in my concern. I agree with the idea of trying to achieve an activity- or application-centric UI. I also agree with the stated goals of providing a visual refresh, and exposing recent documents in a useful way. The real killer for me is that I get the feeling that gnome-shell is not activity-centric, but shell-centric. Shell is set set up like a dashboard, which is not an unpopular type of UI, but it feels unnatural to me in a desktop situation. I have getting stuff done mode, where I'm doing the actual work I have a computer for in the first place, and then I have shell mode, where I manage activities/applications/workspaces/documents. These two modes are completely separate from one another, have very different behavior from one another, and shell mode is completely different from every other popular desktop UI. It's kind of hard for me to explain why this separation is so jarring for me. It could be the foreign nature of it, as I am a little slow to accept change. But the best way I can think to describe it is that it removes the magic from the desktop experience. Arthur C. Clarke said that any technology sufficiently advanced is indistinguishable from magic. I think it makes sense to strive for UIs that seem magical to users. When I use gnome-shell, I feel like it's a very hands-on approach to activity management. But I don't want to learn a new application that requires my full attention to manage activities. With current default GNOME panel, I can switch workspaces and applications through a minimalistic UI without changing modes. Finding and launching applications is tedious, but it too doesn't require a mode switch. These basic desktop features blend into the overall GNOME UI and fit familiar (if imperfect) interaction models. For myself, I've solved the problems with the current task switcher and application launcher by using gnome-do's Docky UI. I get a fairly application-centric approach to task switching (which works across virtual workspaces), and a quick method of application launching that does not require me to open a full screen application like gnome-shell. I'm not saying that GNOME should adopt Docky instead of gnome-shell. Instead, I'm trying to demonstrate that there seem to be ways to achieve the stated goals of gnome-shell without introducing a new full-screen mode that, for me, interrupts my work. Also a few other goals to the list: * Actual design for how workspaces behave (We didn't really have this in any consistent way, but now is an opportunity to fix it right, e.g. make moving an application to a workspace a persistent operation, etc. Actually a lot of cool things are enabled when we have an application based system) I'm very interested to see this progress. I think this type of improvement to workspaces could be very beneficial, and with zeitgeist we may even be able to automatically populate workspaces and bring some of the magic back to the desktop. * Help push forward the technology stack by being a consumer of Clutter, introspection etc., including hopefully providing a motivation for graphics drivers This is a good long-term goal, too. Sandy
Re: Answering why gnome-shell might not work for me (was Re: What does gnome-shell give us?)
On Fri, Oct 2, 2009 at 3:54 PM, Colin Walters walt...@verbum.org wrote: On Fri, Oct 2, 2009 at 7:54 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: With current default GNOME panel, I can switch workspaces and applications through a minimalistic UI without changing modes. https://bugzilla.gnome.org/show_bug.cgi?id=594931 Thank you Colin, I promise that before I open my mouth again I'll try a recent build and check bugzilla. ;-) I understand it's not very helpful for me to say I don't think the overview is useful without providing a better suggestion. But on the other side, I do think it's fair to compare what gnome-shell brings with what we currently have and other popular desktop modifications. Thanks again, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ChangeLog generation and git
On Thu, Oct 1, 2009 at 12:31 PM, John Stowers john.stowers.li...@gmail.com wrote: I will collect my findings and post on live.gnome.org when done. http://live.gnome.org/Git/ChangeLog Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
On Wed, Sep 30, 2009 at 11:20 AM, Wolter Hellmund wolte...@gmail.com wrote: The project is intended to use a Brainstorm System, which is already provided by IdeaTorrent. It is already implemented in successful projects such as Ubuntu Brainstorm, SourceForge.net and others. Is there any data indicating that Ubuntu Brainstorm works better than filing enhancement bugs? Are there any statistics about how many Ubuntu Brainstorm ideas are actually implemented, and how many are implemented largely due to feedback from Brainstorm? I would hate to implement a system like this that gave users a false impression of being able to vote features into GNOME, so I think hard data showing that's not what would happen is important. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Danger: older bugs are getting squashed with NEEDINFO
On Fri, Sep 18, 2009 at 12:20 PM, Andre Klapper ak...@gmx.net wrote: We are sorry on *not* having communicated with the rest of GNOME about this change, but we believed that all developers subscribed to bugs. We would very much like to know which other mailing lists we should add on. The only mailing list that I ever assume GNOME developers are on is desktop-devel-list. When you say subscribed to bugs, I can only assume you mean the gnome-bugsq...@gnome.org list which appears in the CC here. I have never heard of this mailing list until now. Is this something I should be subscribed to? About the change... I usually don't mark a bug CONFIRMED until a developer has confirmed it, and sometimes things slip through the cracks. This is especially the case with Enhancement bugs, because I only mark such bugs CONFIRMED if I intend to implement them in the short-term. Setting them to NEEDINFO seems a little awkward. NEEDINFO bugs tend to disappear from a lot of searches, but I guess with this change I'll need to start actively keeping an eye on that category. I'm not too freaked out about it, but at the same time I'm not sure how the change helps the bugsquad in the case of my modules. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GlobalMenu Application for inclusion as a GNOME module
On Thu, Sep 3, 2009 at 6:44 AM, Colin Walterswalt...@verbum.org wrote: On Wed, Sep 2, 2009 at 7:17 PM, Sandy Armstrongsanfordarmstr...@gmail.com wrote: Assuming gnome-panel (and therefore panel applets) go away in GNOME 2.30, do you have a plan for integrating GlobalMenu in gnome-shell? The design for 3 is currently that application-global actions go in the application menu area, while document or window-specific ones remain in the window. I'm not going to debate this decision (which I disagree with) here, but does that mean that in the opinion of gnome-shell developers, GlobalMenu will not be a useful or necessary addition to gnome-shell? Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GlobalMenu Application for inclusion as a GNOME module
On Wed, Sep 2, 2009 at 3:40 PM, Pierre Slamichpierre.slam...@gmail.com wrote: Dear GNOME maintainers, This is a proposal on behalf of the GlobalMenu developers for its inclusion either in gnome-applets or as a dependency of GNOME. GlobalMenu is an applet that lets the user have its application menus displayed in the Panel rather than in the windows. For those who haven't heard about it, think of GNUStep or MacOS as an example. Or you can look at a screenshot to get an idea http://code.google.com/p/gnome2-globalmenu Assuming gnome-panel (and therefore panel applets) go away in GNOME 2.30, do you have a plan for integrating GlobalMenu in gnome-shell? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 4:26 AM, Luca Ferrettielle@libero.it wrote: 2009/7/24 Bastien Nocera had...@hadess.net: Heya, Yesterday I've replaced the RSS Podcast date parsing in totem-pl-parser to use GMime instead of evolution-data-server's libcamel, which should make it easier to build, and be lighter for dependencies. We require gmime-2.4, which is the current stable version. For the record, in jhbuild gmime fails to build C# bindings Talking to Jeff Stedfast, this is most likely caused by using gtk# trunk in jhbuild. Although this will surely be fixed, we recommend switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 branch in SVN, which is still maintained). I am not aware of any schedule indicating a release of gtk# from trunk by GNOME 2.28 (but I could be wrong). Hope this helps, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 7:15 AM, Frederic Petersfpet...@gnome.org wrote: Sandy Armstrong wrote: Talking to Jeff Stedfast, this is most likely caused by using gtk# trunk in jhbuild. Although this will surely be fixed, we recommend switching jhbuild to gtk# 2.12 (or building from the gtk-sharp-2-12 branch in SVN, which is still maintained). What about gnome-sharp ? Is it ok to follow trunk ? Probably; I'm not sure. Same question applies to gnome-desktop-sharp, too. CC'ing Mike Kestner, who should have a better idea of what to recommend. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GMime as an external dependency
On Fri, Jul 24, 2009 at 9:41 AM, Andre Klapperak...@gmx.net wrote: Am Freitag, den 24.07.2009, 10:59 -0500 schrieb Mike Kestner: Yes, gtk-sharp-2-12-branch is the stable and probably final 2.x branch for gtk-sharp. The trunk branch will target gtk 3.0 when it is released. The 2.12 branch should be used for future 2.x builds. trunk is still 2.x for gnome-sharp and gnome-desktop-sharp. I'll send a message to d-d-l if/when they switch to 3.0. Does this actually mean that cleanup bugs like http://bugzilla.gnome.org/show_bug.cgi?id=580422 or http://bugzilla.gnome.org/show_bug.cgi?id=587320 that require GTK API that was introduced after GTK 2.12 cannot be fixed before GTK3 gets released? If so this totally blocks GTK3 readiness for applications that depend on gtk-sharp I assume? Well, as stated in at least the Tomboy bug above, we should be able to work around this even if we are using gtk-sharp 2.12. We can just DllImport the new API ourselves. F-Spot has a project on gitorious (called gtk-sharp-beans, I think) where they maintain a few post-2.12 pieces of API that they use, so gtk-sharp being stuck on 2.12 is not too big a hindrance for us. So to be clear, that Tomboy bug does not block on updates to gtk-sharp, and is targeted to be fixed by Tomboy developers before GNOME 2.28. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PyGTK global keybinding module
On Thu, Jul 16, 2009 at 3:47 AM, Ulrik Sverdrupulrik.sverd...@gmail.com wrote: Now which way the gnome desktop takes I don't know. Global keybindings are certainly coming, everyone is including tomboy's code. I know the most sensible way for gnome would be to have a C library + A python binding, I've put this together as a pure python module for my application. A little while ago somebody put together a C library called libghotkey: http://www.grillbar.org/wordpress/?p=250 Don't know anything about its status. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Tue, May 12, 2009 at 5:46 PM, Hubert Figuiere h...@figuiere.net wrote: On 05/12/2009 08:01 PM, Robert Carr wrote: For 2.28, it may make sense to have both gjs and Seed as modules, and try and keep code somewhat compatible. It's still not entirely clear which JavaScript engine is going to end up being better long term, so we might not want to completely commit to one yet. With that plan, it is -1 from me. 2 engines is one too many IMHO. We'll have two engines if Epiphany moves to webkit and gnome-shell sticks with gjs. If the only user of gjs in GNOME is gnome-shell, and the gnome-shell developers are happy with a move to Seed (have we heard from them on this yet?), then I am +1 for Seed's inclusion and gjs' exclusion. I agree with Hubert that sending mixed messages about browser/js engines is not a good idea. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Move back 2.27.1 one week?
On Fri, Apr 24, 2009 at 7:13 AM, Vincent Untz vu...@gnome.org wrote: Le mercredi 22 avril 2009, à 10:50 -0500, Jason D. Clinton a écrit : With the outstanding git migration problems (and the resulting inability to jhbuild) perhaps we should postpone 2.27.1 by one week? Didn't see a lot of replies, but I think it makes sense. Any other opinion? I'm fine either way, but I would love to know ASAP so I can decide how to spend the rest of my weekend. Is there an official decision yet? Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On Wed, Apr 22, 2009 at 7:46 AM, Vincent Untz vu...@gnome.org wrote: Hey, The GTK+ team documented how they'd like to see the git commit messages in http://git.gnome.org/cgit/gtk+/tree/README.commits = copy paste = The expected format for git commit messages is as follows: === begin example commit === Short explanation of the commit Longer explanation explaining exactly what's changed, whether any external or private interfaces changed, what bugs were fixed (with bug tracker reference if applicable) and so forth. Be concise but not too brief. === end example commit === - Always add a brief description of the commit to the _first_ line of the commit and terminate by two newlines (it will work without the second newline, but that is not nice for the interfaces). - First line (the brief description) must only be one sentence and should start with a capital letter unless it starts with a lowercase symbol or identifier. Don't use a trailing period either. Don't exceed 72 characters. - The main description (the body) is normal prose and should use normal punctuation and capital letters where appropriate. Normally, for patches sent to a mailing list it's copied from there. - When committing code on behalf of others use the --author option, e.g. git commit -a --author Joe Coder j...@coder.org and --signoff. I'd like to suggest that this is the default recommendation for GNOME modules, since having some common guidelines will make the life easier for most people. If some maintainers disagree, they can of course ask for something else in their modules. We can copy paste it to http://live.gnome.org/Git/CommitMessages if people agree. I agree. And either Git/Developers should be expanded to include all these details, or its commit message section should link to Git/CommitMessages. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomeweb-wml pushes not causing website updates. missing a hook?
On Sun, Apr 19, 2009 at 9:18 PM, Owen Taylor otay...@redhat.com wrote: On Sun, 2009-04-19 at 13:19 -0400, Owen Taylor wrote: On Sat, 2009-04-18 at 22:44 -0700, Sandy Armstrong wrote: Hi, Not really sure where to direct this, but I made an update to the Tomboy website 3 hours ago: http://git.gnome.org/cgit/gnomeweb-wml/commit/?id=3d1e649acdc765290de0f4a5abbec5ba0064d25f I would expect the live site to have updated by now. Are we missing a hook or some other infrastructure? Is there some manual step I can do to force an update? Indeed, not yet implemented. (The mails get sent on commit, but the scripts that parse them and trigger builds haven't been updated for changes in the mails.) I started working on it yesterday, but I got sidetracked with some GNOME Shell work. I'll try to finish up the procmail handling today. No real way you can force an update, though someone in the gnomeweb group could probably do it manually by looking at how the scripts work. I think I have this set up now, though I haven't really done any testing. I gave gnomeweb-wml a manual run after I set up the hook, so any changes to that done while the updates were unhooked should have been caught. The Tomboy website has still not been updated. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 20, 2009 at 9:24 AM, Hubert Figuiere h...@figuiere.net wrote: On 04/19/2009 05:38 PM, Shaun McCance wrote: The Tomboy applet is an extremely convenient way to access your notes. You think of it as wasting valuable screen real estate. But to a heavy note-taking person, it's just really convenient. Except that Tomboy using a status icon in the notification area has the exact same feature set. Just that the notification area does not offer so much possibilities in term of positioning. Sure, but it's cheating, and the goal is still the same: to have something like an applet in a predictable location. Sandy ___ 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 Sun, Apr 19, 2009 at 6:31 AM, Emmanuele Bassi eba...@gmail.com wrote: On Sun, 2009-04-19 at 14:34 +0200, Sebastian Pölsterl wrote: I think it would be a big mistake to omit applets in the new gnome desktop evolution. why? Because users want some functionality to be conveniently available from the time they log in to the time they log out. we've been changing the platform gradually over the years, mostly by deprecating stuff and including new functionality. nevertheless, I haven't heard a single justification for the continued existence of applets. See above. what do applets provide, nowadays, and are they even remotely useful? what can deskbar-applet provide that cannot be implemented with something that does not sit inside a 24x24 icon on the most valued piece of screen real estate? isn't a gnome-do approach equivalent to the deskbar-applet? I personally use gnome-do to access Tomboy more than I use our applet/tray icon. Do you think you and I are typical? Would be nice if somebody did some work to research this instead of just saying I feel this way, so why don't you?. why tomboy-applet is so special? it's basically a launcher with a custom context menu. also, starting up deskbar-applet *and* tomboy as applets on my panel causes my desktop more to start up on login; not great turn ons, especially when there are developers out there trying to get the boot-to-UI process down in the seconds range. Users put all sorts of crap in startup scripts, session management, panel, etc, because they want it available at login. This is not going to stop if we get rid of applets. The correct solution is to fix the performance problems. Of course, I 100% agree that any applet's functionality should be available *without* it being a required startup item. But going back to your previous statement, doesn't the use of something like gnome-do also increase my login time? But don't a great many users take that hit willingly? clock; and the volume is now becoming a notification area icon since basically everyone has media keys on their keyboard and don't need an on-screen slider anymore. Wow, that statement strikes me as very out-of-touch with reality. yes, it was all good with GNOME 1.x, but even for 2.x the amount of applets has been steadily decreasing - also because writing an applet is not trivial (as it involves dealing with some of the most obscure and less documented parts of our development platform). people have been abusing the system notification area with all sorts of crap (beagle, tomboy, etc.) because writing an applet is *boring* (server files anyone?) and *hard* (weird build changes, hard to debug uses, completely different APIs for handling the menus), and it really doesn't provide you with much functionality (wow, an icon and a context menu!). Yes, we have all abused the hell out of the notification area, despite HIG to the contrary. Tomboy supports it because users demand applet-like functionality even without a GNOME panel. One of the most common ways Tomboy is used is to be added to GNOME session startup and run in the notification area. Do you think this abuse of the notification area to emulate applet behavior is the right thing to promote in the gnome-shell era? so, please: saying it would be a mistake without providing reasons why it would be good to have applets support in the first place it's not going to convince me that we should keep them. I also agree with Sebastian's response, btw. Applets (whatever they are) should be *easy* to create. The idea of ever-present desktop objects is not going to go away, and users are not going to stop wanting it. I'm thinking that the best thing we can do is to run some (long) usability studies on this, or find similar research that can help us make an informed decision. We are developers, and often have very different ideas about how to use a computer, compared to (for example) a typical office worker. And yet, a significant amount of GNOME users *are* developers and otherwise-advanced computer users. Perhaps we should attempt to identify typical user types, and evaluate what it would take to make GNOME 3.0 work for them. But we don't have the money or time for this, so maybe there is existing data that can help us out a bit. Any thoughts? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Git documentation reorganization and cleanup
On Sat, Apr 18, 2009 at 7:17 AM, Alberto Ruiz ar...@gnome.org wrote: 2009/4/18 Sandy Armstrong sanfordarmstr...@gmail.com: Hi all, Just a quick note that I've been working a bit on cleaning up our git documentation. It is now centralized here: http://live.gnome.org/Git And the main developer howto has been simplified. It now recommends a single simple workflow of hacking, making a single commit, and generating a patch using `git format-patch HEAD^`: http://live.gnome.org/Git/Developers I really want to keep this page comprehensible for new contributors, as much as we can. If you have ideas for how to improve it, any help is welcome. Please keep in mind that I'm actually pretty new to git, and may not be aware of better workflows for new contributors. Hi Sandy, great job. However I miss some docs for maintainers of new modules. In freedesktop when you have a new empty repository, you can't clone that repository (something that sounds like the natural first step, specially for people used to subversion). So you have to create your own repository, push it, and then set the origin properly. I found this step pretty confusing at the time. http://live.gnome.org/NewGITRepos I'll make sure more places link to this. Thanks for the feedback, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On doap file naming
On Sat, Apr 18, 2009 at 5:18 AM, Owen Taylor otay...@redhat.com wrote: On Sat, 2009-04-18 at 03:51 -0400, Behdad Esfahbod wrote: Hey, I wonder if naming the doap file after the module name is optimal. Wouldn't be it easier to process if the file was simply named doap or something like module.doap? Now's the time to decide, before too many modules add one... Some advantages of modulename.doap: - Makes sense if the file is copied outside the context of the module, or downloaded from a web URL. - Is amenable to mime-type associations - Stands out more from all the auto* and boilerplate in the module toplevel. Conceivable disadvantages: - A tiny bit harder to explain how to create it. - needs to be renamed if you rename your module - you can't decide how your module is spelled. pkg-config? pkgconfig? PkgConfig? - as you say, puts just a little bit of burden on the automated user to find the file. I like the current scheme. I've added a note about [module].doap here: http://live.gnome.org/MaintainersCorner If the policy changes, please update this page. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnomeweb-wml pushes not causing website updates. missing a hook?
Hi, Not really sure where to direct this, but I made an update to the Tomboy website 3 hours ago: http://git.gnome.org/cgit/gnomeweb-wml/commit/?id=3d1e649acdc765290de0f4a5abbec5ba0064d25f I would expect the live site to have updated by now. Are we missing a hook or some other infrastructure? Is there some manual step I can do to force an update? Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Git documentation reorganization and cleanup
Hi all, Just a quick note that I've been working a bit on cleaning up our git documentation. It is now centralized here: http://live.gnome.org/Git And the main developer howto has been simplified. It now recommends a single simple workflow of hacking, making a single commit, and generating a patch using `git format-patch HEAD^`: http://live.gnome.org/Git/Developers I really want to keep this page comprehensible for new contributors, as much as we can. If you have ideas for how to improve it, any help is welcome. Please keep in mind that I'm actually pretty new to git, and may not be aware of better workflows for new contributors. I'd like to add Git/FAQ and a page about workflows and/or branching strategies, as well as how to share branches via gitorious, github, etc. If anyone is interested in this, any content is better than no content. I'd rather see a FAQ full of unanswered questions than a blank one. :-) I'm also particularly interested in having good documentation for Windows and Mac users, so if anybody is already working on something similar, I'd love to hear about it. Let's try to keep our git documentation under l.g.o/Git/. Best, Sandy ___ 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 04/13/2009 12:20 PM, Olav Vitters wrote: On Mon, Apr 13, 2009 at 11:45:56AM -0700, Sandy Armstrong wrote: What other changes in GNOME 2.30 depend on inclusion of mutter and gnome-shell? Not really sure why we are willing to hold back the 2.30 release, instead of holding back the inclusion of gnome-shell. GNOME 2.30 does not depend on gnome-shell. GNOME 3.0 does. We could also name 2.32 as 3.0 if really needed. Hopefully my use of obnoxious repetition has made my point easier to understand. You wanted some input I guess. But IMO you should read the documents closely. See the QA part. We want some modules included, doesn't mean that they will, just that we really want them. Apologies, I misread the documents on this. It clearly says: we should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for GNOME 2.32 for the 3.0 release Thank you for that clarification. It makes a big difference! I am now a bit more confident that concerns about gnome-shell and other 3.0 additions will be handled correctly. Sandy ___ 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 04/09/2009 07:56 PM, Dave Neary wrote: Hi Vincent, Vincent Untz wrote: (generally speaking, I believe all release team meetings have public minutes since at least a few years, and the release team mailing list is used most 99% of the time for communication) Thanks for the info and the link, Vincent. I was not aware that the release team archives were public, since the membership is, in theory, restricted to the release team. I would never have thought to follow r-t to follow discussions abpout the future direction of GNOME (it seems to me that d-d-l *should* be serving that purpose, and if it can't for some reason, that's a problem that we need to address). What confuses me is why this wasn't discussed using the same module proposal process we have used for a few years now. Many shiny new things have been blocked for cycle after cycle due to issues or lack of consensus from the community (only to be included when they are deemed to be ready). Why is a new window manager not subject to this process? I sympathize with the desire to compete and innovate, but Dave's criticisms resonate with me: this doesn't feel like a community decision. If this were a regular module proposal email, I'd have pointed out a few things that concern me: * What is the a11y story for gnome-shell and mutter? Eiphany+Webkit has blocked on this for several cycles now. * What is the applet story for gnome-shell? As the maintainer of a GNOME applet (Tomboy), I accept that there may be significant work to port our applet to a new infrastructure, but now I'm concerned that I will also need to *create* that infrastructure (because gnome-shell is basically being imposed upon us, and not going through the regular process, I can only assume that if there's no applet infrastructure, it's my fault for not caring enough to contribute one). * People keep hand-waving the hardware requirements issues, but didn't Federico's deployment survey [0] show that almost half of all GNOME deployments are done via thin clients? We can't just pretend that we're not going to have to continue supporting these users. And lastly, until all of these issues are resolved, I am very concerned about the inevitable differences (and tensions) between distros and upstream GNOME for the next few years. Do we really want this to be like KDE, where some distros ship 3.x, some ship 4.x, and some ship both (then the user can only blame themselves for making the wrong choice, right?)? Perhaps I'm overly-conservative, but I am really quite worried about the state of GNOME for the next few years. That being said, I am glad to see a vibrant community growing around gnome-shell, and sincerely hope that they can work through these issues before 2.28. If everything works out perfectly, maybe my concerns will be shown to have been foolish. But normally when we make these decisions, we don't pretend we can predict the future. Best, Sandy [0] http://www.gnome.org/~federico/docs/gnome-deployments-2006/index.html ___ 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 04/13/2009 10:07 AM, Frederic Peters wrote: Sandy Armstrong wrote: I sympathize with the desire to compete and innovate, but Dave's criticisms resonate with me: this doesn't feel like a community decision. It may not have been clearly stated in the Planning for GNOME 3.0 email but of course the discussion is open, and welcome, in his blog Andre for example started with the following paragraph: Today I have released a GNOME release schedule proposal for 2.27 and 2.29 (please keep discussion streamlined on desktop-devel mailing list instead of e.g. the comments section of this blog). So, the whole thing is not a community decision, it is just the result of the release team thinking about 3.0, and *discussing* the plans with other people, be it in real life, at GUADEC, at the user experience hackfest, in other events, or in digital life. Nevertheless, while the plan is final (but flexible), it doesn't sum up 3.0 by itself, at the end it will be the community that will decide what goes in, simply by focusing of areas of interest. I think you are missing my point. The inclusion of gnome-shell did not follow the usual module inclusion process. Or maybe I am misunderstanding what you mean by the plan is final. If this were a regular module proposal email, I'd have pointed out a few things that concern me: * What is the a11y story for gnome-shell and mutter? Eiphany+Webkit has blocked on this for several cycles now. It has been repeated many times accessibility is important, it is a great asset of GNOME, and I want to keep it that way. The 3.0 schedule has this item for April 27th: Clear a11y plan and schedule MUST exist for 3.0 and must be in place for 2.29.5. Define acceptable regressions. The plan is not yet clear, but we want it to be, soon, because we care about a11y. If Epiphany/Webkit is not ready when a release comes around, it is not included. This rule does not seem to apply to gnome-shell. Instead, the release schedule is pushed back. * What is the applet story for gnome-shell? As the maintainer of a GNOME applet (Tomboy), I accept that there may be significant work to port our applet to a new infrastructure, but now I'm concerned that I will also need to *create* that infrastructure (because gnome-shell is basically being imposed upon us, and not going through the regular process, I can only assume that if there's no applet infrastructure, it's my fault for not caring enough to contribute one). I expect gnome-shell people will have a proper answer here; I remember a few exchanges going on about the i18n clock applet, but can't locate them at the moment. From hanging out in #gnome-shell and reading gnome-shell-list, I have seen that there is no clear plan for this, little interest on the part of lead developers, and contradicting answers that seem to converge mostly on the idea of a separate workspace hosting Dashboard-like widgets (which, in my opinion, is an irritatingly modal approach). Normally we get to test an app and understand its impact on the rest of the Desktop suite before deciding to include it in GNOME. * People keep hand-waving the hardware requirements issues, but didn't Federico's deployment survey [0] show that almost half of all GNOME deployments are done via thin clients? We can't just pretend that we're not going to have to continue supporting these users. Jason Clinton pointed somewhere else in this thread: An approach similar to what Dave Richards is using at City of Largo is actually the right way to do this: the compositor and a few video-intensive apps run locally on the hardware. There's no technical reason that Shell couldn't do the same thing. I was including Jason's post when I referred to hand-waving. This obviously increases the cost of each thin client, and will surely require an upgrade for many existing thin client installations. Aslo my current laptop, my development laptop, will be five years old next week, and I really want to be able to run 3.0 on it. We have been tackling performance problems in many places, for many cycles, this won't go to a waste. Normally we get to evaluate the performance issues of an app before deciding to include it in GNOME. And lastly, until all of these issues are resolved, I am very concerned about the inevitable differences (and tensions) between distros and upstream GNOME for the next few years. Do we really want this to be like KDE, where some distros ship 3.x, some ship 4.x, and some ship both (then the user can only blame themselves for making the wrong choice, right?)? We definitely do not want, and it is noted in the 3.0 plan: we should be ready to diagnose early on during the 2.29 development cycle and we should not be afraid of keeping GNOME 2.30 as 2.30 and waiting for GNOME 2.32 for the 3.0 release Well, I am glad that we are ensuring that gnome-shell will not suck for 3.0. Normally we wait until an app does not suck before deciding
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Metacity, Mutter, GNOME Shell, GNOME-2.28
On 03/24/2009 11:30 AM, Xavier Bestel wrote: On Tue, 2009-03-24 at 13:53 -0400, Owen Taylor wrote: On Tue, 2009-03-24 at 18:33 +0100, Xavier Bestel wrote: On Tue, 2009-03-24 at 10:28 -0700, Sandy Armstrong wrote: On 03/24/2009 08:47 AM, Owen Taylor wrote: Using Compiz to create a GNOME desktop using GNOME applications, the GNOME control-center, and so forth will of course remain possible. We have no current plans to create hard dependencies on GNOME Shell within the GNOME desktop (just as there are no hard dependencies on gnome-panel now.) Yeah, but I can still use gnome-panel in compiz. I understand the reasoning here, and don't have any suggestions or anything, but it's a bit disappointing that the new desktop experience will be so tied to the window manager. Asking to leave all the compiz goodness will be a tough sell :) What in particular would you miss? We're not looking to take goodness away from you, we are looking to replace it with better goodness (*). - Owen (*) Better here means, in particular, better integrated with GNOME. Hopefully more concentrated on consistent design and usability. Probably not quite as pretty, at least initially. Though there's no inherent reason we can't match Compiz bling for bling; we have access to the same hardware capabilities and a better programming environment. Admittedly I never tried gnome-shell. When I first tried compiz, I found the bling really just that: bling. I used it for a while, then came back to metacity - oh the horror ! Once you're accustomed to wobbly windows and workspaces-on-a-cube, there's no going back. The feeling of a solid desktop, with tangible windows is true usability, not just eye candy. There's more: non-computer-savvy people can't really grasp the workspace concept with metacity, whereas with compiz's cube (or one of its variants) it's obvious to them. Yes, metacity has a compositor. It's better but still far away. Of course I'm open to other ways to map my mind to the multiple applications running on my desktop, like most. But if gnome-shell feels clunky, if it looses the objects-I-can-touch feeling that compiz has, it's gonna be a tough sell. I agree completely with Xav. I have come to rely greatly on the Scale plugin (like Expose in OS X). There are also several animations that are either helpful directly or at least add to that tangibility Xav describes: * Animations on Window open, close, minimize, and maximize * Animations on appearance and disappearance of menus * Animation when moving a window between desktops I have tried switching to Metacity because I do occasionally experience unrecoverable hangs with Compiz's Scale plugin, but I lose too much productivity. I am looking forward to trying out gnome-shell soon so I can give more specific feedback. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Mea Culpa: If you've been rejected from being a Summer of Code mentor on the basis of not being a Foundation member, please reapply
Hi all, Sorry for this spam, but apparently I've been a little overzealous in enforcing our requirement that only GNOME Foundation members can be Summer of Code mentors. In fact, if you are not a foundation member but easily could be, you are more than welcome as a mentor! So, if you have received a rejection for your mentor application, and you feel that your contributions are enough to hypothetically receive Foundation membership, please accept my apologies and reapply. We can always use more mentors, even if you just want to help with ranking proposals. The proposal period opens today, so now is a great time to join. :-) Thanks for your time, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
If applying to be a SoC mentor, please share your link id via email or IRC
Hi folks, Frustratingly, when looking at the list of people who have applied to be mentors for GNOME in Summer of Code, administrators can only see your link id, not your full name. Sometimes there is an obvious correlation, but sometimes not. To move things along, I would ask that you let the administrators know that you have applied, and what link id you used. Please do this either by emailing soc-mentors-list or pinging an admin in #soc-admin. Believe it or not, random people and even students have been known to apply to be mentors in previous years, so we have to make sure we know who we're accepting. :-) Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
SoC 2009 Ideas List Officially Triaged (New Untriaged Ideas still accepted until Monday)
Hi all, I just wanted to briefly mention that the triage committee has finished sorting community-proposed SoC ideas into categories on: http://live.gnome.org/SummerOfCode2009/Ideas The student proposal period begins Monday, so if you have a new idea to add between now and then, please add it to the New Untriaged Ideas section, and the committee will decide how to categorize it. We are mostly interested in ideas with a mentor already attached. :-) Students: keep in mind that you may propose any idea you like, even if it is not on the list. With the proper attention to detail, even an Underground idea can lead to a Rockstar proposal. Enjoy your weekend, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Fwd: If applying to be a SoC mentor, please share your link id via email or IRC]
Apparently BCC'ing a list is now allowed, so here's a forward of this mail to soc-mentors-list: Original Message Subject: If applying to be a SoC mentor, please share your link id via email or IRC Date: Fri, 20 Mar 2009 07:23:53 -0700 From: Sandy Armstrong sanfordarmstr...@gmail.com To: soc-mentors-l...@gnome.org soc-mentors-l...@gnome.org Hi folks, Frustratingly, when looking at the list of people who have applied to be mentors for GNOME in Summer of Code, administrators can only see your link id, not your full name. Sometimes there is an obvious correlation, but sometimes not. To move things along, I would ask that you let the administrators know that you have applied, and what link id you used. Please do this either by emailing soc-mentors-list or pinging an admin in #soc-admin. Believe it or not, random people and even students have been known to apply to be mentors in previous years, so we have to make sure we know who we're accepting. :-) Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME accepted as a Google Summer o Code project
On 03/18/2009 03:21 PM, Jason D. Clinton wrote: On Wed, Mar 18, 2009 at 5:00 PM, Adam Schreibersa...@clemson.edu wrote: GNOME has been accepted as a GSoC project for 2009. If you're interested in being a mentor and/or reviewing student applications, make your way to [1] and sign up. As far as I can tell, students have to start submitting their proposal in five days and we have not yet triaged the bug proposals. Can we do this soon; do you need help? Yes, we do need help. Please see my response on soc-mentors-list for details. Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tomboy branched for GNOME 2.26
Hi all, Just branched Tomboy for GNOME 2.26, to a branch named gnome-2-26 [1]. Trunk is now open for new development. Cheers, Sandy [1] http://svn.gnome.org/viewvc/tomboy/branches/gnome-2-26/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gobject-introspection, gir-repository and gjs moved to git
On 02/11/2009 12:54 PM, John Stowers wrote: On Wed, 2009-02-11 at 17:25 -0200, Johan Dahlin wrote: gobject-introspection, gir-repository and gjs were today moved over to git. The old svn repositories will still work, but only in read-only mode. Does this mean the GNOME move to git is complete and the git repositories are now writeable and persistent? I'm just guessing, but if you check out git.gnome.org in your browser, some repos say GNOME git repositories and some say Git conversion preview repositories. I'm fairly certain there are still plenty of repos with errors (either conversion errors or problems in the original cvs or svn). Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus drop-down menu with view type
(You forgot to CC the list, so I'm CCing my response) On 02/08/2009 02:41 AM, Matteo Settenvini wrote: On sab, 2009-02-07 at 15:25 -0800, Sandy Armstrong wrote: On 02/07/2009 02:40 PM, Matteo Settenvini wrote: I'd personally prefer to have the quick drop-down menu with the view type replaced by a drop-down menu with the sorting order in the main nautilus window, because I find it more useful and accessible there. Maybe I'm misunderstanding, but assuming you view as list, why can't you click on the column headers to change the sort order? Or if you view as icons, you could right-click anywhere and select Arrange Items - By Modification Date, etc. Whoops, didn't think about it. My bad. No worries, hope it helps. Also, where is this drop-down menu with the view type? Do you mean in the View menu of the menubar? It's to the right of the zoom level. Hmm, not sure where this is. Maybe one of our distros patches it in or out. I'm on openSUSE 11.0. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus drop-down menu with view type
On 02/07/2009 02:40 PM, Matteo Settenvini wrote: Hi, I'd like your opinion on a usability concern. Whereas I change the ordering of elements in nautilus quite a lot (for example, ordering files by creation date, or by name, or by type...), I almost never change the type of visualization (icons, list, etc...). I'd personally prefer to have the quick drop-down menu with the view type replaced by a drop-down menu with the sorting order in the main nautilus window, because I find it more useful and accessible there. Maybe I'm misunderstanding, but assuming you view as list, why can't you click on the column headers to change the sort order? Or if you view as icons, you could right-click anywhere and select Arrange Items - By Modification Date, etc. Also, where is this drop-down menu with the view type? Do you mean in the View menu of the menubar? Best, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: how I write GTK+ theme?
On 01/18/2009 09:19 PM, Davyd Madeley wrote: I'm trying to get a feel for how hard it would be to write a tool similar to the Java Swing theme Napkin: http://napkinlaf.sourceforge.net/ This would be awesome. I've always thought Napkin was a good idea for customer prototypes. Was it Kathy Sierra who wrote about it a few years ago? Good luck, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On 01/06/2009 02:09 AM, Ruben Vermeersch wrote: What if this user publishes his branch using bzr (which works fine with the GNOME servers). How will I merge this branch, if I'm using git? It looks to me that with the git+bzr proposal, we're being forced to learn both systems anyway. We can control what's going on on our own servers, but not what happens outside. So don't tell us it's equivalent. It's not. And let's not forget the broad confusion that will arise from the fact that part of the developers advice you to use git and other parts advice you to use bzr. I am exceedingly less convinced that the advantages of supporting both outweigh the disadvantages (looking at the usage patterns, not the technical merits). I was on the fence about this, especially because I prefer bzr to git. But Ruben is right on the money. Implementing DVCS should not raise the barrier for entry for contributors. It should not make it *harder* for maintainers to accept patches/branches. If 70% of GNOME goes one way and 30% goes another way, it will suck for everybody. We need one official VCS for GNOME. The hybrid solution really only makes sense if that one VCS is bzr, which (sadly) seems to go against popular opinion. So assuming we have the manpower to do the git conversion and the tools to make it rock (viewvc, giorious, whtaever), let's JFDI. Man I'm tempted to make a pun about committing right now... Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hosting app binaries at download.gnome.org?
Hi, I'm wondering where I should be putting my Tomboy binaries for Windows/Mac. I'd like to have them in the same place where source tarballs are downloaded [1], but I don't know how to do that or even if it is possible. Currently I'm hosting them on my own server. The nice thing about that is that I can track the number of downloads. Would that information be available if they were hosted at download.gnome.org? Any hints or ideas? Thanks, Sandy [1] http://download.gnome.org/sources/tomboy/0.13/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hosting app binaries at download.gnome.org?
On 12/19/2008 08:03 AM, Vincent Untz wrote: Le vendredi 19 décembre 2008, à 07:46 -0800, Sandy Armstrong a écrit : Hi, I'm wondering where I should be putting my Tomboy binaries for Windows/Mac. I'd like to have them in the same place where source tarballs are downloaded [1], but I don't know how to do that or even if it is possible. Currently I'm hosting them on my own server. The nice thing about that is that I can track the number of downloads. Would that information be available if they were hosted at download.gnome.org? Any hints or ideas? http://mail.gnome.org/archives/gnome-web-list/2008-May/msg8.html Awesome, thanks Vincent. I guess I'll make a http://ftp.gnome.org/pub/GNOME/binaries/mac directory to keep my OS X binaries. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: Mono.Addins
Sandy Armstrong wrote: Tomboy has depended on Mono.Addins = 0.3 [1] for over a year now, but since it's not a blessed dependency in GNOME we've been forced to bundle a copy. For all the obvious reasons why this is a bad idea, we'd like to stop doing it. Mono.Addins is widely used in the Mono community by popular (extensible) apps like Banshee, F-Spot, Gnome Do, and MonoDevelop. It is packaged by all major distros. It's been over a week, with only positive response, so per the instructions on the wiki, I am requesting that this page be updated: http://live.gnome.org/TwoPointTwentyfive/ExternalDependencies Is that something I should myself? Thanks, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposed external dependency: Mono.Addins
Howdy, Tomboy has depended on Mono.Addins = 0.3 [1] for over a year now, but since it's not a blessed dependency in GNOME we've been forced to bundle a copy. For all the obvious reasons why this is a bad idea, we'd like to stop doing it. Mono.Addins is widely used in the Mono community by popular (extensible) apps like Banshee, F-Spot, Gnome Do, and MonoDevelop. It is packaged by all major distros. To quote the website, Mono.Addins is a framework for creating extensible applications, and for creating libraries which extend those applications. Thanks, Sandy [1] http://mono-project.com/Mono.Addins ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prototyping the next generation panel?
Thomas Thurman wrote: Ysgrifennodd John Stowers: Personally I would not be sad if AWN were to replace gnome-panel all together (in the default install), but thats a story for another day. I really like AWN. I'd love if we could use it or some of it. Bikeshed: are we calling this gnome-shell after all? Maybe we could call it nemo after the captain of the Nautilus. Let's avoid that one, unless we absorb that project (Federico has talked about looking at some of their code for timeline stuff, at least): http://www.iola.dk/nemo/ Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: indentation of c code
Jason D. Clinton wrote: On Mon, Aug 18, 2008 at 7:22 AM, Dodji Seketeli [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: BJörn Lindqvist a écrit : [...] There is no GNOME standard for indenting C code -- every project use their own indentation style (unfortunately). But to reformat a file to an indentation style many projects use, you can just run indent without any arguments. I am sorry, but I think there is a GNOME standard for indenting C code. It's at http://developer.gnome.org/doc/guides/programming-guidelines/book1.html, chapter http://developer.gnome.org/doc/guides/programming-guidelines/code-style.html. If GNOME C projects use their own indentation style, I think it's just because only a few people have read that documentation or because GNOME as a project does not enforce it that much. GTK+ uses the GNU indentation style that is documented at http://www.gnu.org/prep/standards/standards.html. I would love to clean up indentation in my module but I fear that it creates useless svn blame output henceforth. svn blame has an option to ignore whitespace, fyi. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [+gnome] Re: Project Hamster now in GNOME SVN
Wouter Bolsterlee wrote: 2008-08-15 klockan 18:26 skrev Patryk Zawadzki: On Fri, Aug 15, 2008 at 6:03 PM, Anders Feder [EMAIL PROTECTED] wrote: I think Time Tracker had been suggested in earlier discussions on this list? Or perhaps that was only intended for menu titles? It was for the user-visible UI. fre, 15 08 2008 kl. 17:03 +0200, skrev Wouter Bolsterlee: Well, if the move hasn't been propagated to all places yet, we can easily fix it and use project-hamster instead. That makes more sense right? (The project is not just an applet!) For 2.26 Project Hamster will likely also ship a command line client and what not. Do you think changing the module name is a good idea? Certainly better to do it now than after it ships as part of GNOME. Yeah, that's why I suggested the project-hamster name for the SVN module. Should be a simple mv for Olav, after all. If you're going to change it, save everybody a lot of typing and call the SVN module hamster. :-) Personally I think it's no big deal to keep it the way it is. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New svn module: gnome-sound-theme
Wouter Bolsterlee wrote: 2008-08-12 klockan 05:42 skrev Sandy Armstrong: Brian Cameron wrote: We should update our spec so that FLAC is the recommended uncompressed format. Huh? Isn't FLAC a *compressed* format? Lossless != uncompressed. That's not true. According to your defition, gzip would also be lossy? What definition? All I said was that, though FLAC is lossless, it is not uncompressed (as Brian had claimed). Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed module: project hamster
Vincent Untz wrote: Homepage: http://projecthamster.wordpress.com/ svn/git/bzr/...: http://code.google.com/p/projecthamster/source/checkout Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2008-April/msg00138.html License: GPLv3 (or is it GPLv3 or later?) Short description: == 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. Requires new external dependencies: === python-pysqlite2 [although we can just say it's python] Summary so far: === + not hosted in the GNOME infrastructure, but willing to migrate + many releases since the proposal + some discussion about using e-d-s instead of sqlite. It seems the maintainers prefer to stay with sqlite + some people like it I finally decided to try this out and I'm really digging it. I'm an easily-distracted person and Hamster is helping me to track where my time is going. Sure, it's probably most useful to people who do actual work from their GNOME desktop...but is that much different than Evolution? I think there is a lot of potential to integrate Hamster further into GNOME, perhaps by tracking your usage of certain applications, or by integrating into the clock applet or e-d-s as has been suggested. Being part of GNOME gives it the opportunity to do this integration in a well-supported manner. Ultimately, it's for the distros (and users) to decide what ends up on a desktop. I think GNOME and Project Hamster have a lot to gain by joining forces at a project level, though. Cheers, Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Something wrong with SVN access?
http://tinyurl.com/56vsoa On 5/15/08, Jaap A. Haitsma [EMAIL PROTECTED] wrote: Hi, When I check out code with my gnome account I get prompted for a password and I don't have a clue which password it needs to be. svn co svn+ssh://[EMAIL PROTECTED]/svn/vala/trunk vala-trunk [EMAIL PROTECTED]'s password: Normally I always got prompted for my ssh passphrase. Anybody knows what's wrong? Jaap ___ 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
