desktop April 2010

desktop@lists.stg.fedoraproject.org

43 participants
37 discussions

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

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

Fuse Workspace Union
by Jeroen van Meeuwen 07 May '10

07 May '10

Hello there, I just received a phone call from Stef Bon, a fellow Dutchman who's been working on a Fuse technology based module to make it easier, and more transparent, to a user, to mount, navigate and use pluggable storage devices and network resources like Samba shares. While Stef is in a better position to describe the project, I'm going to take a stab at providing a summary. Since Stef wrote a bunch of good documentation on his project, please allow me to refer you to those pages: http://linux.bononline.nl/linux/mount.md5key.new/ In short, this type of technology could move the user's desktop experience forward a great deal as far as navigation experience goes. For instance, and this is just one of many example scenarios listed in the documentation, creating a "Shared Folder" for documents and files that all users on a system can use is a little more difficult on Linux still then it is on, say, a Windows XP Home edition workstation. Very much the same goes for navigation to a freshly (automatically) mounted USB thumb drive, that simply is not mounted within the user's home directory, but instead causes the user to have to navigate through system folders (e.g. /media/XXX/), even though a "1.8 GiB Filesystem" might show up in "Places" -if you use that navigation pane. Stef would love to increase awareness about his project, and would appreciate some constructive feedback. I'm glad to be able to make the introductions. I think Stef's project has a very high potential, and so, if you're interested, Stef would also appreciate some help in terms of further development. Kind regards, Jeroen van Meeuwen

4 4

Re: Fuse Workspace Union
by Bastien Nocera 30 Apr '10

30 Apr '10

On Fri, 2010-04-30 at 10:08 +0200, Stef Bon wrote: > 2010/4/29 Bastien Nocera <bnocera(a)redhat.com>: > > On Thu, 2010-04-29 at 12:35 +0200, Jeroen van Meeuwen wrote: > >> Hello there, > >> > >> I just received a phone call from Stef Bon, a fellow Dutchman who's been > >> working on a Fuse technology based module to make it easier, and more > >> transparent, to a user, to mount, navigate and use pluggable storage devices > >> and network resources like Samba shares. > > > > From a quick glance, this is something that gvfs already offers, > > user-space filesystems and fuse integration for non-GIO applications. > Well there are some important differences. Correct me if I'm wrong, but the > Gnome VFS is providing a browing facility for applications, and if you're not a > Gnome App, and there fore cannot make use of these libaries, you'll > have to use the > fuse module. Non-GIO applications can still browse already mounted sources. Note that in all of your demos, you're using a file manager to browse those filesystems. Browsing the file system with a GIO-using file manager (Thunar or nautilus) would work about the same. > Mine is completely based on the fuse module (and the automounter to do > the mounting) > and does not depend on the desktop environment, it's just a level > lower: the filesystem. > > Second, I'm working on inotify, still thinking how to make it work. > Does it already work with Gvfs? Yes. See the g_file_monitor*() functions. > Futher locking, extended attributes, and seeking in afile is > supported by mine. Does Gvfs also? We don't have locking support, but the rest works fine. > Finally mine lacks good integration with hal (udisk) for local devices > to export the directory > where a device is available for the user. We have that as well. Cheers

1 0

Re: spin kickstart/minimization cleanups
by Colin Walters 29 Apr '10

29 Apr '10

On Wed, Apr 21, 2010 at 7:08 AM, Peter Robinson <pbrobinson(a)gmail.com> wrote: > > I've spent a little time looking at the hardware side of things and > done a basic patch for some of the hardware stuff based on the current > rawhide comps file. I've broken it down into network/server/misc for > the time being and pushed the print stuff over to its group. More can > be done as it was a quick look through. The old hardware-support > currently includes all the other groups so there's no real change for > current builds overall. This looks like a good start. I think the way this kind of thing should work in general is that the system detects if you have the hardware, and dynamically installs support for it. We'd need some database mapping things like USB ids to packages. Networking is an exception; we should include as many drivers/tools for networking-related functionality as possible so that the system can be bootstrapped. Basically: if you have a GPS chip, gypsy gets installed and runs. If you don't, it doesn't.

11 23

change to critical-path-gnome group
by Bill Nottingham 28 Apr '10

28 Apr '10

As part of the update acceptance policy approved by FESCo, we have the following: The 'important' package set is defined as the following: * The current critical path package set * All major desktop environments' core functionality (GNOME, KDE, XFCE, * LXDE) * Package updating frameworks (gnome-packagekit, kpackagekit) * Major desktop productivity apps. An initial list would be firefox, * kdebase (konqueror), thunderbird, evolution, kdepim (kmail). (c.f. https://fedoraproject.org/wiki/Package_update_acceptance_criteria) I've generated a change to the F-14 comps file along these lines. Does this look accurate? Bill

