Re: Fwd: Reminder: FOSDEM CrossDesktop DevRoom 2013 - Call for Talks
Christophe: If CrossDesktop DevRoom is THE place for cross-desktop entente, then why have I seen no discussion about this event on any FreeDesktop mail forum? I only notice GNOME mailing lists in the current cc:list, or am I missing something? What FreeDesktop forum is even supposed to be used for announcing events and activities? Would this be freedesk...@freedesktop.org, platf...@freedesktop.org (which hasn't seen but 3 emails since 2005) or maybe distributi...@freedesktop.org? --- Brian On 12/ 4/12 09:05 AM, Christophe Fergeau wrote: -- Forwarded message -- From: *Pau Garcia i Quiles* pgqui...@elpauer.org mailto:pgqui...@elpauer.org Date: 2012/11/29 Subject: Reminder: FOSDEM CrossDesktop DevRoom 2013 - Call for Talks To: x...@lists.freedesktop.org mailto:x...@lists.freedesktop.org Hello, The Call for Talks for the CrossDesktop DevRoom at FOSDEM 2013 is officially open and will close in two weeks (Dec 14th). FreeDesktop.org is THE place for cross-desktop entente, sure there is a lot of things to talk about. Please submit your talk proposals ASAP! --8--- * FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium). One of the tracks will be the CrossDesktop DevRoom, which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperativity amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: Enlightenment, Gnome, KDE, Unity, XFCE, Windows, Mac OS X, general desktop matters, applications that enhance desktops and web (when related to desktop). Talks can be very specific, such as developing mobile applications with Qt Quick; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2012 schedule might give you some inspiration: https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html https://archive.fosdem.org/2012/schedule/track/crossdesktop_devroom.html Please include the following information when submitting a proposal: * Your name * The title of your talk (please be descriptive, as titles will be listed with around 250 from other projects) * Short abstract of one or two paragraphs * Short bio * Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. The deadline for submissions is December 14th 2012. FOSDEM will be held on the weekend of 2-3 February 2013. Please submit your proposals to crossdesktop-devr...@lists.fosdem.org mailto:crossdesktop-devr...@lists.fosdem.org(subscribtion page for the mailing list: https://lists.fosdem.org/listinfo/crossdesktop-devroom) -- The CrossDesktop DevRoom 2013 Organization Team* --8--- -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ xdg mailing list x...@lists.freedesktop.org mailto:x...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Bastien: I was not trying to suggest that there was no GNOME portability documentation. Instead I was saying that it should not be surprising that non-Linux distros (and many popular Linux distros) are making very slow progress with GNOME 3 based on the quality and scope of the existing documentation. https://live.gnome.org/PortabilityMatrix The Portability Matrix you highlight is a good example of this. The matrix highlights that some distros use different solutions for various features, but no information is provided to help any distro know what should be considered when making decisions. Most of the rows in the matrix assume that the reader already understands what is even being described. For example, the matrix highlights that gsd power features use logind. Most readers would likely need to review the code to understand what specific power features are actually being described here or why they might need logind. Most rows in the table are like this, so this matrix is only a very useful guide if the reader has many hours to invest to understand how the information applies to them. To me, the matrix looks more like a draft of an outline to a guide, but it is a start. On 10/22/12 01:15 AM, Bastien Nocera wrote: On Fri, 2012-10-19 at 13:33 -0500, Brian Cameron wrote: The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. This page: https://live.gnome.org/PortabilityMatrix was created for that purpose 6 months ago. Considering GNOME 3.6 is out the door, 6 months ago seems already quite late to be providing guides on how to port to GNOME 3, but late is better than never. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.8 feature: Drop or Fix Fallback Mode
The Solaris Sun Ray product does not yet support OpenGL (or the Xserver Composite extension). The main desktop products that Solaris supports are all run on Sun Ray. So, if GNOME evolves so that it has no support for machines that do not support OpenGL, then this will further complicate the future of the GNOME desktop on Solaris. There have been discussions about making Sun Ray support OpenGL and/or the Xserver composite extension, but it is hard to predict how these decisions might go, or how long implementing any decision might take. llvmpipe has been discussed as a solution, but it unfortunately does not seem a useful solution when the server is running Sparc hardwae. In past discussions with the GNOME Foundation board of directors, I have highlighted that the Oracle desktop team would like to get more involved with doing tasks that are needed to continue supporting fallback mode, with no concrete response. Below you say there is an interest in getting more people involved, so I am interested to hear what specific help is needed. Brian On 10/22/12 09:55 AM, Vincent Untz wrote: The discussion about features is supposed to heat up next week, but I'll actually be offline. So I'd like to start discussion on the fallback mode today. First of all, go read the wiki page: https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode It more or less documents the current situation with the fallback mode. And I'm of the opinion that we can't accept this situation for 3.8 anymore. So, the two alternatives I can think of are: a) get more people to work on the fallback mode so that it has a high enough quality and follows the current vision of the project b) do not have a fallback mode anymore (or at least, not the current one...) (if anyone can think of another option, please raise your voice) Please note that option b doesn't necessarily mean that all of the features present in GNOME for the fallback mode get dropped too (this would need to be discussed, and this is possibly up to each maintainer), nor that fallback modules suddenly stop to be maintained (although this might happen if nobody steps up). It's merely about stopping to endorse as offical the current fallback mode. It'd be useful to know to what extent people would be affected if we stop supporting the fallback mode. For instance, last June, Antoine mentioned that llvmpipe support is not there yet on OpenBSD... Again, before replying, go read the wiki page: https://live.gnome.org/ThreePointSeven/Features/DropOrFixFallbackMode Cheers, Vincent ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 11:50 AM, David Zeuthen wrote: On Mon, Oct 22, 2012 at 11:18 AM, Brian Cameron brian.came...@oracle.com wrote: You are talking about shipping a *complete* and *free* (libre *and* gratis) graphical desktop environment and you're complaining that you have to spend a couple of hours *reviewing* the code and/or turning off the features that you *did not* participate in developing because you choose to use a different OS than the people who actually *did* spend time working on the feature? I have heard about this couple of hours. Is it even possible to build the GNOME stack in 2 hours if you run into no problems? I don't think that's fair at all - and I really have to constrain myself to not use stronger language here. I never intended to complain. I was only saying that I find it not surprising that things are moving slowly considering the state of documentation. That is just my perspective. If it is necessary to point the blame at anyone, perhaps the right people to blame are, as you suggest, the people who are being slow. That said, I do think the GNOME Foundation does play a role in trying to ensure that there is good communication and coordination across distros, so I think it is equally wrong to suggest that the responsibility of moving forward lies solely in the hands of the distros. Are you suggesting that The GNOME Foundation and community should play no role in making the GNOME 3 transition a success across distros? Instead, may I suggest getting involved early and voicing your concern *during development* so we can either add an abstractions (such as e.g. GVolumeMonitor, GDrive, GVolume, GMount) or ifdefs or whatever [1] and avoid situations like this? I have, over the past years, tried several times to discuss issues surrounding portability. For example, as GDM maintainer I strongly recommended against supporting ConsoleKit as a hard dependency in the first place. In hindsight, I think adopting and throwing away ConsoleKit was not the best decisions. In the situations where I did voice my concerns during development, I did not get the impression that my concerns generated much response. Surely, the way it needs to work in GNOME is that if distributors show up and do portability-work (and it's good enough) [2] it will get merged. But it involves actually showing up and doing the work and not just sending e-mail. I have personally done a fair share of porting work over the years. I do not just send emails. Have we not met? But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 01:01 PM, David Zeuthen wrote: But please don't expect others to port GNOME to run on your OS. I was never suggesting that any others do any sort of port for anyone. I was only highlighting that the lack of documentation makes things slow. I am sure that we can improve the situation with some effort. Many mature products provide docuemntation to help developers make a transition when there is a new major release. I think GNOME is weak in this area. The fact that GNOME's developer documentation and GUI building tools are weak is not a new topic. Last year I remember people talking about how to catch up with KDE in this regards, for example. Unfortunately, I do not think we have yet even accomplished this more modest target. Nah, I really don't think GNOME should be that complicated - we're a desktop, we're a user experience - we should be more fluid, more agile than your grandfather's SDK porting kits with committees (or, worse, mailing lists) having to approve this or that thing. I mean, it's fine to have this for GLib and GTK+ (and we do [1]) but I wouldn't want to see us spend that amount of time on GNOME proper - I'd much much rather see us spend time on improving GNOME or adding cool features. Right. So, you probably are not surprised that things are moving along slowly either. :) Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.8 feature: Drop or Fix Fallback Mode
Piñeiro: On 10/22/12 01:30 PM, Piñeiro wrote: On 10/22/2012 05:36 PM, Brian Cameron wrote: Probably you didn't get any concrete answer as most of the technical/community decisions are not made by the GNOME Foundation Board. As I mentioned on last Boston Summit, now and then a thread about what to do about fallback mode appears. And someone mentions that they know someone that are interested on fallback mode (not only as user), but that someone doesn't appear at the thread. So if Oracle desktop team are interested on it, what are their plans about fallback mode? Because after all, this thread is not only about drop or not fallback mode, but about what to do it it is not dropped. What that team propose to fix it? As a reference, at the wiki [1] there are several questions if the conclusion is maintain it. Oracle has done some testing with GNOME 3 on Solaris. GNOME Shell works okay on Solaris systems that support OpenGL, but significant effort is still needed to make GNOME Shell ready for Solaris users. Though I should highlight that there has not yet been any testing of GNOME 3 a11y features on Solaris yet, so I am not sure how well that works. Based on our testing, GNOME 3 Fallback Mode already works reasonably well on Solaris. It already works quite well with Sun Ray, for example. The major bits of work that have been identified is that GNOME 3 Fallback needs work to support Solaris specific features such as Solaris Trusted Extensions, and the fact that it is necessary to rewrite several Solaris-specific panel applet plug-ins to use D-Bus instead of bonobo. I though GNOME Fallback Mode was being dropped so development could be focused on GNOME Shell, not because GNOME 3 Fallback is particularly bad, but I may well be misinformed about this. Since Oracle would be interested in having panel applets work across GNOME 3 Fallback mode and GNOME Shell, helping to come up with the best way to make this work would likely also be interesting to the Solaris GNOME team to help with, if a solution is not already in place. I would say that it is very probable that people at Oracle could be found to help with maintainership duties for particular GNOME Fallback modules if help like this is needed. Or, perhaps it would be useful to setup a forum where people interested in GNOME Fallback can focus discussion on how to fix high priority bugs. I think there are people at Oracle who would like to participate in more discussion about GNOME portability and fallback mode if it were more clear where discussion was being held. The FreeBSD, OpenBSD, and Solaris communities often share many of the same issues, so there is surely value in getting these communities to better work together to solve common problems. Also, Solaris is probably not the only platform that needs a supported non-OpenGL desktop solution. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
David: On 10/22/12 01:17 PM, David Zeuthen wrote: On Mon, Oct 22, 2012 at 2:05 PM, Brian Cameronbrian.came...@oracle.com wrote: Right. So, you probably are not surprised that things are moving along slowly either. :) Actually I'm quite excited about the development pace for GNOME nowadays - there are lots of cool *user-visible* features landing in new releases. The fact that it's hard for some OSes to keep up is an interesting indicator that the focus in GNOME is more on features than (boring [1]) abstraction / portability work. I'm not saying that's 100% right - in fact, my previous mails calls for help in that area - but as an end-user, I'm pretty excited about GNOME. I would definitely not characterize it as moving along slowly. I agree that the GNOME development pace is exciting. I was talking more about porting efforts moving along slowly. Though I am not sure that either one really needs to be fully at the expense of the other. As a developer (and working for an OS vendor), I *do* want more OS vendors to step up and intensify their participation in the project. Yes, more participation from several different OS vendors might slow down feature development a bit (for example, landing a *simple* library-based abstraction for systemd's logind mechanism), but at the end of the day, it's probably going to be a win for everyone. While the current pace might be good enough, if a little more planning could avoid so much interface churn where interfaces are developed than soon thrown away, then that planning would actually speed up development rather than slow it down. I do not think the GNOME community has yet found the sweet spot here, though others may disagree. When an upstream FOSS community re-invents the wheel too much, it is tiring and encourages a more wait-and-see attitude, and actually discourages healthier cross-distro participation. Whether this is a good or bad thing is probably hard to say without more hindsight. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Requiring systemd for the gnome-settings-daemon power plugin
Some perspective about this issue from a Solaris perspective. On non-Linux systems like Solaris there is little value in using upstream GNOME code for some features. Power management is a good example. On Solaris, power management uses Solaris-specific interfaces and supports Solaris specific features. Solaris GNOME would never see much value in a general-purpose GUI for power management. Enterprise computing systems and clusters have unique power management needs compared to a laptop or desktop, and any upstream power management code is not going to consider how Solaris-specific virtualization features like zones (or Solaris Containers) affects power management. Most Solaris users use the desktop in a Sun Ray environment where they typically should not be setting the power management settings on their Sun Ray server anyway. So, Solaris probably does not care about this plugin much as long as it is possible to build GNOME without the feature and allows custom power management solutions to be integrated in some other reasonable way. Maybe BSD or other non-Linux distros cares about power management more? There is probably some cross-over between Solaris and BSD, and some differences like perhaps power management. There certainty are some systemd features that probably need to be made to work across all non-Linux systems to make GNOME work well. The systemd interfaces needed to make display management and the user session work, for example. Since the GNOME community seems disinterested in defining standard FreeDesktop interfaces for these features, perhaps it is necessary to develop some sort of bridge to make needed systemd functions work across non-Linux systems. The GNOME community provides little guidance about what systemd interfaces are actually needed for various GNOME features to work properly. Maybe nobody really knows yet, but non-Linux distros will likely make slow progress as long as there is so little good guidance. I do understand that the non-Linux GNOME community has to figure out the solutions to these problems by pulling themselves up by their bootstraps to a degree. That said, is it just me, or does it seem there is a harshly discouraging attitude about this amongst the community? Perhaps I am just reading too much into what seems a general lack of discussion about systemd decisions or interface migration? It seems I keep finding out about decisions after they seem to pretty much decided upon already. We might make better progress if we were even just a bit better about a more open and inclusive design process. I do know that amongst Solaris engineers there is an exhaustion of having to adopt, rewrite, and throw-away interfaces as often as the GNOME community seems to do. This does create resistance towards adopting the latest features. I do not mean to complain, though. Perhaps this sort of development style is just what is needed to compete in the vibrant and ever-shifting desktop market we face today. Not sure... Brian On 10/19/12 12:20 PM, Sebastien Bacher wrote: Le 19/10/2012 15:41, Matthias Clasen a écrit : I don't think that is a very productive way to have a discussion. What are you hoping to achieve ? The discussion went this way: 1: g-s-d will drop non systemd support 2: could we define standard interface that are up to the distributor to implement rather than depends on systemd? an hard depends would mean those choices for non systemd distributors: list of options I could see 1: no, I don't intend to spend any time on that, if you don't want to use systemd you need to work with systemd upstream 2: ok, well I guess we need to think what to do then, but it's limiting our options to get GNOME shipped I'm not sure how unproductive it has been, it's merely stating intends and sharing concerns... What I'm hoping to achieve? I guess letting know GNOME, as a project, know in what position this choice put some of the distributors and what might be the outcome. It's sharing information and communicating ... is there any issue with that? Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: FSF's role in GNOME (was Re: Fwd: Questions for the board election candidates)
On 05/22/12 01:45 PM, Bradley M. Kuhn wrote: As most on this list know, I've been the GNOME Advisory Board as FSF's representative for the last decade. Since, as a non-profit, FSF receives Advisory Board membership with no fees, I've always felt it was right to give back in volunteer time (instead of cash [0]) to GNOME. In that capacity, I've done a number of things to help GNOME. Thanks, Bradley, you and the FSF have done a lot. There would not be a GNOME Women's Outreach program if not for the FSF, for example. Here are a few examples from just the last two years: * Answered numerous licensing questions from GNOME developers on a regular basis. * Assisted in the hiring of a sysadmin position, helped recruit the current GNOME Foundation Executive Director, and participated in the hiring committee for the Executive Director position. * Co-drafted GNOME's Copyright Policies, at the request of GNOME Foundation's Board: http://live.gnome.org/CopyrightAssignment http://live.gnome.org/CopyrightAssignment/Guidelines I do volunteer work like this because FSF wants to help GNOME. I do it in the spirit of goodwill and affiliation among the two organizations. Obviously, if GNOME's new Board takes a policy to sever its association with FSF, I'd be presumably kicked off the Advisory Board and would cease my ongoing volunteer work for GNOME that I do on behalf of FSF. Considering the Executive Director of GNOME is from the SFLC, it seems rather unlikely that any such severing would even be possible. I suppose if you feel these contributions above have tarnished GNOME's image, then that would make sense. However, I think even that small list of recent contributions alone shows that GNOME *does* receive direct, valuable benefits from FSF, in addition to other intangible benefits that I think are useful. I'd hardly say that you, Bradley, are the only person who values the FSF who also contributes to GNOME. GNOME project was founded as part of GNU precisely because GNOME was the Free Software desktop project most dedicated to the principles of software freedom that FSF has championed. I have always felt the two organizations -- despite some personal conflicts that might occur among leaders in the two organizations -- were kindred spirits in this regard. I hope the new GNOME Foundation Board will continue that tradition. I do as well. As you say, GNOME and the FSF do sometimes disagree on specific things. But, it is healthy for organizations to be able to disagree on points, I think. I guess I do not see what would be accomplished by severing ties with the FSF. It hasn't seemed like there has been really that much tension between GNOME and the FSF lately. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
Tomeu: On 04/26/12 02:06 AM, Tomeu Vizoso wrote: On Tue, Apr 24, 2012 at 15:10, Alberto Ruizar...@gnome.org wrote: I'm afraid that interfering in the maintainer's responsibilities is a very big can of worms, more likely to do harm than good. There's something powerful in how a maintainer feels responsible about his module and the community that surrounds it. Some of my thoughts about the GNOME maintainer community, aside from the fact that they do a great job. 1) There really are not any good forums for communicating with core GNOME maintainers as a group. Looking at MaintainersCorner I see that GNOME only requires maintainers to subscribe to devel-announce-list. I suppose much communication happens on desktop-devel-list and foundation-list, but it seems hard to figure out how to have a dialog with the maintainers as a group or how to make decisions. A lot of problems might solve themselves if we made it easier for maintainers to focus on decision making when needed. 2) Many distros are currently supporting GNOME 2 based distros. While I think it is good that our development community is focused on GNOME 3, it is also important to encourage distros to cooperate as they maintain GNOME 2 and keep it working well so that the brand is strong and positive. I remember Vincent suggesting that core GNOME 2 modules might need additional maintainers in order to provide ongoing support to do cooperative efforts like this. To make something like this work well requires coordination and decision making amongst maintainers. Providing more support for more branches might require more infrastructure. It seems it should be possible to strike a better balance between focusing energy on new development while providing more impressive support for those who continue to depend on GNOME 2. I'd say there is probably enough topics to warrant having a Maintainers BOF or something at GUADEC where topics like this might be discussed. I think it would be great if we could find new ways to augment our maintainer community, or to make our decision-making processes easier and more transparent. And probably a good forum to discuss what sorts of Usability rules resonate most with maintainers. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Design in the open
Allan: I think it is pretty clear that the GNOME UX team is pretty amazing. As you say, though, I think we recognize that we need to improve in areas like engagement. With GUADEC around the corner, I think now is an important time to make progress on getting better engagement between the developer and usability communities within GNOME. Can we plan activities at GUADEC that could help? Aside from a BOF, I wonder if it might make sense to do some of the same sorts of activities that were done at the UX Hackfest in London. I think it would be interesting to do some usability testing while there, if it were possible to make that happen. Perhaps the next UX Hackfest could happen to coincide with GUADEC. Are plans being discussed on the usability mailing list? Are there any particular design-focused talks being planned? At the Desktop Summit in Berlin, it seemed a lot of talks were about basic design principles. Do you think we will be seeing that again, but perhaps more focused on GNOME 3? Brian On 04/25/12 08:27 AM, Allan Day wrote: Hi all, Apologies in advance for the long mail - there was no other way. There have been a few design-related threads on the list recently. I’m going to try and reboot those discussions in a slightly different and, I hope, more constructive mode. Let’s start with the big picture - design is important for GNOME. Our project’s success rests upon our ability to design and execute an outstanding user experience. It is in all our interests to make GNOME design work, therefore - to work together to produce a consistent, integrated, well-defined, high-quality, delightful user experience. So far we have made some great progress in this direction. We have a small but thriving design community. We have successfully reorganised our development processes around design - development tends to be design led, and we now have new feature proposals each release rather than module proposals. There are very few, if any, real community projects that have achieved this feat. Members of other projects have even approached me in the past to ask how they can replicate GNOME’s success in this area. But there are challenges and things we can do better. Among those obstacles, I see: * lack of design resources - we are always trailing behind where we want to be, and there are important tasks which we are unable to complete (a new HIG springs to mind) * improving the quality of design - we can always do better * getting the project behind a common vision - we sometimes lack focus * giving people a stake in the project - the danger of design-led development is that people feel that the project is no longer theirs. They want to feel they can have an impact and that they can express themselves through their activities in the community. * design disagreements can sour relationships and lead to discord * letting people stay in touch with and understand design activities, and therefore the activities of the project as a whole * helping community members to participate in design activities Now, there have been some initiatives in GNOME to try and help make design more successful within the community. Some of those are well-known, like the design wiki pages and the IRC channel, but there have been other things too, like design office hours (remember those? nobody came), UX Advocates (also suffered from a lack of take up) and Every Detail Matters. We are also working to attract more design contributors, which the Outreach Program for Women is really helping with right now (yay!) But there is more we can do. The challenge for us as a community is to make design an even more successful part of what we do. This isn’t an easy challenge and I don’t think there are any quick fixes, but we have experience and a rich community on our side. It is important to recognise that improving the state of design in GNOME isn’t just the responsibility of designers. There are things that all of us can do to help - from the release team and maintainers, to individual developers and community advocates. Here are some of my ideas for things that all of us can do to make design work more effectively and harmoniously as a part of GNOME: * a more rigorous (and better documented) feature proposal process * new tools for displaying and discussing designs, such as something like Dribble or Design Hub * a process for resolving design disagreements - perhaps maintainers or the release team could mediate if a dispute seems intractable? * better communications about where GNOME is going and what the project is trying to achieve * some kind of active community management role to help soothe ruffled feathers * advertised designer playgrounds and discussion areas (for people wanting to stretch their design wings) * tackle bad behaviour across the project in a more proactive manner (will ensure that disagreements don’t get out of hand) * micro release-cycles in which new features are advertised, completed and tested * better
Re: GNOME3 - Opinion
Uros: Thank you for your feedback. We love to hear what people think of GNOME. Following issue is not directly related to GNOME3, but just my idea I would like to see implemented and believe software developers and professional users would find it very useful. While I'm not 'reinventing the wheel' I still believe it is new idea. Note that the GNOME accessibility interfaces do provide mechanisms for controlling and getting information from GUI programs in alternative ways. Projects like dogtail[1] uses these interfaces to provide record and replay experiences. The dogtail project is not very active today, but it is an example of trying to provide a script-like interface for controlling UI programs: Your suggestion of providing a shell-like interface is unique, but these accessibility interfaces are designed to support a wide range of different alternative interfaces like magnification, on-screen keyboard (caribou), and text-to-speech (orca) features. Perhaps they could also be used by your command prompt interface. If you are interested in doing this sort of thing, then you may be interested to learn more about GNOME accessibility features. Brian [1] https://fedorahosted.org/dogtail/ Proposal. I have been using keyboard-oriented computers for almost 20 years. During this time, I believe, keyboards are segment where we saw very little innovation. 101-keys US keyboard is a standard we could see everywhere with very small differences. Win keys, AltGr and dropping numerical keyboard are very few modifications of this old standard. I believe that this fact is a consequence of one very mature well-designed input device. I would say I wish I could only use a keyboard as my computer input device. For all this time we have old command prompt text interface as the fastest way how software developer could communicate with computer. We are also living in graphic-oriented displays and such technology is very useful so we cannot depend on text interface any more. However, mouse as an input device is not very fast tool. We have to move hands, to concentrate to mouse-pointer, etc. My idea is whether we could develop one command prompt-oriented window where we could communicate with all our applications? I know, you will tell me, about xterm, and other similar emulators, but this emulator allows us just to use bash,csh and other shells, not to communicate with other applications. I propose some application where we could type commands like \calc\open .\myfile for opening file in calc or \gimp\line x1 y1 x2 y2 for drawing line in gimp, for example, and do all things we are doing currently with shortcuts or clicking to icons or to menu items. I realize that each application has to have support for this feature, but for all of us using computers daily this way of interaction would make mouse and other pointer devices completely useless and all communication could be done much faster from keyboard only. Text commands are simple, fast, and very comprehensive way for doing anything and graphic environment could provide us picture/video and all other tools we don't have in plain-text environment. As a consequence all windows and applications could be menu/icon/dialog-free so we could have more space for a real job need to be done when we use them. And my final thought is related to Google Chromebook. We could see that Google is trying to redefine keyboard making it simpler and more useful than it is currently. I think that such idea is great. Lot of garbage computer history collected all these years and somebody has to clean it a little bit. Win keys and some of ASCII characters today doesn't have any sense. Ctrl and Alt are more than enough for giving users more options for typing. That is all from me, so far. If you like my ideas we could start working on it, and I will start proposing more things, if you don't I will be passive observer and in future contributor to other well-established GNOME projects. Uros Nedic, MSc Belgrade, Serbia ___ 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: systemd as external dependency
Paul: Sorry for top-posting, but I'm going to recommend if anyone wants to talk about GNOME OS or platform changes to start a new thread. While related, this is a different issue than the systemd proposal as an external dependency. Agreed. Since we are planning to discuss this anyway at the next GNOME Foundation IRC meeting, could we focus on putting together an agenda perhaps, on a different thread? This systemd proposal does raise questions about how GDM should support ConsoleKit versus systemd interfaces, but this is also a very separate issue that is already being discussed in other threads on gdm-list and the consolekit list. I think one reason for all the noise is that the original proposal is not fully specified. There are significant changes to many diverse modules listed as bullet items, the impact on ConsoleKit seems fuzzy, and is concluded with: And I expect a couple of more interfacing points, however things get more and more into vaporware areas with those. Overall, it seems sensible for GNOME to support systemd and I trust the module maintainers to make the right decisions about how to support the communities needs, including adding systemd support in a sensible way. Where there are issues, lets discuss them, but in a more focused manner. If there is controversy in some areas, then perhaps we can make progress by blessing those aspects of systemd integration that are non-controversial and non-fuzzy first? Brian On Thu, May 19, 2011 at 10:02 AM, Michael Terrym...@mterry.name wrote: On 19 May 2011 10:32, Bastien Nocerahad...@hadess.net wrote: So what are the criteria for deciding which platforms to drop from GNOME's scope? This thread is making it sound like the release team is OK with criteria like whichever platforms systemd doesn't run on, which would certainly seem to put Ubuntu next in line for the axe. I think you need to look at the thread again. That was never mentioned, and we even mentioned ways for distributions that don't use systemd as the init system to ship the D-Bus mechanisms. True. I guess I'm really just interested in an official answer to What are the criteria for deciding which platforms are within GNOME's scope? That's obviously an iffy thing when talking about new modules, because sometimes innovation happens in one place and other platforms get forced to play catchup, which isn't strictly ruling out support. Though some things you know can be ported easily, others you know can't be. Without some formal guidance here, I worry about a slippery slope. And it sounds like the GNOME OS concept changed some minds about what that guidance should be. Olav mentioned the Linux-only issue being on the agenda for the next Foundation meeting. -mt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Sorry for the double post. When I wrote my last post, it was not clear to me that systemd is not and won't be portable. If this is true, then that's probably okay for Oracle too, as long as GNOME can be made smart enough to just disable those aspects of the desktop that require it when systemd is not present. I am sure that we at Oracle can figure out ways to bolt on the support we need for our users using other interfaces. When I write my emails, I try to be even minded and inviting as I think befits a free software community. But I sometimes wonder why I bother considering some of the other posts I read. Brian On 05/18/11 12:08 PM, Johannes Schmid wrote: Hi! Yes, it might cost us a bit to be open and friendly like this -- and to be honest, I'm not convinced the cost is that high for GNOME code, while it certainly is for systemd -- but our community is not just about purely technical matters. We also care about being open and friendly. Or at least, we should. I think Lennart made the point that systemd is not portable and won't be ported. He also made the point that that doesn't mean other OS could share the same interfaces as systemd while providing a completely different backend and he also made clear that the parts GNOME will likely depend on apart from gdm will be buildable on any OS while not providing much use. I really don't think we can make a useful control-center that supports all kind of operating systems. People that care about configuring OS parts on non-linux systems should probably write their own control-center. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: systemd as external dependency
Lennart: The closest integration I expect in gdm. Ideally I'd like to rip out the current CK support completely and replace it entirely by the more low-level systemd specific code. However, that I can only do if the outcome of this discussion is clear. Is it possible to do this, but maintain the ConsoleKit CLI, D-Bus interfaces, and configuration interfaces (e.g. /etc/ConsoleKit) for backwards compatibility? If these interfaces need to change, can you provide some perspective about how much they need to change? I wonder if it might be reasonable for systems that do not support systemd to continue using ConsoleKit. Will #ifdef's be allowed in GDM? If GDM is changed to become Linux specific, then does this mean that non-Linux systems need to migrate to a different display manager? I now know GDM is a Core GNOME application. If a different display manager is used to access a GNOME desktop, then can you still call your desktop GNOME? Can you swap out a Core GNOME program and still call it GNOME? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Vincent: On 05/18/11 02:02 AM, Vincent Untz wrote: I'm obviously no security expert, but doesn't the fact that the greeter runs as the gdm user and not root mean that the audit on the daemon side is enough (since the daemon should clearly validate everything that comes via dbus from the greeter -- there can be other greeters, after all)? Compromising the gdm user is better than compromising root, but is still bad. The gdm user has access to all users Xauth keys, so someone running as the gdm user can easily connect, snoop, and inject events into any running Xserver. You could, for example, snoop for someone to enter the root password into an X terminal program. This is probably not such a big deal on a laptop or desktop where you have some degree of physical security to ensure that random people are not accessing your GDM process. This would be more of a concern in a terminal server environment with public consoles, such as a LTSP (Linux Terminal Server Project) setup using XDMCP. Of course, you can get issues that will break the gdm greeter, but then those will also most likely break the user session anyway. You seem to be thinking of Denial-of-Service attacks. We also need to make sure that there is no way for the user to hit a hotkey or swipe a gesture to cause access to the command line as the gdm user. So, I do not think an audit on the daemon side would really be a sufficient audit, unless some more elaborate and secure method were to replace how Xauth is managed by GDM to disallow the gdm user access to the Xservers once they become user sessions. GDM does provide a very limited UI, so this does limit the code the user runs at login time to a degree. So, this could focus an audit, but there is still a lot of GNOME infrastructure used by the greeter to review. Also, this infrastructure tends to rapidly change every 6 months. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Ray: On Sun, May 15, 2011 at 2:30 PM, Brian Cameronbrian.came...@oracle.com wrote: Yes, you are right. GDM does not currently use OpenGL. My comment was meant to be understood as an example of how GDM may be moving in a direction that requires certain hardware or only works on certain operating systems. Sorry if I was not clear. For example, I also raised concerns that the GDM/ConsoleKit evolution may be moving in a Linux-focused direction. So to be concrete (for clairty to those following along that don't already know). Oracle ships a product called SunRay. It's a thin client system where the individual thin clients are treated as black box hardware devices that speak the X protocol. Some of these devices don't support certain X extensions GNOME rely on like RENDER and GLX. I think this is what Brian is alluding to (Brian, correct me if i'm wrong on any of the above). These sorts of hardware concerns are not specific to Sun Ray. I believe GNOME 3 will support a fallback mode to support such hardware. It is not clear, though, if GDM will follow suit. From a Sun Ray perspective, a more serious issue is that GDM does not support MultiSeat configurations in general. If GDM is evolving into a display manager with tight GNOME integration that works only with specific hardware and/or operating systems, then an alternative display manager may be needed by some users. Of course, that's fine. I don't think many would disagree with that. When developing your platform for SunRay, you've got to make choices that are appropriate for the technology you have. And it may be LightDM is the way to go for that product. Certainly, getting LightDM vetted through the ARC review process would be a good thing for it. It is hard to predict the future. The Oracle Desktop team has already invested a lot of time to make ConsoleKit and GDM work well with Sun Ray on Solaris. Oracle is now using a patched GDM 2.30 and it works reasonably well. What makes sense in the future depends a lot on how GDM and LightDM modules evolve going forward. SunRay is proprietary, though, and so kind of sits outside the focus of GNOME. Yes, Sun Ray is a proprietary product that runs on Solaris and many Linux operating systems. To what degree GNOME supports proprietary software, or how far it sits outside the focus of GNOME I do not know. That said, Sun Ray needs a display manager that supports MultiSeat and the ability to dynamically trigger when a seat is started or stopped (and the ability to specify an Xserver command to use). These features seem generally useful and not what I would characterize as proprietary. Sun/Oracle worked to implement these features into ConsoleKit and GDM. See GNOME bug #536355 for more details. It seems that now ConsoleKit is being rewritten with a goal to better support MultiSeat. Perhaps it will be more straightforward to integrate Sun Ray with GDM after it has better native MultiSeat support. But we've talked about this before, and I think we both agreed (right?) the choices you make for that platform may sometimes be orthogonal to and contrary with the choices we make together for GNOME. We all have several hats to wear and juggle I guess. Sure, but if we have identified a few cases where GDM can not be used, then it could make sense for the GNOME community to recommend an alternative in these cases. Or is Solaris the only distro that has these sorts of issues? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Matthew: I'd expect that a prerequisite for adoption would be functional equivalence. If the greeter is to be maintained by some third party rather than yourself, how is the maintenance overhead reduced over using gdm? When GDM was rewritten, functional equivalence and configuration interface stability were not considered particularly important. For example, the new GDM has several serious regressions compared to GDM 2.20: http://mail.gnome.org/archives/release-team/2008-June/msg00070.html There may be good reasons to not include LightDM as a GNOME module, but we should be fair about the requirements we impose. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Jon: On 05/14/11 03:37 PM, William Jon McCann wrote: It is certainly a serious overreaction to my statement that a proposal that is based on an internal architecture change, that uses lines of code as a metric, and didn't include a single thing that would improve the user experience seems to me like architecture astronauting. Early in this discussion, Miguel de Icaza recommended that an audit be done to compare lightDM and GDM. While lines-of-code is often not a particularly useful metric in general, it can become an important factor when analyzing a security-related module or when doing an audit. GDM provides some really neat GNOME integration. However, much of this integration is available because it uses much of the GNOME infrastructure (gnome-settings-daemon, metacity, gnome-session, etc.). This makes the job of reviewing or auditing GDM quite complicated since it is necessary to review not only the GDM code, but all the infrastructure code that GDM uses. With GDM, it is obviously harder to keep track that changes in the GNOME infrastructure will not negatively impact the security of the display manager. It becomes more important to ensure that developers of infrastructure like g-s-d are aware of how their code is used in the GDM context, and that they write good, secure code. I do not think this is a particularly surprising insight. As long as I have worked on GDM, there has always been tension between usability and keeping security-related code as light as reasonably possible. Obviously this is somewhat subjective, but GDM is rather far at the usability end of the spectrum. Having said all this, I do not think this is a real problem. The GNOME community mantras are usability and simplicity. GDM fits with these mantras quite well for the typical GNOME user and is more than sufficient for keeping the average GNOME desktop secure. However, GDM may not be the best display manager choice for particular users or distros who have more stringent security requirements or who may require reviewing or auditing of security related programs like GDM. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Shaun: So the question here is not Does LightDM better serve the needs of some GNOME-based operating systems? The question is simply Should LightDM replace GDM as the display manager for GNOME? Perhaps I am confused, but I thought that the recent moduleset reorganization was designed to get The GNOME community out of the business of having to decide whether to promote one program over another, when they do the same sorts of things. A common example being should GNOME promote rhythmbox or banshee? I did not think there was a need to decide whether one should replace the other for both to be considered GNOME modules. Or perhaps I misunderstand the goals of the moduleset reorganization. Perhaps display manager programs are special in some way that only allows for one to be approved at a time. But I do not remember anyone discussing any special considerations like this in this thread. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Shaun: Perhaps display manager programs are special in some way that only allows for one to be approved at a time. But I do not remember anyone discussing any special considerations like this in this thread. I think that's the idea behind the Apps moduleset, but not Core. Core is the operating system. Apps are some things we think you might like to install on top of it. At least, that's my understanding. As I have said several times, I do think GDM is more aligned with GNOME. So, if GNOME is only allowed a single display manager, I very much agree that GDM seems the obvious choice. Looking at the core 3.2 modules, it looks like there are some duplicate modules to support things like fallback (e.g. GNOME Shell and gnome-session): http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-3.2.modules I guess if GDM is the only GNOME display manager, this means that GDM will either not require OpenGL, or will provide ongoing non-OpenGL support, or it will not be possible to login to GNOME fallback mode using GDM. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Colin: Your report missed the following bug, which is a better example of some of the more serious issues Canonical had working with upstream GDM: https://bugzilla.gnome.org/show_bug.cgi?id=587750 As you can see in the bug report, Robert was not provided with much real support or guidance about how to move forward even though Canonical made it clear on numerous occasions (on gdm-list and to the board) that this bug was of particular concern to Canonical and their users. Brian On 05/13/11 04:41 PM, Colin Walters wrote: On Fri, May 13, 2011 at 12:55 PM, Robert Ancellrobert.anc...@gmail.com wrote: There have been problems for years and years and years. There is some point where you need to reconsider if that strategy is appropriate. So here's some actual data: https://bugzilla.gnome.org/buglist.cgi?cf_gnome_target=---;cf_gnome_version=---;query_format=advanced;emaillongdesc1=1;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=NEEDINFO;bug_status=RESOLVED;bug_status=VERIFIED;email1=robert.ancell%40gmail.com;product=gdm;emailtype1=substring It looks like to your credit, you have submitted patches; some like https://bugzilla.gnome.org/show_bug.cgi?id=596831 have been accepted, others like https://bugzilla.gnome.org/show_bug.cgi?id=593996 discussed, considered, and rejected. The latter one is obsoleted now by the accounts service anyways. I'm not convinced by this data that GDM has been a problematic code base to work on. You're obviously free to create a new project; but on the basis above, I'd say you really didn't try very hard to make real changes in GDM before deciding to rewrite from scratch. ___ 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: New module proposal: LightDM
Bastien: On Fri, 2011-05-13 at 13:43 -0500, Brian Cameron wrote: GDM has evolved into a display manager that is most focused on tight integration with GNOME. This is perfect for GNOME users and distros that focus on GNOME users. However, GDM is not always a good choice for other desktop systems, distros that perhaps want to provide multiple desktop choices and be more desktop neutral about display management, or distros that need to support devices that may not support things light OpenGL. Since when did GDM require OpenGL? I must have missed the point when we started using gnome-shell in the login screen... Yes, you are right. GDM does not currently use OpenGL. My comment was meant to be understood as an example of how GDM may be moving in a direction that requires certain hardware or only works on certain operating systems. Sorry if I was not clear. For example, I also raised concerns that the GDM/ConsoleKit evolution may be moving in a Linux-focused direction. If GDM is evolving into a display manager with tight GNOME integration that works only with specific hardware and/or operating systems, then an alternative display manager may be needed by some users. It is not really clear what the future GDM/ConsoleKit plans are in this regards, and nobody seems to clarify. snip I think it is obviously important to Oracle to have display management options that are not too tightly bound to things that are not supported on Solaris like systemd, DeviceKit, PolicyKit, etc. Also, Oracle's Sun Ray products work best with a display manager that supports a non OpenGL GUI. I could imagine GDM becoming more tightly focused on OpenGL in the future, like GNOME Shell. Thus, perhaps LightDM could be considered a fallback display manager for the GNOME community. Again, I was just trying to highlight that some things that display managers need to do can be different across different distros. There is already code in upstream GDM to make it work well with Solaris RBAC instead of PolicyKit, for example. I'll repeat what I said in the past. Solaris developers will need to write some code at some point, or just give up. We can't stand around waiting for them to make a move when we want to better the functionality of GNOME as a Desktop. I have personally written committed over 100 patches to GDM since the 2.21 rewrite timeframe. Work I have done has improved GDM usability, XDMCP code, how GDM works when managing multiple displays at the same time, etc. Other Solaris developers have also helped, such as Halton Huo. This has bee time consuming since (as Jos pointed out), getting changes accepted into GDM can be very time consuming. So, developers working on Solaris have been supportive of the new GDM rewrite, I think. Your comment seems to be rather dismissive. Anyway, is there a real need or benefit to talk about Solaris GDM participation in a discussion about whether to accept LightDM as a module? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Interested in GNOME on touchscreens?
Michael: On Sun, 2011-03-06 at 16:12 +, Bastien Nocera wrote: Feel free to add problems that you might find, or start discussing potential fixes for the various problems on this list. For the on-screen keyboard (http://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard), one could consider adapting the MeeGo keyboard (see http://wiki.meego.com/Meego_Input_Methods) It was designed with handhelds and slate devices in mind, so it would be only a matter of writing a clutter input context. It should be easy to adapt it to the GNOME Shell look, too. It would be nice if an on-screen keyboard were integrated directly into the shell. I think it would be good to discuss this opportunity on the gnome-accessibility-de...@gnome.org mailing list. I wonder if this code might be useful to the Caribou project. An on-screen keyboard GUI probably would not need to be coded in Clutter to look well integrated with GNOME Shell, unless there is some advantage to coding the GUI in JavaScript, I'd think. I know the GOK program had a nice feature that allowed you to navigate application menus via the GOK interface. This provided for a faster and more configurable way to navigate application menus for a11y users. Some of these sorts of techniques might also be useful to the general user, making it easier to navigate the desktop for users who cannot use keyboards or who are using touch screen devices. There are probably opportunities to integrate these sorts of features more deeply in the shell. For example, defining mouse gestures to do common things, providing features to quickly navigate application menus directly in the underlying code, or to make it possible for users to define mouse gestures like you can keybindings. Surely, good on-screen and touch-screen keyboard support is important for GNOME Shell to work well on certain devices. I would think the same program could support both features. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
It should be simple to enhance GDM to detect when OpenGL is not available, and avoid showing session-types that require it when it cannot be used. A general interface could eventually be implemented to support this, but it might be reasonable to just hardcode this behavior for known sessions that do not work with OpenGL initially for GNOME 3. Brian On 01/10/11 12:17, Maciej Piechotka wrote: On Mon, 2011-01-10 at 19:03 +0100, Josselin Mouette wrote: Le lundi 10 janvier 2011 à 12:33 -0500, Owen Taylor a écrit : * UI will be added for displaying information about fallback mode and forcing fallback mode when the system seems capable of doing a full composited desktop. (This is my biggest area of concern going into GNOME 3.0 - not having the final design or much code for this.) Is it really necessary? wouldn’t it be simpler to let the user choose in GDM, provided the packages necessary for fallback mode are installed? I'd say yes - if the login will not work out-of-box [new] user will say that Linux is not working and switch back to Windows. Unfortunately from user perspective Windows works out of box (read someone have installed it and configured but user haven't seen it) and Linux requires configuration and is hard. Even more advanced user wouldn't want to track what is wrong with setup that broke after update. Regards ___ 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: My thoughts on fallback mode
Also, this thread has long since passed the point where I'm reading all of the arguments - and I suspect that the same goes for all of the developers working on GNOME 3. I propose that we just stop now, since continuing discussions like this at this point is just wasting the time of everyone who has to delete all the email. +1 Agreed. I am sure there are issues to discuss, but could those with a passion for discussing these topics please at least change the subject line to more clearly reflect what you want to discuss, and move discussions to relevant mailing list(s)? There is no reason to discourage discussion, but please let's try to make it productive. Sometimes threads like this are useful for brainstorming, but it seems time for this particular thread to end. Participating in this discussion is starting to feel nauseous like watching people vomit. Although the Release Team has made it clear that they do not yet have any specific formal plans, that there is nobody standing in the way of interested people working to make GNOME 2 (or Classic Mode or whatever its called) and GNOME 3 interoperate better. Clearly the details need to be worked out, but can we do so in more focused threads than My thoughts on fallback mode? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Emmanuele: On 12/28/10 10:50 AM, Emmanuele Bassi wrote: On Tue, 2010-12-28 at 13:42 +, Sergey Udaltsov wrote: As pointed out before the fallback-mode is not a continuation of GNOME 2. It was just the easiest way to create a fallback because we don't have the resources to create a non-3D shell that could act as a fallback. As we have gnome-panel already it was choosen as the fallback mode. Is it an indication of a problem in gnome3 architecture? I don't see any problem here. I agree that there is no problem with GNOME moving towards OpenGL and acceleration. As you suggest, this is clearly the path to the future. However, there still are issues that the GNOME community needs to consider. For example, I have concerns about how GNOME 2.x is going to be maintained in the long run, and I think a lot of issues raised in this discussion relate to such concerns. To me, it seems that GNOME 2.32 and later 2.x releases were developed as transitional releases moving towards GNOME 3 without a clear roadmap for how GNOME 2 will be supported long-term. To me it is not clear whether those who intend to deliver GNOME 2.x-based solutions should ship GNOME 2.30, 2.32, some random mismash of module versions that you are able to get working, or what. It also is not clear what role(s) the GNOME community will play in helping different distros who ship and support GNOME 2 to work together and collaborate in that effort. I can understand that, at the moment, the GNOME community is more focused on getting GNOME 3 done right rather than focusing on long-term support issues with GNOME 2. However, in time, I think that GNOME 2 support issues will become an increasingly important issue that will require attention. Perhaps through getting distros who need to support GNOME 2 to collaborate together effectively, some of these questions about the future of the GNOME panel, applets, etc. can be worked out. Is it simpler to maintain extra modules than to scale mutter and gnome-shell down? define scale down. if your definition of scale down implies do not use hardware acceleration then the answer is obviously no. that's the whole point. the whole graphics stack (cairo, x11, gtk) is trying to be as hardware accelerated - it's not a new thing. the scaled down version of mutter is metacity with the default, xrender-based, compositor; but mutter is just providing the window management infrastructure for gnome-shell - and you simply cannot implement the gnome-shell designs using a non-hardware accelerated environment. It is obviously not possible to provide OpenGL-based animations when OpenGL is not available. However, I would think that it could be possible to create a GTK3 based user interface that provides the basic functionalities of GNOME shell without the animations. Such an interface could be designed to resemble GNOME shell more than the existing GNOME 2.x panel even if it does not provide as rich of an experience. So I disagree with your assessment that you simply cannot implement the gnome-shell designs using a non-hardware accelerated environment. If someone has the motivation to try, I think they should not be discouraged. Though, as you seem to suggest, it might not be worth the effort. It perhaps does make good sense to just use the existing GNOME panel and mutter for users who need a scaled down experience. While it may not be possible to have the GNOME 3 GNOME Shell experience and the classic GNOME experience working together today, I suspect that the technical issues will be worked out if there is a real need to provide ongoing support for both together. For example, if there is a need to maintain the old GNOME panel and metacity so it only supports D-Bus based applets or works with new GSettings infrastructure, it could be done. Perhaps a GNOME 2.34 release might be something to consider at some point if there is enough interest to continue working on GNOME 2.x to make it inter-operate better with GNOME 3, for example. A lot of these sorts of decisions, though, cannot really be made until it is more clear how much ongoing investment will be made in GNOME 2.x. But perhaps the GNOME community could do more now to make sure that all options are open for consideration and by being more accommodating to discussion. Things may seem impossible now simply since it is not clear how such efforts will be resourced, but this could easily change as GNOME evolves and if there is a real need. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
Johannes: GNOME 2.x will not get any more official support after the 2.32.1 relase which already happened. Single module maintainers may decide (or have already decided/done) to do more 2.32.x release to fix various bugs but no more official releases are planned. This is not different from GNOME 2.30 for example. Distros that ship GNOME 2.30 (Ubuntu LTR for example) basically need to care themselves if they need to backport patches from newer releases of fix things themselves if it is specific to this GNOME release. GNOME never gave a promise to support any release any longer than 6 months. Yes, I understand that is the current plan. I was only trying to suggest that plans could change if the community determines a real need and if distros working together help to provide whatever resources would be necessary. Despite that and this is what this thread is about, GNOME will maintain a non-3D user-experience in the future which will likely use some components of the GNOME 2.x stack but ported to GNOME 3 technologies (no parallel installation required). Until now, this experience seems to end up as metacity + gnome-panel + Applications. This is not a continuation of GNOME 2.x even if a lot of code might be shared. As you say, this is likely what will happen and the current plan. However, as you imply by saying likely it is hard to predict the future. At the very least, I see no harm in discussing options. This tendency to assert that plans cannot change seems to stifle discussion. Answering parts of your questions: Distros should ship GNOME 2.32.1 if they really want to continue shipping GNOME 2. I do not think it is so much about distros really wanting to ship GNOME 2. It is more a fact that many distros currently deliver, or will soon deliver, supported versions of GNOME 2. Regardless of whether the GNOME community provides any more official support after 2.32.1, distros will continue to support their supported products. Distros could work together in these efforts. I see no reason why such collaboration could not happen within the GNOME community. Though, since you seem to suggest that the GNOME community has already decided that there will be no further support, I guess you may be saying that such efforts would necessarily have to happen outside of the GNOME community (whatever that means in a free software community). To me it seems odd to make such final decisions before determining if there is any real interest, need, or if distros might be willing to make resources available to make such efforts happen. These are all variables that probably will not be known until distros seriously consider making the transition to supporting GNOME 3, which could be many years away for some distros. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Consolidating Core Desktop libraries
Behdad: I'd say no. If it's already in a library that does not break its API every other week, let it be there. That's the correct design anyway. Something like libgweather does not belong in a generic desktop library. libgweather is GPL, so it is probably not something that could be integrated into a generic desktop library anyway. I suspect that there are not enough desktop GPL libraries around to do much consolidation with them. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Ray/Robert: On 10/22/10 12:17 AM, Ray Strode wrote: (speaking as one of the 3 maintainers of GDM) Speaking as another... On Thu, Oct 21, 2010 at 12:02 AM, Robert Ancellrobert.anc...@gmail.com wrote: - The GDM greeter is slow due to it loading the GNOME session, the example GTK+ LightDM greeter is very lightweight (so is comparable to the speed of the old GDM and newer display managers like LXDM). Using GNOME session / g-s-d /etc is one of GDMs main features. The point is for there to be consistent experience on the login screen and in the session. If GDM is too slow because of GNOME session then GNOME session needs to be fixed, otherwise login after GDM will be too slow too. Anyway, if gnome-session is slow on your machine we should start by profiling it and figuring out why. I agree that GDM's deep integration with GNOME is one of its great features. GDM is clearly the login manager of choice if you want a very consistent experience between the login manager and the GNOME desktop. However, not everyone really needs or wants the degree of integration that GDM provides with GNOME. It should, I think, be possible to define a lighter degree of GNOME integration for a display manager that intends to be a bit more desktop neutral/agnostic than GDM, but still be a part of the GNOME Desktop. Think about Ephipany. Users who really want tight GNOME integration may prefer Epiphany, but some users may prefer other web browsers for various reasons. - All X server users have pretty much the same requirements beyond the login GUI. By using LightDM the development effort of maintaining the display manager can be shared between projects (GNOME, KDE, LXDE, XFCE). So you're not proposing LightDM to become part of GNOME, you're just proposing GDM get dropped and LightDM become an external dependency? I thought the new release model was all about choice and flexibility. I would think there should be room enough for choices. Have you talked to the other projects about this? We had some discussions some time back with Oswald (KDE developer) about standardizing on one display manager a few years ago: http://mail.gnome.org/archives/gdm-list/2007-October/msg00013.html (added him to cc list) Wasn't that the same discussion where Oswald said that he would only accept a standardized display manager if it didn't regress any current KDM features and if we did all the work? I believe Jon responded by agreeing that he was willing to do it. See here: http://mail.gnome.org/archives/gdm-list/2007-October/msg00014.html Unfortunately, though, I do not think we have progressed much towards these ends since then. Anyway, I'm obviously in favor of keeping GDM in GNOME. So am I, but I'd think there should be room for more than one display manager choice in GNOME. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Ray: On 10/22/10 09:50 AM, Ray Strode wrote: However, not everyone really needs or wants the degree of integration that GDM provides with GNOME. I feel like GNOME should be catering to GNOME's users, and we're doing a disservice to them if we don't provide integration. Agreed, and I agree that GDM should focus on providing this integration. Overall, it does a great job at that. It should, I think, be possible to define a lighter degree of GNOME integration for a display manager that intends to be a bit more desktop neutral/agnostic than GDM, but still be a part of the GNOME Desktop. I disagree. I think that's going the wrong direction. I fully agree with you that having a tightly integrated display manager like GDM makes a lot of sense. I would go so far as to say it makes a lot of sense for the most common use-cases (e.g. single-user desktop/laptop environments probably being the most common). However, to suggest that GDM is the best solution to all problems and use-cases is probably overselling. Some examples: - non OpenGL GNOME is moving towards OpenGL with GNOME 3.0. The GNOME community recommends using gnome-session/gnome-panel for the classic look. I imagine GDM will eventually go the clutter/OpenGL route. Does GDM plan to always support non-OpenGL environments, or is there value in having a lighter display manager to focus on this sort of use case? - non-Linux GDM and ConsoleKit are very Linux-focused and include a fair amount of code that is hard to get working on non-Linux distributions. It may not be reasonable for GDM to position itself as the best display manager for all operating systems. - Multiple Desktop Environments In environments where a distro allows the user to configure what desktop to use on the system, GDM may not make sense since it requires so much of the GNOME stack to be installed. If the user decides to not install GNOME, then using a display manager that does not require so much of the GNOME stack to be installed is a plus. Perhaps the GNOME community doesn't really care so much about this use case since we might not care what non-GNOME users use. But, I am just highlighting that some distros may choose to not use GDM (or not use it all the time) just because they might want a display manager that is not quite so integrated with one particular desktop. - Security/Paranoia In general, the more code that runs at login time creates more opportunity for malicious users find ways to compromise the code. I think that the GDM team has done a great job locking things down so that it is reasonably secure. However, it is impractical to audit everything GDM now depends upon (metacity, gnome-session, gnome- settings-daemon, GConf, etc.) so it is hard to know for sure. The fact that this infrastructure is constantly churning (e.g. metacity to mutter, GNOME 2 to GNOME Shell) means that new issues could pop-up anytime on upgrade. This degree of paranoia is probably not important to most GNOME users who just want a login screen to keep random people from logging into their laptop. However, there are environments where security is more of a concern and where users would want to trade some usability for more security. It is easier for a lighter display manager to be audited and to provide more reasonable assurance that the code is stable and secure simply because considerably less code is running at login time. Just a few examples of use-cases that may not be in-line with the direction of the GDM project. Think about Ephipany. Users who really want tight GNOME integration may prefer Epiphany, but some users may prefer other web browsers for various reasons. I don't think that's a fair card to play. I was not playing any card. I was just trying to provide an example of another situation where GNOME supports multiple programs with differing degrees of GNOME integration. I thought the new release model was all about choice and flexibility. Nope, I think you misunderstood (or I did). The new release model is about putting even apps on an even footing. It doesn't apply to the core of the OS. While I agree that the display manager is more core than the average application, I do think there are plenty of reasons that could cause a user or distro to decide what display manager makes sense in different environments. Users should be able to pick which apps they want, not which window manager, settings daemon, or login window they want. From a desktop point of view, these things are central to defining what the GNOME is. They are the OS which defines the stuff around the apps. Our mantra should be integration, coherency, consistency, just works for the OS. Adam Jackson did an awesome email a while back called Linux is not about choice that's mildly relevant, so I'll post it: https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html Not everybody who uses
Planning for the Boston Summit
The Boston Summit is less than a month away. Here are the details about this GNOME event if you hadn't heard: http://live.gnome.org/Boston2010 The BOF Schedule is pretty empty, so if people have plans to work on things, it would be good to let us know and update the Wiki page: http://live.gnome.org/Boston2010/SessionProposals Surely, we have plans to work on more than just Snowy. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: It's Release Notes time!
Paul: This is the last (we promise!) release of the GNOME 2.x series - let's document the release as best we can. Add your news here: http://live.gnome.org/TwoPointThirtyone/ReleaseNotes Since many distributions ship GNOME 2.x in Long Term Supported releases, it might make sense to continue releasing updated modules with bugfixes and its possible that some GNOME 2.x modules may continue to be maintained (such as those needed to support non-OpenGL users). Therefore, it might not make sense to say that there will be no more GNOME 2.x releases. If, at some point in the future, there are enough important accumulated bugfixes in GNOME 2.x, it might make sense to do more GNOME 2.x releases. Just to help ensure that distros have available the highest quality GNOME 2.x code with the latest security patches, etc. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: It's Release Notes time!
Last 2.x release, but not last 2.32.y release? I'd assume accumulated bugfixes would just warrant another few micro releases, as they always have done. However we want to handle it, I think we should be clear in the release notes that we have a plan in place for managing releasing ongoing support for GNOME 2.x, at least for a reasonable period of time. People reading our release notes should be assured that if their distro ends up providing only GNOME 2.x for a while, that we will continue to support them. We want to avoid distros patching GNOME 2.32 and not providing those patch fixes upstream, for example. If we give the impression that there will be no more releases, distros might not let us know about bugs or fixes they have. Also, it's hard to predict the future, so making proclamations about the last release only beg contradiction later on. Perhaps we could word it in a way that highlights that we do not have any future planned releases, but avoid proclaiming that we will never do something. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump gnutls requirement
If you are going to update it, why not to the latest 2.8.6? Brian On 08/19/10 03:55 AM, Guillaume Desmottes wrote: Hi, The external dep on gnutls is currently 2.4.2. I'd like to bump it to 2.8.5 so Empathy will be able to check TLS certificates [1]. If that's ok I'll update the wiki and jhbuild. G. [1] https://bugzilla.gnome.org/show_bug.cgi?id=626848 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
How to control desktop files
Many OpenSolaris users use GNOME in a terminal server environment, and we notice some serious usability problems with running GNOME in this way. I was wondering if someone might be able to suggest some recommended ways to address these problems. Many of the problems relate to Desktop files. In a terminal server environment you often do not want users to be able to run programs that require elevated privileges, so System Tools (e.g. package managers, etc.) should not show up in the menus. Developer tools may not make sense to display in some environments. Also, users in a terminal server environment may not have access to certain devices which may make some programs not useful (e.g. a power management or battery status tool). Similarly, some programs that are autostarted may not make sense in a terminal server environment, such as power management/package manager related user daemons. Since the GNOME autostart mechanism also uses Desktop files, this seems a related problem. One crude way to resolve this problem would be to simply not install (or uninstall) packages that introduce desktop files. However, this is not an ideal solution for many reasons. It is especially a problem for Oracle because Oracle's terminal server product, Sun Ray, runs on many Linux distros (Fedora, Debian, Ubuntu, openSuse, Gentoo), so it would be ideal if there were a solution that just worked nicely across distros. A sysadmin should be able to specify what desktop files to ignore without requiring distro specific setup (such as uninstalling packages or hand-editing desktop files). It would be best if any needed changes could just be installed with the Sun Ray product and things would just work. I know that the Desktop Specification supports TryExec which does offer some control over whether desktop files should be ignored. However, it does not seem that this is powerful enough to provide the flexibility needed. Desktop files also support a Category field. Is it possible to tell GNOME to ignore desktop files that have a particular values like System and Settings. For example, on user session startup, GDM (and most display managers) sources any files in the /etc/X11/xinit/xinitrc.d directory, so perhaps this could be solved by setting up an environment variable before session startup with a list of categories or desktop file names to ignore. This would work well since it would allow the sysadmin to control what desktop files to ignore via the /etc/X11/xinit/xinitrc.d interface and without needing to modify any GNOME packages or files. Another possible solution might be to store the list of categories or desktop files to ignore in a GConf setting that gnome-session or GNOME Shell checks, and which the sysadmin could setup as mandatory system-wide settings. This seems a generally useful feature in a variety of contexts, not just terminal servers. Many projects may want to provide software on a variety of platforms and have the ability to control on which platforms desktop files should be used or not. Or is there already a way to implement this sort of feature that I do not know about? If not, would it be acceptable to enhance gnome-session and GNOME Shell to support this sort of feature, perhaps with the sort of solution suggested above? Since this feature is of particular interest to Oracle, resources can be provided to do any work needed to make this functionality work well assuming we can come up with an acceptable design. A similar problem is with panel applets. Some applets do not make sense to display and run in a terminal server environment, such as the battery status applet. What is the proper behavior for applets in this situation? For example, should an applet be written to be smart enough to recognize that it is not needed and exit itself? If so, is there an example of a GNOME applet which does this sort of thing? Or is there some interface to control what applets should not be run in certain environments? Or would interfaces need to be added to support this ability? Thanks, Brian ___ 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
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? Brian On 03/ 9/10 03:26 PM, Ruben Vermeersch 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform for Developer Documentation
Alberto/Shaun: I agree that there is no reason why the developer docs should not include good documentation for modules such as PackageKit, PulseAudio, PolicyKit, and udev (DeviceKit friends or whatever they are called this month). That said, OpenSolaris does not distribute any of these. How distros manage packages can be very distro specific, so PackageKit is likely not a good fit for everyone. On OpenSolaris, PolicyKit has never been adopted due to the fact that OpenSolaris uses RBAC which provides (or can provide) similar functionality. udev is currently very Linux specific. I am a bit on the fence about PulseAudio - perhaps it may be integrated into OpenSolaris at some point, though it seems far more useful interesting when using Linux-specific ALSA. I do recognize that most people who distribute GNOME ship with these modules, so I am all for delivering good documentation for them. However, I do think more energy should be focused on the truly cross-platform interfaces that everybody uses. At the very least, the documentation should avoid making assumptions about these sorts of interfaces being used by everyone. Especially when information about these interfaces are mentioned in the documentation for truly cross- platform interfaces. For example, if the docs for a desktop application like totem or nautilus needs to discuss udev of PolicyKit, it should be made clear that not everybody uses these and that other mechanisms may need to be used on some distros. Brian On 03/ 8/10 09:54 AM, Alberto Ruiz wrote: 2010/3/8 Josselin Mouettej...@debian.org: Le dimanche 07 mars 2010 à 15:16 -0600, Shaun McCance a écrit : * PackageKit I don’t think we should consider PackageKit as a core development interface, but rather as an optional service. It doesn’t integrate properly with all distributions, and not all user setups make it useful, especially the largest installations. Release often, release early. The only way to improve support is to embrace it and push its adoption and get people to file bugs. * PulseAudio Maybe it’s (still) a little too early to consider it? Support for a wide range of hardware is still very poor as of kernel 2.6.32. PackageKit and PulseAudio are two projects that are pretty well aligned with the GNOME platform in terms of API technology and goals, they solve hard problems to solve, they don't have any real contenders (yes they have problems, but if we wait until they are perfect, we will never have a platform). So my take on this is, embrace those, help downstream to embrace them, but let's not hold back or we will end up with a half arsed platform that tries to solve everyone's problems and will end up solving no one's. Furthermore, if you want to consider hardware support, maybe you can talk about GUdev? It’s still Linux-specific, but currently it is the way to go. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling ___ 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: [Usability] Announce - GNOME 3 Usability Hackfest (London, Feb 22-26, 2010)
Mahendra: I can suggest Thursday 4pm, how much time would you need for the Wookie event? It would be good if people planning on attending the Usability hackfest could give some indication about whether some of these Dev8D events are of interest. It would obviously be easier to coordinate if we had a clearer idea of the degree of actual interest. Also I understand that you would like a person(s) from dev8D to attend some of Hackfest, is that right? Would one day be enough? Mia Ridge is interested in usability I was thinking of asking her, David? I would think it mostly depends on how much interest the person has in participating in GNOME usability discussions. I would think one day should be enough just to discuss collaboration opportunities and to ensure that we properly coordinate together. However, I don't think it would be a problem to spend more time if the person has a particular interest in contributing more. I think it would be best if the representative could attend the first day of the GNOME Usability hackfest on Monday, February 22nd. This should help to ensure that we give as much time for planning as possible. They could report back on the Saturday at Dev8D (27th) Sounds good. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] Announce - GNOME 3 Usability Hackfest (London, Feb 22-26, 2010)
Steve: How many people in the Dev8D community work in the HE field? [I've added Mahendra to this discussion as lead of Dev8D) I'd guess most, but I am not involved with organising Dev8D Have they worked with free software projects like GNOME before? Are there particular people who might have an interest in attending or participating more directly with the GNOME 3 Usability Hackfest? Perhaps the delegate list would reveal that? I'll check if any of the projects that OSS Watch have advised on open development might possibly be interested in both events. That would be appreciated. If there are particular people who would be good candidates for joining the GNOME event, then it would be good to invite them. The GNOME Usability hackfest is a small event, however, so we probably do not have room to invite more than a few people. So, if people are invited, they should probably be those people with a particular interest in GNOME, or experience with free desktop usability. If there are particular people in the Dev8D community who have an interest in usability or human interface design, then I would recommend that they join the usabil...@gnome.org mailing list and participate in discussion leading up to the event. That way, we could start discussing how we could possibly work together. Perhaps that could be suggested in one of any pre event mailshots? That sounds like a good idea. If possible, it might work out best if the folks at the GNOME Usability hackfest could brainstorm and discuss this on the first day of the GNOME 3 Usability hackfest, or would that be too late to make a decision? That sounds constructive, even if something more definite is decided before. I think we should plan on it then. Just let us know who will be the representative from the Dev8D community who can join and we can have further discussions to firm up plans. One idea that might work if GNOME use W3C widgets at all, or it is being considered. I know there was talk of closer web/desktop integration. The GNOME project does embed WebKit and/or mozilla in a few places. The GNOME community did recently have a WebKitGTK+ hackfest last December which probably would have been an event with a bit closer match in focus. http://live.gnome.org/WebKitGtk/Hackfest2009 While these sorts of usages will likely not be the major focus at the GNOME Usability hackfest, it is likely that some time will be devoted to discussing such things. The Wookie project from Bolton University is a W3C Widget server (and is now in the Apache incubator). OSS Watch are running a Wookie training day and then a Wookie + Sling/OSGI event at Dev8D. If there is interest in this then perhaps the usability folk could help us understand what we need to do when building widgets? http://getwookie.org/Welcome.html It is good to highlight these sorts of things, so that those people who are attending and have a particular interest in this area can consider joining these events. Which day will these Wookie related events happen? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Usability] Announce - GNOME 3 Usability Hackfest (London, Feb 22-26, 2010)
Steve: As already discussed with Brian Cameron and David Flanders, there is a great opportunity to hook up this event with the JISC Dev8D developer event that is happening in London at the same time. http://www.dev8d.org Yes, it does seem like there is a real opportunity for some good synergy, and I think we should plan to do some activities together. I updated the GNOME 3 Usability Hackfest Wiki with more of the details you mention in your email: http://live.gnome.org/UsabilityProject/London2010 OSS Watch are very interested in forging links between open projects as part of our support services to UK HE projects. So we're looking for ideas for how to develop some positive synergy and how develop this into the perfect opportunity for UK HE developers to learn about, use and and hack on GNOME projects, and visa-versa. It would be good if we could flesh out the possibilities a bit more before the event, I think. How many people in the Dev8D community work in the HE field? Have they worked with free software projects like GNOME before? Are there particular people who might have an interest in attending or participating more directly with the GNOME 3 Usability Hackfest? If there are particular people in the Dev8D community who have an interest in usability or human interface design, then I would recommend that they join the usabil...@gnome.org mailing list and participate in discussion leading up to the event. That way, we could start discussing how we could possibly work together. Below I've listed some ideas for collaboration that have already been proposed by Brian and David and I've added a couple more ideas. * Organize a day when the GNOME Usability Team or community meets at the Dev8D venue to give a talk or session or hang out for or hack. The 27th looks like being a good day to encourage people from the GNOME Usability hackfest to attend the Dev8D conference as it is the day after the GNOME event. Since the 27th is the day following the GNOME Usability hackfest this could work really well. However, I notice that everybody who has added their name to the Usability hackfest Wiki has only listed the dates Feb 22-26, which might indicate that people are not planning on staying the extra day. It would be good if people planning on attending the GNOME Usability hackfest could chime in and let us know if there is an interest in doing this sort of collaboration, and whether the 27th would work well. * The GNOME Foundation could provide some compelling speakers, presenters, or discussion topics on GNOME Usability or free software GUI usability in general. This seems very doable. Is there any sort of timeframe that we need to decide on the specifics for this to happen? If possible, it might work out best if the folks at the GNOME Usability hackfest could brainstorm and discuss this on the first day of the GNOME 3 Usability hackfest, or would that be too late to make a decision? * Dev8D attendees could provide an introduction to HE research specific projects Could you provide any details? * OSS Watch will be running a workshop before the events that will provide an opportunity for learning about Wookie, the W3C Widget server that is now in the Apache Incubator. This means there will be people hacking on Wookie and widgets at Dev8D. * Eye gaze control using cheap web cams is a hot accessibility topic so it would be good to see some joint hacking on GNOME Mouse Trap and University of Cambridge Inference group's opengazer project; http://bit.ly/6iZqbr and http://bit.ly/GL9tJ (thanks to @pepperbox for the idea). These do sound interesting. It would be good if others who are planning on attending the GNOME Usability Hackfest could voice their thoughts about this as well. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Announce - GNOME 3 Usability Hackfest (London, Feb 22-26, 2010)
I would like to announce the GNOME 3 Usability Hackfest planned for February 22-26, 2010 in London, England. This is an exciting opportunity for GNOME Usability to take a step forward and this hackfest will provide the GNOME Usability team an opportunity to focus, set goals, and accomplish work to prepare the GNOME community for the GNOME 3.0 transition and the future. Details, goals, and instructions can be found on the Usability Project London 2010 Wiki here: http://live.gnome.org/UsabilityProject/London2010 If you plan on attending, please sign up in the Attendees section. If you need assistance with travel costs, note the instructions to follow the GNOME Travel Subsidy process on the Wiki page. Looking forward to seeing you in London! Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module semi-proposal: gnome-shell
Owen: It sounds like GNOME Shell will likely not integrate with GNOME 2.30. How are users expected to turn on/enable GNOME Shell? At the Boston Summit, I remember people suggesting that there should be a checkbox in the Preferences-Appearance capplet that the user can check it to start using GNOME Shell. Is this the plan? Whatever such interfaces are needed in the base desktop to provide end users with the ability to switch to GNOME Shell, I hope these interfaces make it into GNOME 2.30. Ideally, users should just need to install the new GNOME Shell, mutter, etc. modules and have their desktop just work. Users should be able to enable GNOME Shell without needing to hack around with gconf-editor, .desktop files, etc. I think it will cause problems for adoption and testing if users need to reinstall patched versions of gnome-control-center (or whatever) in order to turn on GNOME Shell after installing the GNOME Shell packages. In terms of zeitgeist, there have not been any tarball releases as far as I can tell. If we are seriously considering adding zeitgeist into GNOME, I would think we should be starting to do more formal releases of the code. I would think the sooner the better. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Project Proposal: GNOME Innovation
Wolter: I think your graphic flowchart is a good start. However, a lot of GNOME modules do not really have active maintainers. To date, I think the community has dealt with that problem in an ad hoc manner. However, if we are going to formalize how such a process works, then I think i would be of value to make it more clear how modules without active maintainers are maintained. Maciej: Ok. The only feature different then bugzilla is vote down AFAIU. Moderation is similar to marking NEW and vote up to adding to CC. I think one main benefit to the innovation idea is that it creates an archive where people can, hopefully, go to find out the discussion behind particular design choices, and what issues were considered. This can be helpful reference, for example, when trying to make changes to that code later or replacing it with something new. Since much of this discussion has already happened on mailing lists, it would be especially useful if the innovation tool made it easy to reference such past threads. It would be neat if you could go to some website and quickly find links to particular design discussions that happened in the past, whether on mailing list or captured directly in the innovation tool. This sort of process is also similar to the OpenSolaris ARC (Architecture Review Committee), where you have a process to help make architectural decisions. http://www.opensolaris.org/os/community/arc/ In this process, the focus is on a project's interfaces moreso than the internal, or private, architecture of a given module. The focus is more to ensure that modules integrate well together on the system. For a project like GNOME, there might be more value in studying and documenting the internal architecture of some modules, though. The ARC process is probably not the right fit for the GNOME community, but I'd encourage people to read some about how the process works and cherry pick any good ideas that might apply. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
What version of clutter should be used in 2.27/2.28?
The 2.27 external dependencies page still lists clutter 0.8.x as the supported version of clutter to be used with GNOME. http://live.gnome.org/TwoPointTwentyseven/ExternalDependencies However, clutter 1.0 and clutter-foo 0.10 have recently been released. Will the dependencies page be updated to the new versions, or are the 0.8 versions still recommended for GNOME 2.27/2.28? If so... I know that gobject-introspection is an optional dependency of clutter 1.0, so will gobject-introspection also be added as a dependency? Since GNOME 2.28 was called a GNOME 3.0 beta at GUADEC and since GNOME shell requires that clutter be built with gobject-introspection, I wonder whether the GNOME community recommends that distros build clutter 1.0 with gobject-introspection or not. Thanks, Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
David: On Tue, 2009-07-28 at 12:10 -0500, Brian Cameron wrote: I have pinged the Sun team working on DeviceKit and suggested they be better about communication with upstream by sending some status to the devkit-devel mailing list. Thanks. I heard from Lin Guo at Sun that he has followed up and sent an email to devkit-devel about our plans. He works on the team at Sun which is responsible for HAL, PolicyKit, and DeviceKit; so I hope this starts a better dialog between Sun and the upstream community. Also, Solaris has a security rule that requires that users not be asked to enter passwords for gaining authorization unless they are in the trusted path. To my understanding, PolicyKit does not address this issue today, perhaps because most Linux distros are not as strict about this requirement. This technical issue could be overcome, for example, by switching to a separate VT in the trusted path to display the dialog. Yes, it is entirely possible to easily make PolicyKit use an Authentication Agent that runs outside the session. If you wanted you could even make the authentication agent communicate with a separate device (for example a separate device connected via USB with small display / big flashy button the user can press to authenticate the request) or a mobile phone display (using BT for proximity)... or whatever... e.g. the APIs are in place for such things. Right. I was not trying to suggest that this is necessarily a blocker for integrating PolicyKit in Solaris. Trusted path is particularly important in the Trusted Solaris product. Until the above work is done, PolicyKit could, I am sure, be configured to do the right thing (e.g. never pop up dialogs asking for passwords) in this environment. The fact that PolicyKit doesn't just work with Trusted Path today just makes the process of integrating it into Solaris and making sure it is configured properly in various environments, such as Trusted Solaris, more complicated. And, sure, for home/consumer usage just having both the screensaver unlock dialog, the PolicyKit authentication dialogs and other stuff (such as GMountOperation interaction [1]) running in a trusted sandbox (e.g. separate Xserver/VT) is probably what we want. That way, nothing running in the user session can ever snoop on passwords. Of course this requires a lot of bug fixes in the X.org stack (it is essentially fast user switching), we need a system compositor (like wayland), ConsoleKit changes and so on... so blue sky for now. Jon McCann gave a presentation at the 2007 GUADEC that he was interested in making GDM manage the screen lock dialog in a separate VT, to better address lock screen trusted path issues. I do not think much work has been done on this yet, but it does not sound too impossible. If that work is done, perhaps the GDM interfaces could be further extended so that programs like PolicyKit could call GDM to trigger a similar authentication dialog. Thus making GDM a single-point program to manage authentication dialogs in a secure, trusted path manner. Btw, I wonder how you implement screen locking (e.g. screen saver) / connecting to network shares (e.g. gvfs) / ssh (via the terminal) if you don't want people to enter passwords... seems like a weird backwards requirement to only require it for gaining authorizations and not for something like unlocking the screen. As I mentioned above, for Sun trusted path is more of a concern with Trusted Solaris. The Trusted Solaris product locks down the user environment so that users cannot do things like starting up a terminal to run ssh or su, where they might enter a password. Today in Solaris/OpenSolaris, the lock screen does not run in the Trusted Path, unless you are using Trusted Solaris. Trusted Solaris makes use of an Xserver extension written by Sun (not too dissimilar to SELinux) that forces the screen lock to run in the trusted path. One problem with this approach is that the lock screen is not accessible when using Trusted Solaris. Ideally it would be better to move away from this solution and use a lock screen solution that just worked with trusted path without hacking around with Xserver extensions. For example, if GDM managed the lock screen and provided a11y similarly as it does today for login, then this would work better and would provide a more secure trusted path environment for all users. There has been some concern expressed about using PolicyKit with an RBAC backend. If Solaris ships configuration files for both RBAC and PolicyKit, then users will likely need to understand and configure both systems to properly configure their setup. There is a desire to avoid adding unnecessary complexity. Perhaps a GUI that hides this complexity from the user could help to address this concern. The only thing you need is to figure out whether an mechanism-defined action (as defined in the .policy file shipping with the mechanism) is allowed or not. So you would just have a small
Re: GNOME and non-linux platforms (release team please stand up)
David: On Thu, 2009-07-23 at 04:58 -0500, Brian Cameron wrote: Sun is already working to add DeviceKit support to Solaris It would be good to the devkit-devel mailing list know about this. Because if this is so, we need to change some of our plans; in particular move the make porting easier up the priority list. Also, I hope you guys know that PolicyKit is a not an optional dependency. I have pinged the Sun team working on DeviceKit and suggested they be better about communication with upstream by sending some status to the devkit-devel mailing list. Sun does not have much of an interest in shipping modules which have a strong dependency on PolicyKit No-one ever explained to me why Sun is suddenly not interested in this - and SUN did send patches to PolicyKit earlier on. The only explanations I've seen (in private mails) included childish statements like claiming PolicyKit is rubbish and that the author, me, didn't know what I was doing. Myself and Jim Li were the two Sun engineers working to make sure that PolicyKit works on Solaris. Much of this work was done in late 2007 and early 2008. At that time, there was not an urgent need for integrating PolicyKit into Solaris, but we wanted to make sure that we were keeping abreast with the new technologies that were going to have a lot of impact on the desktop. We wanted to make sure we were more familiar with the codebase and start getting fixes for Solaris-specific issues upstream. We provided spec-files in the Solaris spec-files-extra repository so that others in the OpenSolaris community could get involved with building it if they wanted to further test it out. If we gave the impression that we were being more aggressive about integrating PolicyKit, that was not intended. I can not speak for Sun in general on this matter, but my understanding is that Sun does not have any problems with integrating a module like PolicyKit. In fact, Solaris does already ship a stripped-down version of PolicyKit that is only used by HAL. If you look at a recent OpenSolaris release, you will see libpolkit.so in /usr/lib. However, this is a hacked PolicyKit that just works as needed for HAL alone, and does not provide any configuration for the user to change. Instead it works with a RBAC backend. Since PolicyKit relates so much to security, going through the processes of review and auditing needed to integrate a more complete PolicyKit will be cumbersome, though not impossible. The security team at Sun has expressed some concerns about the maturity of PolicyKit, since it is such a new framework. If some of these concerns were communicated in childish ways in private emails, then I apologize. Also, Solaris has a security rule that requires that users not be asked to enter passwords for gaining authorization unless they are in the trusted path. To my understanding, PolicyKit does not address this issue today, perhaps because most Linux distros are not as strict about this requirement. This technical issue could be overcome, for example, by switching to a separate VT in the trusted path to display the dialog. There has been some concern expressed about using PolicyKit with an RBAC backend. If Solaris ships configuration files for both RBAC and PolicyKit, then users will likely need to understand and configure both systems to properly configure their setup. There is a desire to avoid adding unnecessary complexity. Perhaps a GUI that hides this complexity from the user could help to address this concern. Though, probably the main reason why there has not much of a drive to add PolicyKit to Solaris is because there has not been much need. To date, Sun has not had much of a problem integrating the GNOME stack without having PolicyKit available. I am sure there are some features that Solaris is lacking because of this, but I do not recall any bug reports or user complaints about this. The lack of specific need-to-have features that would be solved by adding PolicyKit makes it easier to not integrate PolicyKit than to address all of the above issues and concerns. Anyway, maybe you should ask someone at Sun out the latest polkit version http://hal.freedesktop.org/docs/polkit/ which is a complete rewrite of the old code. PolicyKit, by itself, is now merely an interface to interface to the authorization system - adding support for a Solaris RBAC backend amounts to subclassing a single class, implementing two methods and drop that code in an .so in $libdir/polkit-1/extensions. Yes, you're welcome that it is now this easy. This does improve things a lot. As I mention above, HAL already uses an old version of libpolkit with a hacked RBAC backend. At the very least, it seems it would make sense to update to the new version of PolicyKit to take advantage of the new, more flexible framework for RBAC integratin. That is probably the practical next step towards better integrating PolicyKit into Solaris. I am not sure what the big deal is here
Re: GNOME and non-linux platforms (release team please stand up)
Colin: Though, probably the main reason why there has not much of a drive to add PolicyKit to Solaris is because there has not been much need. To date, Sun has not had much of a problem integrating the GNOME stack without having PolicyKit available. I am sure there are some features that Solaris is lacking because of this, but I do not recall any bug reports or user complaints about this. I don't have a full feature list to hand, but some concrete examples are things like: * shutdown/reboot (the legacy code may still be there) Yes, Solaris has a hack to workaround this. * Changing the system time from the clock We keep planning to hack the clock to launch Visual Panels for doing this, but that will need to wait until Visual Panels actually fully integrates. * PackageKit updater Solaris does not use PackageKit. * Doing simple administrative process control in gnome-system-monitor Not sure about our plans on this one, actually. I think it makes sense for things like this to be in the default desktop UI flow, and enabled by default by OS vendors for the unmanaged case[1], the first three particularly without any authorization required at all. Here PolicyKit is just a fancy way for us to work around the default Unix permissions model which was designed for timesharing servers, while allowing administrators in the managed case well-defined control. This doesn't replace the need for tools targeted for admins, but I think it is going to be a better experience than firing up Visual Panels, system-config-date or whatever for the covered cases. True, there are some features that Solaris lacks because PolicyKit is not yet integrated. The question really becomes when are the features significant enough to warrant the work involved to integrate PolicyKit. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME and non-linux platforms (release team please stand up)
Jason: Obviously the alleged pointlessness of something that we are arguing about is relevant. Whether or not there are--you know--actual people using said OS is what this is really about. And apparently even Sun doesn't think so since they no longer invest the same level of resources in it that they once did. I'm calling a duck a duck here. It's a failure and even Sun knows that it is. There's no reason we shouldn't be scrambling a few eggs on Solaris to advance the Linux desktop experience. I didn't realize that Sun was the only company involved with GNOME that has had resources negatively impacted by this long-standing downturn in the economy. Even though, it is true, Sun does have fewer resources working on GNOME than we did several years ago, there are still several dozen engineers at Sun working on GNOME and GNOME-related technologies. Recently Sun has been focusing a lot of time and energy into making a new accessible installer, the Time Slider GNOME ZFS integration application, adding better wireless and printing support, improving the multimedia experience, and lots of other things. The latest releases of OpenSolaris have been well received, I think because we are doing a good bit of work making GNOME available on Solaris. http://blogs.zdnet.com/perlow/?p=10250 Sun is already working to add DeviceKit support to Solaris, GNOME runs fine on Solaris without PulseAudio. Sun does not have much of an interest in shipping modules which have a strong dependency on PolicyKit (e.g. Sun is moving to use VisualPanels instead of wanting to ship GNOME system tools), and it typically isn't hard to make those few programs that use PolicyKit that we do want to ship use RBAC instead. I am not sure what the big deal is here. Nobody from Sun has been complaining about GNOME being too Linux-ey, have they? Sun has always had a good relationship with the GNOME community, and it has never been particularly hard to get patches upstream to support things needed for GNOME to work well on Solaris or OpenSolaris. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
Jaap A. Haitsma wrote: On Tue, Jul 14, 2009 at 12:29, Felix Riemannfriem...@gnome.org wrote: Regarding the non-default / deprecated widgets I'll take it like Thomas Andersen in comment 9 in above bug: it makes no sense fixing them. * gst-mixer doesn't need any fixing and works with deprecated symbols disabled already. (Note, this seems to be used at least in Gentoo when building your system without PA) Why don't we remove gst-mixer, vu-meter, gnome-cd and cddb-slave2 completely from gnome media 2.27. People that want to keep on building them can use the 2.26 branch Solaris continues to use gst-mixer since Solaris does not yet provide PulseAudio. PulseAudio doesn't provide as much value on Solaris since OSSv4 provides mixing functionalities directly in the OSS layer. Providing an alternative GStreamer-based mixer program still has value, I think. Sun would appreciate if gst-mixer could stay in gnome-media. Since it doesn't need any fixing and works with deprecated symbols disabled already, I don't think there is any reason to remove it from that standpoint. I don't think there is an issue with removing the other programs, though. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
Patryk: On Wed, Jul 15, 2009 at 11:46 AM, Brian Cameronbrian.came...@sun.com wrote: Solaris continues to use gst-mixer since Solaris does not yet provide PulseAudio. PulseAudio doesn't provide as much value on Solaris since OSSv4 provides mixing functionalities directly in the OSS layer. Would introducing PA have any downsides? Having a common abstraction layer for sound would likely make it easier to develop portable apps. There would be some advantages for using PulseAudio, yes. Positional sounds could be an interesting feature, for example. This was discussed before. Refer: http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00208.html However, many of the additional benefits (e.g. GlitchFree) requires support in the drivers, which currently does not exist on Solaris. It would be a significant effort to add such features, and not currently in the plans. However, this could perhaps change sometime in the future and make PulseAudio more attractive on Solaris. Also, for PulseAudio to work properly, you need to redirect all audio applications to use it. On Solaris, this would be a non-trivial effort since we need to support several applications that aren't designed to use PulseAudio currently (such as Real Player, Flash, etc.). In short, it would be a fair bit of work to integrate PulseAudio, and the benefits do not seem worth the effort at the moment. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 - shell and applets
Frederic: As a side note, another reason developers are currently abusing notification area is that is it the only cross-desktop (GNOME/KDE/LXDE/XFCE/IceWM/insert_your_favorite_de_here) way to get applets-like icons on a Xorg system, which also have the nice pro to not pull something as ugly as bonobo in the loop. Wow, that sounds useful. So, if we really want to improve the situation for GNOME 3, we should also try to solve this cross-desktop missing API for applets. Agreed. Good thing we are meeting with the KDE people in a month at GUADEC. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Kjartan: Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Won't clutter-0.9.x work with clutter-gtk-0.8.x? What do you mean by work? You need clutter 0.8 to build clutter-gtk 0.8. They are parallel installable, so if you want jhbuild to build both clutter 0.8 and 0.9, then that's one aproach. However, it seems it would be nice to just move over to 0.9 in one step if possible. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Emmanuele: I'll make a clutter-gtk 0.9.0 release tarball tomorrow, then. Will it include gobject-introspection support? http://bugzilla.o-hand.com/show_bug.cgi?id=1490 Would be nice to support gnome-shell with this, I think. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
Shaun: Shouldn't GStreamer be included for media support? If not in the Platform, then at least Recommended? Also, what about gvfs, libdaemon, and libunique? Brian On 05/05/09 14:05, Shaun McCance wrote: Hey folks, I'm taking a hard look at the Platform Overview and how we can improve our message to ISDs through better documentation. Our release sets, unfortunately, don't really reflect what we really recommend to developers. That role has more or less been delegated to the Platform Overview. The problem is that what's in the Platform Overview is based entirely on what I happened to think was worth mentioning at some point. I should not be the arbiter of our platform. I would like to get people's opinions on what technologies we should be pushing. I'm interested both in the here and now and in what people think the Gnome 3 message should be. I've organized my thoughts into three categories: Platform contains technologies that are currently in our Developer Platform release; Recommended contains thing that we seem to agree we should push, but are either in the Desktop release or just in our external dependencies; and Others contains stuff that I think is cool and could be part of our core offering some time in the indeterminate future. The list is what came to mind as I was writing this email. Please feel free to discuss libraries I forgot. Platform GTK+ -- The core of how we make graphical applications. Pango -- Internationalized text rendering system. You love it and you know it. GLib -- The foundation for pretty much everything we do. GIO -- Part of GLib, but worth a separate mention in the Platform Overview. GConf -- Configuration system. There is talk of a new system (see below). But I think it's obvious that we need to be pushing something here. So as long as GConf is what we have, it's what we push. ATK -- Accessibility toolkit. Used by GTK+. Should be used by anything else that does UIs. Recommended === Cairo -- Incredible drawing library, used by GTK+. There seems to be general agreement that developers should use Cairo when they need to do custom drawing. GStreamer -- All things multimedia. I don't think there's any argument against GStreamer being the Gnome-blessed way to do multimedia. D-Bus -- Inter-process messaging system. Lots of stuff is built on it. How much do we want to push it directly? Avahi -- Service discovery. This is used in quite a few places. I know some people in the past had talked about having a simple wrapper in GLib. How much do we push it? gnome-keyring -- Storing passwords and other secrets. I think this is an important thing to offer ISDs, but this seems to be languishing as a desktop-only thing. evolution-data-server -- Address book and calendaring. I've seen half a dozen projects come and go that aim to augment or replace e-d-s. We seem to like the idea, but I'm not sure we all love the implementation. libsoup -- HTTP library. Honestly, HTTP is such a core thing these days, we need to offer something. Everybody seems generally happy with libsoup in general. Should it be in the Platform? Should its functionality just live in GLib alongside fancy new networking stuff? libxml2/libxslt -- We put these into the external deps a couple release cycles back. Do we want to continue pushing them as part of our platform? Others == GSettings -- GConf replacement to live in GLib. Telepathy -- Instant messaging and beyond. I think there is a lot of really cool potential here. Libchamplain -- Wicked cool mapping library. This is not something I would have thought of as something we need to offer. But now that it's here, it's a really compelling technology with a lot of potential. Clutter -- Are we actively embracing Clutter, or is it just something we're OK with people using? The message is unclear. Tracker -- I don't think we can afford to be without a search system. This isn't just about having file search as a feature. It's about providing something that ISDs can leverage to make their applications better. GNIO -- Networking library for GLib. WebKit -- More and more applications are finding uses for an embedded HTML rendering widget. I think we need to provide one with a solid API. WebKit seems to be the direction people are heading in. Various D-Bus services and APIs -- DeviceKit, PolicyKit, ConsoleKit, I think there's something for power management, etc. Are these things we expect applications developers to use directly? What's our message? All right, that's what's come to mind so far. I'd also like to discuss what we're pushing on the mobile front, but that's another can of worms. I'm really curious to hear what the community thinks. Thanks, Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___
Re: gnome-games requires clutter 0.9.x
Kjartan: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Brian ___ 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
Emmanuele: 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. I wonder how this fits in with the gdesklets project, if at all. I know Calum Benson, UI engineer at Sun, has suggested that it would be nicer from a UI perspective if there were just one desklet/applet type interface. Perhaps moving to a gdesklets model would be nicer? Or do we need to reinvent the wheel here? Also, does the avant-window-manager fit into plans at all. In terms of providing a nice interface for keeping track of running applications and providing desktop shortcuts, it seems a nice alternative to consider. Perhaps I missed the discussion where such alternative designs are being considered, so please forgive if I'm asking a stupid question. Brian 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? 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. any default GNOME installation on basically every modern distribution comes with: - menu applet - notification area - clock (+ weather) - audio volume applet - window list applet and not only I have yet to see any regular user change the contents of the panel (because it's mostly undiscoverable and because most people *just don't care*) but I also haven't heard any justification for allowing this in the first place. gnome-shell moves away from the menu and the window list applets; it embeds the notification area and the 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. 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!). 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. ciao, Emmanuele. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Kde-accessibility] Potential GUADEC/Akademy a11y BOF? (was Re: Planning for GNOME 3.0)
Willie: I would be interested to attend such a BoF. I think that all three topics you mention are important. Perhaps another agenda item to discuss how GNOME 3.0 will impact a11y would also be appropriate. I think the Bonobo/CORBA deprecation falls into this category, but I think there are other issues. How, for example, will clutter-based metacity and gnome-shell work with a11y? Brian Tomorrow (Friday) is the deadline for GUADEC/Akademy submissions. I'm curious if there would be interest in setting up a GUADEC BOF around accessibility? My personal goals would be to focus on three main areas: 1) Bonobo/CORBA deprecation, including AT-SPI/D-Bus, magnification, and speech 2) Alignment with KDE a11y 3) WebKit a11y I think we agree these are all important. But, I'm curious if people who will be attending GUADEC/Akademy would be willing to attend and participate in such a BOF and if we can get critical mass to make them worthwhile. In addition, if the response is overwhelming, should we consider making separate BOFs? Will Willie Walker wrote: I'm really excited about GNOME 3.0. There are a lot of great ideas that people have come up with. As people work on new GUI designs, I request that people engage the GNOME accessibility team on their designs. Accessibility is a big selling point for GNOME and I'd really hate to see it take a step back. Too often, GUI designers and developers forget about important details such as keyboard access, theming, and support for the AT-SPI. It's a lot easier to develop for accessibility from the beginning than to retrofit later. Engaging earlier than later also helps us act more like a team than adversaries. For developers local to the Boston area, I'm happy to take a visit to your sight to go over accessibility considerations and to discuss your new UI's with you from an accessibility standpoint. I promise to focus solely on accessibility considerations and will avoid general armchair HCI quarterbacking. For those outside the Boston area, we can try to find someone to visit you for a face-to-face and/or we could do conference calls with screenshots or just shared desktops via VNC. Thanks! Will (your friendly GNOME a11y guy) On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote: During the first few months of 2008, a few Release Team members discussed here and there about the state of GNOME. This was nothing official, and it could actually have been considered as some friends talking together about things they deeply care about. There were thoughts that GNOME could stay with the 2.x branch for a very long time given our solid development methods, but that it was not the future that our community wants to see happening. Because of lack of excitement. Because of lack of vision. Slowly, a plan started to emerge. It evolved, changed, was trimmed a bit, made more solid. We started discussing with a few more people, got more feedback. And then, at GUADEC, the Release Team proposed an initial plan to the community that would lead the project to GNOME 3.0. Quite some time passed; actually, too much time passed because too many people were busy with other things. But it's never too late to do the right thing, so let's really be serious about GNOME 3.0 now! Let's first diverge a bit and discuss the general impression that GNOME is lacking a vision. If you look closely at our community, it'd be wrong to say that people are lacking a vision; but the project as a whole does indeed have this issue. What we are missing is people blessing one specific vision and making it official, giving goals to the community so we can all work together in the same direction. In the pre-2.x days, the community accepted as a whole one specific vision, and such an explicit blessing wasn't needed. But during the 2.x cycle, with our six months schedules, it appeared that everything (community, development process, etc.) was just working very well, and as the vision got more and more fulfilled, the long-term plans became less important as we focused on polishing our desktop. But we've now reached a point where our next steps should be moving to another level, and those next steps require important decisions. This is part of what the Release Team should do. Please note that Release Team members don't have to be the ones who have the vision; we just have to be the voice of the community. (As a sidenote, the roadmap process [1] that we tried to re-establish two years ago was a first attempt to fix this. Unfortunately, it turned out that we were missing the most important side of things: a project-wide roadmap. This is because a collection of individual roadmaps isn't enough to create a project-wide roadmap.) So let's go to the core topic and discuss what the GNOME 3.0 effort should be. We propose the following list of areas to focus our efforts on: - Revamp our User Experience - Streamlining of the Platform - Promotion of GNOME There are also other potential areas that are worth
Re: dconf
I think dconf is a great project, but I do have one question. Will the new dconf address the sorts of D-Bus problems raised in these GConf bugs? http://bugzilla.gnome.org/show_bug.cgi?id=555745 http://bugs.freedesktop.org/show_bug.cgi?id=17970 Thanks, Brian On 04/02/09 10:37, Ryan Lortie wrote: Hello, d-d-l. I'm a long-time listener, first time caller. Many of you are probably aware of two things about me: 0) I'm that guy who is working on that weird cloud of dbus-ish stuff involving GVariant and dconf and GSettings, etc. 1) A few months ago I started working for Codethink This email is a statement of status, of direction and of intention. A lot of people have been asking what is going on, so this is an update. It's not really an attempt to start a discussion, but if that happens, then I'm happy to answer any questions. :) first: GVariant. GVariant has been in an essentially-complete state for quite a long time now. I recently rolled a tarball of it and announced it to the announcement list. It is available here: http://www.gnome.org/~ryanl/src/ GVariant is currently hosted as a totally separate project in a git repository on git.desrt.ca: https://desrt.ca/gitweb/?p=gvariant The intention is that it be merged with glib (into the base libglib library). Now that glib is in git I will be making a branch and performing the merge. This should be complete within a couple of days. I will then propose it for inclusion in the next release of glib. GVariant is reasonably well-tested and is being used in a number of other projects that I'm working on. Of course, it surely has some bugs hiding in it. I believe that the API is more or less stable at this point, but I welcome constructive criticism and feedback. There are plans to add more functionality (such as the ability to print/parse pythonic text strings). You can read more details about how GVariant works in the release announcement here: http://mail.gnome.org/archives/gnome-announce-list/2009-March/msg00103.html second: dconf and GSettings For some time I've been talking about these pair of projects as a proposed replacement for GConf. The reasons that we might want to replace GConf are well understood and widely documented and I won't talk about them here. A while ago there was even a reasonably-working implementation of dconf. This was based on a different value system (ie: before I started writing the more-generally-useful GVariant). I stopped working on dconf when I shifted focus to GVariant and when school started consuming a lot of my time. Recently, sponsored by Codethink (now my employer), I have resumed work on dconf. This has come in the form of a total rewrite (and simplification) based on GVariant. This rewrite (along with another project, GBus) is doing a lot to convince me of the stability and usability of GVariant. Briefly, dconf is a simple untyped hierarchy of keys. It is used as the backend storage for GSettings which is a very strictly typed high-level settings system intended to be used by GNOME applications. The API is much nicer than GConf. dconf is very efficient. The majority case in accessing settings is reading (think about desktop login: 1000s of settings read, none written). Reading in dconf is done directly from a memory-mapped file containing the settings in an efficient tree format and doesn't require an extra service to be running. The service is only needed for writes. Communication occurs over DBus, of course. :) The rewrite of dconf is currently extremely unstable and incomplete, but it is currently being hacked on (along with GSettings) full-time. Progress is good. In a week or two I will have something to show for this and I intend to have a stable release to go along with 2.28. Stay tuned. :) Ideally, I'd like to see GNOME using GSettings for 3.0. Rob Taylor (my boss) has indicated that I will definitely be able to spend time addressing issues that may arise with dconf and GSettings in the lead-up to 3.0. So that's it. That's what I'm up to. Have a good day :) ___ 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: dconf
Ryan: I was not familiar with these bugs. I'm glad to bring them to your attention, then, since I think it relates to the work in dconf. One thing is definitely true: for reading from the configuration settings, these bugs will not be an issue because you don't need to use the bus or launch the service at all for this to work. For writing, it's really hard to say. This seems like a wider DBus issue affecting all things that use it. Depending on how those bugs are resolved upstream, the result will be different for dconf. It seems, in general, we need to have a better-defined idea of what a session is. I assume the reason that these bugs bother you is because GConf used to work properly under 'su' when it was straight-up CORBA? Many people have complained to me about the fact that the configuration management can't start unless D-Bus is running. People don't understand the need to run dbus-launch when they just want to run some program which uses GConf or dconf. It makes it awkward to run programs outside of normal D-Bus enabled user sessions. The fact that this causes problems with su is just an example of a wider problem and probably the most annoying aspect of the bug to normal users. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: dconf
Rob: My question would be is why do these People have a desktop in which there isn't a DBus session bus? Its been there for a very long time now in most distros, afact. For gnome 3.0, running without a session bus is going to be like running gnome 2.0 without orbit2. i.e. it ain't gonna work right. I monitor opensolaris user list discussions, and it does cause some confusion and problems for users when they are working in certain setups. As an example, I remember one user who was setting up a multi-user kiosk environment, and only wanted the browser and a few other applications launched with particular geometries. They had some trouble figuring out they needed to use dbus-launch to run one of the programs that was GConf based. It isn't the worst bug in the world, and the workaround is usually not bad. I just wanted to find out if there were any plans to make dconf autostart itself and the services it needs more nicely than what we have today. However, if you want to discuss this bug more, lets discuss it in the bug report rather than clutter this discussion further. The fact that this causes problems with su is just an example of a wider problem and probably the most annoying aspect of the bug to normal users. Actually, no, the su problem is completely orthogonal, this is something that needs addressing in DBus itself and is fixable. Yes, they are two different bug reports. Just something I wanted to highlight to people's attention. Brian ___ 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
Owen: I just don't think it makes sense to code GNOME Shell to the limitations of other pieces of the software stack. The effort to fix the other pieces of the stack - to create free software ways of doing thin clients with a composited snazzy desktop - is going to be comparable or less then the extra effort we'd need to put into GNOME Shell, and the end result is much better. And the same applies to virtualized desktops, but more so. Don't put the effort into avoiding 3D. Put the effort into making 3D work. As a general rule, I agree with you. However, there are bound to be a few 3D features that do not work well in low-network-latency environments. I think it would be unreasonable to expect that such users (and users in general) won't want some degree of configuration control to make the desktop as usable as possible. However, such configuration should obviously be kept to a minimum and only when there is a strong use case for supporting it, I'd think. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Separate UI and core processes
Tristan: Note that the ATK provides interfaces for controlling and getting state information for all common GUI interfaces. These interfaces are widget-set neutral and currently both Java and GTK+ work with them. KDE is on the way, I understand. Currently libgail (the GTK+ ATK implemention) sits on top of the GTK+ library and provides ATK implementations for the GTK+ widget set. The current model is that any new widget set would need to write its own ATK implementation and would then work with the ATK. An alternative approach would be for programs to not specify their GUI at all via a specific widget set, and instead use ATK interfaces to specify what functionalities are available at any point. Then different UI plugins could be used to specify how those functionalities are presented to the user. For example, there could be a GTK+ plugin, a Java plugin, a KDE plugin, etc. Then different widget sets could be swapped in or out easily for any program. This would also make it easier to develop applications that use very different usability models. A user interface for blind users, for example, would not really need any graphical user interface running. A 3-D user interface would likely present data very differently than a 2-D one. Separating the functionality of the program from how it is presented to the user via a widget set would make it easier to implement such wildly different user experiences. I guess I am trying to highlight that much of the infrastructure is already in place to make this sort of change, but I am sure this approach would require some significant re-engineering of how GTK+ and ATK work together, but it is one approach that could be used for separating the model from the view. Brian With the recent shakeup to the computing ecosystem with the addition of netbooks, ipods, android, gmail, facebook, etc.; I was wondering what place gnome will have in the future. I was concerned with the platform inflexibility of programs such as Evolution, which is only really suitable to be run on a desktop or laptop; Gmail on the other hand works great on desktops, laptops, android phones, netbooks etc. I can also run Gmail from pretty much any ones computer, whether it be Linux, Windows or Mac OS. Now what I am advocating is not a complete rewrite of Gnome to run on the web; I believe that this is implausible for the moment. What I would like to see is a concerted effort to provide greater separation between the UI and the core of Gnome programs, so the eventually there is a complete separation, ie. the UIs runs on a completely separate processes than the cores and so it would be possible to separate UIs and cores into completely separate development projects. Such separation would have a multitude of benefits. Most programs already try to separate UI code, from core code, as this is simply a good programming practice, so this would just be taking that to the next step. With the UI being a separate project, it would then be easy to fork this project and create a plethora of UIs, ones that work well on netbooks, ones for the web, even windows, mac osx and KDE ones (please don't shoot me, or start some flame war about using qt). Such a development effort I think will help future proof Gnome and prevent Gnome become a collection of monolithic applications that only run properly on outdated platforms. In the future I don't want to worry about what computer I am using, I just want to access my mail, music, documents, ect. in a consistent way no matter where the files are actually stored or where the core computations are actually done. The cloud computing dream could become within reach. It would also open Gnome up to a whole new set of potential open source developers; no longer will a developer have to understand the underlying architecture of an application to contribute to it. Programmers would be free to experiment will all sorts of new UIs, taking advantage of new technologies such as 'multi-touch', accelerometers, eye-tracking, speech-recognition, etc. New opportunities would exist for writing programs accessible for the deaf, or blind. Also, I am sure Intel and AMD won't mind a few more processes for there future zillion core CPUs to play with. Anyway that is just my armchair observer 2-cents, feel free to ignore me :-) Tristan ___ 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: Brasero improvements over the 2.26 release cycle
Philippe: As Luis said I'm not against relicencing the library (and even the whole of brasero). It's just I wasn't aware of the issue at stake since I don't care much about licencing (which turns out to be a mistake). Regarding libbrasero-media, it shouldn't take long as I wrote all of the code but the two backends for : - FreeBSD but the copyright holder agreed to the licence change - OpenSolaris and I'm waiting for the answer. Given the size of the latter file, I can easily rewrite it if need be but I don't think it'll be necessary. A few questions: - is using the same licence and wording as rhythmbox OK? If Brasero uses GStreamer plugins directly, then GPL+exception would be good for the the Brasero application. LGPL seems a better choice for libraries that are intended to be used by multiple applications. If you use LGPL, for such libraries an exception is not needed. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Brasero improvements over the 2.26 release cycle
Josselin: Le lundi 12 janvier 2009 à 19:18 +, Bastien Nocera a écrit : - Split Brasero into a library (available on trunk) named libbrasero-media that is being documented (devhelp) and re-arranged so we can deliver a stable API. The library isn't usable in Rhythmbox or sound-juicer, as it conflicts with their license (GPLv2 vs. GPLv2 + exception). Well, they are not incompatible per se, it’s just that the exception cannot apply if rhythmbox/sound-juicer links to this library. Considering how much work has gone into adding this exception to rhythmbox, totem, and songbird; it would be a shame to toss that work out. I don't believe sound-juicer yet has the exception. I believe the upstream community is working on it. http://bugzilla.gnome.org/show_bug.cgi?id=513615 http://live.gnome.org/SoundJuicerRelicense For the record, what is making this exception necessary? I don’t think any non-GPL-compatible GStreamer plugins are required for the normal operation of rb or s-j. No distribution can ship any popular non-free GStreamer codecs if the GStreamer based programs link in any GPL code without the exception. So, with the exception a distro or mobile device OS using GNOME/GStreamer could purchase a MP3 audio license and include that with their GStreamer based-engine. If we link in code which removes that exception, then distros lose this ability. This drives people towards using other operating systems where they can distribute with popular non-free support built in. Considering how important mobile is to the GNOME community these days, and how important it is to play things like mp3 audio files or YouTube videos on mobile devices, I would think this would be pretty important issue and concern. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Brasero improvements over the 2.26 release cycle
Josselin: Le jeudi 15 janvier 2009 à 11:12 -0600, Brian Cameron a écrit : No distribution can ship any popular non-free GStreamer codecs if the GStreamer based programs link in any GPL code without the exception. Well first of all, I find this interpretation of the GPL rather extreme. A GStreamer plugin is a derived work of GStreamer, but it is not a derived work of rhythmbox (unless rb as shipped actually requires it for normal operation, of course). However I understand that people want to be on the safe side and adopt the most conservative interpretation. I am not a lawyer, so I can't really say with any authority; but it seems unclear whether clause 7 of the GPL is in effect if the non-free code in question is a plugin and the application can be used without it. Clause 7 states: For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program. Regardless, the GNOME community has spent a lot of time making sure that the licenses clearly avoid any confusion in this area by adding the GPL license exception. This seems a good thing and something we shouldn't just abandon without careful consideration. So, with the exception a distro or mobile device OS using GNOME/GStreamer could purchase a MP3 audio license and include that with their GStreamer based-engine. They could also purchase a patent license for a free MP3 implementation. It’s not as if there weren’t any such implementations. Right, although things get more complicated if the GPL is involved since it is a violation of the GPL use this license and distribute code which requires royalty fees. Even if, as you suggest, using a plugin framework like GStreamer works around this, it wouldn't solve the problem for other GPL'ed programs like VLC or mplayer that link such non-free code directly into the application. Considering how important mobile is to the GNOME community these days, and how important it is to play things like mp3 audio files or YouTube videos on mobile devices, I would think this would be pretty important issue and concern. I don’t like spreading statements implying the assumption that free software-based h264 or MP3 playback is illegal. This is what Fraunhoffer and the MPEG consortium would like to be true, but please don’t assume they are right. It's not inappropriate as long as the free license being used doesn't disallow such usage. Clause 7 of the GPL makes it (at the very least) complicated to use this license to distribute such non-free code. Note that the GPL restrictions are only concerning distribution. I don't believe there is any problem with a person who owns a media license building their own code to play non-free media. However, such free and non-free code may not be distributable together without violating the terms of the GPL. You are right, though, that we shouldn't assume. Perhaps it would be good to get some authoritative opinion about this, so that we don't waste time bickering, adding license exceptions if they are needless, etc. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 module inclusion discussion heats up
Lennart: However, the benefits of using PulseAudio when using OSS don't seem to be as compelling as when you are using ALSA since OSS has mixing functionalities lacking in ALSA already built in. These are misconceptions. Misconceptions about what ALSA does, and about what PA does. ALSA does have mixing capabilities (it goes by the name of dmix). While dmix might have some drawbacks it is certainly not nearly as crazy as OSS4-style in-kernel mixing. It has been discussed gazillions of times before what PA is and why you'd want to have it or not have it. I am not going to repeat it here once more. But rest assured: PA is not what you apparently think it is. I think the best explanation I have seen you give was on the libcanberra-discuss mailing list (August 22, 2008): It is popular misconception to reduce PA just to something that does mixing. If that was the case, then yes, it would be completely redundant by OSS4 or dmix. One of the primary reasons why I think everyone should adopt PA is the glitch-free playback model, which you might already have read about on Planet GNOME. It's something very technical, and not directly visible to the user, but if you ask me, this is an absolute must-have for a modern PCM audio system -- and OSS4 certainly doesn't give you that. (to make g-f work on OSS will need some substantial hacking from your side however, both in PA itself and probably also in OSS). https://fedoraproject.org/wiki/Features/GlitchFreeAudio Other features PA has, besides nifty effects like positional event sounds, and such like is: network transparency, saves/restores volumes/devices for streams, allows users to switch streams between devices on-the-fly, has an elaborate property system for all sterams/devices (i.e. have a nice icon for each stream that shows up in the per-application volume control), hotplug, rescues streams to different devices on hot-unplug; combining multiple audio devices into a single one; automatic upmixing/downmixing of surround sound; ... Here at Sun we've never been really opposed to integrating PulseAudio. We do, however, tend to avoid integrating new modules unless there is a very clear need or benefit. Probably the most exciting new feature, glitch-free, won't work without significant additional work in OSS which isn't resourced. Some features seem nice, like positional event sounds and better hotplug support, but I am not sure that such features by themselves is worth the bother of integrating and supporting yet another audio library. Whatever this says about the average Solaris user, not a single user has yet requested we add PulseAudio to Solaris for any reason. If some user had ever told us, please add PulseAudio because it would enable some important feature for me, then we probably would have already integrated it. At any rate, since it seems PulseAudio is becoming a more hard dependency of GNOME in general, this well might push us to integrate it. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 module inclusion discussion heats up
Frederic: Note that Solaris does not yet use PulseAudio. On Solaris we are currently using the GStreamer backend for libcanberra, so it is incorrect to say that it is an official approved dependency just by virtue of libcanberra. If it is necessary to integrate PulseAudio for gnome-mixer functionalities to work, then we can consider adding it. However, the benefits of using PulseAudio when using OSS don't seem to be as compelling as when you are using ALSA since OSS has mixing functionalities lacking in ALSA already built in. Brian Frederic Peters says: So it seems to me that we should officially promote pulseaudio as official dep, or readd volume control applet and audio capplet somewhere. It was almost an officially approved dependency already, by virtue of libcanberra, that was accepted for 2.24. I added it, as well as its dependencies (speex and libsndfile) in JHBuild in this revision: http://svn.gnome.org/viewvc/jhbuild?view=revisionrevision=2620 Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gdm-list] GDM trunk will be used for GNOME 2.24.
Peter: Agreed. The solution you suggest is in the works. By solving the problem in gnome-settings-daemon, the solution should work the same way in both the GNOME session and in GDM, so it will be a huge improvement over what existed before (a GDM-only solution which was typically turned off by default, and even when turned on it would leave the user unable to use their session after navigating the login screen without additional manual configuration). Brian Gil - while Brian cites some specific problems with having all assistive technologies running always by default (especially on new or public systems), the basic concept behind your suggestion is very valid. For example, you don't have StickyKeys turned on by default (where a single press of the shift or other modifiers starts out being sticky), but you do have keyboard accessibility support turned on by default and the system sensing that five presses of the shift key in sequence (with nothing else pressed in between) interpreted as a signal to turn StickyKeys on. Gamers who find this interferes with their game play turn this feature off. Similarly SlowKeys sensing is turned on while the feature is off (and a Shift key held for 8 seconds turns SlowKeys on; again something gamers/graphic designers may then turn off for their sessions). Applying that approach to your suggestion, we would have as on by default: - the Assistive Technology support libraries - well known/publicized gesture listeners ready to turn various AT apps on Regards, Peter Korn Accessibility Architect Principal Engineer, Sun Microsystems, Inc. Gil: Just thinking about it ... Wouldn't it be reasonable to enable everything the first time the user logs in and the if no accessible technology has been used ask if they have to be turned off by default (and with a little explain about how to re-enable them)? From a usability standpoint, starting GDM with the magnifier by default would probably make it hard to use for people who don't need to use the magnifier. Also, this sort of solution wouldn't work well in situations where multiple users use the same machine. Some users may need AT programs while other users may not. So, it would be problematic if the first user said No, I don't need them, and messed up the login process for the next user who does. Brian El dl 22 de 09 de 2008 a les 10:31 -0700, en/na Peter Korn va escriure: Brian, all, Do we have a chicken-and-egg situation here? Why do all that is necessary in GDM if we don't yet feel that accessibility on the desktop is sufficiently stable to have it on by default from the GNOME community? (so goes one argument) At the same time, if we aren't quite there yet in login, then we need system administration help to set up the initial login, so we can have system administration help to turn it on at the desktop (and leave that problem unfixed until later). Lather-rinse-repeat. Meanwhile some distros are leapfrogging GNOME the core community that introduced accessibility and made it a core value by enabling users to turn accessibility on with a gesture in their LiveCD, and then the installation process turns it on for that user on the desktop. But this is a hack. And users don't have the experience of full and independent accessibility in GNOME; they rather instead have it (and have it differently) in some distros. We should fix this. And component by component, we shouldn't play a game of chicken, insisting that some other component fix it first. Regards, Peter Korn Accessibility Architect Principal Engineer, Sun Microsystems, Inc. Will: While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. I agree with you that let the user be independent is best. However, I was just highlighting that GDM's a11y has never matured to the point where it was turned on by default (much like the situation with the rest of GNOME not having a11y turned on by default). Therefore, I was just highlighting that the new GDM is pretty much as good as the old GDM in terms of a11y. The main area of regression is that you can not launch a11y on-demand when a11y is turned on. The ability to launch a11y on demand is really only useful if the GNOME desktop also supports this feature (which it currently doesn't). Being able to navigate the login screen independently is not very useful if you still need someone to help you set up your user session. Another use case where the on-demand launching feature is useful is in terminal server situations where many users may be sharing the same server. However, the new GDM doesn't support that anyway, and the release team seems okay with that. So I don't think these a11y issues are a real blocker. This is why the long term goal is to make a11y
Re: [gdm-list] GDM trunk will be used for GNOME 2.24.
Gil: Just thinking about it ... Wouldn't it be reasonable to enable everything the first time the user logs in and the if no accessible technology has been used ask if they have to be turned off by default (and with a little explain about how to re-enable them)? From a usability standpoint, starting GDM with the magnifier by default would probably make it hard to use for people who don't need to use the magnifier. Also, this sort of solution wouldn't work well in situations where multiple users use the same machine. Some users may need AT programs while other users may not. So, it would be problematic if the first user said No, I don't need them, and messed up the login process for the next user who does. Brian El dl 22 de 09 de 2008 a les 10:31 -0700, en/na Peter Korn va escriure: Brian, all, Do we have a chicken-and-egg situation here? Why do all that is necessary in GDM if we don't yet feel that accessibility on the desktop is sufficiently stable to have it on by default from the GNOME community? (so goes one argument) At the same time, if we aren't quite there yet in login, then we need system administration help to set up the initial login, so we can have system administration help to turn it on at the desktop (and leave that problem unfixed until later). Lather-rinse-repeat. Meanwhile some distros are leapfrogging GNOME the core community that introduced accessibility and made it a core value by enabling users to turn accessibility on with a gesture in their LiveCD, and then the installation process turns it on for that user on the desktop. But this is a hack. And users don't have the experience of full and independent accessibility in GNOME; they rather instead have it (and have it differently) in some distros. We should fix this. And component by component, we shouldn't play a game of chicken, insisting that some other component fix it first. Regards, Peter Korn Accessibility Architect Principal Engineer, Sun Microsystems, Inc. Will: While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. I agree with you that let the user be independent is best. However, I was just highlighting that GDM's a11y has never matured to the point where it was turned on by default (much like the situation with the rest of GNOME not having a11y turned on by default). Therefore, I was just highlighting that the new GDM is pretty much as good as the old GDM in terms of a11y. The main area of regression is that you can not launch a11y on-demand when a11y is turned on. The ability to launch a11y on demand is really only useful if the GNOME desktop also supports this feature (which it currently doesn't). Being able to navigate the login screen independently is not very useful if you still need someone to help you set up your user session. Another use case where the on-demand launching feature is useful is in terminal server situations where many users may be sharing the same server. However, the new GDM doesn't support that anyway, and the release team seems okay with that. So I don't think these a11y issues are a real blocker. This is why the long term goal is to make a11y on-demand launching a part of gnome-settings-daemon so it works the same in both GDM and the user session. Then I think we will have gotten to the point where we all have been pushing to get. Brian Vincent Untz wrote: Le lundi 22 septembre 2008, à 09:46 -0400, Matthias Clasen a écrit : On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper [EMAIL PROTECTED] wrote: The release-team is going to use gdm trunk for GNOME 2.24. Note that most release-team members have mixed feelings. Entire discussion would have been less frustrating if gdm developers had been more responsible to the concerns shared in discussions. Maybe just my point of view. Translations of gdm trunk are in a good shape. Distributors: Old gdm is still available in case you hit a regression. I'm surprised by this turn of events, after Vincent decreed that we'd go with 2.20 on Friday... See http://mail.gnome.org/archives/release-team/2008-September/msg00251.html Vincent ___ gdm-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gdm-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ gnome-i18n mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gnome-i18n ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gdm-list] GDM trunk will be used for GNOME 2.24.
Will: While I disagree with Brian's assessment (I think he tends to lean more to the 'it's OK as long as an able-bodied sysadmin can configure the system for the disabled user' side than the 'let the user be independent' side), I'll support the decision nonetheless. I agree with you that let the user be independent is best. However, I was just highlighting that GDM's a11y has never matured to the point where it was turned on by default (much like the situation with the rest of GNOME not having a11y turned on by default). Therefore, I was just highlighting that the new GDM is pretty much as good as the old GDM in terms of a11y. The main area of regression is that you can not launch a11y on-demand when a11y is turned on. The ability to launch a11y on demand is really only useful if the GNOME desktop also supports this feature (which it currently doesn't). Being able to navigate the login screen independently is not very useful if you still need someone to help you set up your user session. Another use case where the on-demand launching feature is useful is in terminal server situations where many users may be sharing the same server. However, the new GDM doesn't support that anyway, and the release team seems okay with that. So I don't think these a11y issues are a real blocker. This is why the long term goal is to make a11y on-demand launching a part of gnome-settings-daemon so it works the same in both GDM and the user session. Then I think we will have gotten to the point where we all have been pushing to get. Brian Vincent Untz wrote: Le lundi 22 septembre 2008, à 09:46 -0400, Matthias Clasen a écrit : On Sun, Sep 21, 2008 at 8:19 PM, Andre Klapper [EMAIL PROTECTED] wrote: The release-team is going to use gdm trunk for GNOME 2.24. Note that most release-team members have mixed feelings. Entire discussion would have been less frustrating if gdm developers had been more responsible to the concerns shared in discussions. Maybe just my point of view. Translations of gdm trunk are in a good shape. Distributors: Old gdm is still available in case you hit a regression. I'm surprised by this turn of events, after Vincent decreed that we'd go with 2.20 on Friday... See http://mail.gnome.org/archives/release-team/2008-September/msg00251.html Vincent ___ gdm-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gdm-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Note that the Windows solution to use Ctrl+Alt+Del as a Secure Attention Key is just one way to implement Trusted Path. There is no reason that the GNOME or UNIX community couldn't come up with a different and novel way to meet the same requirements. The Secure Attention Key should be viewed as just an example of how Trusted Path requirements can be solved and the solution as used by Windows (along with Kerberos). Debating about whether we should use the same sort of solution, or a different solution makes for good discussion, but I don't think it makes sense to suggest that just because this particular solution has usability issues means that Trusted Path requirements are somehow invalid or inappropriate for UNIX environments. Even though some might suggest that security is good enough on Linux without meeting these requirements, it still is a good idea to consider how to make GNOME and UNIX more secure. Whatever solution might be decided upon will likely require enough infrastructure enhancements that we will have time to be thoughtful about the best way to provide the feature. Brian But I'm no security expert; I might be missing something. I believe the goal is to use some uncatchable keyboard sequence a'la Windows' secure auth (Ctrl+Alt+Del). This works on Windows (on a domain) because the goal in those situations is to have perfect and total single sign on. This has been watered down in more recent (less coherent) Windows releases, but the goal was always to prompt the user once and never prompt them again for any application because the system uses kerberos. In our mix of applications and protocols passwords abound, and it's less likely that a Ctrl-Alt-Del style solution would be sufficiently usable. Cheers, Stef Walter ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM version used for GNOME 2.24?
Willie: I'm not sure this is a really important regression. You can configure the new GDM to always launch various AT programs as needed. The main lost feature is that users cannot launch AT programs on demand. I'm curious who the you is you can configure. The important thing here is independence. People with disabilities need to be able to do as much as possible without the need for assistance. Since GDM has never had a11y turned on by default, a person with disabilities would likely need help to set up either the old or new GDM to work for them. Or, if a person could boot up into console mode with a11y enabled, then the person could probably set up the configuration themselves. The long-term goal is to make GDM and GNOME in general work better for independent usage, but we're not there yet. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM version used for GNOME 2.24?
Kjartan/Willie: fr., 19.09.2008 kl. 00.34 +0200, skrev Vincent Untz: Le mercredi 17 septembre 2008, à 17:23 -0400, Willie Walker a écrit : Well...hmm...if I read the answers correctly, I think what I'm hearing is that there are a lot of great ideas, but they aren't done yet. If this is the case, then I think this sounds like a regression. I see nobody jumping in to say it's not a regression. So, we're going with GDM 2.20, I guess... Is there any objection? I see people saying it's a regression, but what does it mean in practise? Is a11y busted? Is it a minor inconvenience affecting only login? Can someone please post a list of pros and cons for this specific issue wrt 2.22 vs 2.24? I'm not sure this is a really important regression. You can configure the new GDM to always launch various AT programs as needed. The main lost feature is that users cannot launch AT programs on demand. This feature is mostly useful in multi-user terminal situations (e.g. terminal servers), which aren't supported in the new GDM anyway. This feature is also useful in situations where multiple users may share the same computer, but some users don't want AT programs to launch and others do. The old GDM 2.20 doesn't turn on a11y by default anyway, so users with a11y needs need to configure GDM before using it. So the new GDM isn't much worse. I don't think this particular issue should be a blocker. The more serious issue is that the new GDM doesn't support managing multiple displays. But it seems the release team is agreeable to accepting this as a regression. At any rate, I'll leave this up to the release team to decide if the new GDM is ready or not. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prompting for passwords on the desktop?
Stef: Is there a standard way or goal for the UI and behavior of password prompts on the desktop? Besides having as few as possible, that is. There is Trusted Path to consider. To meet Trusted Path requirements, any entry of the root password needs to be done via a trusted user. This means that the dialog would need to run as a special trusted user, and not as the user whose session is running. Much like the GDM GUI programs are run by the special gdm user. Otherwise, someone who has gained a user privilege could possibly snoop process memory space to get the root password. Also if the dialog is running as the user and core dumps (or can be induced to core dump), then the password may be left behind in the core file readable by the user. Also the dialog would need to run with a separate Xauth connection to the Xserver to protect against snooping via X interfaces. However, to resolve this problem would require a fairly significant amount of infrastructure that does not exist today. Most people feel that the existing security is good enough, but sysadmins with strict Trusted Path requirements would likely have to disable programs from asking for root passwords in dialogs via programs like gnome-keyring, PolicyKit, or gksu. gnome-screensaver has similar Trusted Path issues. I understand Jon McCann is planning to fix this by making the screen lock program show up in a separate Xserver running as a trusted user. This would work via a mechanism similar to VT switching. Once that is done, perhaps that could be extended so programs like gnome-keyring or gksu could use a similar interface for added security and for meeting Trusted Path requirements. That would also resolve a lot of the grabbing and focus issues that plague programs asking for sensitive root passwords in a user session. So this information is probably not useful in the short term, but something to be aware of. A long-term goal should be to address these issues so that root password entry is handled in a more secure fashion in the future. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gdm-list] GDM version used for GNOME 2.24?
Ray: I think Jon is in Portland right now for the Plumbers conference, so I'll try to answer for him. I believe Brian wrote some code to port the dwell listeners over to the new GDM some time ago. It's not completely finished, but it's most of the way there. Note there are two gesture listeners, a dwell listener and a key/mousebutton listener. It is probably better to refer to them as gesture listeners since dwell is just one type of gesture. Yes, I did some work to port the old code to the new framework. I got it mostly working. We could, of course, consider using that code in GDM as a temporary solution until something better comes along. On the other hand, Jon wants it to be done from gnome-settings-daemon instead of from GDM. One of the big rationales for Jon's recent desktop a11y work was so that a user can come up to a system in an unknown state (logged in or logged out) and take a known set of actions to make that system accessible to that user. Doing the work in gnome-settings-daemon is a better choice. This would make the same gestures work in both GDM and the user's actual GNOME session. Having a common framework for starting AT programs would be a big step forward. I agree with Jon on this. However, note that the dwell gesture mechanism will need to be completely reworked. The GDM dwell mechanism works by moving the mouse in and out of the GDM login window. This works reasonably well when there is only one window on the screen which is always displayed, as when GDM is running. However, it probably is not a good solution for the user's session where these assumptions are not true. A different mechanism that instead relies on a mouse gesture that relates to the position on the screen (such as moving the mouse to a combination of corners on the screen), or wiggling the scroll wheel in a certain way would probably make more sense for making dwell work in both GDM and the GNOME session. Since GNOME already has some keybinding support, it might make sense to reuse that code rather than write a new plugin. That might be a bit of work, though, since AT-style gestures are a bit different than your normal keybinding: - AT key gestures are often things like press a key (like Shift) five times in a certain timeout or press a key and hold it down for a certain long time. - AT button gestures are often things like hold the left mouse button down for 3 seconds, and then do this 3 times in a row in a certain timeout or hold the right mouse button down for 10 seconds. The goal is that some users have trouble hitting certain key or mouse button combinations, so there is often a desire to make the gestures work in a way that instead of holding down multiple keys/buttons at the same time, you instead hit a single key in a repeated fashion. Obviously the existing keybinding support does not support these types of gestures. Not sure if it makes more sense to extend the existing keybinding code or make a new g-s-d plugin. Another possible issue is that the two existing gesture listeners use a custom flat file format for configuring the gestures. I have a suspicion that Jon would likely also want this to be reworked to use something more standard and/or modern. At the very least, the configuration files should probably be moved out of the /etc/gdm directory and put somewhere else. So to answer the question to the best of my ability (and Jon or Brian would be better to answer), 1) there is some inprogress code that Brian Cameron wrote 2) that code targeted GDM when it was written, isn't slated for GDM now, and instead needs to get reworked to go into gnome-settings-daemon I am not very familiar with g-s-d. I would be happy to help port the code, but I would need some help, someone to explain how to go about making them g-s-d plugins. Also, if we are going to go to the bother of reworking the code, we probably need to rethink some of the issues I discuss above. The old GDM gesture code could be used for inspiration, of course, but I don't think it is just an easy matter of porting the code. As I say above, the dwell listener would need to be reworked to be useful in the user session. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Suggestions for a software engineering class project?
Marshall: I would recommend looking into GNOME accessibility. I would think it might be especially rewarding to work on a project that is geared towards a humanitarian effort, such as helping people with disabilities use technology. There are some suggestions of tasks that need attention on the website. http://live.gnome.org/Accessibility/GetInvolved Also the gnome-accessibility-list would be a good place to discuss further if you want additional suggestions that best fit your program. http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list Brian Hello everybody, I am an undergraduate computer science student at The University of Wisconsin Oshkosh. My software engineering class is looking for an open source project we can work on as a semester project. This software development project will need to be something that a team of ~4 students, working ~10 hours a week, can accomplish in ~2 months. The project can include developing a new application or adding substantial functionality to an existing open source application/project. Ideally programming will be done with some kind of modern-ish language (C#, Python, Vala) but any programming language would be fine. Does anybody have any suggestions for a project (GNOME or otherwise) that we could work on? Thank you in advance for any suggestions/advice. Marshall Scorcio scorcm43 at uwosh dot edu ___ 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: GDM version used for GNOME 2.24?
Vincent: I don't see us ignoring a good bunch of the comments (there are good points on each side), so there are two ways to go forward: + use GDM 2.24, and mention that it is not ready for all uses (listing the use cases where it needs work would help), and that GDM 2.20 is still available and working. + stay with GDM 2.20, and mention that we have a new GDM coming soon. We kind of did solution b for 2.22, but it turned out not a lot of people stepped up to fix the remaining issues in the new GDM. I don't think this is true. A lot of issues hav ebeen addressed in the 2.24 timeframe. GDM 2.24 will have considerably less regressions than GDM had. I think that the issue is that re-implementing some of the regressions is just time-consuming. Plus some of the people working on GDM have also been focused on adding new functionalities (such as features available via the new GDM panel like power management and keyboard switching functionalities) rather than addressing the identified regressions. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-volume-manager disables automount
Jerry: Note that gnome-volume-manager on Solaris is a bit old. I know the team at Sun responsible for integrating HAL plans to update to the latest gnome-volume-manager code when they update to the latest HAL code. You might want to work with them to find out if the below issue is caused by the fact that we aren't using the latest and greatest gnome-volume-manager/HAL code. Brian gnome-volume-manager disables automount by default. The reason is that Nautilus handles it, as it said in configure.ac. But after a rough investigation, nautilus don't handle automount. So I'm a little confused here. Thanks, Jerry ___ 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: New svn module: gnome-sound-theme
Luca: We should update our spec so that FLAC is the recommended uncompressed format. It is superior from a technology standpoint, saves disk space, and comes from the free software community (WAV was written by IBM and Microsoft and is based on the older IFF format from Commodore-Amiga). We should work harder to replace the legacy WAV format with newer, more exciting technologies that are available from the free software community. The mandatory supported sound file formats are WAV/PCM 8-48kHz, 8/16bits, and OGG/Vorbis. WAV at 48kHz/Stereo is the recommended uncompressed format, and OGG/Vorbis is the recommended compressed format. The sample must be normalized, in order to be mixed down nicely with a suitable average replay level. You should probably define what you mean by normalized. My understanding of what normalized means is that you ensure that the maximum volume is at a particular level. However, this says nothing about the average volume level, since a relatively low-volume clip can have a single moment with an unusually high volume, and therefore not be adjusted much by normalization. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libcanberra as an external dependency
Joe: I think libcanberra must have an esd output plug-in at the very least (i.e. if not also OSS and Sun Audio) in order to be a viable external dependency. This would go a long way to helping non-Linux platforms achieve working sound theme support using all blessed GNOME dependencies. Sun plans to write a Sun Audio backend, though we probably won't have time to get this done for our GNOME 2.24 release. Sound that requires libcanberra probably will be broken until we get that addressed. Overall, we at Sun are excited to use the new framework and get away from using ESD. It would be nice if libcanberra supported an esd backend for stability. This way things still work reasonably while people are transitioning. Since ESD has the blessing of a GNOME Platform interface, it seems we should be a little careful about backwards compatibility support. I don't think providing such backwards compatibility will slow the killing of ESD. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: enable accessibility by default for GNOME
Mathias: Ok, I agree, that it is ridiculous that currently accessibility has to be activated manually. Agreed. What makes me wonder: Can't we improve our to enable those features on demand? As far as I understand the accessibility tool chain it consists of those components: In GDM 2.20 and earlier, it supported the ability to define keypress (hotkey), mouse-button-press, and dwell gestures (implemented by moving the mouse in-and-out of the login screen in various patterns). These gestures were used to launch AT programs on demand as needed by users. With the new GDM rewrite, these features were dropped. Now that GDM uses gnome-settings-daemon, it was suggested that the best way for this to work would be to implement such on-demand AT launching features in gnome-settings-daemon in a way that it would work for both the login screen and the user session. Presumably you could also use a similar (or the same) mechanism when installing. This way the same mechanisms work in all places. It was discussed that there probably needs to be 3 types of programs that can be started via this mechanism: - an On-screen keyboard (would be nice to support both dwell-type and single-button type users separately) - a magnifier - text-to-speech and braille support Most likely these features would be launched in a lowest-common-denominator fashion so that it would work for the most users. The idea being that users would then navigate to the preferences to best configure how they want a particular AT program to work. This would obviously be a one-time event for the user session. It is probably also necessary to support hotkey, button-press, and dwell gestures for launching the three types of programs to support the widest range of users with accessibility needs. However, the dwell method implemented in GDM (moving the mouse in-and-out of the login window) probably doesn't make as much sense when running in a user session. However, there are other dwell type gestures that could be implemented that would be more generally useful (such as moving the mouse to points in the screen in some pattern or something). To me, this seems the best approach. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Problem with intltool 0.40.0?
Yesterday I discovered that make dist/distcheck in gdm 2.20 branch failed because make couldn't find intltool-merge.in, intltool-extract.in, and intltool-update.in. These files get generated by the intltool module. I was able to fix this problem by rebuilding my intltool module with the older 0.37.1 version (which was what I was using before I encountered this problem). The intltool documentation (e.g. intltoolize manpage) seems to imply that you need to add these intltool-*.in files to EXTRA_DIST in your top-level Makefile.am. Are we supposed to update our top-level Makefile.am files to be compatible with the latest intltool? Apologies if this has been addressed already, and I missed some post telling me I was supposed to do something. If we are no longer supposed to set EXTRA_DIST, then the documentation should be updated to reflect this, I guess. Or is this just a bug in intltool 0.40.0 that the files don't get created anymore? Thanks, Brian I've posted new tarballs to http://dlc.sun.com/osol/jds/downloads/cbe/test/ All bugs you guys reported are supposed to be fixed, also cmake updated to 2.6.0. Laca On Fri, 2008-06-20 at 18:24 +1200, Laszlo (Laca) Peter wrote: If you used the JDS CBE and/or the KBE (KDE build env) before, here's the big news: they have been merged to form the Desktop CBE. Test tarballs are now available here: http://dlc.sun.com/osol/jds/downloads/cbe/test/ The most important changes: - a lot more tools included - supports Solaris 10, Nevada, OpenSolaris - only the tools that are not integrated in the OS are installed - all tools updated to more recent versions, including pkgbuild (1.3.0) - interactive and hands-free installation - improved env.sh script now supports: - multiple compilers - subshell mode Note: the Desktop CBE is installed in /opt/dtbld. Please send feedback to Lukas, myself or desktop-discuss. Remember that this is a test release, it is entirely possible that it will wipe your hard drive, shred your dvd collection or transfer your savings to offshore bank accounts so use at your own risk. Thanks, Lukas and Laca ___ desktop-discuss mailing list [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Problem with intltool 0.40.0?
David: So what does this mean? Should all GNOME modules fix their top-level Makefile.am files, manpages, and other docs that refer to the need to add these generated files to EXTRA_DIST? Or do we just not work with the latest intltool 0.40.0 for now until this issue gets fixed in intltool? Should this change be coordinated? I assume that once this change happens that we won't support building on systems with older intltool. Kind of a drag. Brian On Tue, 2008-07-01 at 11:31 -0500, Brian Cameron wrote: Yesterday I discovered that make dist/distcheck in gdm 2.20 branch failed because make couldn't find intltool-merge.in, intltool-extract.in, and intltool-update.in. These files get generated by the intltool module. Apparently what you are experiencing is a bug fix http://bugzilla.gnome.org/show_bug.cgi?id=490620 Personally I think the new behavior is bug. And further I think it's silly. Because now every user of intltool get to fix his module and distributions get to add something like BuildRequire: intltool to their spec files or similar. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session proposal
William Jon McCann wrote: Hi, Dan Winship and Lucas Rocha have done a nice job revamping the gnome-session codebase. It was a meritorious task. You can read about the design here: http://live.gnome.org/SessionManagement/NewGnomeSession The new code is much cleaner. Parts of the new design are very good. In particular, using autostart as the database of registered/automatically started applications, allowing use of a gconf key to turn programs on and off, and starting up the desktop in phases all make a lot of sense. I don't have a problem with coming up with a better design, but it should work with any configuration setup users may already have setup. The current GNOME System Administration Guide recommends to people that they use the old default.session interface for starting programs. Will this interface be supported for backwards compatibility, or will there be some automatic migration of any existing programs to the new system? http://library.gnome.org/admin/system-admin-guide/stable/sessions-3.html.en Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Need Leadership
Jason: We need to tap in to the wave of energy generated by the The Thread on Planet Gnome. Already, it's apparent that the fervor that surrounded it has started to dwindle. A ton of interesting ideas were thrown out and lot of belly-aching about no one taking responsibility for making it happen was heard. That is not quite true. There is a lot going on to make the GNOME Developer Platform more rich and stable, making GNOME a richer development platform for third-party ISV's. As GNOME slowly develops more and more interest from third-party ISV's (such as Adobe and Real) the platform becomes more usable to a wider audience. Some examples currently underway include gail merging into GTK+, accessibility moving away from ORBit2 and towards D-Bus, gvfs replacing gnome-vfs, and so on. This is in relation to Project Ridley [1]. So, there is a lot of digging in the trenches to prepare GNOME for taking things to the next level, I think. It's clear from The Thread that we need to Get Our House In Order. There's nearly universal agreement that Gnome lacks leadership in the sense that there's someone that sets release goals. In my opinion, whatever The Next-Gen Gnome is, it isn't going to happen until we really, really have a deep maintenance cycle going on here. That means fixing a Handful of Giant Warts on our maintenance process: In addition to having a richer developer platform, it is probably necessary for GNOME to get some sort of a face-lift in order to warrant next generation attention. This probably would require some addition of needed functionality, and some theming/visual elements. Compiz, Clutter, and/or pigment could be a part of this. Work seems to be fairly active in these areas. 1. DVCS needs to happen; now. It's time. The number of people using a DVCS frontend to circumvent the insanity of SVN continues to grow. In that vein, we need to a) debate the One True DVCS for Gnome, b) delinate the work that needs to be done to get there and set a timeframe, and c) find the man power to do it. This would have little impact on end-users, I think. 2. The Giant Rift in the Gnome community over Mono has to end. I hate Mono as much as the next guy but it's quite apparent now that some really cool stuff with financial backing from Big Linux Distributor is not going away: Gnome Main Menu, Banshee, F-Spot, Beagle, Tomboy, etc. We have to get rid of the rift and bring the two diverging communities back together. Whatever damage that might incur in the minds of the Slashdot crowd has already been done--Gnome is perceived (rightly or wrongly) to be largley 'infested with Mono' in the minds of our critics. We cannot capitulate on this to appease a vocal minority of users that detest Mono. It's obvious it's not going away and, with a trivial amount of work, we can mend the rift by including the afore-mentioned mondules in our official releases. Let's just do it and move on with our lives. Solaris doesn't distribute with Mono, but I wouldn't say anybody at Sun detests Mono. Mono is great! Aside from causing some distros to have slightly different applications (e.g. Beagle versus MetaTracker), I do not think whether Mono is used on a given distro causes end-users much grief. In some ways, I think the fact that distros differentiate themselves a bit is probably a good thing. It gives people some choices to consider when they pick a distro. 3. Marketing to developers must get ramped up; we agree that we need a new generation of awesome developers to bring new ideas and blood in to our process. A number of our Gnome modules are in barely maintained mode. With new blood, we can reinvigorate 2.x while looking to the future. And I've volunteer for this one in the form of 15 minute screen casts. However, it needs web hosting space. And that needs Gnome resources. What do we have to do to make this hosting happen? What else can we do to get more developers? The GNOME project has a marketing-list, and you are right that there does not seem to be enough volunteers or energy to do a lot of exciting things. If you, or anybody has an interest, I'd get involved. I think its good to discuss what sort of features we should consider in taking GNOME to the next generation, so I appreciate your suggestions. Brian [1] http://live.gnome.org/ProjectRidley ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: off topic; HELP! I cannot create a terminal window in gnome.
Ralph: If you have a configuration problem that affects one user and not other users, the problem is likely a configuration option stored in your $HOME/.gconf directory. Note that gnome-terminal configuration settings are in the directory $HOME/.gconf/apps/gnome-terminal If you make sure that the gconfd daemon is not running and delete this directory, then gnome-terminal should go back to its default configuration. Note that it is not good to try and modify the GConf database when gconfd is running because it will, in some cases, rewrite keys it thinks are missing when it does exit, and undo your change. For example, a good way to do this is to login into a Failsafe session from the login screen to delete the $HOME/.gconf directory without worrying about such issues. You can also run the gnome-cleanup program. This deletes all your user configuration and returns your user to a default state. In other words, it basically does the same thing I described above, but deletes configuration for all GNOME programs, not just gnome-terminal. You can refer to the gnome-cleanup man page for more information. Hopefully this helps if Zoran's suggestion isn't the right fix. Brian I assume the answer to your question might be of some use to less experienced GNOME users / new developers as well, so I am CCing it to the list. Most likely you have set the custom command to something that returns immediately and forgot to set the option to keep the terminal window open when the command exits. Unless I am grossly mistaken, you can try the following command: $ gconftool-2 --set /apps/gnome-terminal/profiles/Default/use_custom_command --type=bool false to reset your setting on that key. Of course, in your current predicament, you would either switch to a text console using Ctrl-Alt-F1 (getting back to X via Alt-F7), or else hit Alt-F2 and paste the command there. It may help, but the main issue is about where gnome-terminal keeps its preferences. Those are stored (as are many other applications' preferences) in GConf tree, which is akin to Windows registry: a central repository for small bits of data that together make up your desktop configuration. Given your inclination towards poking around I am reluctant to tell you about GConf editing tool, but I guess you can not be stopped either way ;) so might as well let you in on it sooner rather than later: gconf-editor is its name. If the above command does not solve your issue with the terminal, launch gconf-editor (either via menus or Alt-F2), navigate to /apps/gnome-terminal/profiles/Default and play around with the switches. All changes take place immediately so do be careful. GConf is an integral part of GNOME. All desktop developers must at least be aware of its existence. :) Cheers, Zoran On Sun, 2008-05-25 at 20:26 -0600, Ralph Boland wrote: Sorry for not being a development issue unless you consider modifying gnome so those stupid enough to do what I have done can't do it anymore. What I did was experiment with terminal window profiles to learn how useful they were. I somehow set up my only terminal window profile to close immediately upon opening. Thus I cannot open any terminal windows. Since I use them all the time this is a major pain. For now I just created a new user for myself (on ubuntu) but this is not acceptable. This has happened on my work machine so I need my original name back. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org mailto:desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
Colin: Yes, I think Jason was being unfair; as far as I know RBAC predates PolicyKit, and obviously Solaris can't just drop it in the near future. However - I do think it makes sense for a technology like this to be integrated into the desktop. Oh, I agree. I very much support PolicyKit and I agree that it should be an official GNOME dependency. I am just not sure it should be mandatory, though perhaps I was reading too much into that word. Obviously Sun does not mind if PolicyKit is a hard dependency of modules that we do not intend to ship, such as GNOME System Tools, package management tools, etc. In fact, I very much support PolicyKit. Jim Li and I have worked together to make a Solaris PolicyKit spec-file available so we can evaluate it and so users can download and build it if they want to use it, and help get it working. It's available via the Solaris spec-files-extra repository. For example, with PolicyKit the developers were able to create a nice user experience for changing the system time directly from the clock applet. If Solaris goes with Visual Panels, it would be good to at least consider how you approach that level of integration - maybe it's as low-tech as exec'ing visual-panel --show-control=system-time, but this way we at least cooperate on where the hooks for the desktop/system integration are. The Sun GNOME and PolicyKit teams are working together to make sure that Visual Panels is well integrated into our desktop. However, I know the Visual Panels team is working hard just to get the functionality right. So it might take some time to get all the polish together. If the story is simply that they're patched away and you have to go to some special Administration menu, the user experience is worse, in addition to being farther away from upstream code-wise. Good point, and thanks for the pointers. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
I would like to propose PolicyKit[1] as an external dep for 2.26 - it's mostly API stable[2], and is now being used as an optional dep in many modules in gnome svn and HAL. I would like to depend on it for gnome-power-manager, and I hate all the #ifdefs. Does anybody have any problems with PolicyKit being an external dependency in 2.26? At Sun we do not yet support PolicyKit, and it is not clear whether Sun will support it in the future. Instead Solaris supports RBAC and there is debate whether it makes sense to support two similar frameworks for doing the same sort of thing. Including PolicyKit is still under evaluation, and no decisions have been made, but I expect it will be a while before there more visibility. Getting the buy-in of the security team at Sun will likely be a long process. Efforts are underway to support RBAC as a PolicyKit backend. As this matures, obviously, the possibility that Sun might integrate PolicyKit increases, but still too early to tell. At any rate, I anticipate that at Sun we will continue to need #ifdef's to disable PolicyKit functionality for the foreseeable future, at least in those modules shipped on Solaris. So far, this is not a big issue since Sun does not ship most programs which use PolicyKit. I do not think it is a problem for PolicyKit to be an external dependency for GNOME. However, there will probably be people at Sun working to #ifdef out PolicyKit code in the modules that tend to get shipped with Solaris. From Sun's perspective, I think it would be best if PolicyKit were considered more of an optional dependency. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dep: PolicyKit
Jason: If Sun wants to do something completely different from what the rest of the community is doing, it seems like the responsibility for bearing the consequences of that course of action should lay squarely on the shoulders of Sun's engineering teams. Understood. I was not really trying to suggest otherwise, I just wanted to inform people of how decisions relating to PolicyKit will impact Sun. That said, I would hope that the community would take this into some consideration when making decisions. I also was not trying to suggest that Sun would never consider integrating PolicyKit. Of course, we might at some future point, but it probably will not be in the near term. At the moment, it does not seem there is a real need. As I said in my previous email, there are not really very many GNOME modules that Sun ships which use PolicyKit. Mainly because Sun seems to be moving away from using GNOME system tools and will likely move towards using our in-house developed Java-based Visual Panels [1] instead. There do not seem to be many other GNOME programs that require special authentications via PolicyKit. So it is not yet clear how important it will be to support PolicyKit on Solaris. Since there appears to be a clear way forward for you to write some layer of compatibility with your different way, I don't understand why we should hold back on mandatory dependencies. One difficulty with supporting RBAC via PolicyKit compatibility layer is that it complicates configuring the system. This is not desirable especially when relating to security. A compatibility layer requires that sysadmins need to configure both RBAC and PolicyKit separately to make the two work together. Also, determining RBAC - PolicyKit mappings has not been very straightforward. With work, we can probably simplify and resolve these issues, but it is probably overstating things to describe this as a clear way forward. Considering that PolicyKit is just one mechanism to support authentication management, I guess I do not really understand the need to make PolicyKit mandatory. Since GNOME is free software, I would think that if Sun, or anybody, wants to add support for alternative systems, such as RBAC, that this would, at least, be considered. If PolicyKitusage starts creeping into core GNOME modules, then Sun will need to either modify the code to work without PolicyKit, or perhaps integrating PolicyKit will become more of a priority. It is too early to tell, I think. Brian [1] http://blogs.sun.com/dep/entry/visual_panels_in_opensolaris_2008 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Disabling building of gnome-cd and cddb-slave in gnome-media. Any objections?
On Solaris, we haven't shipped gnome-cd for several years, since we ship sound-juicer and rhythmbox which, as you say, work much better. We currently disable the building of gnome-cd from gnome-media. Brian We would like to disable building of gnome-cd and cddb-slave by default in the gnome-media package, because there are much better alternatives such as sound juicer and rhythmbox. Furthermore gnome-cd and cddb-slave use the deprecated libgnome libraries. So it also helps with the goal of not using these deprecated libraries anymore. Does anybody have objections against disabling gnome-cd and cddb-slave by default? On Archlinux we disable gnome-cd in our package since the 2.20.0 release. I haven't had a single request from our users to add it back, so our 2.22.0 build has it disabled also. ___ 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: communication/information between forward-looking projects [was Re: Some info (Ref: GSOC 2008 advice)]
Dave/Behdad: Dave Neary wrote: Behdad Esfahbod wrote: On Mon, 2008-03-03 at 16:14 +0100, Dave Neary wrote: The first step in releasing GNOME 3.0 is to dissociate the in-built assumption will break everything from the version jump. Sure, we can go from GNOME 2.22 this cycle straight to GNOME 24 the next one. What does *that* buy us? That is, there needs to be reason for breaking the current practice, not the other way. Quoting myself: Many users think major version bump is synonymous with significant new features. Many is a fuzzy word. How many is many? Whether a user would find a GNOME 2.24 renamed to GNOME 3.0 release exciting would probably depends on what version the user was previously using. If they were using 2.6 (or something similarly old), they might feel the wealth of new features warrants the major release bump. Users coming from GNOME 2.22 might not feel the same. If you agree with that (you're free not to), then it's not a huge leap to negate that statement: Many users think minor version bump is synonymous with no significant new features. And that gives you a good reason to periodically increment the major version number. There are other ways to fix a problem of perception than to do a 3.0 release. Perhaps we could make people more aware that the GNOME team does a great job of keeping the platform interfaces stable, and we do this without sacrificing new and exciting features. There is value in keeping interfaces stable, and we could perhaps better market this fact. I am not opposed to doing a 3.0 release, mind you. I just think that a 3.0 release should involve more coordination than just deciding to rename GNOME 2.24 to 3.0. In my opinion, a 3.0 release should make some effort to take GNOME to the next level. It should not be done because a major release hasn't happened in a long time, and the KDE team did one. For example, shouldn't we do things like review the HIG and make sure that long-standing issues get resolution, make some effort to coordinate a 3.0 release with a new Project Ridley based development platform that is lighter and more powerful. Might it make sense to wait until GNOME and KDE are using common D-Bus based interfaces for accessibility? We should coordinate our 3.0 efforts so that we have some substance to back it up. There seem to be things in the pipeline that would warrant a 3.0 release in the non-too-distant future. Why not just hold off until then? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Where to put X-GNOME-Bugzilla-ExtraInfoScript?
Jaap: Make that $(libexecdir) in the Makefile, and Debian will be happy as well as the rest of us ;) I'd like to make you and the rest happy but as somebody who just copies Makefiles and configure scripts of other projects I'm afraid I need a bit more explanation $(libexecdir) is a smarter place to put scripts/programs that are not intended for the end-user to run. In other words, this is a good place to put programs that are normally run by other programs. Note when you run configure you can specify --libexecdir to specify where such programs should be installed. Some distros choose to install libexecdir stuff to /usr/lib, which can be accomplished by running configure with --libexecdir=/usr/lib. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.22
Vincent/Others: + swfdec-gnome (desktop) = accept if it moves to the GNOME infrastructure = swfdec becomes a new external dependency Section 3a seems of the Adobe SWF and FLV File Format Specification License Agreement seems to be pretty clear that the specification does not allow additional client programs, players, etc. to use the format. Even if this has been implemented by reverse-engineering or clean-room techniques, then this may require some legal review to ensure that this was done appropriately to avoid legal issue down the road for GNOME. Has this been done? Are we really comfortable adding something into the official GNOME project that has known legal/licensing issues? --- http://www.adobe.com/licensing/developer/fileformat/license/ For reference, Section 3a says: 3. Restrictions a. You may not use the Specification in any way to create or develop a runtime, client, player, executable or other program that reads or renders SWF files. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Releasing libgweather standalone
Federico : Yeah, it would be nice to move the pick a location widgets into libgweather... as well as a more general / global what's my location, and what locations do I care about? mechanism. Evolution will also want to use this. I would think that pick a location widgetry would be of general use, not just to libgweather, but to other programs as well. Perhaps it makes sense to move it into some common library rather than a library specificly for weather. Having said that I'm not sure what common library makes the most sense. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing dependencies for gnome-games
Josef: gnome-games has for some time offered online gaming capabilities on top of the GGZ Gaming Zone platform. Three games are already working fine, a fourth one is currently being ported. As an upstream author of GGZ I'm very pleased to see this. However, gnome-games includes internal copies of all GGZ libraries in its SVN, with the justification of wanting to have GGZ support even if the distro in question doesn't have GGZ packages yet. Recently, a member of the Debian security team got very upset about this as this requires patching more packages. I share these concerns, especially since there are no major distros left that do not include recent GGZ packages. Sorry for the late response, but not quite true. Solaris is a major distro that doesn't include GGZ packages. Solaris has never included GGZ. Perhaps in the future we will include GGZ, but I am not aware of any specific plans to add it in the short-term. If gnome-games starts to depend on it, then we will need to consider adding it. Not sure how long that will take. I was pointed out that in order to let gnome-games' configure script fail when no external GGZ libraries are found, I would need to propose those libraries as external dependencies on this list. Why is it necessary for gnome-games configure to fail if GGZ is not found? If configure doesn't find GGZ, why not just disable building whatever games have hard dependencies on GGZ? Or do all the games now depend on GGZ? Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM login to a JHBuild session
Owen: The GDM/KDM standard for using /usr/share/xsessions/*.desktop files is documented in the GDM documentation here: http://www.gnome.org/projects/gdm/docs/2.20/configuration.html We can extend the .desktop file further if this makes it possible to do useful things. However, if we are going to ask all distros to change the way they start dbus-launch to support DISABLE_DBUS_LAUNCH, then perhaps we should rethink how we start D-Bus. Perhaps starting this at Xsession time isn't the right place? Perhaps we should always start dbus-launch in the /usr/share/xsession/*.desktop files as needed? Or perhaps it should be managed more directly by gnome-session itself rather than needing the login program/process to be aware of D-Bus? Brian I'm currently working on establishing a standard jhbuild configuration for the online-desktop. One of the things I'd like to accomplish with that is the ability to log directly into a jhbuild of GNOME from GDM. My first attempt was to create an entry in /etc/X11/sessions like: === [Desktop Entry] Encoding=UTF-8 Name=JHBuild Comment=Custom Per-User Build Exec=/usr/local/bin/jhbuild-session Icon= Type=Application === Where /usr/local/bin/jhbuild-session looked like: === if [ -x $HOME/bin/jhbuild ] ; then exec $HOME/bin/jhbuild/run dbus-launch gnome-session fi # Report error === But this doesn't really work because the system Xsession script has already launched D-BUS using the system built copy and system session configuration. So the .services files in $prefix/share/dbus-1/services won't be found. The relevant portions of the system Xsession script on Fedora looks like: # GDM provies either a command line as the first argument or # provides 'failsafe', 'default' or 'custom'. KDM will do the # same at some point if [ $1 != default -a $1 != custom ]; then exec -l $SHELL -c $SSH_AGENT $DBUS_LAUNCH $1 fi I assume that other distributions do something similar. So, the question is: how should a session .desktop file disable the running of DBUS_LAUNCH in the system session initialization? My proposal would be to extend the session .desktop file (is this a standard defined somewhere? It appears to be shared with kdm in some fashion) to allow setting environment variables. So, we'd add a line: X-GNOME-Environment: DISABLE_DBUS_LAUNCH=true; [...] Then we could push patches to distributes that would check that environment variable before invoking the session inside D-BUS. Any better ideas? - Owen ___ 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: GDM login to a JHBuild session
Owen: We can extend the .desktop file further if this makes it possible to do useful things. However, if we are going to ask all distros to change the way they start dbus-launch to support DISABLE_DBUS_LAUNCH, then perhaps we should rethink how we start D-Bus. Perhaps starting this at Xsession time isn't the right place? Perhaps we should always start dbus-launch in the /usr/share/xsession/*.desktop files as needed? Or perhaps it should be managed more directly by gnome-session itself rather than needing the login program/process to be aware of D-Bus? While there are certainly other ways of doing it, having dbus-launch be the parent process of the session, ssh-agent style, is a robust way of doing things, and I don't see a big argument for changing that and forcing everybody to adapt (especially since the dbus for the session makes sense in simplified contexts where they may not be a chunk of code like gnome-session that could substitute for dbus-launch.) Similarly, while moving dbus-launch into the desktop file would work, that would require adapting all session desktop files in every distribution in a way that would break (through double dbus-launches) if the Xsession and the session files got out of sync. My proposal was meant to be surgical - to just address the problem of the exceptional case where you didn't want the system D-BUS service - rather than to try and redesign things. I understand, though the temptation to add more surgical fixes to GDM makes it harder to maintain. I also don't like the fact that your suggested fix requires that the distro support the feature in their Xsession script. Some distros probably won't fix this, and thus causing confusion and user's thinking GDM is broken. GDM already has too many surgical workarounds that are only used in odd corner-cases, and these tend to break on occasion. I'm not opposed to adding more if someone wants to provide a patch, but if there is a way to make things work without hacking GDM further, that would be better, I think. Could dbus-launch be made smarter so that if dbus-launch was already started earlier in the stack, it does something smarter and just works? If possible, this would be better than adding a hack to GDM to support a flag that requires the the distro Xsession script support it. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GDM login to a JHBuild session
Owen: GDM already has too many surgical workarounds that are only used in odd corner-cases, and these tend to break on occasion. I'm not opposed to adding more if someone wants to provide a patch, but if there is a way to make things work without hacking GDM further, that would be better, I think. The addition I'm suggesting to GDM is not set environment variable to prevent launching of D-BUS it's set an environment variable before running Xsession, which seems like a very general thing. Whether I can convince distros to use this feature to fix the dbus-launch problem is between me and them :-) What might be a better solution would be to add an extension to the .desktop file which allows you to specify a script that gets sourced before running the Xsession script. Then you could set environment variables and such that might affect how Xsession works. Perhaps an extension, though, isn't really required. Note that GDM first calls /etc/X11/gdm/Xsession. Also note that GDM sets GDMSESSION and DESKTOP_SESSION to the session you are going to run. The /etc/X11/gdm/Xsession script could be enhanced to source a special optional desktop session script like if -f /etc/X11/gdm/$GDMSESSION.Xsession ] ; then . /etc/X11/gdm/$GDMSESSION.Xsession fi This way you could add a special script for your session that gets sourced before dbus-launch is called in your Xsession script. If you want to disable dbus-launch, then you could make that work this way. No? I think an approach like this might be better since it would allow people to do more general things, rather than adding a hack that just solves one problem that is specific to D-Bus. Brian ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update external dependency: system-tools-backends
Luca: Sorry - that was a mispost. I'm not sure how my email browser got so confused. Brian You don't answer #6. A good answer might be whether the XML formats used for saving documents has changed to a new revision in this release. I'd focus on mentioning any data formats that are visbile to end users. This TPT document looks really good, by the way. Brian Il giorno ven, 14/09/2007 alle 23.02 +0200, Andre Klapper ha scritto: hi carlos, Am Freitag, den 14.09.2007, 20:48 +0200 schrieb Carlos Garnacho: I've just released system-tools-backends 2.4.0, this release was intended to be synchronized with the 2.20 schedule, and I'd like it to be the recommended version, The minimum version can stay as it is, as they're compatible. Reasons? Lots of bugfixing, and being able to set WPA in network-admin relies on it. go ahead for it! (means: feel encouraged to update the wiki page ( http://live.gnome.org/TwoPointNineteen/ExternalDependencies ) and the jhbuild moduleset.) I've updated both. OK? ___ 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
