Re: Debian-specific patches for the GNOME packages
Hi, > X-RedHat stuff doesn't harm, but it might make sense to remove them > upstream and have Fedora add them back. Don't know. Pretty sure we don't depend on X-RedHat-Base et al anymore, so we wouldn't need to add them back. --Ray ___ 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?
Hi, On Sun, Sep 14, 2008 at 6:39 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le mercredi 10 septembre 2008, à 09:39 -0400, Willie Walker a écrit : >> Hi: >> >> I asked this earlier, but I might have missed the response. Have the >> accessibility issues been resolved with the new GDM? In particular, >> does accessible login still work and do the keyboard/mouse/dwell >> gestures still work to launch assistive technologies? I know there was >> a great plan in place (thanks Jon McCann!), but if it hasn't been >> completed, I think this is a show stopper regression. :-( > > Let's do it this way: if there's no reply about this before Tuesday noon > (UTC), we go with the old GDM (where reply can be "it's not ready", > "it's ready", "we're working on this"). > > I hate putting deadlines for this kind of things, but translators need > to know what we're going to do. 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. 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. 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 Hope that helps, Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Generating .gitignore files
Hi, > Based on an idea from halfline, I hacked a few lines to automatically > generate .gitignore from Makefile.am. It grew to a couple hundred lines, > and is available from pango/git.mk. > > http://git.gnome.org/cgit/pango/tree/git.mk > > It generates perfect .gitignore files for pango, vte, gnome-terminal, and > gucharmap. Which means it knows how to deal with gtk-doc, gnome-doc-utils, > and intltool. Neat! --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Searching for patches in bugzilla
Hi, On Tue, Sep 1, 2009 at 4:34 PM, Kjartan Maraas wrote: > ti., 01.09.2009 kl. 16.14 -0400, skrev Owen Taylor: >> Finding patches in your component that haven't been reviewed is a pretty >> common operation. Our previous ways of doing it (emblems, links from >> browse.cgi) aren't working at the moment, so I thought I'd mention here >> how to do it with the boolean charts feature, since I had trouble >> figuring it out. >> >> A screenshot is attached that demonstrates. >> >> Note that it's important that this is all in one boolean chart - because >> it's in one boolean chart, all the checks that are anded together have >> to match on the *same* attachment. >> >> Since you don't want to have to do this frequently, you should set up >> the search once for your module, than save it as a named query. >> > Note that the right patch status would be accepted-commit_now and > accepted-commit_after_freeze with underscores instead of hyphens. I added a and CC is %user% to this query and saved it as a global search: Bugs I watch with patches Which I think people should be able to access by going to http://bugzilla.gnome.org/userprefs.cgi?tab=saved-searches and checking it from the bottom list --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-session branched
Hi, I've created a gnome-2-32 branch for gnome-session in order to make gtk3 build fixes on master. See https://bugzilla.gnome.org/show_bug.cgi?id=630277 For more details. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME 3 external dependency proposal (accounts service)
Hi guys, Right now gnome-shell uses a cut-and-paste version of some code from GDM for showing its user switch applet (and also its login dialog). That code isn't very GDM specific, and really belongs in a library. At this point, it's basically a thin caching layer around the accounts service and consolekit dbus apis on freedesktop.org with some fallback code for when the accounts service isn't available. So I think it probably makes sense to have that code in the accounts service module. I've done that today here: http://cgit.freedesktop.org/accountsservice/commit/?id=8c031bce3f6fe67bd5f0f782a457aebd6af0ceba Vincent and Jon McCann talked recently about moving the user switch applet to the gnome-panel. This is in the vein of matching the gnome 2 fallback experience with the default gnome 3 experience for 3.0. That means the panel will too need to depend on this same bit of code, in the near future. Also, there's been some discussion on IRC and elsewhere about putting the accounts dialog in control-center. These three things together mean we really need an external dependency on accounts service, I think. The accounts service is a small module Matthias wrote for enumerating the users on a system and storing some metadata (well mainly just the face icon right now) outside of the users home directory, so it's available by other users and before the user is logged in. I agreed to help him comaintain it a few days ago. Sound good? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: about me (was: Re: GNOME 3 external dependency proposal (accounts service))
Hi, > While we are on it: Is there a cental place in GNOME3 to get basic user > information (like prefered E-Mail or things like that). It is annoying > when you have to configure a couple of applications with data that's > already there. I really don't want to depend on evolution-data-server > for this or at least not directly, dbus is probably ok. The accounts service being proposed has a field for email. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, (speaking as one of the 3 maintainers of GDM) On Thu, Oct 21, 2010 at 12:02 AM, Robert Ancell 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. > - The GDM greeter has very limited themeing capabilities. A > contributor to LightDM (PCMan) was able to quickly write a new greeter > that used GtkBuilder and provided comparable themeing support to the > old GDM. GDM uses the standard theming mechanism as the rest of GNOME. This a good thing. Making GDM use GNOME components and integrate with GNOME is not a bad thing. It used to not do that and was explicitly changed... Of course, things will need to be rethought about in a post- GNOME 3 world (use mutter / clutter?) > - While it is technically possible to write an alternate greeter for > GDM, in practise it is too difficult. LightDM has been designed from > the start to make writing a greeter no harder than a standard X > application. Granted, the interface between greeter and daemon isn't as clean as it could be. Still, 1) it's obviously not too difficult, or there couldn't be one functioning greeter 2) When writing a new greeter becomes a priority to someone, the interface is completely changeable. It's a private interface so it can be changed in any way that's needed. > - 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? 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) Anyway, I'm obviously in favor of keeping GDM in GNOME. I admit it has some baggage (some of it removed and added back later by popular demand), but overall GDM is in really good shape as a project.. FWIW, your various patches over the years have been a part of getting GDM to where it is. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 5:31 AM, Josselin Mouette wrote: > Le vendredi 22 octobre 2010 à 01:17 -0400, Ray Strode a écrit : >> 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. > > That, I fully agree with. This is a major feature of GDM, that makes > extending it easy and makes a11y support a breeze. > > It’s really a shame that LightDM doesn’t re-use this concept. Right, GDM used to work the way LightDM apparently works now, and it was changed because this way is better. >> Anyway, I'm obviously in favor of keeping GDM in GNOME. I admit it >> has some baggage (some of it removed and added back later by popular >> demand), but overall GDM is in really good shape as a project.. FWIW, >> your various patches over the years have been a part of getting GDM to >> where it is. > > I wouldn’t really call it in “good shape” from a distributor’s point of > view. We have to include an ever-growing number of complex patches just > to have the features that we consider essential, and development > upstream is happening faster than the pace at which we can get these > patches merged. I understand this point--maintaining a load of patches can be totally unfun. We discussed this before on gdm-list and I think we've made progress on that front since then. If you drop by #gdm and ping me, we can figure out what to do about your remaining patches. > This situation is not new and we also carry too many > patches in the 2.20 branch, but it’s not getting better; the sole 2.30.2 > → 2.30.3 upgrade included larger changes than all our patches added. Sure, but those changes were important bug fixes and performance enhancements. I realize even if the changes were "worthwhile" it doesn't make maintenance for you any easier if you've complex patches to rebase, though. > Having had to deal again with GDM’s labyrinth of classes, I came to the > conclusion that Robert’s decision to restart a project from scratch was > the right one. GDM does have a lot of code, but I'm happy to explain any parts of the code that seem confusing. I will say there are some classes in there that aren't compiled in. We could probably cull some of the excess fat to make it easier to see the active code and just add it back from history when if they become important again. One example of something that's #if 0'd out "factory mode". This is where GDM always runs in the background on a VT and the user is sent to that VT when ever they need a login screen. This helps fast user switching cases, and potentially paves the way for "trusted path" password dialogs (which I think Robert was alluding to as a potential future feature for LightDM). That's something we could potentially drop for now. > This means we don’t have the same priorities for GDM development, and of > course it’s fine; you’re doing whatever you want with your own project. I don't see GDM as "my project". I see my work on GDM as way of helping GNOME. I do see GNOME as "my project" (well "our project") though. Again, I think one of the most important features of the display manager is "integration". We have to stop thinking about GNOME as this thing layered on top of the OS, and start thinking of it *as the OS*. We need to be able to rely on important components being available and we need to leverage their presence to provide a slick, coherent experience to the user. As an example, the user switch applet is being moved to gnome-panel (and a comparable version already exists in the shell). Another example is the accounts-dialog (which is slated to go into control-center pretty soon I think. see the thread i posted about accounts daemon a few days ago) is used to configure things like "Automatic Login". This is all under the umbrella of providing a consistent, unified experience to the user. The "core" of gnome shouldn't be hot swappable--it defines what gnome is. I'd say the login experience is central to the core user experience. > But LightDM seems to focus much more on features that do matter for us. Which features are those? I think there may still be some lingering unhappiness about GDM losing features (like the themeable greeter) when it was reinvented in 2.22. Some of the criticism then was fair criticism and we worked hard to add back the important things in a way that makes the most sense. We didn't add back the themeable greeter for good reasons. It had bizarre rendering bugs, an underspecified file format, and also wasn't accessible. GDM had to ship with a separate,"plain greeter" that wasn't enabled by default in most distros for users who wanted an accessible
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 2:11 AM, Brian Cameron wrote: > 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. 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. > 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. > 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. Firefox has a lot more marketshare than GNOME, has a ton of development resources, etc, so distros embrace it to provide brand recognition, get security updates, etc. Also, back when this was a hot button issue, you needed firefox installed to run epiphany. Firefox also goes to great lengths to try to integrate as well as it can with GNOME. Anyway, I kind of wish distros embraced ephipany more. The mozilla foundation is doing a lot for the open source community (really, a ton, more than anyone else problably), the health of the internet, etc, but their goals don't always perfectly align with GNOME's or distros. Also, they have a powerful trademark they need to protect, which complicates things in various ways I don't want to get into here. > 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. 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 We really need to band together and focus on making our OS better, not more flexible, just better. I don't want to ship a bucket of parts to our users and leave them to fend for themselves. I want the user to get something refined, cohesive, and out-of-their way so it fades into the background while they're trying to get their job done (whatever job that may be). They shouldn't have think about the computer when they use the computer as a tool to do something else. We're not there yet. It should be an important goal. The only way we'll get there is if we work less on modularizing and more on integrating. > 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? Right, that's why I was wondering if Robert had talked to him yet, when he mentioned he wants LightDM to be cross-desktop. >> 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. Again, I disagree here for the reasons mentioned above. We need to focus, not splinter. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Fri, Oct 22, 2010 at 2:50 AM, Robert Ancell wrote: > While I appreciate the use of a full session for the greeter has it's > advantages, I'm not sure they're all necessary for the limited GUI > required in a greeter. It's not necessary (i mean there's a lot of prior art showing that). I'd argue though that doing it any other way is wrong. > It really comes down to flexibility - I think any capable application > developer should be able to develop a greeter > (with a full session if required) without needing detailed knowledge > of how the display manager works. I agree the interface between the greeter and daemon in GDM could be cleaned up, and doing that would be a worthwhile thing to do. > I had been trying to get this interface into GDM, but I'd come to the >conclusion that the > architecture of GDM is overly complex and that holds back innovation. We have the ability to simplify the complicated parts of the architecture where necessary. It's just internal code and it can be changed to fit needs as necessary. There's no API/ABI worries or anything like that. We can fix problems, all it takes is fixing them... and of course there's 3 maintainers of GDM that are very familiar with the code. We're all frequently available to answer questions, too (although, like everyone else we're all busy doing other things as well) > I am talking with other projects and trying to get people working > together. I'd like to see the fragmentation in display managers > reduce so we can look at the daemon as the boring reliable bit and > have people go wild designing new interfaces! Ensuring the display manager is flexible enough to meet the expectations of designers is an important goal. There's no doubt, telling a designer with a competent design, "we can't implement that" often means the user loses. I think that's why one of the main reasons parts of GNOME 3 are getting themed with CSS and getting written in javascript. Adding another display manager fragments things even more, though. 2 display managers for GNOME would be bad for GNOME. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GTK+ modules loading changes
Hi, > Finally, if you require 2 modules to be loaded in a certain order, > you'll need to define the X-GTK-Module-Name as "module1:module2". This > is the case for the a11y modules. Any reason the list separator isn't a ';' ? That's the typical separator in key files (or less commonly "," which was added for icon themes) --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Release Candidate (2.91.92) Released!
Hi, On Wed, Mar 23, 2011 at 2:14 PM, Frederic Peters wrote: > GNOME 3.0 Release Candidate (2.91.92) > = > > 3.0 is now around the corner, and this release candidate has it all > already, everyone has been working really hard those last days to make > it wonderful. Thanks! Anyone trying this should also get gnome-session-2.91.93. It contains an important fix for log out and shut down. See https://bugzilla.gnome.org/show_bug.cgi?id=645432#c10 for more details --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi,
(speaking again as one of the three GDM maintainers)
On Fri, May 13, 2011 at 8:59 AM, Robert Ancell wrote:
> Why replace GDM?
>
> - LightDM is a cross-platform solution.
What platforms does LightDM support that GDM doesn't? Are they
platforms GNOME is targetting? Not sure this is necessarily a win
without knowing more details.
> Ubuntu is planning to switch to it this cycle,
Sure, and I can see how that decision may potentially make sense for
Canonical (you would be able to offer in-house expertise, better
control over unity integration etc etc.)
> By sharing this piece of infrastructure GNOME can spend
> more time working on important GNOME components.
So you're saying, we could stop working on GDM, Brian, McCann and I
could leave the login screen to you to handle and we could use the
extra time we got to work on other parts of GNOME? There's no
question that we're all busy, for sure, but let's look at the "big
things" (modulo small patch review, security errata, etc, that would
exist in both projects) needed for GDM:
1) Landing the multiple simultaneous pam conversations branch of GDM
so you get sane behavior in the presence of smartcards, fingerprint
readers, etc. This lets you swipe your finger, insert your smart
card, or whatever while sitting at a enter password prompt.
2) Giving GDM a more of a GNOME 3 look and feel (as per the mockups
you already mentioned elsewhere in the thread)
3) Better support starting a login screen dynamically a keyboard,
mouse, and display show up ("multi-seat"). Also, see the work Lennart
and Kay are discussing lower in the stack to help facilitate some of
this.
4) Figuring out how GDM, screen locking, and the shell all fit together
I don't think LightDM will help us with any of these 4, will it?
> - I am confident that the LightDM architecture is simpler than GDM.
There are certainly parts of the architecture of GDM that could be
cleaned up, and that would be a worthwhile thing to do.
I don't see why it should get replaced though.
> Architecture can be a personal opinion, and I encourage those with
> programming experience to look at the code and decide for themselves.
Right, coding style is definitely a subjective thing. And everyone will
have their own opinions.
> Note that LightDM is not lighter in features, but in architecture.
And a different focus, right? GDM is firmly a GNOME project, designed
to integrate and work well with GNOME. LightDM is designed with the
idea of being more generic right?
> - By having a well defined interface between the greeter and daemon,
> it is significantly easier to develop a greeter without knowledge of
> how display management works. This is useful as the skillset and
> motivations of these two sets of developers are different.
Not sure how much of a selling point "multiple greeters" is, but GDM's
architecture allows for it.
Dr. Mo even did one apparently:
http://doctormo.org/2011/04/12/how-to-make-a-gnome-login-screen-in-python/
Anyway, we own the code. GDM is GNOME's project. it's imminently
fixable. If an interface isn't ideal, we can change the interface.
We have the ability to do whatever we want or need to do.
> - LightDM is a platform for future work and is investigating the use
> of new technologies like Wayland.
Wayland is really cool. It has the potential to let us ditch the junk
unix VT system, and potentially to get us away from X. Krisitian is
an amazing programmer and wayland is no doubt the future in my mind.
GDM will happily jump on that bandwagon when its time to.
Anyway, I'm obviously of the opinion we should stick with GDM. There
just doesn't seem to be a good reason to switch.
--Ray
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Difficulties getting patch reviewed
Hi, On Fri, May 13, 2011 at 12:43 PM, Daniel Drake wrote: > Having not heard anything, I emailed the maintainer on March 8th, > politely asking for a review - no response. Best bet is to ping marnanel on irc. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Fri, May 13, 2011 at 1:06 PM, Robert Ancell wrote: >>> Note that LightDM is not lighter in features, but in architecture. >> And a different focus, right? GDM is firmly a GNOME project, designed >> to integrate and work well with GNOME. LightDM is designed with the >> idea of being more generic right? > > More generic in the parts that are common. In the parts that are > GNOME specific, as differentiated as is required. But you said someone will need to volunteer to do the GNOME integration part, right? >> Anyway, I'm obviously of the opinion we should stick with GDM. There >> just doesn't seem to be a good reason to switch. > > I'll keep trying to convince you, thanks for the feedback Ray. :) Fair enough. I'm not ready to give up on GDM yet. It's serving it's place well enough, I think. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Sun, May 15, 2011 at 2:30 PM, Brian Cameron 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). > 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. SunRay is proprietary, though, and so kind of sits outside the focus of GNOME. 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. > It is not really clear what the future GDM/ConsoleKit plans are in this >regards, > and nobody seems to clarify. Clearly, GDM should try to stay as closely aligned with the direction of GNOME as possible. Certainly that means gaining a GNOME 3 look and feel, and using the bits of the GNOME 3 library stack that make sense to use, etc. > 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? Right, this is straying a bit off the original topic. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Sun, May 15, 2011 at 1:58 PM, Brian Cameron wrote: > 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 As far as I know, every time "no gdmsetup" has been brought up the response has always been more or less that GDM shouldn't act like a bolted on app with its own setup UI. Instead, the various bits of configuration that are supported should be exposed in an integrated fashion with the rest of GNOME. That means putting some stuff in the (at the time unwritten but planned and frequently discussed) accounts dialog, relying on system default values for certain things, and potentially adding "Make default" buttons to places in control-center. I know you and I personally discussed this at various points (and seemingly came to consensus on). I'm pretty sure Robert and I discussed it (but could be I'm misremembering and it was Martin or Sebastien I talked too, not 100% sure). Jon also sort of mentioned it on the bug report you point at above. Anyway, we can't all agree on every change. We have to evaluate each one on a case-by-case basis and do what's right for the project as a whole. I think on the whole, though, GDM does a pretty good job at what it's supposed to do, has a pretty good track record. It totally could be that this particular bug is the reason is Robert wrote LightDM. I don't know. I don't know the history there at all. I guess it doesn't *really* matter though. It's fine he's writing LightDM! I wish him the best for that project. I'm sure that project has its place and its own intrinsic value. I just don't think its place is in GNOME right now. We have something in that place already, and it's serving its role well enough. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: LightDM
Hi, On Tue, May 17, 2011 at 2:07 PM, Brian Cameron wrote: > 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. Yea, clearly we'll have to make sure GDM continues to work on the same set of systems the rest of GNOME works on. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2 features: login screen
Hi, On Mon, May 23, 2011 at 12:17 PM, Brian Cameron wrote: > Most of the discussion does not seem to be about the login screen as > the subject line suggests. I think this is because the original email > in this thread lumped together GDM "shell-style greeter" topics with > unrelated "installer setup tool" topics. To me, it seems that issues > with the installer has completely drowned out any real discussion about > the GDM changes proposed. In my experience, installer topics tend to be > more controversial since you tend to get into more OS and distro > specific issues. Well it's not about an installer setup tool, but about a first login tool. There's no installing going on here... It's sort of akin to 602663 but dealing with more than just login setup and at least initially only handling the initial-user case instead of all first-login cases (with a way to bypass it for situations where it doesn't make sense) > In terms of the login screen, the mock-up[1] looks nice but seems > underspecified. I do not see why you would even need to use OpenGL > or clutter, or even need to change the GDM code much to just make it > visibly look like the mock-ups. Well, we should leverage the gnome platform as much as makes sense, though, --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Login Process on Gnome
Hi, On Tue, Sep 27, 2011 at 9:04 PM, Leonel Florin Selles wrote: > I'm working in a school, in which I have the list of students that visit > the computer lab, the list of users is in a database along with their > alleged passwords. > > I need to create a login for Gonome sesions, that allow me to take the > username and password that the students put and get validated against the > database, and if the credentials of the students are true let him enter > for an existing session on the system, all this need to be performances on > the login windows of gdm or gonome. > > In windows I do not have problems with this, because a rewrite the > MSGINA.dll, but here with gonome I don't know how. > > there is anyone can help me On Linux you would use write your own PAM module to validate the user against your database. Alternatively, you could sync your database with /etc/shadow or change /etc/nsswitch.conf to use db for shadow (password hash) information instead of /etc/shadow Another option would be export the database via ldap and use ldap for authentication. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: Securing maintainer uploads to master.gnome.org
Hi, On Thu, Nov 10, 2011 at 6:47 AM, Olav Vitters wrote: > 3. Access is determined using "doap" files > 4. If you're not in the doap file of that module, you cannot upload It's pretty common for people not listed as maintainers in the doap files to do releases, especially for the lesser maintained modules. I don't think that's a bad thing, either. In fact, I think the lack of fine grained ACLs for this sort of thing is one part of GNOME that work better than projects that try to lock things down more aggressively. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: Securing maintainer uploads to master.gnome.org
Hi, On Fri, Nov 11, 2011 at 10:26 AM, Olav Vitters wrote: > On Fri, Nov 11, 2011 at 03:23:25PM +, Bastien Nocera wrote: >> It's useful. > > What do you suggest then? > > 1. Let anyone with git.gnome.org upload any tarball they want This one ^^ > 2. Let selected people upload any tarball they want; handled by > accou...@gnome.org. > 3. Only maintainers, release team What I'm saying is there shouldn't be a lot of process involved here, because people informally help out pretty frequently. If you keep track of it already you can see probably see how often it happens by looking at the stats, I guess. A number of modules are sort of "maintained by the masses". It's not just release-team members who do the releases, either. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: Securing maintainer uploads to master.gnome.org
Hi, On Fri, Nov 11, 2011 at 3:22 AM, Alan Cox wrote: > Locking stuff down means reducing the attack surface (eg getting rid of > shell accounts) and who can write stuff to trusted repositories. It > doesn't mean contorting the release process. You just need to have the > signing policy right. Giving everyone read access isn't a big deal, its > write access that causes the problem - either to modify repositories or > to put up fake releases. The latter can to a fair extent be handled by > enforcing the upload be of a signed file with an appropriate signature > for the destination. I understand the arguments for per module ACLs (be it for commits, or releases). I understand they close down an attack vector. I just don't think it's necessary in practice. These kinds of things can be handled through social means just as they always have. (version control has been open since the 90s without issue!) If we really have to lock down the release, it should be something handled at the very end of the process, where a random gnomie can do a one off release as a favor or to get a bug fix/feature he has vested interested in deployed and it sits in moderation until given a quick rubber stamp. It would be much better to avoid that red tape, though. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Last GNOME 3.4 Blocker Report
Hi, > === > GDM > === > [PATCH] add automatic multi seat support > https://bugzilla.gnome.org/show_bug.cgi?id=655380 I plan on looking at this one before doing the release --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cairo / Highlighting
Hey, On Sat, Mar 31, 2012 at 8:28 AM, Sebastian Geiger wrote: > Hi, > > given cairo type cr which contains an icon. How can I produce some kind of > highlighting on this icon. For example light it up a little and change the > background (the parts which are transparent) to a different color (e.g > white), or even using a light white blur as background. > > Im sure it only requires a few calls to cairo but as I am not very familiar > with cairo maybe someone can give me a suggestion. I'm a little late to reply here, but checkout the link labeled "How to:Perform a Gaussian blur on an image surface" from here: http://cairographics.org/cookbook/ also this is a good resource, in general: http://cairographics.org/samples/ --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reviewed-By: and pastebins
Hi, On Thu, May 3, 2012 at 12:00 PM, Colin Walters wrote: > In this scenario, I don't want to lose the critical information that the > patch has been reviewed (and who reviewed it). So here's the proposal: I think when the person who reviewed a patch is critical information, then the details of the review is normally also important. I don't think the person who reviewed a patch is always critical information, though. Certainly, drive-by pastebin patches should be trivial and obvious. If the proposed changes aren't trivial and obvious, then they should go to bugzilla first so there is a paper trail leading back to the discussion. Basically, adding the reviewer's name doesn't hurt anything, but my opinion is it doesn't necessarily help either. What does help is knowing that the patch was sanity checked at all (like you said), and not committed blindly, and at that point adding the person who did the sanity checking doesn't seem like a bad idea. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hi, On Fri, May 4, 2012 at 4:54 PM, Andre Klapper wrote: > Lionel proposes to consider merging the login screen and the lock screen > as both are about logging in. > In the end Allan wrote "let's continue some place else." > > Did this conversation continue somewhere, and what were the results? > > Asking as I think that Lionel has a good point and don't see good > arguments against it yet either. It doesn't make sense to go to a new login screen because that would incur a VT switch, would stop your music from playing etc. It something to reconsider once wayland has been integrated. At that point we'll be well situated, since both are implemented with gnome-shell anyway. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Lock Screen
Hi, On Wed, May 9, 2012 at 11:21 AM, Frederic Peters wrote: > I believe the point Lionel made was not about technicalities but about > the design by itself, e.g. why would the process of logging in be > different in the morning when you turn your computer on than in the > afternoon when you walk back to a computer with the screen locked. Technical details aside, from a user experience point of view, the user preceived process is very similar. In my experience, even very techinical people have gotten gdm and gnome-screensaver confused. There are some differences. 1) if you're already logged in, you may want to be able to interact with the lock section in tightly controlled ways (change tracks on songs, adjust volume, etc) 2) if you're already logged in on a multiuser machine, it's more like you'll want to unlock the already logged in session, then log in as a new user (so it makes sense to go straight to the password screen, where for initial login it may make sense to go straight to a user list) My point was just that from an implementation point of view, we can't jump to the GDM screen, since that will mute any running audio and cause all sorts of screen flicker. In the future it may make sense to do, though. Especially when we have wayland (so can smoothly switch X servers). Keep in mind, though, that today, the login screen is implemented with gnome-shell. This feature will make the unlock screen be implemented with gnome-shell. So the implementations are converging. > As Andre wrote, "did this conversation continue somewhere, and what > were the results?" No idea. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
live image
Hey, I put together a live image with a jhbuild built in it here: http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.1-LiveUSB.iso You can write the image to a usb stick with this command: sudo dd if=GNOME-3.5.1-LiveUSB.iso of=/dev/DRIVE bs=8M conv=fsync (where DRIVE is a usb stick, probably /dev/sdb, but could be something different, so be careful!) It's a little hacked together, at the moment. I'd like to get the process I used more refined and potentially automated so we can do testing more easily and regularly through the development cycle. One thing, that makes this image less than useful in virtual machines is a bug in software rendering. Adam Jackson, has a cogl workaround here: https://bugzilla.gnome.org/show_bug.cgi?id=674208 But that patch isn't applied, so this image doesn't work great in virtual machines. Hopefully that will be resolved soon. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: live image
Hey, again, On Thu, May 17, 2012 at 4:55 PM, Ray Strode wrote: > I put together a live image with a jhbuild built in it here: > > http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.1-LiveUSB.iso I forgot to announce I put up one for 3.5.2: http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.2-LiveUSB.iso --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libxml2 commit 65c7d3b2e6506283eecd19a23dcf0122fbcdac33
Hi,
On Mon, Aug 6, 2012 at 3:05 AM, Daniel Veillard wrote:
> mistake done circa 98-99 IIRC and a bit late to fix ... The problem are
> that those buffers were using int instead of size_t for various size
> leading to a variety of troubles including security ones. How to fix
> that while keeping everything pblic API and ABI compatible ?
One idea (if you're sure consumers are just reading the public
structure and not allocating/writing to it):
struct xmlExtendedBuffer {
xmlBuffer compatBuffer;
size_t realSize;
}
Then when allocating e.g., an output buffer:
outputBuffer->buffer = &extendedBuffer->compatBuffer;
and any time you need to get at the extended buffer do:
extendedBuffer = (xmExtendedBufferPtr) outputBuffer->buffer;
Any time you need to adjust the size of the buffer, adjust
extendedBuffer->realSize, and then do
extendedBuffer->compatBuffer.size = (int) extendedBuffer->realSize;
Though, sizeof(size_t) == sizeof(int) on 32-bit arches so i'm a little
unsure how swapping one for the other could fix overflow problems.
--Ray
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libxml2 commit 65c7d3b2e6506283eecd19a23dcf0122fbcdac33
Hey, On Thu, Aug 9, 2012 at 10:21 AM, Daniel Veillard wrote: > that's basically what I did in xmlBuf . But I broke the ABI more > frankly by making the xmlBuf private, as I prefer to have the code > fixed when people recompile. Those buffers were not supposed to be > accessed that way, but people did, they didn't get the supposedly > uneeded accessors, those are available now, it's better to clean things > up for good an not rely on the old buffer for input and output on > newly compiled apps (old buffers are still available for generic > purposes though). So to be clear, i was proposing leaving the structure public, but embedding the structure in a private structure. Since you're referring the the structure via a pointer, you can point into the middle of the private structure. Users of the api could then access the public size field, but it wouldn't be the *real* size field, just an int sized truncated copy of the size field. The real size field would be out of view a bytes before where the pointer points (or after the structure block). Anyway, sounds like it's water under the bridge now and people have coped, so maybe not worth persuing. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.5.91 second beta release
Hi, On Sun, Sep 9, 2012 at 1:57 PM, Javier Jardón wrote: > More details about changes and news for this beta are available here: > >core: http://download.gnome.org/core/3.5/3.5.91/NEWS >apps: http://download.gnome.org/apps/3.5/3.5.91/NEWS > > > The GNOME 3.5.91 release itself is available here: > >core sources: http://download.gnome.org/core/3.5/3.5.91/ >apps sources: http://download.gnome.org/apps/3.5/3.5.91/ I put a test live image here: http://ftp.gnome.org/pub/gnome/misc/testing/GNOME-3.5.91-LiveUSB.iso See http://www.gnome.org/getting-gnome/ for info on how to try the ISO out with a usb stick. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Questions (about CJK input) on GNOME 3.6 live image
Hey, On Sat, Oct 6, 2012 at 2:33 PM, Ma Xiaojun wrote: > The live image is downloaded from: > http://ftp.gnome.org/pub/gnome/misc/promo-usb/GNOME-3.6.0.iso I've pushed a new iso to fix this: > Firstly, according to "rpm -qa | grep ibus" and Input Sources tab, > there is no Chinese input sources but there is Japanese (ibus-anthy) > and Korean (ibus-hangul) input sources. Why is that? and this: > Fifthly, can you remove the application launch for im-chooser? It > maybe useful for non-IBus users. However, currently it is just broken > and confuses uninformed users. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cangjie and Quick input method missing in Live CD
Hi, On Mon, Oct 8, 2012 at 12:39 AM, Shu Hung (Koala) wrote: > I've just tried the Gnome 3.6 Live CD (downloaded today): > http://ftp.gnome.org/pub/gnome/misc/promo-usb/GNOME-3.6.0.iso > > In "System Settings > Region & Language > Input Sources", > Cangjie (ibus-table-cangjie) and Quick (ibus-table-quick) are not in the > list of choose of input methods. > > These 2 input methods are the most popular for Chinese (Hong Kong) users. > Would you please add them to the Live CD? I've pushed a new iso if you want to give it a try: 753c99ce2342f65865c1f74bc3722e44 GNOME-3.6.0.iso It may take a while for the mirrors to sync. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Cangjie and Quick input method missing in Live CD
Hi, The respun ISO added the new requested ibus subpackages to the manifest and hid the ibus config panels launchers from the apps view. --Ray On Mon, Oct 8, 2012 at 11:12 PM, Parag Nemade wrote: > Hi Ray, > > On 09/10/12 02:03, Ray Strode wrote: >> >> Hi, >> >> On Mon, Oct 8, 2012 at 12:39 AM, Shu Hung (Koala) >> wrote: >>> >>> I've just tried the Gnome 3.6 Live CD (downloaded today): >>> http://ftp.gnome.org/pub/gnome/misc/promo-usb/GNOME-3.6.0.iso >>> >>> In "System Settings > Region & Language > Input Sources", >>> Cangjie (ibus-table-cangjie) and Quick (ibus-table-quick) are not in the >>> list of choose of input methods. >>> >>> These 2 input methods are the most popular for Chinese (Hong Kong) users. >>> Would you please add them to the Live CD? >> >> I've pushed a new iso if you want to give it a try: >> >> 753c99ce2342f65865c1f74bc3722e44 GNOME-3.6.0.iso > > What changes are pushed in this updated iso? > > Regards, > Parag. > > ___ > 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: Preserved Window Placement
Hi, On Wed, Oct 24, 2012 at 12:17 PM, Alan Cox wrote: > It's supposed to be a property of the X session management, including > automatically restarting applications that were running before (which > Gnome doesn't bother to do). This is usually managed by a mix of the > toolkit and the X window manager (with a little necessary help from the > app). This feature is toggle-able in gnome. run gnome-session-properties and check the "Automatically remember running applications when logging out" Of course, it's off by default for a reason. It's based on a horrible protocol from the 90s and it doesn't work very well from application to application. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Blocker bug review for 3.8
Hi, On Tue, Mar 5, 2013 at 1:31 PM, Jeremy Bicha wrote: > Dropping the simple greeter from gdm breaks feature freeze. Removing a > feature is even more disruptive than adding a feature so I thought it > was understood that we shouldn't be doing these changes after feature > freeze without getting approval. (For instance Debian Wheezy ships the > simple greeter by default.) I don't have a problem making it build time optional configure switch for 3.8 and then moving it to a separate git module for 3.10 --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Blocker bug review for 3.8
Hi, On Wed, Mar 6, 2013 at 9:59 AM, Javier Jardón wrote: > If you dont mind the extra work, I think this is the best solution > (and set to not build the simple greater by default) wasn't any extra work for me. walters beat me to it: https://bugzilla.gnome.org/show_bug.cgi?id=695414 --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: Completing the Wayland port
Hi, On Tue, Sep 24, 2013 at 9:14 AM, Matthias Clasen wrote: > I'll make the start for discussing 3.12 features by giving an update > on the status of the Wayland port, and what work remains to be done > next cycle. > - finish the gdm support I started on this last cycle but didn't get done in time. The in-progress work is here: https://git.gnome.org/browse/gdm/log/?h=wip/wayland I also think some of the requisite logind work has landed since, so I'm going to investigate integrating with that. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fish in GNOME Panel
Hi, > Oh cruel, cruel world... > Luis (who just this weekend fondly reminisced about the days when > wanda would appear completely at random) Wanda is always a just a short command away: type Alt-F2 and then free the fish and then press enter --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The future of session management in GNOME
Hi, > * XSMP does a number of useful session-managey things (logout > notification, logout cancellation, specifying apps that > should be restarted right away if they crash, specifying > commands to run at logout, etc) which we currently have no > other way of doing, so we'd be forced to reinvent half of > XSMP if we ditched it. So at this point I'm sort of of the opinion that logout cancellation isn't really useful. Apps should just be saving their state all along the way. This is interesting for other cases, too, like if the power goes out. In general, I don't think people should ever lose work, and having this "save everything that's still open when the user just wants to get out the door" step isn't really the right way to go about it. I know this is punting the hardest part of the problem to every app though. > * To reduce the number of special case hacks the session > manager contains for various bits of GNOME functionality, > we'll add a way for autostarted programs to make changes to > the session manager's environment; eg, setting GTK_MODULES > for a11y, So for this one, we should just switch over to using gtksettings instead of environment variables. >setting G_DEBUG for unstable-series testing, > setting GNOME_KEYRING_SOCKET for the keyring manager, > etc--currently these are all done as special cases in > gnome-session. The clients would work like ssh-agent (print > out a few VARIABLE=value lines at startup and then fork or > exit), and there would be a new autostart .desktop property > indicating that the client behaves this way. The session > manager would start them, read their stdout, run the > appropriate putenv()s, and continue starting things up. Sounds reasonable enough...my only concern is that apps tend to spew things to the console without really realizing it. > We could make the splash screen a separate program too. > (Would this actually be useful?) The session manager has > .desktop files for everything it's starting, so it could > just do startup notification when it launches them, and then > the splash screen program could watch that to see what > icons/localized app names to put up. (We'd also need to have > the session manager signal somehow when the splash screen > should go away.) Do we even need a splash screen? Soeren turned if off by default in fedora. > * The session management UI will be more icon-y and less > command-line-y than it is now. (The session manager will > hopefully have a .desktop file for each app, so it can use > those to get icons and localized names.) It will probably > communicate with the session manager via dbus, rather than > using kludgey hacks on top of XSMP. That sounds good. One conclusion I came to the other day about gnome-session-properties: It has three tabs. The first one isn't really useful at all, the second one should be merged into gnome-system-monitor, and the third one is the only one that really seems interesting. Maybe it should just be gnome-startup-programs? > Of course we'll want to throw away the gnome-session codebase > completely. (If you disagree, please go read the code.) The best bet > would probably be to rewrite it in C#. I'm kidding. I'M KIDDING! The > "msm" module that Havoc started several years ago and Ray Strode > continued hacking on a bit later is probably a good starting point for > a new session manager. If you start with that, make sure you rip out DSME bits. That spec never went anywhere. > We also want a better client API than GnomeClient. GnomeClient is a > very very thin layer around XSMP, mostly because when it was written > there wasn't enough agreement about what certain parts of XSMP meant, > so it was impossible to abstract/simplify the API. As mentioned > before, this is somewhat fixed now[3], so we can make a nicer API > based on our new understanding. At the very least we want separate > "save_state" (Local SaveYourself) and "save_files" (Global > SaveYourself) signals, rather than a generic "save_yourself" signal > with 36 possible combinations of flags where almost every single app > in jhbuild that uses GnomeClient implements only one behavior that it > uses regardless of the flags passed (and often that behavior is not > 100% correct for any of the 36 possibilities). msm has a client library, too, that Havoc was working on at one point. It's probably too lowleve
Re: Bacon, Bonobo, Sockets and Strangeness
Hi, > How is it, that a factory which is not the original server of the > socket can be responsible for holding a socket open after the parent > has been killed? Are you leaking the fd to the child process when you fork? look in /proc/PID-OF-CHILD/fd and see if you have an open reference to the socket there. If so, you might need to close the fd in the child after you fork, or set the close-on-exec bit using fcntl if the child eventually calls exec. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-session patch nag: change client removal order when logging out
Hi, > My point is: On logout, close all other apps first (by whatever > appropriate means), > then close all nautilus windows (the last remaining windows), which will > eventually > clear the desktop, and finally close metacity and gnome-panel (by whatever > appropriate means). I think Bastien was saying something like "ask apps to save themselves and then when that's done just exit gnome-session and let X die (and then most apps will die almost simultaneously with a fatal x io error while the login screen is been brought back up)" --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Network problems in gnome-session
Hi, > The bug is basically as follows: after switching network connections via > NetworkManager (maybe in combination with hibernate/resume, I'm not sure > about that yet), suddenly every window takes about 10 seconds to open > while waiting for gnome-session to respond. > > I've done various ltraces and straces of gnome-session and some > applications. > > The applications themselves hang in, e.g. XtOpenApplication (in case of > Xterm) or gnome_program_init (in case of gedit, for example). > > At the same time, gnome-session hangs in SmsGenerateClientID. strace > shows that it seems to be waiting for a DNS reply from a long-gone DNS > server for the local hostname.. What is the output of echo $SESSION_MANAGER ? Does it contain a hostname in it? The wrong hostname? Does unset SESSION_MANAGER make things magically startup faster? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Network problems in gnome-session
Hi, > My current nameserver is 129.xxx.xxx.xxx, and 129.* is the only active > network and route. gnome-session still tries to ask 192.168.1.3, though, > which was the previously active nameserver from my home network. Do you have nscd running? If you do nscd -i hosts as root after switching networks do things start working? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Network problems in gnome-session
Hi, > So, do you think that it's a configuration problem on my side or > actually a bug in gnome-session? I still think it's the latter. I don't really know what's going on, but I'm guessing it's either a bug in the NetworkManager backend for your distro, or a bug in libc. I have these vague memories of apps taking ~30 seconds to recognized network changes after early versions of NetworkManager switched networks and it ended up being some glibc interaction that I don't remember the details of. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: RFC: hiding the new timezone feature in the clock applet for 2.20
Hi, > Since I didn't have time to fix a few things for the clock applet for > 2.20, and I don't think anybody did it either, I think this feature is > not ready to be used by all our users for 2.20: the UI is clearly far > from being optimal, and it's also a bit slow for reasons I've not > investigated. > > I'd like to remove the UI bits from the clock pref dialog that let the > user enable this feature. People could still enable it via a gconf key, > though. Seems reasonable enough. After that, maybe we can get Novell's prettier map/clock graphics integrated into it? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, > Even though the keyring is locked, it seems like the application that set > the secret should be able to retrieve it. I don't know how you want to make > sure it's the same calling application, there might be some tricks in that. > But this would reduce the number of login / access the keyring dialogs. So, at some point a password has to be asked for, because that password is used to unencrypt the data. In theory only one password should need to be asked for though, the password (or smart card PIN code) you type when you login. That's the whole single sign on dream, and what pam_gnomekeyring is trying to tackle. > Perhaps my vision of the keyring is more of a secure little area where > applications can save data that's reliable and encrypted and I have the > master password to; however if an application wants to save some random > secret bits in the keyring that only it will retrieve later I find it pretty > harmless. Is that a false assumption? If the data is encrypted then the application won't be able to get to the data until it's unencrypted, which means asking for a password. Are you asking for an unencrypted area that only one application has read access to? If so, you might be able to do something like that with SELinux (or AppArmor?), but I don't think it would be a very robust solution. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: cleaning up keyrings
Hi, On 8/29/07, Alan Cox <[EMAIL PROTECTED]> wrote: > > Are you asking for an unencrypted area that only one application has > > read access to? If so, you might be able to do something like that > > with SELinux (or AppArmor?), but I don't think it would be a very > > robust solution. > > The Linux kernel key service can do this for session/user/user+session > and other key types, and you can use SELinux labels on it. But the kernel keyring isn't persistent across reboots is it? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Fwd: Fwd: MAINTAINERS in svn -- have it or no commit for you
Hi, Daniel took care of his (libxml, libxslt, gamin) --Ray -- Forwarded message -- From: Daniel Veillard <[EMAIL PROTECTED]> Date: Sep 4, 2007 4:25 AM Subject: Re: Fwd: MAINTAINERS in svn -- have it or no commit for you To: Ray Strode <[EMAIL PROTECTED]> On Mon, Sep 03, 2007 at 07:57:04PM -0400, Ray Strode wrote: > Hey Daniel, > > Have you seen this thread? Most of the modules left are yours, yea? > > Can you commit the MAINTAINERS file changes? > > The info is here: > > > http://live.gnome.org/MaintainersCorner#maintainers Okay done, note that gamin is not part of Gnome releases, and for libxml2 and libxslt it's a bit controversial too, it's more part of the base OS now in my opinion, but I understand the files are needed for the management of teh CVS base too, at least as a point of contact, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome.org's crypto infrastructure
Hi, > * GNOME releases tarballs of source code. Maintainers regularly post > checksums of their tarballs along with their announcement emails. Until > now, I'm not sure if we have had the need to *guarantee* that a > particular release of code is authentic. For example, we don't actually > crypto-sign tarballs like the Tor project would --- in their case, > whoever downloads the code *really* wants to ensure that it hasn't been > tampered with. Again, I'm not sure if we have such kind of > security-conscious code, but maybe we could start crypto-signing our > tarballs. Which brings me to... One thing that would be really neat (imo) is if instead of maintainers pushing tarballs to master.gnome.org and running ftpadmin manually, they instead pushed a "git-tag -s" GPG signed tag of a specific naming scheme (maybe an rc suffix, e.g., "3.13.4-rc1"), and then an automated release-team VM would notice the tag, check out the tarball, run "make distcheck" and if it all passed muster, push a final tag (e.g., "3.13.4") signed with a release-team key, and then push the tarball to master.gnome.org. A few downsides: 1) make distcheck often fails, and this model sort of encourages maintainers to "fire-and-forget" when making a release instead of baby sitting it to the end 2) The system would have to be implemented, and it's a non-trivial amount of work to implement 3) It might mean keeping a release-team private key with no password on a VM connected directly to the internet. a few upsides: 1) tarballs would be generated with a standardized set of autotools, instead of whatever the maintainer happens to have installed 2) "make distcheck" would be run on a fresh checkout of the source, so it would eliminate a failure mode where some left over bits in the maintainers working tree made things work even when the pushed git tree itself is missing files. 3) all the tarballs would be signed with an "official" key --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome.org's crypto infrastructure
Hi, > I think the opposite is true as well, in that some software needs > other frameworks in place to do "distcheck" rather than "check" -- for > instance colord needs a running colord daemon to test against. Other > software needs X. Well, maybe it could do it in a gnome-continuous VM or something like that. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Anyone going to be using ConsoleKit for 3.16 ?
Hey, I'm wondering if there are distros/platforms that are planning on using 3.16 and ConsoleKit together. I know there's LoginKit, systemd-shim and systembsd now that try to provide logind compatible interfaces for non-systemd systems, so I'd really like to get rid of the ConsoleKit code in GDM. The code is complicated and not really tested. I'm leaning toward getting rid of it in 3.16 (versus say 3.18). Distros, of course, could ship a patch to reverse to removal if necessary, so I don't think doing it for 3.16 should be too controversial, but I wanted to shoot a mail first anyway to gauge the reaction. Thoughts? Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hi, >> > I'm wondering if there are distros/platforms that are planning on >> > using 3.16 and ConsoleKit together. >> > >> > I'm leaning toward getting rid of it in 3.16 (versus say 3.18). >> > Distros, of course, could ship a patch to reverse to removal if >> > necessary, so I don't think doing it for 3.16 should be too >> > controversial, but I wanted to shoot a mail first anyway to gauge >> > the reaction. >> I would not mind removing such support for 3.16 if and only if >> reverting the removal is easy and not too intrusive. > FreeBSD will also be using ConsoleKit for 3.16. Antoine pretty much > said everything that goes for us already. Okay guys, so what I'll do then is take the code out but post a patch to https://bugzilla.gnome.org/show_bug.cgi?id=743940 that adds it back. You guys can ship that with 3.16 and then drop it with 3.18 when LoginKit is integrated into your distros. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hi, On Tue, Feb 3, 2015 at 12:00 PM, Olav Vitters wrote: > Can't we hide it behind a --this-is-going-away-in-3.18 configure switch? That was certainly a possibility, but, what's the advantage of doing it? The bug Antoine pointed to shows that distros that use ConsoleKit in 3.14 are already shipping patches to keep it working. No one who has chimed in has said that one more would be a big deal. And this is really only for one release, by 3.18 everyone should be using the newer apis, and then the patches will go away. It wouldn't be a big deal to deprecate for a release but no one who will be using ConsoleKit in 3.16 advocated for that. And cutting out the code is a net win for the codebase, so I'd rather do it now than later. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hi, On Wed, Feb 4, 2015 at 4:24 AM, Olav Vitters wrote: > Having a configure option would not > mean it is suddenly gone (if they miss this email, they'd also not know > about the patch), but it clearly tells them it'll be gone. Okay so there's a pretty good middle ground we can come up with here. I'll leave the --with-console-kit argument in configure, but if it gets used, then I'll error out and point to the wiki page mclasen suggests in another message. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Discouraging use of sync APIs
Hi, On Wed, Feb 11, 2015 at 7:17 AM, Philip Withnall wrote: > It might turn out that runtime checks are just not feasible, but in that > case I think we still need some way of solving the original problem: > that people are using sync calls and blocking up the main loop. I'm all for discouraging sync use in the main thread after the application is up, but are stalled applications actually a wide spread problem? I don't really remember any apps I use regularly locking up (except for maybe hexchat when connecting to my irc proxy). Granted, it's harder to notice these days now that we have a compositor and applications don't need to redraw after getting uncovered, so it could be it's happening more than is obvious. But, I just wonder if we really need to do anything. It seems like the bad/obvious cases would get bug reports and fixes pretty quickly, and so the problem should regulate itself. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hi again, > Okay so there's a pretty good middle ground we can come up with here. > I'll leave the --with-console-kit argument in configure, but if it > gets used, then > I'll error out and point to the wiki page mclasen suggests in another message. So I started a wiki page here: https://wiki.gnome.org/wiki/Projects/ConsoleKit It probably needs to be fleshed out more. I haven't dropped the ConsoleKit support from GDM yet, but I did add the message and change configure to default with ConsoleKit off. I'll excise the code of ConsoleKit and provide the reversion patches before 3.15.91. I'm holding off for now since a bunch of changes went in for 3.15.90 and I want to make sure that things are settled down a little before generating patches (so they don't go stale right out of the gate) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone going to be using ConsoleKit for 3.16 ?
Hey, Just to follow up here... On Wed, Feb 18, 2015 at 10:31 PM, Ray Strode wrote: > I'll excise the code of ConsoleKit and provide the reversion patches > before 3.15.91. I'm holding off for now since a bunch of changes went > in for 3.15.90 and I want to make sure that things are settled down a > little before generating patches (so they don't go stale right out of > the gate) I didn't get this done for 3.15.91 and by the time 3.15.92 was around (code-freeze) I decided it's probably a little too late in the game to do it. So the new plan is keep ConsoleKit support in tree for 3.16 and just drop it from 3.18 --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How do you hack on GNOME? How can we do better?
Hi, On Mon, Jul 20, 2015 at 7:11 PM, Owen Taylor wrote:> > We can classify hacking on "GNOME" (taken very widely) into the following: > > 1) Hacking on system components that require hardware access (kernel > drivers, NetworkManager) > 2) Hacking on system components that don't inherently require hardware > access (kernel filesystems, systemd, polkit, gdm) > 3) Hacking on session level components (gnome-session, gnome-shell, > gnome-settings-daemon), and the libraries they use (gnome-desktop, clutter) > 4) Hacking on libraries (gtk+) > 5) Hacking on applications > > Which ones of these do you do? Mostly 2 and 3 for me (though all the above on occasion) > How do you do it? Is 'jhbuild run' sufficient for your needs? No, jhbuild doesn't work for GDM. (though I think Ryan got it to work at some point, some how, with patches) > Do you log into a jhbuild session? as yourself? as a test user? Do you > replace system level components? With 'make install'? I do the quickest, dirtiest, and sloppiest thing: alias %configure="./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --libdir=/usr/lib64" and then make install. Sometimes as a test user, but usually as myself. > 3 seems like a place where we can make progress - the vague idea I have is: > > - Move our standard install location back to /opt I actually like things going to /usr with the same flags as the distro packages so I can get things running pretty much the same way as downstream when i'm testing things. granted i realiize that makes some people cringe. > - Have utility scripts that set up a test user > - Have hotkeys that switch directly back and forth between the main session > and the test user session and respawn the test session I guess that will help for some cases, but a lot debugging (especailly for gnome-shell) really works better with a second machine. I realize that's not always feasible, but in some cases it's 100x easier. Even when doing app development. Clearly we should make the single system case work as well as possible, but i pretty much always try to have two machines with me if i'm doing development or debugging (even if it's two laptops at a coffeeshop) --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application id, XDG App, and you.
Hi,
> One thing I've wanted in the past is a very simple file to allow
> someone to declare an alias for an application. So GNOME Clocks would
> ship both an org.gnome.clocks.desktop and a gnome-clocks.desktop, the
> latter looking something like:
>
> [Desktop Entry]
> AliasFor=org.gnome.clocks.desktop
>
Here's the hack we did for gedit for instance:
# for backward compatibility with user defined file associations•
cat << EOF > $RPM_BUILD_ROOT%{_datadir}/applications/gedit.desktop
[Desktop Entry]
Name=gedit
Exec=gedit %U
Type=Application
MimeType=text/plain;
NoDisplay=true
X-GNOME-UsesNotifications=false
X-RHEL-AliasOf=org.gnome.gedit
EOF
Then we did a little gtk+ patch to filter X-RHEL-AliasOf entries from
the app chooser, and we still relied on the map in gnome-shell for
doing deduplication of apps in gnome-shell.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application id, XDG App, and you.
Hi, > Here's the hack we did for gedit for instance: Sorry, some how I lost the first sentence in my mail. I meant to put, "We actually ended up doing that for RHEL 7.2 when we rebased GNOME and various apps changed desktop file names," first. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm enabling Xorg to listening on tcp
Hi, On Wed, Jun 29, 2016 at 8:20 AM, Stephen Adler wrote: > You have a mechanism to turn off the use of the Xorg command line > option "-nolisten tcp" by setting "DisallowTCP=false" in the [security] > section of the /gdm/custom.conf file. The Xorg server now has "tcp > listening" turned off by default and if you wish to enable it, you need > to add the command line option "-listen tcp". How does one enable > listening on tcp withing the configuration framework of GDM? May I > suggest adding "AllowTCP=true" to the [security] section of the gdm > custom configuration file? Or is there another method of configuring > gdm so that when it starts the Xorg server it passed along "-listen > tcp" as one of the command line options? So GDM automatically figures out whether to add -nolisten tcp or -listen tcp depending on what X server is installed when GDM is built. See: https://bugzilla.gnome.org/show_bug.cgi?id=750026 and https://git.gnome.org/browse/gdm/commit/?id=3f59fa0da5168451898db63e51e312ce894af0c1 You probably just need to make sure you have your xserver devel package installed at GDM build time. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gdm enabling Xorg to listening on tcp
Hi, On Wed, Jun 29, 2016 at 10:51 AM, Stephen Adler wrote: > thanks, I just double checked on my fedora 24 installation, and it > doesn't seem to do what's advertised. Was because of a missing buildrequires in the spec file. Update is in updates-testing now: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9a33db9a54 --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
onlooking k Kinnikinnick
___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: onlooking k Kinnikinnick
(sorry my 7 month old decided to start a thread and initiate discussion) On Mon, Jul 4, 2016, 7:35 PM Ray Strode wrote: > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Multi DPI user interface
hi, On Tue, Jul 19, 2016 at 11:04 AM Jonas Ådahl wrote: > 2) Represent each monitor separately, generating one file for each This makes the most sense to me. Or even only do the active monitor. Of course for screen recording (versus screenshoting), only doing the active monitor could be weird, if the user moves their mouse from one monitor to the other mid recording. I don't like how, today, a small monitor next to a big monitor leads to screenshots with large void areas. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: g_log_structured() and introspection
Hey,
> During the talk on GLib's new structured logging API at GUADEC today,
> it was pointed out that g_log_structured() (and the rest of the
> interesting bits of the new structured logging API) are not
> introspectable.
>
> I'm not sure what we can do about this. The API is based around
> GLogField, which is basically a pointer and a length, and hence is not
> introspectable:
>
> struct _GLogField
> {
> const gchar *key;
> gconstpointer value;
> gssize length;
> };
One idea:
1) g_log_variant (GLogLevelFlags log_level, GVariant *variant);
The variant would have to be of type G_VARIANT_TYPE_VARDICT
In javascript for instance it could look like this:
fields = { 'MESSAGE': new GLib.Variant('s', 'checking for optional
sweep modulation'),
'GLIB_DOMAIN': new GLib.Variant('s', 'Foo'),
'FOO_STATE': new GLib.Variant('s', JSON.stringify(fooState)),
'FOO_AGE': new GLib.Variant('u', 3) };
GLib.log_variant(GLib.LogLevelFlags.level_debug, new
GLib.Variant('a{sv}', fields))
which is a little wordy, but not more awful than how dbus is done.
Then Gjs could ship a string only convenience
api like g_log_structured by doing:
GLib.log_structured = function(logDomain, logLevel, stringFields) = {
fields = {};
for (let key in stringFields) {
fields[key] = new GLib.Variant('s', stringFields[key]);
}
fields['GLIB_DOMAIN'] = new GLib.Variant('s', logDomain);
GLib.log_variant(logLevel, new GLib.Variant('a{sv}', fields);
}
then the javascript would be:
GLib.log_structured(GLib.LogLevelFlags.level_debug,
{ 'MESSAGE': 'checking for optional sweep
modulation',
'FOO_STATE': JSON.stringify(fooState)});
(or it could make it variadic like g_log_structured, but that's less
idiomatic for our brand of javascript)
One complication with g_log_variant, is figuring out how to send the
variant off to journald. If you just use g_variant_print, you'll end
up putting quotes around all the strings, which is probably wrong.
It's probably have to unpack the variant manually, with fall back to
g_variant_print
anyway, just an idea.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, On Tue, May 16, 2017 at 12:20 PM wrote: > Another issue we haven't discussed yet is commit permissions. Right > now, everyone can commit anything to every repository, but with GitLab > we'll probably eventually want something more fine-grained where > *active* maintainers have more control over who is allowed to commit. > uhh, why? I think the lack of fine grained ACLs is an extremely useful feature of our current setup. Are you concerned we might grow abusers at some point? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
Hi, > It's quite hard to get commit access atm because you have to be > trusted initially. If a maintainer can give commit access to one repo > he/she watches anyway there is less trust needed in the beginning. Or > if a new contributor wants to take over an abandoned project. > is that true? I mean you have to have someone with commit access vouch for you but that's a pretty low bar. I don't think it should be any lower than that, but I also wouldn't want to see it higher than that. GNOME has had open ACLs from the beginning and it's a good thing! There's no evidence of abuse, we shouldn't go locking everything down just because we can. IMO, there should be three access tiers: 1) Can report issues and propose fixes 2) Can triage issues 3) Can fix issues Anything more granular than that is a bad idea. It just introduces artificial barriers that people will run into. (What happens when a maintainer goes AWOL ?) Let's keep things open like we always have! --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 2:38 PM Carlos Soriano wrote: > That's a nice discussion to have, but a goal on the initiative was to try > to match what we have now (with the inherited niceties for those > workflow/use cases), with the less disruption possible, while keeping the > "nice things we could do" for a later case-by-case evaluation. > Right, to be clear, what i'm proposing is to keep status quo for access control, but on the new system. here's what I proposed mapped to the existing system: Can report issues and propose fixes → anyone can currently report bugs to bugzilla, and attach patches Can triage issues → those with editbugs can triage issues Can fix issues → those with commit access can fix issues. So if we keep that level of access control without adding additional ACLs and such I'm a happy camper --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Too many broken modules
Hey, On Mon, Jul 31, 2017 at 7:12 AM wrote: > 'gdm' Do you hav eany details on this one? It built during distcheck, I just tried building the tarball into an rpm and that worked, and it's not broken in continuous. I can try doing a jhbuild run with the moduleset I guess... but i'm wondering if maybe this was just angry pixies that have since mellowed out ? --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Too many broken modules
Just to follow up... > Do you hav eany details on this one? It built during distcheck, I just > tried building the tarball into an rpm and that worked, and it's not > broken in continuous. This ended up being the moduleset's GDM requiring plymouth to build, and Javier's distro not having plymouth available. He's going to change the moduleset to make plymouth optional and it should resolve the problem. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: smproxy/save.c
Hi,
> const gchar *path;
> ...
> ...
>
> path = getenv ("SM_SAVE_DIR");
> if (!path)
> path = gnome_util_home_file (NULL); (needs to be freed)
> if (!path)
> path = g_get_home_dir ();
> if (!path)
> path = getenv ("HOME");
> if (!path)
> path = ".";
>
> But I can't see how to sanely free this without redoing the whole
> function since it's assigned using different methods where some allocate
> new memory and others don't and the variable is declared as const so the
> compiler will complain loudly if you try to free it...
I don't think any of those functions are likely to return different
values during the lifetime of the program. I'd make the variable
static, and take some of the lines out, because those functions overlap
in functionality.
Maybe just do..
static const gchar *path = NULL;
if (!path)
path = (const gchar *) g_getenv ("SM_SAVE_DIR");
if (!path)
path = (const gchar *) g_build_filename (g_get_home_dir (),
".gnome2", NULL);
> Is this piece of code worth bothering to fix? It seems FC3 doesn't even
> use the session proxy at all. I don't have any ~/.gnome2/.gnome-smproxy-
> * files at least...
Probably not. The smproxy stuff is just so pre-xsmp applications can
work with gnome-session. My thoughts are that those applications aren't
integrated with the desktop in so many other ways that spending time so
that they can restore their state on login doesn't really seem useful.
--Ray Strode
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: houston, we have a problem- 2.10 showstoppers
Hi Luis, > And of course the number of patches in the fedora vte package (Kjartan > told me the count was 23) tells me that at least some of the OS > vendors /are/ distracted by it. Actually there are ~7, I think. 2 of them were written by Nalin and are in upstream CVS and 3 or 4 of them were done outside of Red Hat. The last vte package that was pushed in fedora was about 4 months ago. There is no question vte could use some work, but in the grand scheme of things, there are more important parts of the user's desktop to be focusing on, and vte, for the most part, does what it's supposed to do. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome terminal displaying utf-8 unicode text
Hi, > I would like to know which source files I should look to for to > correct the behavior. You actually want to be looking at vte, the terminal rendering widget for gnome-terminal. There are multiple levels to getting indic text to work well. 1) getting cat text_file.txt to work 2) getting ls to align columns right 3) getting line editing to work (e.g., shells) 4) getting programs like vi to work 1 and 2 are going to be a lot easier than 4. I'm not really sure how hard 3 would be. --Ray Strode ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Session Services Framework
Hi Rodrigo, > ok, attached patch, with the services framework disabled by default. You can't just disable the session management stuff. The right approach will be to load service manager stuff first, then load the session. Also, if something was started by the service manager then it shouldn't be started again by the session manager. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Session Services Framework
Hi, > this is the only thing missing in my patch (which only includes changes > in existing files, the new files, are the same version as in my previous > patch). I guess I would just need to go over the client_list in Session. > But, the problem I see is how to check we really don't want to start > that process from the session? That is, I might have a > gnome-service-launch process in autostart, and another one, to start a > different/local service on the session. > So, how to deal with that? Compare the whole command line? Comparing the whole command lines won't work, because programs started from the session manager generally have state encoded in their command lines (whatever is specified in their RestartCommand).I'd say ultimately all services should be stripped of session manager support. In the mean time, they should be invoked with --sm-disable. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Session Services Framework
Hi, > Updated patch attached So a few comments... You shoulnd't start the session until all the services are done loading. You shouldn't need the is_done function. Instead connect to the "startup-complete" signal of the service manager object. gnome-keyring-daemon isn't actually a good fit for libgnomservice. You want gnome-keyring to work when a gnome app is running in KDE for instance. It probably should just be started by the gnome-keyring client library like gconfd is started by the gconf client libraries. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Session Services Framework
Hi, > What it means right now, according to the code, is that a service > isn't started until its dependency reaches the "running" state. But > when does a service reach the "running" state? As soon as it has > been spawned? As soon as possible after its shared libraries has > been loaded and it can establish a D-BUS connection? Or when all > its initialization is complete and it is ready to provide its > service? A service isn't supposed to set its status to the running state until it's initialization is complete and it's ready to provide all the functionality it's dependents may need. Until then, it should stay in the starting state. > When using gnome-service-launch, the service reaches a "running" > state as soon as it has been spawned. If all services like this, we > get a behaviour similar to the current gnome-session behaviour > where all services are spawned one after the other, as quick as > possible (except for the delay we've introduced by making D-BUS do > the spawning and not spawning the next service until we get > notification that the first service has been spawned) One thing I was going to look into when I had some free time was investigate using libstartupnotification to know when a service reaches the running state (passing an extra arg to gnome-service-launch or something). > I think the intention here, though, is that services shouldn't be > spawned until their dependencies have been fully initialized. right. > So, e.g., we wouldn't spawn the panel until the window manager is ready > to manage the panel windows. Yup, exactly. > If that is the case, I'm not sure why > we're doing this ... certainly in the case of the panel, there's no > reason to delay the panel startup that long; the current behaviour > of spawning the panel immediately after the window manager is fine. Is it? what if the panel process puts up a dialog before the window manager is fully started? The panel shouldn't really be started until the window manager can manage it properly I think. > Looking at the list of potential session services, I don't see any > dependencies of the "wait until foo is fully initialized" sort: > > metacity, panel, nautilus, vino, gnome-settings-daemon, > gnome-volume-manager, gnome-screensaver, > gnome-keyring-daemon, Well gnome-keyring-daemon in particular should probably just be stared by its client libraries like gconfd is. > esound, assistive technologies, beagled, NetworkManager, > netapplet, resapplet Any service that has non override redirect windows have a dependency on the window manager. Any service that puts an icon in the notification area should probably have a dependency on the panel. > Also, with the likes of Vino we'd want it to be one of the last to > start up, but it has no real dependencies. So, should be add some > arbitrary dependency (e.g. NetworkManager) to ensure it gets > started up towards the end? But what happens if NetworkManager > isn't installed. Why does it need to be started at the end? Is the answer that it's non-essential for a usable desktop, so it can be started later to speed up login time? If so, then you really don't want it started anywhere in the currently services lifecycle, but after the user's session has started loading. > I'm not sure what to suggest - perhaps rename Dependencies to > StartAfter with "spawn immediately after" semantics What does starting something immediately after something else buy us? It doesn't seem useful to me. > add a WaitFor key if we really need the "wait until initialized" > semantics and > add a StartLast key for services that should be launched in a > jumble after the important stuff? Hmm. I'm okay with calling "Dependencies" "Wait For". I'm not sure how StartLast is useful. I think what we really want (and please correct me if I'm wrong) is the ability to say, "this service isn't important enough to slow down the user's login. Punt starting it until we've started the user's session". Is that correct? If so, one solution is to make gnome-session provide it's own org.gnome.Session service and just add it to the dependency tree as necessary. So then the ordering would be fundamental services -> user's session -> non-fundamental services > - I'd like to see support for conditional activation - i.e. that a > service is only started if a given GConf key is set and that > gnome-session monitors the GConf key during the session, starting > and shutting down the service based on the value of the key. Yea, that was planned (but not implemented yet). > I don't think the "Enabled" key in the service file is the right > way to do this. You don't want all these apps copying system files > to the homedir just to tweak the Enabled key - think translations > not getting updated, the file sticking around if the
Re: Missing releases and state of 3.33.90
hi, On Tue, Aug 13, 2019, 2:24 PM Olav Vitters wrote: > Hi, > > I had various issues packaging GNOME 3.33.90. It seems that there's > various modules which haven't made a release, e.g.: > - no gdm 3.33.90 > - no gnome-session 3.33.90 > sorry, will do them. Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Missing releases and state of 3.33.90
hey, On Wed, Aug 14, 2019, 4:23 PM Olav Vitters wrote: > Ah!! I thought it was intentional (more testing needed or something) as > usually release team would chase as well. I didn't expect it just to be > forgotten, else I would not have used d-d-l. Sorry for possibly being > impolite. > it wasn't forgotton, but it was very late and i wasnt giving it the priority i should have... so your email was good.. Ray > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to detect a gtk desktop programmatically
Hi, > So, with the removal of this GNOME_DESKTOP_SESSION_ID variable, how should > OpenJDK -- moving forward -- detect a Gtk-based desktop? So as I understand it, the choices for look and feel are: WindowsLookAndFeel, GTKLookAndFeel, AquaLookAndFeel, MotifLookAndFeel, and MetalLookAndFeel Of those choices, GTKLookAndFeel is the best answer for any linux desktop I think. KDE configures gtk to look nice on KDE, and the rest of the desktops use GTK or at least look good with GTK. Defaulting to Metal means looking bad on almost every desktop. Or can you think of a common desktop choice where GTK look and feel isn't the best option of the available ones? I think the logic should just be "if running linux, pick gtk". You shouldn't need to check any environment variables, imo. --Ray ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