5 8

Some Ideas About Fedora 14 Media
by Liang Suilong 28 Apr '10

28 Apr '10

Hi, all. Fedora 13 Desktop Spin would target to 1GB LiveDVD. But at last desktop team decided to return to 700MB CD size. It means that we should give up OpenOffice.org and GIMP by default. It looks quite sad. Looking at BrOffice.org, I seem to find out some ideas. Broffice suite and GIMP are installed in BrOffice.org by default, nevertheless, broffice spin gives up many locale files. Broffice just only support English, Spanish and Portuguese. So does desktop spin follow this method? Deskop spin contains OOo and GIMP, but it should remove most of GNOME locale files and OOo langpack. Then desktop spin can keep 700MB CD size. How can we download langpack file? Yum-langpacks seems to be the best solution. When we choose some language in system-config-lanage, yum-langpacks can download langpack of GNOME, KDE and OOo and some fonts we need and IME for that language. Anaconda also can run this plugin in %post-install so that it can fetch language pack and IME from remote repository. But We can not ignore that separating langpack from GNOME is a great job. Packaging langpack like kde-l10n-* and language-pack-* in Ubuntu needs a lot of packager to do it. Better experience: Live/Install Hybrid DVD Looking at install DVD, it looks too old. To add a Livesystem on DVD media can improve user experience. However, unlike Anaconda on install media, Anaconda on live system can not load a repository on media or a remote repository. That's a great problem. Just hope these suggestions can help Fedora community, I wish that Fedora 14 would have a better installation experience. Liang Suilong -- Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong

2 1

RE: The hardware
by Hristo Petkov 25 Apr '10

25 Apr '10

Hi, The OS should provide absolute control on the hardware with full functionality. This can be used as a competitive advantage in the design and development. When people buy some hardware they expect to get the most out of it. If the OS could not manage with this requirement - people start looking for alternatives. Thus for example I have installed hplip 3.10.2 fc11 and it gives a bug report when shutting down the computer that hp-systray is crashed (whatever this may mean) and I have no idea of how to fix it. I have tried various things without success (to manage with the bug). The printer however is working normally. Just for the record, the Ubuntu forums are reporting similar problem. It is amazing that with hplip 3.9.12 the absolutely same hardware with absolutely the same Distro (fc11) from the very same Live CD worked 'without remarks'. The idea is when a development is done one should be very careful to avoid 'downgrading' things meanwhile. Regards

3 2

Updates next steps
by William Jon McCann 24 Apr '10

24 Apr '10

Hey folks, We discussed this a bit on IRC yesterday but I wanted to bring it up on the list too. Now that we have rough consensus that we should try to limit the volume of "pointless" updates, what is next? I propose we look at two things right away: 1. Limit the frequency of non-critical updates to once per week in stable releases 2. Establish norms or rules that limit the types of changes in stable releases to ensure the releases remain stable A concrete example of the kind of thing that I think we should try to avoid: Two days ago I installed updates for F12 (over a hundred random updates) then yesterday I noticed a lot more udpates (40ish) that included an update for vala 0.8.0 with the description "Update to new major release 0.8.0". Longer term, I'd like to see a more comprehensive plan similar to http://fedoraproject.org/wiki/Desktop/Whiteboards/UpdateExperience but we probably need to work towards that incrementally. Thoughts? What is the best way to accomplish these two things? Jon

12 44

RE: Updates
by Hristo Petkov 23 Apr '10

23 Apr '10

Hi, > And we can address part of the 'update frequency' problem client-side, > by only checking for new updates once a week. > > But one problem which we cannot address client-side, and for which 'do > nothing now and reassess later' will not help at all is the amount of > updates. Even if you only check once per week, the flood of pointless > updates is a problem. That is that part of the problem that we need to > address with Jon's 'establishing norms or rules to limit changes'. In my view the problem is not in the updates themselves, but rather in the Fedora specification of developing new software versions which should differ significantly from the previous ones. Who really needs all these distos to change at the 'speed of light in vacuum'. New distros - yes, but not like this, and not so often. Perhaps the new distro should be something like a compilation of the old distros with the updates. In this way the problem with the compatibility of the distros would be solved as well. For over 30 years of software monopoly on the market MS has all in all 9 OS, and within less time some other people have 14. Maybe this needs some interpretation. Regards

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

desktop April 2010