desktop May 2010

desktop@lists.fedoraproject.org

37 participants
18 discussions

Developer Experience
by William Jon McCann 15 Jun '10

15 Jun '10

Hey, So one thing we talked about on IRC last week was the idea of driving the design of the OS from two different and complementary angles: user experience and developer experience. We have a pretty strong and unfolding story for the evolution of the user experience but I don't yet see discussion and planning for the improvement of the developer experience. I imagine this could involve things like OS platform and subsystem design, toolkit API and SDK design, development tools, deployment and management, feedback, etc. Anyone want to take part in some discussions and/or brainstorm sessions on this? We might be able to arrange a call in number if we want to try it live. Though, first, maybe we should try to research and document things we like and dislike about existing systems. Does this sound interesting to anyone? Thanks, Jon

10 13

Out of the box Touchscreen/tablet support.
by Jóhann B. Guðmundsson 27 May '10

27 May '10

There was one tester that drop by the test list and mentioned that the touchscreen on his Lenovo Ideapad S10-3t did not work which raised the question what's the current status on out of the box touchscreen/tablet support ( single/multi ) in the Kernel/Xorg/Gnome in Fedora? Given that there are more and more touchscreen/tablets coming of the product line and they are getting increased popularity with end user perhaps it should be considered a F14 feature trying to get the best out of the box touchscreen/tablets experience for the end user? Perhaps the project could try to sponsor those that are willing to work on it by providing them with tablets? JBG http://lii-enac.fr/en/projects/shareit/xorg.html ( Running F12 with MPX support )

3 3

Initial thoughts about F14 / GNOME3
by Matthias Clasen 21 May '10

21 May '10

This Fedora cycle will see more drastic changes in the GNOME stack than usual, with GNOME3 getting rolled out. We should start early to think about how to best organize this transition in Fedora. Here are some unsorted thoughts on this: 1) GConf is getting phased out in favor of GSettings+DConf [1]. GSettings has already landed in rawhide, as part of GLib 2.25.x. For a first example of an application that has been ported from GConf to GSettings, look at evince in rawhide. GSettings relies on backends for actual data storage. The only non-toy backend that is available in rawhide right now is the GConf backend that is included in GConf 2.31. It is only meant as a transition help (it allows to switch applications to the GSettings API without migrating the user data to another storage). Any day now, dconf will be available as the main settings backend that will replace GConf. Making applications use dconf as the settings backend requires migration of existing user data. GConf comes with a tool that is intended to help with this, gsettings-data-convert(1). I plan to try this out with evince or another early-adopter application as soon as dconf is available, and then write some more detailed instructions on how to best deal with this on the packaging level. I expect that we will have a mixture of GConf- and GSettings-using applications in F14. 2) GTK+ gets a major new version, GTK3. Packages are currently under review [2]. GTK3 will be fully parallel-installable with gtk2, and applications can be ported at their own speed. >From a packaging perspective, the most important consequence of this is that packages that provides modules for GTK+ (such as image loaders, theme engines, input methods) need to provide them for both gtk2 and gtk3. As soon as the gtk3 package is in rawhide, I'll try this out for a simple example like librsvg2. Some of the notable features in GTK3 that applications may want to make use of are support for symbolic icons and dark themes. Theme packagers may want to look into providing dark variants for the themes they package. At least we should make sure that our default theme has such a variant. Here too, it is clear that F14 will still include plenty of gtk2-using applications. 3) gnome-shell will be the designated user experience. For practical reasons, the 'classical GNOME2' experience with gnome-panel+metacity will still be available, and we need a reasonable way to fall back to the GNOME2 experience if the shell does not work for some reason. I expect this to be worked out between the shell team and the gnome-session/gdm maintainers, but it is something to keep an eye on. It would also be good to start a discussion on the if/when/how of switching to the shell as the default user experience (on supported hardware). Matthias [1]http://mail.gnome.org/archives/devel-announce-list/2010-April/msg00000.ht… [2]https://bugzilla.redhat.com/show_bug.cgi?id=591222

11 13

Self introduction to the Desktop Team
by Adam Miller 19 May '10

19 May '10

