desktop discussion

[Havoc Pennington]

Hi,

I've closed our internal desktop discussion list for new posts.

Here are the topics we've discussed recently that should have been
public:

1. Java/Mono - I moved this discussion to fairly public places ;-)
    Best to keep it off this list.

2. Hardware autoconfiguration.
    General goal is to autoconfigure hardware without user 
    intervention or writing to /etc. This is the hal/dbus/
    Project Utopia stuff. http://ometer.com/hardware.html

3. Deployment scenarios that avoid per-machine state, including
    read-only root fs copied from a central image, thin clients, 
    and so forth. There was a discussion of this on fedora-devel.
    We don't have very detailed ideas yet.

4. Media players, Colin just posted on this.

5. Details of rearranging menus

6. Daniel Veillard is hacking on a per-user daemon to replace
    the FAM system daemon, primarily motivated by SELinux
    (FAM system daemon lets you violate the security boundaries)

7. The gconf multiple login question, which everyone is already 
    familiar with sadly... Mark was having a look.

Our OS desktop discussion is less than you might think, since most
topics fall into an upstream project such as GNOME. If you're interested
in the Fedora desktop I'd definitely recommend watching the
project-specific forums as well.

Hope this is helpful. Feel free to ask about specific development
topics.

Havoc

[seth vidal]

> Daniel Veillard is hacking on a per-user daemon to replace
> the FAM system daemon, primarily motivated by SELinux
> (FAM system daemon lets you violate the security boundaries)

What is it that fam is supposed to achieve? I know it does file change
notification but I've never noticed a change in system behavior from
when it is off or on. Is Daniel's work on line somewhere?
> The gconf multiple login question, which everyone is already 
> familiar with sadly... Mark was having a look.

What's been mark's take on this? Last thing I heard some discussion of
application configuration storage daemon - possibly not gconfd based -
but that sounded like deep in the future.

thanks for the info.
-sv

[Jeremy Katz]

On Wed, 2004-04-21 at 15:31 -0400, seth vidal wrote:
> > Daniel Veillard is hacking on a per-user daemon to replace
> > the FAM system daemon, primarily motivated by SELinux
> > (FAM system daemon lets you violate the security boundaries)
>
> What is it that fam is supposed to achieve? I know it does file change
> notification but I've never noticed a change in system behavior from
> when it is off or on. Is Daniel's work on line somewhere?

You should definitely notice a change with it off in rawhide.  Install a
new app, watch the gnome-vfs menu backend not notice the change and you
get to kill gnome-panel to refresh your menus.

Jeremy

[Havoc Pennington]

On Wed, 2004-04-21 at 15:45, Jeremy Katz wrote:
> You should definitely notice a change with it off in rawhide.  Install a
> new app, watch the gnome-vfs menu backend not notice the change and you
> get to kill gnome-panel to refresh your menus.

I think that's just the new menu code sucking, I don't think it works
with FAM enabled either :-P

Havoc

[Jeremy Katz]

On Wed, 2004-04-21 at 15:50 -0400, Havoc Pennington wrote:
> On Wed, 2004-04-21 at 15:45, Jeremy Katz wrote:
> > You should definitely notice a change with it off in rawhide.  Install a
> > new app, watch the gnome-vfs menu backend not notice the change and you
> > get to kill gnome-panel to refresh your menus.
>
> I think that's just the new menu code sucking, I don't think it works
> with FAM enabled either :-P

dcbw said it did.  I was believing him at the time ;)

Jeremy

[Dan Williams]

Jeremey,

I said I was _working_ on it :)  It invalidates 2 out of the 3 caches
that need to be invalidated right now, but unfortunately, the 3rd cache
is the "money cache", and quite elusive.

Dan

On Wed, 2004-04-21 at 15:52 -0400, Jeremy Katz wrote:
> On Wed, 2004-04-21 at 15:50 -0400, Havoc Pennington wrote:
> > On Wed, 2004-04-21 at 15:45, Jeremy Katz wrote:
> > > You should definitely notice a change with it off in rawhide.  Install a
> > > new app, watch the gnome-vfs menu backend not notice the change and you
> > > get to kill gnome-panel to refresh your menus.
> >
> > I think that's just the new menu code sucking, I don't think it works
> > with FAM enabled either :-P
>
> dcbw said it did.  I was believing him at the time ;)
>
> Jeremy
>
> -- 
> Fedora-desktop-list mailing list
> [e-mail]
> http://www.redhat.com/mailman/listinfo/fedora-desktop-list

[seth vidal]

On Wed, 2004-04-21 at 16:06, Dan Williams wrote:
> Jeremey,
>
> I said I was _working_ on it :)  It invalidates 2 out of the 3 caches
> that need to be invalidated right now, but unfortunately, the 3rd cache
> is the "money cache", and quite elusive.

there's a money cache!?!
Fantastic!

ok, I'll stop now.
-sv

[Havoc Pennington]

On Wed, 2004-04-21 at 15:31, seth vidal wrote:
> What is it that fam is supposed to achieve? I know it does file change
> notification but I've never noticed a change in system behavior from
> when it is off or on. Is Daniel's work on line somewhere?

