Re: control center plans, etc.



Hi Havoc,

On 19 Jun 2001 19:16:03 -0400, Havoc Pennington wrote:
> 
> Hi,
> 
> I don't know of a dedicated list for this, so mailing gnome-hackers
> and control-center maintainers.
> 
> I'm considering implementing a simplified control panel scheme as
> discussed in this thread:
> 
>   http://lists.eazel.com/pipermail/nautilus-list/2001-May/003210.html
> 
> I'm looking at doing this against the stable branch, with a port to
> HEAD and merge upstream if people want.
> 
> Basically there are just a few simple features:
> 
>  - hack the control center to be a shell around one capplet 
>    (separate window for each capplet), kill try/revert,
>    kill menubar/statusbar/tree-on-the-side
> 
>  - add the "user prefs" virtual folder to Nautilus, icons in 
>    here launch a single standalone control panel
> 
>  - add the "system settings" virtual folder to Nautilus 
>    (contains Red Hat config tools in the Red Hat release)
> 
>  - have panel submenus that are equivalent to those folders
> 
>  - for future control panels there's no need to use libcapplet, 
>    etc., since control panels are just little dialogs they 
>    can just be small apps with no embedding involved.

Much of this is similar to what has been done in CVS HEAD. Currently the
capplets run in standalone dialogs and libcapplet has been relegated to
a very simple wrapper that creates a dialog box with Ok and Cancel
buttons. The library is present entirely for reasons of backward
compatibility. The shell itself allows some flexibility in viewing the
capplets, though I did that to reflect the principle of least
commitment.

Reading down this thread I have found several messages suggesting that
there should not be a shell at all. While I generally agree that the
need for a shell is minimal when users are running Nautilus, having such
a shell available is useful for folks who do not wish to run a file
manager.

> So, what are the current control center plans, how does this fit in,
> how much of this should go in CVS, on what branches should it go, etc.

For the past few months most of my work has centered on adding XML-based
archiving (i.e. location management and rollback) to the capplets. I
have focused very little on the capplets themselves. I want that to
change.

The capplets do need a lot of GUI work -- many of them are obsolete,
redundant, and utterly confusing. I agree with the general idea that
default applications, file types, url handlers, and default editor
should all be in a single capplet. The various capplets that affect
desktop appearance should be better organized and certain capplets, such
as wm-properties, should not be presented except possibly to very
advanced users. I am not, however, a GUI expert, so I delegate
responsibility for optimizing the user experience to someone with more
knowledge of the subject.

What concerns me most right now is that the capplets are becomming
nightmarishly difficult to maintain, especially the older ones that I
have not rewritten. This is in large part due to the XML archiving
features I added. I want to do some major internal surgery to make the
capplets easier to program. In particular, the developer should not be
concerned with how to get the capplets to work with location management
and rollback -- it should all just work. Thus I need some library
support for this and, after discussing the issue with Dietmar Maurer, I
am leaning towards bonobo-conf for the task.

I would also like to add a couple of capplets, the most urgent of which
is an ssh (and possibly pgp/gpg) key management capplet. This would
facilitate users running remote X applications through ssh more
conveniently, which is of great importance in such large installations
as universities.

I also agree that the XML archiver should not be part of XST. One
possibility would be to put it in bonobo-conf and have a configuration
moniker that, acting as a wrapper, archives data with it. There are
numerous other possibilties, though, and I am not committed to any one.

> I see there are some changes in control-center HEAD but don't know
> what the plans are there.
> 
> Havoc

-- 
-Bradford Hovinen

We are most probably here for local information-gathering and
local-Universe problem-solving in support of the integrity of
eternally regenerative Universe.

   -- R. Buckminster Fuller


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]