Developer Experience
by William Jon McCann
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
12 years, 9 months
Out of the box Touchscreen/tablet support.
by Jóhann B. Guðmundsson
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 )
12 years, 10 months
Initial thoughts about F14 / GNOME3
by Matthias Clasen
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....
[2]https://bugzilla.redhat.com/show_bug.cgi?id=591222
12 years, 10 months
Self introduction to the Desktop Team
by Adam Miller
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
12 years, 10 months
packages using gsettings
by Matthias Clasen
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
12 years, 10 months
sudo by default?
by William Jon McCann
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
12 years, 10 months
Firewall
by William Jon McCann
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
12 years, 10 months
Unblock Avahi by default (for the Desktop live CDs)
by Bastien Nocera
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?
12 years, 10 months
RE: Droid Sans
by Hristo Petkov
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
12 years, 11 months
Droid Sans
by William Jon McCann
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
12 years, 11 months
