Re: gpe system configuration

On Fri, 2002-08-09 at 17:23, Pierre Tardy wrote:
> The fact thas we should develop on a linux-x86 box, and then compile on
> the ipaq cluster is not evident. I 've lost lot of time triing to
> cross-compile..

I think there may be some people cross-compiling, since I remember one
of the apps had its build scripts set up for that....

I'm doing native compiles, but using an NFS Debian chroot on a local
iPAQ rather than using the Skiff Cluster.

> Perhaps someone should write some HACKING file in the gpe/docs dir..

Yes, we're lacking documentation for most things just now.

> My idea to make something like a container, where all configuration stuff
> will be arranged, and uniformised, in the spirit of sysset.
> , to integrate the existant gui, and make new one (multiuser, theme
> selection, etc)
> On the other hand, familiar-menu ( appmgr or mmenu) can assume the task of
> the container, minus the uniformisation and smaller size.
>
> What is gpe staff opinion about configuration gui?

To speak for myself, I'm no longer convinced that having everything
inside one big configuration program is actually the best idea. Once
again I can point to GNOME 2, where the single configuration program
previously used has been abandoned in favour of separate utilities. On a
handheld having separate utilities preserves more screen space for the
actual configuration widgets, and separate utilities should be much less
confusing to the user.

(With the old GNOME control centre, the UI went through various
convolutions to try to show which settings had or hadn't been saved in a
multi-page interface. If, as at present, we have a configuration tab in
gpe-appmgr then I don't see any problem with letting the user choose the
area to configure there - otherwise we're likely to end up reproducing
gpe-appmgr like behaviour in the configuration program.)

I'd also suggest that (where possible) we follow GNOME 2's example by
having configuration settings take immediate effect - see ipaqscreen
0.0.2 for this applied to screen-related settings. (Note however, that
the UI of ipaqscreen could certainly be improved in other respects, e.g.
by having a graphical representation of the different rotation choices.)

We do need a central framework for saving configuration choices - I
think there's a suggestion we have a gconf-like system, but with a more
efficient back-end.

Even if we present different configuration areas to the user as separate
programs in the menu / gpe-appmgr, it would be nice if we didn't end up
duplicating too much code. Ideally, it might be possible to create a
sysset like program that parsed configuration files, so that at run-time
it could act as any of the necessary programs, from a single binary.

-- 
Moray