desktop August 2007

desktop@lists.fedoraproject.org

57 participants
21 discussions

no epiphany.i386 package for Fedora x86_64 ?
by Anuj Verma (Kevin) 11 Sep '07

11 Sep '07

Hello, I use epiphany as my default browser of choice instead firefox. This goes well on i386 installs of Fedora but on x86_64 installations this becomes a trouble, if tools like nspluginwrapper are not working fine or if 64bit JRE plugin is not there yet. Fedora for x86_64 has a firefox.i386 package for 32bit compatibility, should epiphany also have epiphany.i386 package in x86_64 repo ? Kevin

4 6

PackageKit Misconceptions
by Richard Hughes 01 Sep '07

01 Sep '07

Hi guys. I've been pointed to the "low-hanging fruit" discussion on this list by a couple of people. I wasn't on this list, but now am. So what is PackageKit: • A daemon that accepts asynchronous jobs. • A way of letting certain groups of people do stuff to the package database with a fine grained server-client security model. • A system service that starts only when needed. • A way of inhibiting suspend/hibernate/restart/shutdown when performing actions. • An interface to a packaging backend. The fine grained security model allows an installer application to be loaded as the user (without a root password), to do searches without a password, and to only ask the user for authentication for any privileged task, for instance updating the system or installing a package. This lets the admin decide what level of security is best for the box in question. [http://people.freedesktop.org/~hughsient/temp/pk-polkit.png] A packaging backend can be something in a thread like libapt-pkg (as it has a C++ binding) or using a polling backend with external helper scripts for stuff like yum (python) or urpmi (perl) with no C bindings. The helper scripts communicate over stdin, stderr and stdout using a loosly defined (by the backend) protocol, in an effort to make scripted synchronous operations into async ones with a common DBUS interface. I've started to define this here: [http://gitweb.freedesktop.org/?p=users/hughsient/PackageKit.git;a=blob_plai…] What is Packagekit-gnome: • An lightweight update applet that runs once per logged in user that refreshes the cache at startup and displays update status and critical security warnings. [http://people.freedesktop.org/~hughsient/temp/pk-updates-warning.png] • A way of seeing what other users are doing with PackageKit, so you can see why the hdd light is flashing after doing a fast user switch somewhere else. • An application installer. Note, gnome-app-install is probably going to be the long term target as this will be ported to the PackageKit API. [http://people.freedesktop.org/~hughsient/temp/pk-application2.png] So, misconceptions in the thread so far (in my opinion): Pirut and PackageKit are mutually exclusive: You can happily run them both side by side. I am now. If pirut is open then PK should queue the request until pirut is closed. PackageKit is vapourware: Nope, I'm running it right now. True, only the dummy backend is supported but the apt and yum backends are coming on. The deps are also pretty harsh; you need PolicyKit, dbus-glib, dbus and PolicyKit-gnome all from git. F8 rpm's for PackageKit are in my repo [http://people.freedesktop.org/~hughsient/fedora/]. PackageKit API is rubbish: I know. It's unstable right now, and is changing to fulfill all the use-cases. My view is you have to let an API evolve to be optimal, rather than over-engineer everything when the complexities are not known. [http://people.freedesktop.org/~hughsient/temp/pk-interface.xml] Error enums will not be powerful enough Fair enough, I hear you loud and clear. Maybe we can set a hint to the backend about the locale, but I would have to think about this more. PackageKit will be included in F9/F10/desktop-spin/crackpot-spin That's up to you guys. I think it will be some time before the API is stable, and all the UI and policy bits and bobs are worked out. PackageKit also needs a security code review as sometimes it's running as the root user. So, the short story is I'm not pushing this to be included in fedora right now, as it can only do 10% of what the current tools can do. PackageKit allows you to install stuff without a password Well, it allows the admin to set what sort of authentication you need to do each action, be it your own password, an admins password, or just to deny the request. PackageKit is yet another system daemon to be started at boot time: Nope, it's started only when needed using system activation, and quits a few seconds after finishing it's last queued task. We are just a layer over yum -y --ask-no-questions: If PackageKit is just a layer, I think the layer allows us to do some important things the old system could not, and allows us to share code between distros and desktop projects. Also, my view is that questions should never be asked. Who has ever clicked no to "Load GPG key from Fedora Project"? Is there a legal requirement to show such a warning? So, I hope that has cleared things up a bit. Comments and suggestions welcome. Thanks, Richard Hughes.

13 41

no Desktop SIG meeting today
by David Zeuthen 29 Aug '07

29 Aug '07

Hi, There is no meeting today; Matthias is out on vacation, Chris is dealing with fender bender and the rest of us didn't send out an agenda / organize it in time. Apologies. We'll meet next week; will be a good time to reflect on F8t2 and the road ahead bringing us to Fedora 8. Thanks, David

1 0

Okay earlygdm re-tooled for a desktop spin
by Jon Nettleton 29 Aug '07

29 Aug '07

Based on some urging from the community I decided to re-tool what I had and release a version of patches to it that could use the existing rhgb without any patches. You can download the svn diff here http://www.hekanetworks.com/~jnettlet/open-source/fedora/earlygdm.diff Before you just going and applying this patch to your system here are the working internals *!!!!* I have patched start_udev so it can be run in two separate pieces. So I had the necessary pieces to start X without waiting 7 seconds staring at starting udev *yawn* this was necessary. There is no reason we can't dupe start_udev into two individual files that doesn't touch the original file. I am open to doing that. I don't have init level checking in my code yet. It is simple to do I just haven't done it yet. I have gdm reading from a custom earlygdm.conf file so you can mess with that without changing your systems default behavior. One other patch just moves the acpi module installation to /etc/sysconfig/modules . Working the rc.sysinit I just kept seeing that there and had no idea why were weren't using the mechanism 10 lines above it. Right now this works seamlessly on my nvidia box, but my openchrome laptop is killing off the x-server before the gdm greeter has run. My guess is my laptop is slow enough that it is hitting one of gdm's timeout values and the slave is getting reset. Currently the manual fscking and such is not interactive because rhgb needs another fifo to send input back from it's vte to another program. I started writing this and then decided to wait until I found out what other people think. I am also toying with allowing rhgb to do gtk.embedding, or possibly create an overlay like gdm uses to run it's setup program, so the apps run in rc.sysinit if it is unconfigured can run their Xorg counterparts. I am also tempted to play around with Zenity to see what else we can do to remove the need for a terminal and give more intuitive dialogs easily. Jon

1 0

livecd hacking
by Colin Walters 29 Aug '07

29 Aug '07

I've done some work on the Live CD kickstart images, available here: http://submind.verbum.org/~walters/livecd.git/ (Until Jeremy returns from vacation and can review patches to be put in the main livecd git repository) The most important change so far is to create "livecd-desktop-minimal.ks" which is then used as a basis for: livecd-fedora-desktop.ks livecd-fedora-kde.ks livecd-online-desktop.ks Rather than each thing duplicating a lot of code for the livecd init script, etc. The online-desktop is just a stub right now while I fix up some issues, but I've booted the livecd-fedora-desktop successfully (livecd-desktop-minimal.ks also boots...into twm! Retro.). Admittedly I haven't tested the KDE one, but moving forward this unforking should help us to identify changes common between them which seem like good candidates for comps or Fedora package changes. Sebastian, since you were the last person to touch the KDE bits, could you have a look at these changes? I also added a number of improvements to livecd-creator, the git log has the gory details.

11 30

low-hanging fruit
by Matthias Clasen 28 Aug '07

28 Aug '07

As discussed in the meeting, here is my personal "laundry list" of low-hanging fruit. Note that some of these are being worked on for F8 anyway. - enable nss-mdns by default - clean up emblems in nautilus - remove obsolete applets - reconsider default panel config (launchers) - unlock keyring on login - use xdg-user-dirs consistently - disable root login - get rid of xfs - get rid of pam_console - NM by default - PA by default - get rid of a bunch of services that we don't need on a live cd, like nfs/rpc/autofs - have a close look at the system-config tools we install - cleaned up artwork packaging And here are some larger things: - rethink installation and updates (see hughsie's recent work) - desktop background stuff: slideshows, channels, per-workspace - no lvm/raid in livecd installer - good xrandr 1.2 support - no root user - replace init system - new graphical boot - composited desktop by default - rethink user account handling: kiosk mode (?), guest accounts Matthias

