I've created a new basic layout for the cd:
The size on todays rawhide is about 667 MB.
Please tell me which package should be added or removed.
On todays KDE-SIG-Meeting Rex Dieter and Kevin Kofler suggested to give
the local communities the ability to create their own localized cds
easily. To do this there should be an extra configuration file for each
language which adds the needed packages and do some configurations. And
also the additional language must fit on one cd.
A second option for localized versions could (or should?) be a
live-dvd with all available language packages. livecd-creator in git
seems to be able to do this (but I haven't checked this yet). 
I've created a first draft for an configuration for the german language.
This adds kde-i18n-de and koffice-langpack-de to the cd. Also the
standard keyboard layout, the local timezone and the locale is changed.
To change the keyboard layout inside kde I've used an ugly
If anybody knows a better way, please tell me. :)
Compared to the version above this one needs ~675 MB.
To create the configuration files for different languages I need some
informations from one person that uses the language:
4. keybordtype from "system-config-keyboard --help"
5. needed additional packages (eg. scim-* or fonts-*)
And of course all are invited to discuss this. :)
How to create the live cd:
rpm -ivh livecd-tools-001-3.fc7.i386.rpm
Create the spin:
To create the german version:
On Wed, 2007-03-28 at 21:22 -0400, Kristian Høgsberg wrote:
> I added the appearance, the workspace and the above patches from the GNOME
> bugzilla locally and from a quick look-through they seem OK and they work
> pretty well. I'm not sure if we wan't to add this stuff after the FC7 feature
> freeze - Matthias?
If they work thats fine with me. Wrt. to the ABOVE patch note that I
sent mail to the wm-spec list to get _NET_WM_ACTION_ABOVE/BELOW added to
Kristian Høgsberg wrote:
> dragoran wrote:
>> With fc6 compiz and AIGLX got into fedora and we should improve the
>> user expirence with this in F7, not make it worse.
>> We also need to integrate compiz better into our desktop.
>> Right now its easy to active and to disable with the "Desktop
>> Effects" app.
>> But this does not work correctly due to some regressions.
>> 1)Compiz gets started from the session manager and so its not
>> possible to switch compiz->metacity because compiz restarts itself.
> I couldn't reproduce this, but it does look like compiz should
> properly deregister itself. I sent a patch reply to your mail on the
> compiz list, if you could try that out and see if it work that'd be
ok I will test it but not today.. have some work that has to be finished
by tomorrow :(
>> 2)The next thing is that if compiz is configured to use 4 Viewports
>> and Metacity 4 Workspaces compiz will ignore its own setting and use
>> the metacity one until X is restarted.
> Yeah, I reproduced this and it's pretty confusing when you both have
> workspace and viewports active. I'm not sure that feature is even in
it is... the cube does not work without viewports thats why because it
has both now...
>> The god news are that this stuff is fixed, we only need to get the
>> fixes into fedora ;)
>> There is a patch for 1) in bugzilla:
>> As for 2) I have sent a patch upstream which is merged into current
>> git. It adds a --ignore-desktop-hints commandline switch to compiz
>> which fixes this behavior. We need to either make it the default by
>> patching compiz or start compiz with this option from "Desktop
>> Effects". ( I can send a patch for desktop-effects/compiz if needed)
> I'd rather not have to patch this - for our 0.3.6 RPM we'll probably
> have to, but longer term I don't see why compiz would ever want to
> have this behaviour.
ok, then we should move this discussion upstream...
look at this commit:
>> After doing this the switching between metacity and compiz should
>> work as fine as it did when fc6 got released. (The current f6 updates
>> have the same problems). I am using a custom compiz package(git
>> snapshot) with this changes and it works without any problems and is
>> stable. (With compiz-0.3.6 the window decorator sometimes crashes but
>> this is fixed in git; have not seen any crash with it). We have
>> shipped a git snapshot in fc6 so this should not be the problem, also
>> 0.4 should be out sometime soon.
> I haven't seen it crash when I've used it. Do you have an idea what
> the fix is in upstream or could you try to get a backtrace of the crash?
I don't know exactly what has fixed it upstream.. I will test it
tomorrow again, and try to get a backtrace, the problem is that it isn't
easy to reproduce, sometimes it happens after some minutes sometimes it
works for hours with no problems.
as for current git, it never happend for me...
> When we shipped a git snapshot there wasn't an official release out
> yet. I'd like to stick with 0.3.6 until 0.4 is released, and in any
> case, we're not making that change for FC7 at this point.
ok but 0.4 should be out before F7 final so I hope this makes it in.
With fc6 compiz and AIGLX got into fedora and we should improve the user
expirence with this in F7, not make it worse.
We also need to integrate compiz better into our desktop.
Right now its easy to active and to disable with the "Desktop Effects" app.
But this does not work correctly due to some regressions.
1)Compiz gets started from the session manager and so its not possible
to switch compiz->metacity because compiz restarts itself.
2)The next thing is that if compiz is configured to use 4 Viewports and
Metacity 4 Workspaces compiz will ignore its own setting and use the
metacity one until X is restarted.
The god news are that this stuff is fixed, we only need to get the fixes
into fedora ;)
There is a patch for 1) in bugzilla:
As for 2) I have sent a patch upstream which is merged into current git.
It adds a --ignore-desktop-hints commandline switch to compiz which
fixes this behavior. We need to either make it the default by patching
compiz or start compiz with this option from "Desktop Effects". ( I can
send a patch for desktop-effects/compiz if needed)
After doing this the switching between metacity and compiz should work
as fine as it did when fc6 got released. (The current f6 updates have
the same problems). I am using a custom compiz package(git snapshot)
with this changes and it works without any problems and is stable. (With
compiz-0.3.6 the window decorator sometimes crashes but this is fixed in
git; have not seen any crash with it). We have shipped a git snapshot in
fc6 so this should not be the problem, also 0.4 should be out sometime soon.
The next thing is libwnck. Compiz supports the "Always on top" feature
but it is not selectable in the menu because of a bug in libwnck. There
is a patch for it in the gnome bugzilla:
The patch in question is the _NET_WM_STATE_ABOVE.patch we should get
this into our libwnck package. We already have patches in libwnck and
gnome-panel for compiz integration so it would not hurt to add this
small patch too.
There is also the viewport.patch in this bugzilla entry. I am not using
this myself right now (so I can't comment on its stability) but we also
should aim to get this patch in too.
P.S: please don't start a compiz <> beryl flamewar
Read below the line with the many (---) signs for the german version of this
I am a student at the technical university of Vienna. I hope that you can
help me out by taking part in my online questionnaire, which deals with
usability aspects of the two biggest user interfaces Gnome and KDE for open
source desktops. I am doing this research as a part of my theses in computer
science. The questionnaire can be found at:
Even if you are not familiar with those terms right now your contribution is
still of great value to me. Thank you for participating.
Ich bin Student an der Technischen Universität in Wien. Ich hoffe, dass du
kurz Zeit hast und mir beim Herausfinden von Usabilityaspekten der beiden
großen Benutzerschnittstellen Gnome und KDE behilflich sein kannst. Ich führe
diese Umfrage im Rahmen meiner Diplomarbeit für Informatik durch und würde
dich bitten unter folgendem Link:
daran teilzunehmen. Auch wenn dir diese beiden Begriffe momentan unbekannt
scheinen ist dein Beitrag wertvoll. Danke für deine Teilnahme.
I’d like to thank everyone for their submissions to the User Image
Request. We received 67 submissions. Along with the images we already
had and those from the User Pictures Project, this gave us a total of
223 images from which to choose. Needless to say, it was difficult to
narrow these down to 24 default images, but here they are. 
All 223 images will be packaged along with the release, but they can be
found now at:  for the set of 24,  for extras, and  for the
source files (warning 49.7M). I would encourage everyone to explore the
others and find the one that works best for him/her. In addition, I hope
that these will serve as inspiration for other submissions in the
future. Thanks again to everyone for participating in this project.
John W. Lockhart
Jiri Jakub Masek
If I have missed anyone, I apologize. All the submissions and their
contributor information can be found at GNOME-look.org (Content:Clipart,
Name: UserImage - [name of submission]) and User Picture Project. All
images are licensed as GPL.
Red Hat Visual Designer
So we've been collecting some application usage statistics  on
mugshot for a little while now and it's starting to reveal some
interesting (and obvious) stuff. You could look at evolution vs.
thunderbird and firefox vs. epiphany or gossip vs. gaim. It's a bit
hard to pull enough context into those comparisons to really get down to
the reasons why some are used more than others but it's a good start so far.
If you're not aware of the application statistics take a look the
statistics page  as well as the recent blog entry  for some
background. In a nutshell we've asked mugshot users anonymously share
their application usage statistics in order to determine application
popularity. Mugshot is cool and free and open to everyone , you can
sign up today if any of this interests you.
So now we're moving this application statistics idea on to a new phase
and are looking for ideas. During our talk at FUDCon we showed a couple
of mockups  of things we were possibly looking at doing. While we're
still touching on most of the different areas shown there we now have a
decent prototype for the statistical application usage information and
it would be great to drive in that direction for a little while.
We're looking into, as it was suggested on the blog, that we might
provide correlations between usage such that you could see xterm users
are more likely to run xmms. However there might be other correlations
that would be good to show as well.
Also we're trying to figure out how we can determine related
applications. Mime types are a bit of a mess to try linking similar
applications together so we might have to ask people to help edit the
information wiki style. The application categorires are problematic for
this as well. Right now there doesn't seem to be any existing
information on how thunderbird, evolution, and balsa are all email clients.
While our application pages don't always correspond directly to a
project we've looked into providing doap  files for all of our
application information. Because of the disconnect between application,
package, and project this might not work out but it's certainly possible
to provide some information in this format.
As this mockup  suggests we're currently looking into how we could
offer install links for applications thus giving a bit more of a
application browse and download / install feel. The backend bits to
this all use yum / pirut to handle the actual install. And we've also
added a way to pull in more application description information as well.
There's a little bit more information available on the app stats wiki
page  if you still have general questions.
I want to start a discussion about the package list on a possible
f7-kde-livecd. It would be much easier for me to test some
configurations when the direction is cleared. :)
So I've got some questions:
1. Configuration: Do we want (according to the gnome/desktop-livecd) a
base configuration and an "advanced" configuration? Of course only one
(the advanced) would be created and published. But having a standard
configuration would it make easier to change some things.
2. Browser/Email: Do we want Firefox and/or Evolution on the live-cd?
(Be aware that space is limited)
3. Do we want krusader and/or dolphin on the live-cd? In general:
Do we want duplications in the functionality of applications (not as
easy as it sounds; eg. amarok vs. noatun?
4. What about localisation? The kde-i18n-packages are not really slim.
So perhaps putting them on a live-dvd would be the better idea
(gnome/desktop-livecd is fully localized)
For comparison of sizes (the named packages are listed in
20-fedora-livecd-kde.conf and of course have dependencies):
a) A suggested base cd has the size of ~474 MB (here on i386)
Packages: chkconfig, xorg-x11-drivers, system-config-display,
vim-minimal pirut, setroubleshoot, system-config-rootpassword,
system-config-printer, alsa-utils, dejavu-lgc-fonts, arts, kdelibs,
kdebase, kdeadmin, kdeaccessibility, kdeartwork, kdebindings,
kdegraphics, kdenetwork, kdepim, knetworkmanager, k3b, kaffeine,
b) An "advanced" CD uses ~705 MB.
Packages: as in a) plus:
kdeartwork-icons, kdeedu, kdegames, kdetoys, kdeutils, akode, amarok,
beryl-kde, cups, digikam, digikamimageplugins, gnupg2, gpgme,
gstreamer-plugins-base, gstreamer-plugins-good, gstreamer-tools,
gtk-qt-engine, kmenu-gnome, koffice-suite, konversation, krusader,
ktorrent, pinentry-qt, twinkle, taskjuggler, samba-client
c) A localized cd with kde-i18n-* uses ~690MB.
Packages: chkconfig, xorg-x11-drivers, system-config-display,
vim-minimal, pirut, setroubleshoot, system-config-rootpassword,
alsa-utils, dejavu-lgc-fonts, kdelibs, kdebase, arts, kdeaccessibility,
kdeartwork, kdebindings, kdegraphics, kdenetwork, kdepim,
(I'm surely missed some usefull packages)
So the steps for the next time should be:
1. Decide about the packages that should definitely be there (as base
configuration (eg. kdenetwork: yes; kdegames: no)
2. Decide about the configuration for livecd-creator (eg.
20-fedora-livecd-kde.conf AND 30-fedora-livecd-kde-advanced.conf OR
only one configuration)
3. Decide about the addon packages. Not all from
could be integrated into one cd.
4. Test the configurations on all archs (not sure if the size is the
same on x86_64 or ppc).
Of course, these things are all suggestions. :)
Will be happy about some feedback