I think it may be in GNOME CVS. FAM is used by various parts of the
desktop, e.g. you need it for nautilus to notice if you move files
around, and for the theme control panel to notice when you install a
theme, and so forth.
> > The gconf multiple login question, which everyone is already 
> > familiar with sadly... Mark was having a look.
>
> What's been mark's take on this? Last thing I heard some discussion of
> application configuration storage daemon - possibly not gconfd based -
> but that sounded like deep in the future.

Our idea was to merge all of /apps/metacity into one file, all of
/apps/panel into one file, etc. That makes gconf equivalent to plain
text files in terms of semantics. Mark already implemented it mostly.

But we were getting stuck on the fact that then you can't share homedirs
with old installations. Also, some apps have pretty deep trees under the
level 1 directory, so the single file would be kinda huge.

We could make it configurable, that's probably the right answer.

Note that you can do this today using the gconf-merge-tree command to
merge an existing ~/.gconf and then it will stay merged.

Havoc

[Matt Hansen]

On Thu, 2004-04-22 at 05:47, Havoc Pennington wrote:
> On Wed, 2004-04-21 at 15:31, seth vidal wrote:
> > What is it that fam is supposed to achieve? I know it does file change
> > notification but I've never noticed a change in system behavior from
> > when it is off or on. Is Daniel's work on line somewhere?
>
> I think it may be in GNOME CVS. FAM is used by various parts of the
> desktop, e.g. you need it for nautilus to notice if you move files
> around, and for the theme control panel to notice when you install a
> theme, and so forth.

Well, is it supposed to notice new files downloaded to a directory? For
example, if I d/l files to a directory, and have an open nautilus window
in that dir, I have to manually "reload" the window before the new file
shows, no matter if sgi_fam is on or not.

Ok, I have to ask, what's the status for GNOME menu editing? What state
will it be in for FC2 and which release do you foresee full
functionality for this?

Regards,
-Matt

[Havoc Pennington]

On Wed, 2004-04-21 at 21:11, Matt Hansen wrote:
> Well, is it supposed to notice new files downloaded to a directory? For
> example, if I d/l files to a directory, and have an open nautilus window
> in that dir, I have to manually "reload" the window before the new file
> shows, no matter if sgi_fam is on or not.

That should work, it's always worked for me. Could be hosed by selinux
or something perhaps.
> Ok, I have to ask, what's the status for GNOME menu editing? What state
> will it be in for FC2 and which release do you foresee full
> functionality for this?

In FC2 the menus will use the documented freedesktop.org specification
which is reasonable to edit with a text editor if you're an admin
setting up a default user session.

For the users themselves, longer term one line of thought is to just
have a way to enable/disable menu items, and perhaps Favorites, I guess.
But maybe Dan will get the nautilus editing to work, or GNOME upstream
will do something else.

Havoc

[Mark McLoughlin]

Hey,

On Wed, 2004-04-21 at 20:47, Havoc Pennington wrote:
> On Wed, 2004-04-21 at 15:31, seth vidal wrote:
> > > The gconf multiple login question, which everyone is already 
> > > familiar with sadly... Mark was having a look.
> >
> > What's been mark's take on this? Last thing I heard some discussion of
> > application configuration storage daemon - possibly not gconfd based -
> > but that sounded like deep in the future.
>
> Our idea was to merge all of /apps/metacity into one file, all of
> /apps/panel into one file, etc. That makes gconf equivalent to plain
> text files in terms of semantics. Mark already implemented it mostly.
>
> But we were getting stuck on the fact that then you can't share homedirs
> with old installations. Also, some apps have pretty deep trees under the
> level 1 directory, so the single file would be kinda huge.
>
> We could make it configurable, that's probably the right answer.

Yeah, so I think there are two problems:

1) Some people (e.g. people who are switching back and forth between 
     say RHEL4 and RHEL3 daily) are going to be screwed by this feature 
     because GConf 2.4 and earlier don't understand the merged file 
     format. So, I think for FC3 we'll switch it on by default but allow
     it be switched off with a backend flag. So by default 
     /etc/gconf/2/path would contain:

xml:readwrite:$(HOME)/.gconf

and if you needed to switch back and forth between version you 
     could change it to:

xml:readwrite,nomerge:$(HOME)/.gconf

The nomerge flag should probably explode all existing 
     %gconf-tree.xml files into a directory based hierarchy again, too.

2) The optimal set of trees to merge into a file isn't that easy to 
     figure out - we may want to just go with merging everything two 
     levels down and if we figure out later that it should be 
     configurable we can implement it then.

Anyway, more details (and a better explanation of the problems) in the
upstream bug report:

http://bugzilla.gnome.org/show_bug.cgi?id=138498

Cheers,
Mark.

[Mark McLoughlin]

Hey,

On Wed, 2004-04-21 at 19:32, Havoc Pennington wrote:
> Hardware autoconfiguration.
> General goal is to autoconfigure hardware without user 
> intervention or writing to /etc. This is the hal/dbus/
> Project Utopia stuff. http://ometer.com/hardware.html

People interested in this might want to follow the hal and dbus mailing
lists:

http://freedesktop.org/mailman/listinfo/dbus
http://freedesktop.org/mailman/listinfo/hal

and a Project Utpopia mailing list has just started with a discussion
about the roadmap for the project:

http://mail.gnome.org/archives/utopia-list/2004-April/thread.html#00001

Cheers,
Mark.