36 183

More low hanging fruit.
by Jon Nettleton 27 Aug '07

27 Aug '07

Should the desktop release have X run on vt1 and a text console on vt2? I also don't see much reason to have more than that either. I probably wouldn't remove them from inittab just disable them in run level 5. Jon

12 35

PA by default
by Bastien Nocera 27 Aug '07

27 Aug '07

Heya, Before Fedora 8, is there a plan to fix a few regressions or integration issue with PA? From: https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01196.html > You also have to make sure that some GConf keys are set up properly: > > /system/gstreamer/0.10/default/audiosrc -> pulsesrc > /system/gstreamer/0.10/default/audiosink -> pulsesink (or autoaudiosink) > /system/gstreamer/0.10/default/chataudiosink -> pulsesink (or autoaudiosink) > /system/gstreamer/0.10/default/musicaudiosink -> pulsesink (or autoaudiosink) This means that the "Devices" part of the Sound Preferences in GNOME is pretty useless. I guess there's a PA specific way of changing the default input and output, but you lose integration with the desktop. This will also probably break the device selection that the volume applet uses (it uses the same as the default sound events device, iirc). I'm also thinking of applications' volume setup. At least Totem and Rhythmbox have the concept of "system volume" (which is per device, and they don't touch), and the "application volume" (which they do). Here, we're adding the "PA volume". How do we plan on handling that? Cheers

2 5

Idea: easier transition for newcomers from other DEs/OSes
by Martin Sourada 26 Aug '07

26 Aug '07

Hi, It's all about picking default settings new users wish. Imagine a user who is coming from Windows to Fedora, but he has no clue how linux works. It would greatly help him if the linux behaved to some extent similar to Windows - meaning applications look (themes), window's buttons layout (in this case same), menu layout, keyboard shortcuts etc. The same for users coming from Mac OS and for users used to Gnome and switching to KDE and opposite way. The idea is that user selects what he wants his desktop resemble, and then the usage of the desktop would be more intuitive to him. What would we need for that? 1. Check out, how much we can set up GNOME/KDE to look and behave like other DEs/OSes 2. If some of the stuff which makes this easier is available, but not in fedora, get it into repository 3. Write a utility that can change the DE's settings to what we have found in 1. 4. Integrate the utility into anaconda or first boot. The utility should be pretty straightforward - you will have a bunch of radio buttons captioned Windows 9x, Windows XP, Windows Vista, Mac OS X (dunno version differences though, might need more radio buttons for that one), GNOME, KDE (for how it should look like) and a two check boxes with simple description of GNOME and KDE (in the description should be noted primarily differences between those to, to ease selection to one who has no idea what GNOME/KDE is; for what will be used as 'backend'). Just a though... Your opinions? Is it even desirable? Does it make sense? Martin

4 6

Desktop spin: Java browser plugin
by Andrew Overholt 24 Aug '07

24 Aug '07

Hi, With IcedTea set to be in F8, should we look at including the java browser plugin in the desktop spin by default? Andrew

4 8

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop August 2007