Hello all, My name is Adam Miller and judging by the wiki page I've met a number of the members of the Desktop SIG at FUDCon Toronto 2010 but for those of you who I haven't met I'd like to introduce myself. I have been a Fedora contributor for a couple years now and in my time I've found interest in many different aspects of the Fedora Project (Ambassadors, Xfce SIG, ARM SIG, Packager, and QA Community contributor are my notable involvements) and as time goes on I'm becoming more and more interested in the concept of the "Fedora experience" which is what I understand to be, at least one of, the goal(s) of the Desktop SIG. I would like to join in these efforts in any place where I am able. I am emailing the list for the combined reasons of introducing myself as well as asking for guidance on "where to start." Many thanks, -AdamM -- http://maxamillion.googlepages.com --------------------------------------------------------- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

1 0

packages using gsettings
by Matthias Clasen 17 May '10

17 May '10

Hey, GConf is finally on the way out, it is being replaced by GSettings/DConf. From a packaging perspective, the following facts are important to know if your package starts using GSettings: GSettings uses schemas. These are installed as xml files in /usr/share/glib-2.0/schemas. The schemas need to be compiled into binary form using glib-compile-schemas, so you will have to add the following to your spec: %postun glib-compile-schemas /usr/share/glib-2.0/schemas ||: %posttrans glib-compile-schemas /usr/share/glib-2.0/schemas ||: If the schema is ported 1-1 from a GConf schema and uses key names including _ or other characters outside [a-z0-9-], you need to use the --allow-any-name option when calling glib-compile-schemas You can look at the rawhide evince package for an example. Matthias

3 3

sudo by default?
by William Jon McCann 17 May '10

17 May '10

Hey, So what is our view of setting up sudo by default for standalone systems? Probably has some relationship with the systems on which we prevent root logins. It is worth noting that many of us have to set up ourselves each time we install Fedora. Might be nice if something like it was done by default. Is sudo the right answer or should we be thinking about pkexec? Thoughts? Thanks, Jon

16 27

Firewall
by William Jon McCann 17 May '10

17 May '10

Hey, So I know we've had long threads about this on fedora-devel but it isn't clear to me anything came out of them. Maybe we can be more specific. Does our current firewall policy for the desktop install make sense? Does a firewall add any value at all? Should we have a bidirectional firewall? Other thoughts? I'd be interested to know if we at least have rough agreement between people who have written or maintain network listening services like David, Lennart, Colin, and Owen. Thanks, Jon

10 14

Unblock Avahi by default (for the Desktop live CDs)
by Bastien Nocera 14 May '10

14 May '10

Heya, It seems to me that Avahi would be safe to run by default. That would allow accessing remote machines through their .local names, even if it wouldn't solve the problem of sharing *from* the machine itself. But it would mean we can SSH, or VNC into local area machines, and consume data (shares, music, etc.). Comments?

9 18

RE: Droid Sans
by Hristo Petkov 09 May '10

09 May '10

Hi, I installed Droid Sans on F11 (not on the Desktop, but in the TTFs of OpenOffice). You may add Droid Sans to the repository list of F11, if you wish. (to improve the vertical compatibility of the Distros). RE: The Desktop I don't see any reasonable ground to replace Deja Vu Sans with Droid Sans on the Desktop menu - this 'font space problem' could be fixed within the Deja Vu Sans itself. Anyway. RE: The name of F14 A proposal - to remove the digits of the Distros, or at least to 'amend' the numbering. As a user I interpret this in the following fearful way: within less than 11 years of Linux Distros I would have to change my OS at least 14 times - this makes at average in every 6-8 months. Who is prepared to change the OS on his computer at that speed? Who is willing to do so, and what is the idea of all that? (BTW the competition on the software market is solving this problem by adding fractional indices). F14 could be even called with any commercialised name, like for example 'Fedora-Collection Series' (integrating the best solutions of the last five Fedora distros, providing high speed, better security, better reliability, better compatibility, better accessibility - in that direction). Deja Vu Sans and Droid Sans are the least problem. Have a nice day, Regards

1 0

Droid Sans
by William Jon McCann 07 May '10

07 May '10

Hey, I think we want to consider switching to Droid Sans for the default font. At the very least I want it included on the install/live media. What do we need to do to make this happen? I seem to recall there were some technical reasons why we weren't able to make this happen for F12. Thanks, Jon

14 27

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop May 2010