Re: GNOME keyring unlocking
Le jeudi 10 octobre 2013 à 14:26 +0300, p10 a écrit : Thanks for the explanation , so the problem is not trivial . But it still stands - people are setting empty passwords to avoid entering a password every time + the auto-login option becomes practically obsolete when using the keyring. So where do I further the discussion on that - a bug , a blueprint ? What are you asking for exactly? To encrypt your keyring using a password you do not need to type at all? ;-) If you want to secure your keyring, you'll have to type at some point a secret information that is not stored on the system. If you don't need to do that, anybody could access your keyring. So that's really not an implementation issue, that's a logical one. Regards Petko On Thu, 2013-10-10 at 11:33 +0100, Simon McVittie wrote: On 10/10/13 11:13, p10 wrote: autologin doesn't unlock the keyring . I think I understand more or less why that's happening The reason is: libpam-gnome-keyring needs your password to decrypt the keyring. Without your password, it just doesn't have enough information. Now my first question is - how does GDM store the password to autologin a specific user It doesn't. GDM (or at least, enough of GDM) is a privileged process running as root with full capabilities, and can do whatever it has been configured to do, including changing its uid to you without asking for a password first. Login processes *usually* prompt for, and check, an ordinary password first - but that's not required. They can equally well use a one-time-password scheme like OATH[1], query a fingerprint reader[2], or just say yes regardless[3]. When GDM has been configured to auto-login, its policy for that user's login is just say yes. when AFAIK the kernel handles user login services The kernel doesn't handle user login services (at least, not on typical Unix OSs like Linux and *BSD). The kernel allows processes with appropriate capabilities[4] to become another user. That's all gdm has to do. S [1] more secure than ordinary passwords [2] not actually very secure [3] not at all secure [4] approximately running as root, although on a modern system, Linux capabilities (POSIX.1e draft capabilities) are also involved ___ 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: En-dash versus em-dash
Le mardi 11 décembre 2012 à 08:49 +0700, Nguyen Thai Ngoc Duy a écrit : On Tue, Dec 11, 2012 at 12:28 AM, Philip Withnall phi...@tecnocode.co.uk wrote: Creating and maintaining an en_US locale which is identical to the C locale apart from its use of UTF-8 would be a huge amount of effort for no benefit (that I know of; please correct me if I’m wrong). Updating C locale just for English benefits invalidates a lot of translations and translators have to go over and check all of them. There are about 20 supported languages iirc versus en_US.po. OTOH, speaking as an occasional French translator, I think i18n teams may be interested if somebody provided a script to apply the changes to msgid *and* msgstr so that all languages follow the new rule. For example, French translations do not use curly quotes nor ellipses currently, and a script could easily fix most European languages in one run. Languages that do not use such characters could just have their msgid strings updated so that no manual work is needed. My two cents ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Using the Unicode ellipsis (…) instead of three periods
Le lundi 03 décembre 2012 à 19:09 -0500, Jeremy Bicha a écrit : I think it's time that we move away from using three periods (...) to represent the ellipsis and instead use the Unicode character (…). This style has already been adopted by Microsoft [1] and Apple [2]. [1] http://msdn.microsoft.com/en-us/library/windows/apps/jj553415.aspx#2._Exploit_the_power_of_Unicode [2] http://developer.apple.com/library/mac/#documentation/userexperience/conceptual/applehiguidelines/TextStyle/TextStyle.html#//apple_ref/doc/uid/TP3365-TPXREF126 On the other hand, I think it's less clear whether we should change command line output as the single Unicode ellipsis takes up significantly less space than three periods in a monospace font. The Microsoft link recommends using curly quotes instead of straight ones too. Do you think this is a valuable change too? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dropping fallback mode in 3.8
Le mercredi 21 novembre 2012 à 20:53 +0100, Raphaël Jacquot a écrit : On 9 nov. 2012, at 16:56, Matthias Clasen matthias.cla...@gmail.com wrote: Hi, last weekend, the release team met and discussed (among other things) the DropOrFixFallbackMode [1] feature. We've come to the conclusion that we can't maintain fallback mode in reasonable quality, and are better off dropping it. We're now working on organizing this so that it does not create more unnecessary fallout. I don't talk often on this list, for lack of available time, but have the following to say : The decision is all nice and well. however this will force people that don't have the latest and greatest accelerated hardware to switch to something else. most PCs that are more that 2 years old are probably out of the game. now the REAL question is : Is the Gnome community NO BETTER than Microsoft at forcing Hardware Upgrades ? I really don't think this is a matter of recent hardware or not. I used GNOME Shell for several years on a laptop that I bought in 2006. So definitely not a recent machine. But it had an Intel GPU with a good support. Today, the question is more whether you have a good free driver for your card or not, which mostly depends on the hardware vendor. (And guess what, the paradox is that bleeding edge GPUs are often not supported as well as relatively older ones.) And of course, for people with poor driver support for they GPU, llvmpipe should work with reasonably recent CPUs. This is not a very strong requirement at all. My two cents ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le mardi 17 avril 2012 à 22:47 +0200, Seif Lotfy a écrit : Purpose: Zeitgeist is an event logging framework. It stores user activity in a structured manner and provides a powerful DBus API to query and monitor the log. Zeitgeist as such does not have a graphical component, but is intended to integrate wherever it makes sense. Just like Tracker, Folks and GStreamer, Zeitgeist does not provide a UI. And is not a going to be used by the user directly, but rather would allow developers to harnest the feature it provides and make something useful out of it in their UX. Preamble: It has been 3 years and 8 month since Zeitgeist started under the GNOME umbrella. We proposed Zeitgeist for inclusion in 2010 but we got rejected due to several reasons including but not limited to: * Not enough integration with GNOME applications * Project hosting difficulties You didn't say anything about the places integration to the core desktop, i.e. the Shell and the Documents app. I think this is the key point. What's the status of the experimental Finding and Reminding view that was based on Zeitgeist[1] and of the Shell extension[2]? Have you discussed with designers about that recently? I'm all for adding Zeitgeist as a dependency, but the essential question is (and has been since the beginning) how to make the best use of it in the core desktop. IMHO that's where you can break the chicken-and-egg vicious cycle. My two cents 1: http://people.gnome.org/~federico/news-2011-02.html#zeitgeist-in-gnome-shell 2: https://extensions.gnome.org/extension/62/journal/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to set a value using gsettings
Le dimanche 05 février 2012 à 16:56 +0100, Marco a écrit : ∙ The following never works: gsettings set org.gnome.settings-daemon.plugins.power idle-dim-battery true error message: GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. Failed to set value This means dconf-service is not running, and probably that it could not be started via D-Bus activation. Try running /usr/libexec/dconf-service But you'd better file a bug against dconf or your distribution. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [gnome-settings-daemon] datetime: Remove datetime D-Bus mechanism
Le samedi 28 janvier 2012 à 12:54 -0500, Colin Walters a écrit : Anyways I don't think we're in violent disagreement here, and what I want to focus on is concrete actions. Vincent, Michael, Milan, as the people who actually contributed code here - are you guys OK with the DBus backend work and/or future plans to use systemd? (My contribution was only a few lines to add Debian support, and my position doesn't reflect anything about Debian/Ubuntu since I don't contribute to these projects directly.) FWIW, I totally agree with your stance on this issue. The move towards systemd or D-Bus interfaces for distributions that don't use it is a great goal, but I think we'll all benefit from announcing better the changes in requirements. We can only count on distributor's responsibility to implement these interfaces if they are aware of this need early enough in the cycle. So now it's too late to do that, I'd say it's up to the distributors to tell us whether they think it's possible to package the systemd tools in time for 3.4. My two cents ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: File Transfers in Shell Panel
Le dimanche 22 janvier 2012 à 12:56 -0600, Jason Simanek a écrit : If the new transfers design is this: https://live.gnome.org/GnomeOS/Design/Whiteboards/Transfers that seems to explicitly exclude the use of a file manager. Which is nice and all, but the reality is that file managers are still very useful and necessary tools. My little mockup addresses a problem that exists with how Nautilus currently presents file transfer information. See also https://live.gnome.org/Design/Apps/Transfers It says the goals include File copy/move operations within the system. There's a screenshot of the current Nautilus file copy dialog in the Relevant art section there. Should I be talking directly to the Nautilus developers? Are the Gnome developers more focused on this, er, future with no file manager desktop model? I think you'd rather discuss this with designers on #gnome-design first. I don't think integrating with Nautilus is really contrary to the goals of the Transfers idea. It's just that Nautilus isn't the main objective in the designers' mind: the design will be driven by other concerns, and Nautilus will have to fit into that. About the mockup, I think the idea is definitely good, but I suspect designers will tell you to put this as an icon in the messaging bar at the bottom, which is designed for this kind of temporary task, rather than in the top panel. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop files
Le vendredi 25 novembre 2011 à 12:54 +, Patrick Welche a écrit : I hope this is the right list... My question is essentially where should desktop files be installed? http://developer.gnome.org/integration-guide/stable/desktop-files.html.en suggests /usr/share/applications or ~.local/share/applications Actually, you should use /usr/share/applications if you're installing your app to /usr, /usr/local/share/applications if you're installing it to /usr/local, and ~/.local/share/applications if you're installing it to ~. These come from the default values recommended in the Base Directory Specification[1], and defined in the Desktop Menu Specification [2][3]. This applies to applications that should be made visible to the user. however if you want your at-spi daemon to start, etc/xdg/autostart/at-spi-dbus-bus.desktop might be a good place. These OTC should be used when you want your program to start on login. The same rules as above apply: use /etc/xdg/autostart/ for installs to /usr, and ~/.config/autostart for installs to ~. This is defined in the Desktop Application Autostart Specification [4]. Hope this helps. 1: http://standards.freedesktop.org/basedir-spec/latest/ 2: http://standards.freedesktop.org/menu-spec/latest/apc.html 3: http://standards.freedesktop.org/menu-spec/latest/apcs02.html 4: http://standards.freedesktop.org/autostart-spec/autostart-spec-latest.html ___ 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
Le vendredi 20 mai 2011 à 15:12 +0200, Josselin Mouette a écrit : Le vendredi 20 mai 2011 à 09:07 -0400, Matthias Clasen a écrit : A system should be immediately usable once the installation is finished. There's plenty of scenarios where this logic doesn't work: - preinstalled or otherwise provisioned systems - generally any situation where the person doing the installation is not the same as the person using the system This is precisely the kind of situations where the installer needs to take care of everything. But should (and can) the installer also take care of setting up your Google/Facebook/Yahoo.. account? Saving your WPA passphrase in your user keyring? That will probably be even harder to do than from a special GDM session. Or maybe the installer could just take care of creating the user, and the initial setup would only be something to run for each new user? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: no external panels for gnome-control-center [was Re: GNOME Feature Proposal: Backup]
Le jeudi 12 mai 2011 à 13:48 +0200, Gendre Sebastien a écrit : System-config-* are not only one: Lirc settings? Boot (Grub+Plymouth) settings, etc. Recently, I read in Phoronix that AMD want to add the support of all these future CPU to the Free (as Freedom) bios/EFI nammed Coreboot. Some settings of this bios/EFI can be set from the operating system. So, we can have a panel for some basic settings in system settings. But only if we have this bios/EFI. How can we do that if we can't do a 3rd-party panel? With 3rd-party panel don't possible we are sure to broke these futures works, only for block some hypothetical problem. I don't think it's a good Compromise. I guess in the designer's mind, the two tools you cite are too advanced to be part of the control center. No normal user is going to need to tweak the BIOS settings, and actually I think that's exactly the kind of panel we want to block out of the control center. For system-config-printer, it might not be as clear a choice, but probably if important features are missing, they should be added to the Printing panel. And if they're not really needed for most people, it's OK for admins or geeks to use a separate tool. (Same for firewall.) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
Le mercredi 11 mai 2011 à 13:47 +0200, Michael Terry a écrit : How long to keep backups: Forever or as long as there are storage left. I like the TimeCapsule version with a nice default algorithm that tries to keep as much as possible as long as possible. The collapsing of older backups is tough with this backup format. Duplicity does not assume it can run code on the backend, so it can't really do a logarithmic collapsing of backups as they get older (unless it downloaded, collapsed, uploaded). I agree it would be a nice feature though. Why not just ask the user when performing a new backup in case there's not enough space left? Since DéjàDup already does full backups from time to time, it could notice the user that in order to backup new data, s/he needs to get rid of older versions until the date of a full backup (chosen so that just enough data can be freed to make the new one). That way, we can get rid of the somewhat scary setting How long too keep backups. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Open containing folder for all apps
Le mardi 10 mai 2011 à 19:13 +0100, Bastien Nocera a écrit : So, what do you think? The patches for apps should be pretty small, and they really provide much better circulation within your files. And applications that can send out files, could also add a little menu item to send it out using nautilus-sendto (the API there being nautilus-sendto filename). Evolution, Totem, Rhythmbox and a number of others allow you to do that. Couldn't there be a common menu in the Shell that would work like the application menu, but for documents? I think it would be a real benefit to know that in every app you use, you're able to perform common actions on the opened file, without thinking where's that button/menu again? what app am I using?. As a rough sketch, we have three items, the two latter being menus: [Activities][Application name:] [Document name] The Document menu would only be shown when the current window exports some hint about the document it's currently editing, e.g. by a X property on the window, which would be made easy via a simple GTK+ function. (AFAIK Zeitgeit wouldn't work because it doesn't know about the window, only about the application, which is needed for multi-instance apps.) Does that sound completely mad? ;-) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome Feature Request
Le lundi 09 mai 2011 à 00:58 -0400, Erick Pérez a écrit : Finally, I do think this childish behavior is not getting anything useful for no-one of us. If the spirit of the Gnome Team, is: 'Bring some code/mockups, then we will judge' Ok. Mockups would help understanding your idea, but code isn't necessary at this point. I think you'd best write a few use cases that are enough to prove that your project would be beneficial to the user experience, and that the implementation you suggest is really needed to achieve them. Have a look at the Online Accounts panel for 3.2 thread to get an insight on what kind of rationale people are expecting. I'll do it myself. And then maybe, you find it interesting, or not. That's also a possibility, of course, but you might waste time if it's not going to be accepted in the end... Mockups and use-cases are cheaper. ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Plugins, modules and extensions
Le lundi 09 mai 2011 à 17:13 +0200, Florian Müllner a écrit : So I'd imagine something simple as a gzipped tarball with a custom extension (gsx == GNOME Shell extension?) which is distributed on addons.gnome.org - then we can have a dedicated app (Desktop Extension Manager?) registered as MIME handler to deal with installation/removal/disabling/... . And upgrade. I think an important part is to allow people to get up-to-date versions of their extensions at the same time as they update their system packages. What should we do e.g. when people upgrade to GNOME 3.2 and their extensions are no longer compatible with the API? Ideally IMHO, new versions of extensions would be downloaded from addons.gnome.org when the system packages are upgraded. But if they are installed per-user, that has to be done per-user too, i.e. on first login after upgrade... I kind of hate this idea: when all apps are doing this, users are getting random dialogs about upgrades they don't understand. Though I guess that's OK if there's a single extension manager for GNOME (Shell, gedit, Epiphany...) - but don't forget Firefox is also doing this, and other third-party apps might too. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Help Wanted Installing jhbuild on LFS 6.8
Le samedi 07 mai 2011 à 23:46 -0400, Jasper St. Pierre a écrit : But this approach only goes so far: there's eventually going to be a point where you'll need a newer polkit or networkmanager version, and whoops, those need to run those as root. That said, I think jhbuild is a convenient way of building and installing GNOME and its deps to /usr. PolicyKit, NetworkManager and friends can probably work if you install them as root. That can be tricky, but that's LFS after all... ;-) So to me your only problem (for now) is that --sysconfdir doesn't seem to be taken into account by jhbuild. Maybe you should ping more clued-up people about that, e.g. fpeters on #gnome-hackers (unless he answers here). But isn't there a recommended way of building GNOME on LFS? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome3 session and gnome shell crash on sparc64: FreeBSD 9_Current
Le mercredi 20 avril 2011 à 15:52 -0400, Super Bisquit a écrit : gnome-session: http://slexy.org/view/s20L2lzAD0 gnome-shell: http://slexy.org/view/s21z3rtwzu Compiler runs with default values. Two UltraSPARCIII 750MHz cpus. Thanks for the report, but please use Bugzilla to report crashes. This list is meant to discuss GNOME development. Also, you need to type at least 'ba' in gdb to get a useful output. 'n' doesn't do anything when the program has crashed. You may also need to install debugging symbols. See http://live.gnome.org/GettingTraces Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Accounts panel for 3.2
Le mardi 19 avril 2011 à 09:08 -0400, David Zeuthen a écrit : - a daemon, goad, that implements the org.gnome.OnlineAccounts interface on a well-known object /org/gnome/OnlineAccounts and owns the well-known name org.gnome.OnlineAccounts (all this is on the session bus). Additionally, this daemon would notify the user if attention is needed (e.g. reauth) using org.freedesktop.Notificatins / libnotify. Do you really need a daemon? Sounds like everything could be handled by applications that use these accounts via the library. Is there a point in connecting to these accounts if no app is using them? If not, then notifications can be emitted by the app when it tries to connect and finds the password has changed (which would be done automatically by libgoa). And the library would get information about accounts from GSettings and gnome-keyring, without the need for any daemon. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fix gsettings path to use /org/gnome instead /apps
On jeu., 2011-03-24 at 23:41 +0100, Luca Ferretti wrote: Flash news from release team to our all brave developers. A member of release team known as *cough*Luca Ferretti*cough* was sure gsettings PATHs and gsettings IDs were the same, so he was also sure all GNOME 3 core apps were using the proper path. So he never sent any notice or filed bug report... But we don't want to blame his errors, we want to have a fine tuned GNOME 3 Desktop. A quick grep[1] shows about 15 basic modules using the wrong PATH. Patches are available here[2][3]. Looking at the patches, I see people chose different conventions for id and path. For example, the Shell uses the id org.gnome.shell, and gnome-system-monitor uses org.gnome.gnome-system-monitor. This in turns can lead to different paths: your patches use /org/gnome/gnome-shell and /org/gnome/gnome-system-monitor. But this isn't consistent with the id for the Shell (same problem with gnome-power-manager). Can we choose one of these conventions? Then, I think id and path should have the same form when there's no reason to make it different. (Personally, I think /org/gnome/shell is better than /org/gnome/gnome-shell because gnome- is redundant.) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planned GNOME Shell UI changes (was Re: String and UI Change Announcement)
Le lundi 10 janvier 2011 à 10:29 -0600, Brian Cameron a écrit : It should be simple to enhance GDM to detect when OpenGL is not available, and avoid showing session-types that require it when it cannot be used. A general interface could eventually be implemented to support this, but it might be reasonable to just hardcode this behavior for known sessions that do not work with OpenGL initially for GNOME 3. I can imagine detection being harder, though. Some cards will seem/pretend to work, but won't, either because they are too slow or because Mutter triggers major bugs on them. So it might get much more messy than checking for OpenGL. Maybe a whitelist of supported cards would have to be created, just like it was required for Compiz (at least in Ubuntu). But I'm sure Owen can tell us how this could work... Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
Le mardi 04 janvier 2011 à 10:54 +0100, Christopher Roy Bratusek a écrit : Ever thought, that the attitude of the people above (especially Emanuelles arrogant we allow you to choose another DE, that's the freedom we leave to you) might stop possible contributors from doing so? And: if critics are only allowed when providing patches, something isn't right. Unless they don't accept that they are not infaillable, why should they accept patches, as it's their mind and their decision that's ultimate, not the contributors or (even worser) users? Emanuelle said GNOME3 won't be modular anymore, so why should anyone bother providing patches, *before* they changed their mood? No one will, because their statements clearly tell people we won't accept patches in that direction, as the decision we made is already done and ultimate, we don't fail, period. That's not about patches. The decision that the Shell requires Mutter isn't something you can patch out, that's a design decision that affects the whole codebase and strongly impacts developer's efficiency and the project's stability. This decision is in the hands of people that define the general design of the GNOME desktop, who are the ones working the most on it. You can ask them to listen to your criticism, but you can't force them to drop this design, because that's not something random contributors could fix (Contrary to keeping panel and applets working in GNOME 3.) So before doing anything we would first try to open their minds by writing mails like we just did, but: they are not open-minded, so I fear we could make this discussion endless with no change in any regard. To bring this discussion to end from my side, my conclusion: Linus was absolutely right as he called them control freaks, but with GNOME3 their freakyness is taken to another dimension, if you ask me. Since they argue like what they do is ultimate, no one will waste his/her freetime to contribute patches in a direction against those decisions. (Again: I'm *not* talking about gnome-applets!) I thought we would be able to wake them up from their trance, but we failed... lot's of users already left GNOME and especially Compiz-Fans will, as soon as they recognize: GNOME3 + Compiz = Fail ... or: GNOME3 + Sawfish = Fail GNOME 3's Shell + Compiz = Fail so use GNOME 3's fallback mode + Compiz if you really like Compiz (or Sawfish). Nobody said gnome-panel was being removed. Why should someone who's hardware is capable of running Plasma (which runs just fine without 3D accel and which is equal in 2D and 3D, except animations), use an incomplete fallback rather than something more appealing? Unlike GNOME- Shell Plasms is not limited to KWin. Sooner or later people will recognize that and KDE will get lightyears in front. We wanted to point that missconcept out, but imagine this: someone would listen to a non-gods (^= non- RT) voice. OMG. The Shell requires 3D acceleration because it's at the core of its features - that's not just eye candy, that's really useful. It's almost like asking Compiz to provide a non-composited compatibility mode. Do you want the Shell to work without animations, i.e. an Exposé-like effect that wouldn't use compositing? That wouldn't be usable. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
Le mardi 04 janvier 2011 à 11:11 +, Sergey Udaltsov a écrit : From X11 POV gnome-shell is just an app. Why should it depend so heavily on features of some particular wm? Maybe because it's using Clutter, and no WM other than Mutter allows displaying windows as Clutter actors? The Shell isn't external to the WM, it lives in the WM, and thus depends on its peculiarities. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can you help me to merge your avatars?
Le mardi 23 novembre 2010 à 15:00 +0100, Mathieu Goeminne a écrit : Hello there, First of all, thanks for your work! I send you a mail because I asked a question on the Brasero IRC chat which said to ask it to you. I'm Mathieu Goeminne, a phd student (at the UMONS, Belgium) and I'm studying the free software ecosystems. A part of my job consists in a merge of all persons involved in free software (including Brasero and Evince). I designed some new algorithms, and implemented others to try to detect real physical persons behind a mail adress, a svn login, a pseudo, etc. In order to validate my algorithms, I need a merge reference, ie, a list of correspondences between all evolved people. I firstly did it manually but there are still errors on my reference. Have you a correspondency table such that using it I can say this person and this one are actually the same physical person? I'm focused on the committers, mailers and bug reporters. I think that as Johannes said, there is no such list. You have a git account, and Bugzilla account, and a mail account, but you're not forced at all to use this e-mail address for the two other accounts. If not, have you an idea about a mean to build this kind of table? I'm afraid you cannot, at least if you mean to get an exact information. People that wanted this information just did like you, by using a few tricks to approach the reality, but we can't be sure their succeeded. See for example the GNOME Census, which has required some reflections about this problem: http://blogs.gnome.org/bolsh/2010/07/28/gnome-census/ The only solution I can see is to validate a part of your data by hand, and then get a measure of what your algorithm got wrong. Then, statistical tests will give you confidence intervals that you'll be able to apply to the broader survey. But I'm sure you thought about this already. ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings best practice
Le dimanche 07 novembre 2010 à 10:57 -0500, Ryan Lortie a écrit : Hi everyone, We were sitting around at the Boston summit today (me, vuntz, tedg, and pbor via IRC) noticing that we have a mix of people using /apps/gedit/ sort of paths and /org/gnome/evince/ sort of paths in GSettings. We all prefer /org/gnome/evince/ type of paths. Hmpf, you should have spoken up earlier! ;-) This was very quickly discussed with on the list, and nobody answered then except Matthias: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00097.html I was in favor of the org/gnome/something approach, but what would then happen to /desktop/ keys, which (as Matthias said in his reply) would be better kept separate? And what about the migration now that both schemes are in use? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 external dependency proposal (accounts service)
Le mardi 12 octobre 2010 à 19:17 +0100, Bastien Nocera a écrit : On Tue, 2010-10-12 at 14:07 -0400, Ray Strode wrote: 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. +1 The users panel will be very useful in adding some long sought after basic GDM configuration, as well as replacing the horror that was gnome-about-me. With my (infanticidal ;-) gnome-system-tools maintainer hat on, I'd just like to note that I think the way forward is to use accounts-dialog and accounts service instead of users-admin and the system-tools-backends. They allow for a better integration with the desktop, e.g. by configuring preferred locale and e-mail address; the system-tools-backends don't really allow us to do this because of their too generic model. We still need to do something about the two features that accounts-dialog is missing compared to users-admin (password-less login and encrypted home directory). But that's definitely +1 for me too, since using a single backend and frontend in all distributions will be of high benefit. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: package dependencies
Le samedi 09 octobre 2010 à 22:57 -0400, Kevin McKinney a écrit : Hi Developers, I am attempting to compile the source code of a package that is looking for an old version of a dependency. The package is looking for “hal 0.5.10”; however, I have “hal 0.5.14” installed on my system. Can someone provide me with some pointers on how to upgrade a dependency within a package? The package I am updating is gnome-device-manager. Are you sure you actually have the HAL *development* files installed? You need a libhal-dev on Debian/Ubuntu, and something like libhal-devel on RPM distributions. I've checked configure.ac, and it only checks for a version superior to 0.5.10 - it doesn't require this precise version. If the previous doesn't work, please paste the actual error you get. (BTW, you can play with required versions by editing configure.ac, changing the value of LIBHAL_REQUIRED, and running ./autogen.sh afterwards.) I understand this package may be obsolete; but I would like to bring it back to life by converting the architecture from hal to udev. Any information would be helpful. Then, you can to grab David Zeuthen (davidz on IRC) to know what he thinks, since he's the guy who wrote this application and did the HAL to udev move. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: package dependencies
Le dimanche 10 octobre 2010 à 16:12 -0400, Kevin McKinney a écrit : Then, you can to grab David Zeuthen (davidz on IRC) to know what he thinks, since he's the guy who wrote this application and did the HAL to udev move. Do you know what channel he is on? I have recently tried to email him at dav...@redhat.com with no success. I have also tried to look for him on GIMPNet, channel #fedora-desktop. I basically want to find out from him if I can help fix issues and enhance the gnome-device-manager package. Dude, it's Sunday! On weekdays, he's usually on #gnome-hackers (even if he's quite busy ;-). But he's surely going to notice this thread too. Another question... Do you know where I can find this header source file: dbus/dbus-glib-lowlevel.h ? I am assuming I can download it from somewhere? $ dpkg -S dbus-glib-lowlevel.h libdbus-glib-1-dev: /usr/include/dbus-1.0/dbus/dbus-glib-lowlevel.h So you also need libdbus-glib-1-dev. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
Le jeudi 07 octobre 2010 à 08:30 -0400, Michael Terry a écrit : On 7 October 2010 07:57, Johannes Schmid j...@jsschmid.de wrote: What about Launchpad? I think if we want to integrate which other hosting possibilities we definitely need a working i18n-solution with Transiflex and Launchpad before accepting applications from there. Probably something the sysadmin-team and the i18n-team should focus on in this cycle. For Launchpad applications (such as mine, Deja Dup), I proposed three ways we could smooth the way for GNOME/LP interaction last time this came up: 1) Having an approved GNOME coding team (~gnome-team?) that the maintainer sets to own the trunk. This way, documenters and GNOME-approved coders can directly commit. It would be best if being added to that team was automatic. Then have some documentation that says, for this app, here is the trunk. 2) Having the maintainer set the approved translation team to '~gnome-translation-project' and having some documentation for translators that this particular app lives in launchpad. With Launchpad Translations, they wouldn't need direct access to trunk, but it wouldn't hurt if they chose to edit directly instead of the web interface. Existing translation teams should be encouraged to join that team (or automatically added), as it seems a little sparse right now: https://translations.launchpad.net/+groups/gnome-translation-project 3) For the documentation team, a similar situation. Again, this would need some documentation that says, 'for this app, edit docs in this trunk'. Then they could directly commit. I can't really speak for translators, as I only contributed a few strings in GNOME (but I also translate software in Ubuntu, so I know Launchpad too). But I think we're going to open Pandora's box if we allow applications to be translated using different systems. There will be the « core applications », that are hosted on git.gnome.org and get good quality translations as now, and other peripheral applications that will quite possibly get less attention because tracking their status and learning their translation systems will be a pain. The best solution IMHO would be to import PO files for all applications, and integrate them into Damned Lies. Else, we're taking the risk of losing consistency, and « moduleset » won't mean anything in the end. Of course, I'd like to hear what « real » translators think of this change. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
Le dimanche 03 octobre 2010 à 10:48 +0100, Emmanuele Bassi a écrit : then the section is referring to the licensee, i.e. people redistributing the program under the terms of the license, not the original authors of the program itself; in this case, the Debian developer applying distribution patches and thus modifying the copy of the program. Good point, but what if the author is not the copyright owner of all the codebase ? Many module maintainers (like me) are releasing modifications of a large codebase that was written by many other people. Thus, they aren't the « original authors » of their module, and I'm not sure what rule should apply (just wondering). Anyway, as you said, I think it would be good to add autotools stuff for this, and have all modules ship with their git changelog, since it can be useful to distributors and users. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bumping external dep on system-tools-backends
Hi! I'd like to raise our external dependency on system-tools-backends from 2.10.0 to 2.10.1, which I'd like to release this week if approved. This is required by the gnome-system-tools to get a more consistent handling of permissions when changing a user's UID or home directory path. The GUI (users-admin) needs to be able to rely on a stable behavior from the backends in order to ask the admin what to do, and currently this behavior varies depending on the platform (the joys of usermod...). Don't bother replying if you agree, I'll update the Wiki and jhbuild in a few days if nobody is against this. ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: desktop schemas review [was: Re: GSettings migration status]
Le samedi 03 juillet 2010 à 13:37 +0200, Christian Persch a écrit : Hi; I think we should use the opportunity of converting to gsettings to redesign the desktop schemas, not just do a 1:1 translation from gconf. Let me make some remarks about the gsettings desktop schemas as they right now are in gsettings-desktop-schemas module. I agree with most of your suggestions too. Just two remarks. snip Coincidentally, taking a look at all the summary and description strings, it seems to me that once these value enumerations are taken out, not too much remains that justifies the split between two strings. IMHO we should consider dropping summary from gschema and only provide for the one description strings. In the case of these schemas, I think you're right, but in general the split is really needed. Consider for example this Metacity key, which is only one example among many others: key name=resize-with-right-button type=b defaultfalse/default summaryWhether to resize with the right button/summary description Set this to true to resize with the right button and show a menu with the middle button while holding down the key given in mouse-button-modifier; set it to false to make it work the opposite way around. /description /key If only one string was provided, it would be a pain to find what a key is supposed to do without reading the full description. And that's what makes the settings database more useful than a mere addition of binary values (for example, if we want a « plumbing tool » to tweak advanced settings, we need it to have short and useful summaries). Looks like this should use a settings list, with a base schema containing exec, needs-term (should be needs-terminal as below) keys, and an extended schema for the browser settings adding the nremote key. I've considered this too when reading the file, but in the end I was really not sure we gain anything with a list. GSettingsList is intended for schemas that will be extended at runtime, while here we have a list that is mostly set in stone. Apps only look for a known schema, and will never want to get the list of all registered applications, nor add an application to the list. So I don't think that's worth the complexity it would add Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSettings migration status
Le vendredi 02 juillet 2010 à 02:24 +0200, Vincent Untz a écrit : Here we go: http://cgit.freedesktop.org/~vuntz/gsettings-desktop-schemas/ I'd appreciate if people can take a quick look. If everything is okay, I'll push that to git.gnome.org in a proper repository. Right now, it contains a simple conversion of a few gconf schemas from libgnome and gnome-vfs: org.gnome.Desktop.background.gschema.xml org.gnome.Desktop.default-applications.gschema.xml org.gnome.Desktop.interface.gschema.xml org.gnome.Desktop.lockdown.gschema.xml org.gnome.Desktop.url-handlers.gschema.xml I'm pretty sure there are some keys there we want to remove, or to rename, or something else, so patches welcome, etc. If something is missing, just tell me. Thanks for tackling this! I've had a look at the parts I'm interested in to port Metacity (default apps, animations, accessibility), and they look right. Hard to get wrong anyway, since these are really simple keys. Note it may be nice for translators to use the _description hack until proper gschema support lands in intltool, so that they can start working on the package. Even better if you found a way to import the old translations from libgnome and gnome-vfs... ;-) On a side note, I'd like somebody to point me to the module responsible for the /desktop/gnome/peripherals/mouse/cursor_theme key. I can't find where it was defined in GConf. Do we want this key to be included here? I'm not sure, since most modules don't need to access it; OTOH it's very close to the theming prefs that are already present. Else, we can make Metacity depend on the provider of this key, if it doesn't already. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
Le lundi 14 juin 2010 à 10:43 +0200, Rodrigo Moya a écrit : seems the situation has changed, and GTK3 will be available in Universe, but not on the CD, and all apps are going to be linked against GTK2 But is it very likely that Ubuntu CD will contain applications that still require GTK+2? If you have a look at the list published recently by Andre, it seems we're pretty close to the goal: http://blogs.gnome.org/aklapper/2010/06/10/heads-up-gnome-2-31-soon-to-ship-gtk-2-90/ And Ubuntu default packages aren't that esoteric, are they? It seems to me that fixing the few apps that still depend on GTK+2 would be less work than backporting features to 2.22 and cherry-picking change for modules that couldn't enter 10.10 because they require GTK+3. I mean: as an Ubuntu user and contributor, I'm tired of seeing that this distribution is considering itself as pure downstream, and would rather patch all they can rather than spend this effort helping the move in GNOME itself. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le dimanche 06 juin 2010 à 19:53 +0200, Tomeu Vizoso a écrit : Moving bindings modules to the Desktop moduleset won't make them less second-class citizens as long as API that is not bindable without resorting to language-specific glue code keeps being added to Platform. Examples of this are GVariant (which affects GSettings) and GDBus, in the latter this question was raised on gtk-devel but nobody showed interest in how to make the new functionality available to bindings: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00136.html I don't think the authors of those APIs are to blame for this, because they asked for feedback before merging and nobody who cared about non-C languages replied. It's nice that the release team worries about bindings because lots of software is written for GNOME in languages other than C. But today we are seeing a disproportion between the people who use bindings and those that build them and it worries me a lot. What will happen to those applications when old APIs such as GConf are not available any more and GSettings is not available to their language? An action more in accordance with the intention of making bindings a first class citizen would be to require new API (with exceptions for low level glib stuff) to be bindable by the introspecting bindings, and also maybe some thinking into why the bindings landscape is in such a mess right now. While I agree with you case about the importance of bindings, I don't see why GSettings shouldn't work with bindings. For GNOME Shell, we had a few issues with g_settings_get_strv() and g_settings_set_strv(), but the API was quickly improved, and now GObject introspection allows us to use GSettings from JavaScript via GJS without any flaw. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
Le mercredi 02 juin 2010 à 22:08 +0200, Mikkel Kamstrup Erlandsen a écrit : snip My proposal is to let us inspire by the Apache Incubator idea[1], making app inclusion a two stage process. Mature in the Gnome Incubator and then when the project is mature and well maintained it gets the honour of graduating into the Gnome Application Portfolio. It's important to note that we should be able to have several competing apps in both incubator and in the portfolio. It might not be a good idea to have 10 music players, but 3 or 4 should not be a problem. Distributors and contributors alike can make their own choices and pick their favourite(s). So I call it portfolio because it's not a module where we expect distributors to ship everything, but a collection of blessed top notch stuff. But isn't GNOME's failure to decide on a blessed music player the reason why we now have the choice between (at least) two good ones which are mostly equivalent, instead of one excellent? The same applies to Rhythmbox vs. Banshee and GThumb vs. F-Spot vs. Shotwell vs. Solang: I suspect we may be wasting energy in largely duplicated efforts. OTOH nobody has tried duplicating Evolution, Eye of GNOME or Evince - or if they have, that's gone unnoticed, which amounts to the same. Once an application is an official module, people know they better improve it and join their efforts rather than starting their random project elsewhere; eventually we get better software. I think the idea of an incubator and an app portfolio is great for optional apps, but for *essential* applications, making a (hard) choice at some point is really important. See how Brasero has improved and integrated nicely with all the desktop where GnomeBaker and others had failed for many years. GNOME INCUBATOR snip GNOME APPLICATION PORTFOLIO When an application has been in incubation and has reached maturity the maintainers, or the Gnome release team, can propose it for graduation into the portfolio, the highest honour we can attribute to a project. In addition to the points evaluated for the incubator (leaving out the last one about similar projects) the following points should be considered when evaluating a project for joining the portfolio: * i18n, l10n * a11y * help docs * Build system must be autotools * Integration * HIG compliance * Using only blessed deps * Project hosting (and VCS) is on a list of approved sites I'll second people concerned about the consistence of the infrastructure here. I guess Approved sites includes Launchpad, which I appreciate in many regards - but the whole point of defining official modules and branding their sum GNOME is to get them work together. Not only translators would have a hard time using different VCS, but developers will stay each on their module. There will eventually be a core GNOME on git.gnome.org, and second-class modules all over the place. If people aren't happy with the infrastructure, then it needs to be improved, not escaped. Anyway, for git, it's not an argument, since one can always use a bzr bridge. And one more message in this interesting-but-growing thread! ;-) Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GSettings schema paths: time to do some cleaning?
Hi! I was wondering what kind of schema paths should adopt during the migration to GSettings. Old GConf paths feel really lame, since we basically put everything into /apps, with a few general settings going to /desktop. Only /system really makes sense. This reminds people of the horrid Windows Registry's HKEY_CLASSES_ROOT and friends! ;-) If we want to choose a better way of organizing schemas, the time is now. What about going with something similar to D-Bus, with /org/gnome/my-app? This feels pretty natural, and settings would be sorted much more logically. For most simple schemas, name and path would be equivalent (i.e. org.gnome.my-app), which makes sense. System-wide settings could go into /system. Or do we want two top-level directories, /user and /system? The migration docs don't say a word about this, and Ryan told me he hasn't planned anything for that. So let's discuss this before it's too late! Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Le lundi 03 mai 2010 à 00:37 +0200, Seif Lotfy a écrit : snip So in case Zeitgeist can not be a GNOME module because of its development infrastructure, we hereby withdraw our proposal of Zeitgeist being a GNOME module and propose it as an external dependency for GNOME Activity Journal, so it will always have a close relation to GNOME. Sounds a sane solution to me, since you seem to head towards KDE support too. Though, having a git clone repository somewhere would be nice for people willing to help on both sides. It's likely that GNOME contributors will want to improve the engine, and not only the GUI. What about a clone on git.gnome.org, just like the system-tools-backends-clone one? Would there be a way in Launchpad to merge git branches by importing them to bzr? Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Finding and Reminding, tech issues, 3.0 and beyond
Le samedi 10 avril 2010 à 09:10 +0200, Johannes Schmid a écrit : Hi! There are two basic approaches here - one is to avoid storing things on the Desktop. Instead of seeing the Desktop as a separate location in the file selector, you'd have a checkbox: [ ] Pin to Desktop (or whatever the designers come up with), and that would create a symlink to the desktop. The other approach is when expiring or archiving to move files from ~/Desktop to an archival location like ~/Documents. The pinning should be done automatically and the files should stay in the place I saved them (e.g. a firefox download should end up in ~/Downloads and OO.o should default to ~/Documents. The recent files should be stored by pinning on the Desktop. Agreed. You don't even need to create a real ~/Desktop folder with symlinks in it. Let's just fill the desktop with a Tracker query just like virtual search folders are handled now. That way, you can customize what is shown on the desktop. By default, it could show files that were used in the last 15 days *and* are in a given directory. Then, files are left where they were originally saved. There's no automated archiving, it's just that files you save in the dumping directory are not always shown on your desktop, which makes it smarter and cleaner. Actually, the desktop directory becomes kind of an archive for random files you've not moved to a precise place (with tons of mess in it, like ~/Downloads ATM ;-) - but you don't matter since it's mostly hidden. If required, a special tag (e.g. desktop) can force pinning files on the desktop. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Label in tray = P in the A
Le mercredi 24 mars 2010 à 14:17 +, Sergey Udaltsov a écrit : Translated. Typically, 3 letters (well, at least that's my recommendation as maintainer of xkeyboard-config). Can't you fit these letters in a square, as small as it may be? I don't see any other solution to your problem. Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Label in tray = P in the A
Le mercredi 24 mars 2010 à 14:22 +, Sergey Udaltsov a écrit : I can fit indeed. The only thing is that the resulting font would be different from the font used in the menu. I do not see any other solution either, to be true... Yeah, that's really a hack. Hope we can get something nicer soon using a GNOME Shell extension, and libappindicator for the old panel. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Raising external dependency on System Tools Backends
Hello, fans of desktops and system tools! The upcoming GNOME System Tools and liboobs 2.29.2 depend on the System Tools Backends 2.9.0 now, which are being developed almost as a part of GNOME since we are the only client application. OK to raise the dependency on the wiki? I'd also need somebody to update the jhbuild modulesets. By the way, may I get the authorization in advance to raise the dependency as needed until the stable 2.10 is released? It's not unlikely that GNOME 2.30 will need it. (If somebody actually cares, 2.9.0 introduces a new users and groups D-Bus protocol which fixes many issues we've suffered from for a long time. Details at: http://mail.gnome.org/archives/system-tools-list/2010-January/msg0.html http://mail.gnome.org/archives/system-tools-list/2010-January/msg1.html http://mail.gnome.org/archives/system-tools-list/2010-January/msg2.html) Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: So.... Who's redoing their UI for 2.30/3.0?
Joanmarie Diggs wrote: Since there are undoubtedly countless lists I'm not on Anyone else making major UI changes? :-) In the gnome-system-tools, we're planning to redesign users-admin GUI for 2.30. I'd be happy to fix the problems you may find. You can see the new UI on our users-ui-redesign git branch (though you'll want to wait for a few months before things take shape). BTW, any remarks/help from usability guys, or anybody caring about it will be greatly appreciated. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Freeze break request] gnome-system-tools broken user creation
Le samedi 19 septembre 2009 à 14:51 +0200, Andre Klapper a écrit : Hi Milan, Am Samstag, den 19.09.2009, 14:02 +0200 schrieb Milan Bouchet-Valat: The fix I've committed to master is a one-liner with a very low risk since it only changes the uid variable to user_uid, since it's what was intended. http://git.gnome.org/cgit/gnome-system-tools/tree/src/users/user-settings.c/?h=gnome-2-28 does not include any definition for user_uid. Are you sure that your one-liner should not better be a two-liner, or am i missing something and should get a coffee first? Maybe I could stop drinking coffee and double-check my branches before requesting... I'm happy to say I had been cautious enough not to push that little feature (commit 36cdbf) to the gnome-2-28 branch, partly because it required a string change during the freeze. So everything is right now, no need to bother you with that bug. Sorry for the noise! At least, I've checked that the release team is doing its work seriously - more than I do... :-p ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
[Freeze break request] gnome-system-tools broken user creation
Hi!
I've just realized by performing some more tests that a subtly mistaken
commit from August 31st had introduced a random failure to create users.
Basically, we are checking that an UID is free by comparing all UIDs to
an uninitialized uid_t, which obviously won't work. Sometimes, you
cannot create a new user at all (when the random int is an existing
UID). Sounds like a blocker to me.
The fix I've committed to master is a one-liner with a very low risk
since it only changes the uid variable to user_uid, since it's what
was intended. No need to say, it works as expected in my tests, and
should be system-independent enough to be safe.
What I still don't understand is how it has gone unnoticed for three
weeks, even of myself. Lack of an active development and testing crew is
very sad...
OK to push that to the gnome-2-28 branch?
From cb83e86d2dbb4df44e7d00a3ae809fe88a718547 Mon Sep 17 00:00:00 2001
From: Milan Bouchet-Valat nalimi...@club.fr
Date: Sat, 19 Sep 2009 13:45:07 +0200
Subject: [PATCH] Fix checking whether an UID is free
A mistake in variables could prevent user creation from working at all. We were comparing UIDs with an uninitialized int, leading to strange results. This was introduced by 36cdbf80fa16cfac1a15f24ee32c2b272f68e521.
---
src/users/user-settings.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/users/user-settings.c b/src/users/user-settings.c
index 74d68fe..227b27b 100644
--- a/src/users/user-settings.c
+++ b/src/users/user-settings.c
@@ -339,7 +339,7 @@ uid_exists (uid_t uid)
while (valid) {
user = oobs_list_get (list, list_iter);
- uid = oobs_user_get_uid (OOBS_USER (user));
+ user_uid = oobs_user_get_uid (OOBS_USER (user));
g_object_unref (user);
if (user_uid == uid)
--
1.6.0.4
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping/Dropping the PolicyKit external dep
Frederic Peters wrote: - gnome-system-tools still depends on the old version, and I don't see it listed in the Fedora feature page As of 2.27.3, released today, the gnome-system-tools use PolicyKit1 (well, actually, polkit-gtk-1). They require the system-tools-backends 2.8 or above for that. They are not listed on the Fedora wiki since they don't use them (sadly...). That said, I've just checked the external dependency list, and PolicyKit is still 0.9. Is it outdated? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Le lundi 20 avril 2009 à 16:10 -0700, Dylan McCall a écrit : I do have a guess what could be done. Firstly, abolish applets as things which must be run differently from other applications; the user should not Ever see the word applet again. Enhance running applications and how they connect with application launchers and their windows; one of the things GNOME Shell seems to be doing. Maybe one way about this is to build on that part of the window manager where it's up to The User whether he wants to minimize a window, shade it or put it beside another on the right side of the screen. How about window management hotspots, such as a panel and a sidebar, each with unique properties for how they treat windows? The user places a window in one of those and, depending on whether it supports some fancy extensions, it becomes a docked window like any file in the panel or the desktop (eg: a window icon that when clicked opens into a full window again). Super awesomeness could extend that so the docked window gains desklety / applety functionality when supported. Basically, kill the distinction and leave it up to the user to say what he wants a window to do rather than have them making unpredictable guesses, and have the window - or whatever other object - do what it can to meet the user's commands. While I agree your proposal would be a great enhancement for most applications that abuse of the notification area (e.g. music players), I don't think that could fully replace applets. Applets like timerapplet or sticky notes are different from standard applications in the sense that you don't work with them as a full task, but only keep them in the background to be easily accessible, while you actually use them for a very short period. The point with them is that the ratio (time running)/(time use) is very low compared with e.g. a text processor. Thus, you need them not to take too much space on the screen, not even, as you suggested, stacked in a corner by the window manager. I'd argue that the best place to put them is on a separate layer à la dashboard (Apple), or directly on the desktop. This layer could be accessed with a button in the top panel, somewhere or in the overlay. Many widgets of this kind exist, see Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way of reintroducing applets in a correct way would be to support e.g. Screenlets in an overlay: replacements for Tomboy already exist in that framework, which is AFAIK compatible with other widget formats. At least, that's really how I consider we could get rid of the clutter on the main screen, which is distracting us with icons we don't need to be always visible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Mon, 9 Feb 2009, Alberto Ruiz wrote: What is Pulse? What is Mallard? How can they help? I've been thinking how hard would it be to have a very basic webkit based editor that would convert the html it generates into docbook? Really, good documentation writers are most likely people with no skills on SVN/DVCS/Docbook/XML whatsoever. We should provide a focused editor supporting the very basic stuff to write a good GNOME document. I second this. For some time I've been thinking that a wiki infrastructure would be the only way to really improve GNOME's documentation. Many people contribute to Wikipedia, which is not WYSIWYG, so if DocBook/Mallard's syntax is not so hard to learn, I guess we can leverage a large support from users. See how distribution docs are good on many subjects. People (included myself) like to contribute if the starting cost is not too high. And especially following a thematic organisation around common problems rather than a boring explanation of the GUIs. I don't know if setting up such a system would be easy, but IMHO that would definitely help our heros at the documentation team. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Mon, 9 Feb 2009, Alberto Ruiz wrote: What is Pulse? What is Mallard? How can they help? I've been thinking how hard would it be to have a very basic webkit based editor that would convert the html it generates into docbook? Really, good documentation writers are most likely people with no skills on SVN/DVCS/Docbook/XML whatsoever. We should provide a focused editor supporting the very basic stuff to write a good GNOME document. I second this. For some time I've been thinking that a wiki infrastructure would be the only way to really improve GNOME's documentation. Many people contribute to Wikipedia, which is not WYSIWYG, so if DocBook/Mallard's syntax is not so hard to learn, I guess we can leverage a large support from users. See how distribution docs are good on many subjects. People (included myself) like to contribute if the starting cost is not too high. And especially following a thematic organisation around common problems rather than a boring explanation of the GUIs. I don't know if setting up such a system would be easy, but IMHO that would definitely help our heros at the documentation team. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: quo vadis, docs
On Mon, 9 Feb 2009, Alberto Ruiz wrote: What is Pulse? What is Mallard? How can they help? I've been thinking how hard would it be to have a very basic webkit based editor that would convert the html it generates into docbook? Really, good documentation writers are most likely people with no skills on SVN/DVCS/Docbook/XML whatsoever. We should provide a focused editor supporting the very basic stuff to write a good GNOME document. I second this. For some time I've been thinking that a wiki infrastructure would be the only way to really improve GNOME's documentation. Many people contribute to Wikipedia, which is not WYSIWYG, so if DocBook/Mallard's syntax is not so hard to learn, I guess we can leverage a large support from users. See how distribution docs are good on many subjects. People (included myself) like to contribute if the starting cost is not too high. And especially following a thematic organisation around common problems rather than a boring explanation of the GUIs. I don't know if setting up such a system would be easy, but IMHO that would definitely help our heros at the documentation team. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: Password-less login with gnome-system-tools
On Sat, 7 Jun 2008 Wouter Bolsterlee wrote: It would help if you file a bug, so that the relevant people will be notified and your patch does not go unnoticed. Good idea. I've just updated bug 414852 [1], adding comments and my patch. But I suspect it will soon be forgotten if nobody reviews the patch now. ;-) Cheers 1: http://bugzilla.gnome.org/show_bug.cgi?id=414852 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Password-less login with gnome-system-tools
A month ago, I wrote [1] to the gnome-system-tools list proposing to implement a nice feature: password-less connections via GDM and gnome-screensaver (see the original message for details and explanations). I got a quick answer from Carlos Garnacho, the g-s-t maintainer, giving me a hint to achieve this easily. I've proposed a rough patch [2] in the same thread, in hope I'd get comments and help. But still nothing has come, and I couldn't get any anwser! Would somebody care about this and tell me what I should change or improve in order to get this committed? I cannot do this alone, and it would be very cool we get this easy-to-add feature in 2.24. Best regards 1: http://mail.gnome.org/archives/system-tools-list/2008-May/msg0.html 2: http://mail.gnome.org/archives/system-tools-list/2008-May/msg7.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
