1:32 p.m.
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
2:31 p.m.
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)
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?
7. 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
2:45 p.m.
On Wed, 2004-04-21 at 15:31 -0400, seth vidal wrote:
> 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)
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
2:50 p.m.
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
2:52 p.m.
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
3:06 p.m.
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
Fedora-desktop-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-desktop-list
3:09 p.m.
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
2:47 p.m.
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.
>
> 7. 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
8:11 p.m.
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
--
"Would you buy a car with the hood welded shut?"
- Bob Young on the benefits of the open source development model.
mhelios - www.fedoraforum.org
9:01 p.m.
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
4:38 a.m.
Hey,
On Wed, 2004-04-21 at 20:47, Havoc Pennington wrote:
On Wed, 2004-04-21 at 15:31, seth vidal wrote:
> > 7. 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.
4:20 a.m.
Hey,
On Wed, 2004-04-21 at 19:32, Havoc Pennington wrote:
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
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.
7307
days inactive
7309
days old
desktop@lists.fedoraproject.org
11 comments
6 participants
participants (6)
-
Dan Williams -
Havoc Pennington -
Jeremy Katz -
Mark McLoughlin -
Matt Hansen -
seth vidal