Date: Mon, 1 Feb 1999 10:28:06 -0400 (AST) From: The Hermit Hacker <scrappy@hub.org> To: Jeremy Lea <reg@shale.csir.co.za> Cc: freebsd-hackers@FreeBSD.ORG, Terry Lambert <tlambert@primenet.com> Subject: Re: XMenu - adding ports to the desktop [was: From Slashdot...] Message-ID: <Pine.BSF.4.05.9902011022260.4262-100000@thelab.hub.org> In-Reply-To: <19990201161504.E3184@shale.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Just read through this, and don't *quite* agree with how you have it
spec'd out, or, at least, unless I'm misunderstanding it...
The main problem I have is that, if I'm reading it right, every package
ever installed on a system will auto-magically get added to my personal
configuration?
I like the XMenu concept, no problems there...I like the fact that any new
package added to the system gets 'registered' to a central configuration
file (don't we already do this?)...but I'd rather XMenu -update, from a
users perspective, pop up with a GUI interface that allows the user to
pick and choose what gets added to their personal configuration.
Something that lists all packages, whether they are "installed" into their
configuration or not, and let's them change that state...
On Mon, 1 Feb 1999, Jeremy Lea wrote:
> Hi,
>
> [redirected to -hackers, bcc'd to -chat]
>
> On Sun, Jan 31, 1999 at 10:03:22PM -0800, Jordan K. Hubbard wrote:
> > It's really pretty simple - get a package included in packages/All (by
> > making it a port) which does nothing more than install some prototype
> > dotfiles for root, some collection of WMs and applications (all of
> > which can be done by @pkgdep'ing an existing package rather than
> > including the whole thing). Then it appears automatically in the
> > index, perhaps in a category of "canned package sets" or something,
> > and the user can add it just like any other package. man pkg_create
> > or RTFM bsd.port.mk's package rule for more info. :)
>
> I started work on designing an extension to the Ports collection, which
> would allow packages to add items to the desktop for various window
> managers. Below is my design document, but I've not started coding. In
> particular I'm a C++ hacker (and not much of one) and I think this might be
> a Perl job...
>
> Are there any people interested in helping code the XMenu system described
> below? Especially any Perl hackers? Any comments would also be welcome.
> The syntax for the configuration files is very much a first draft, and any
> comments and ideas would be appreciated. I'm not a trained syntax writer...
>
> Regards,
> -Jeremy
>
> XMenu
> ~~~~~
> An X11 window manager configuration tool
> Jeremy Lea, 1999
>
>
> Purpose
> ~~~~~~~
> The purpose of XMenu will be to provide an active link between the
> FreeBSD ports collection and various X11 window managers. When ports
> are installed or un-installed (or their packages), it will try to update
> the menu's presented to all of the users, in whatever window manager is
> being used, to reflect the changes in the system.
>
> XMenu will have configuration files which will allow the user to control
> which applications are installed/de-installed, where they are added to
> the menus and which icons should be used. These will be configurable
> for all WM's or for each one individually.
>
> XMenu will not aim to be a complete solution to automatic X11 desktops
> for FreeBSD, but will be aimed at the non-hacker who is not into manual
> maintenance. The configuration files should, however, be flexible
> enough to cater for a large percentage of the users.
>
>
> Architecture
> ~~~~~~~~~~~~
> XMenu is broken into three parts. The first will be XMENU files in the
> ports /pkg directory, along with associated additions to bsd.port.mk and
> pkg_* to notify XMenu to update it's configuration. The second is a
> core module (XMenu) which will be responsible for managing the various
> ports registered, system and user configuration files and passing
> directives to WM specific backends. The WM specific backends will be
> responsible for parsing the records they are sent and either adding or
> removing them from the user's window maker configuration files. They
> are also responsible for passing the current configuration back to
> XMenu.
>
>
> XMENU files
> ~~~~~~~~~~~
> The structure of the XMENU files will resemble this example (for the
> netscape port):
>
> WindowManager "wmaker"
> { Desktop "WWW"
> { Toolbar "WWW"
> { Item "Netscape"
> { Program "/usr/local/bin/netscape"
> Icon "." override
> Options minimise, autostart
> }
> }
> }
> }
> WindowManager "*"
> { Desktop "*"
> { Menu "."
> Category "Applications"."WWW"
> Group "Netscape"
> { MenuItem "Communicator 4.08"
> { Program "/usr/local/bin/netscape"
> Icon "." override
> }
> }
> }
> }
>
> This might imply the XMenu should attempt to install netscape under
> Applications->WWW->Netscape on the default menu (implied by a "."), for
> all installed window managers and for all desktops. The icon used
> should be the default for netscape for that WM, and should always be
> used in place of the application supplied icon.
>
> For Window Maker it should additionally install netscape docked to the
> clip on the desktop WWW (if this exists) and auto-launch it minimised on
> startup.
>
> XMENU files would need to be added to each port which has programs which
> would normally be run under X. However, ports without such files would
> still function normally. The setup of these files would be the
> responsibility of the port maintainer, although some general guidelines
> as to defaults should be given.
>
>
> XMenu
> ~~~~~
> This is the core program, which performs most of the logic involved with
> managing the addition and removal of items. It is a command line driven
> application, with the following options:
>
> -add <package>:
> Causes XMenu to read and process the file
> /var/db/pkg/<package>/+XMENU. This would add this package to the
> default configuration.
>
> -remove <package>:
> Causes XMenu to remove the package from the default configuration.
>
> -install <windowmanager>:
> Allow XMenu to manage configuration for <windowmanager>. This would
> involve the installation of default config files in /usr/X11R6/skel
> (which would be maintained as the default config) if called as root.
> If called as a user, install the files for <windowmanager> to
> ${HOME}.
>
> This could be called as a final stage from all ports in x11-wm.
>
> -deinstall <windowmanager>:
> Undo the work of install.
>
> -update:
> If called as root, resync the config files with /var/db/pkg/*.
> Maintenance option in case things get out of sync.
>
> If called as a user, update all of their config files.
>
> XMenu stores the following files:
> /usr/X11R6/skel/.XMenu/windowmanagers
> List of installed windowmanagers.
> /usr/X11R6/skel/.XMenu/packages
> List of installed packages.
> /usr/X11R6/skel/.XMenu/config
> Configuration file.
> ~/.XMenu/...
> Same as above, user specific.
>
> The format of the configuration file will follow this example:
>
> WindowManager "wmaker"
> { Desktop "*"
> { Toolbar "WWW"
> { Item "*"
> { Ignore
> }
> }
> }
> Desktop "WWW"
> { Menu "*"
> { Group "Netscape"
> { Override Category "WWW"
> }
> }
> }
> }
> Package "xemacs*"
> { WindowManager "*"
> { Item "*"
> { Override Icon "~/pixmaps/elephant.xpm"
> }
> }
> }
>
> The configuration files must be able to perform ignore, override and add
> commands based on a three way filter: package, windowmanager and
> configuration item, with sub-filters for desktop, menu and toolbar. The
> task of XMenu is to merge the XMENU file passed by the package
> installation with these configuration options to generate a final
> configuration.
>
>
> Window Manager backends
> ~~~~~~~~~~~~~~~~~~~~~~~
> These programs (named XMenu_<windowmanger>) are responsible for the
> merging of XMenu information with the installed configuration files for
> the specific window manager. They will take the following arguments:
>
> -add <package>:
> Causes XMenu_wm to read the XMENU file for <package> from stdin, and
> make the changes to the config files
>
> -remove <package>:
> Causes XMenu_wm to remove the package from the config files.
>
> -list:
> This would cause XMenu_wm to list the installed packages, as
> determined from the config files, to stdout. This option would be
> used for the purpose of syncing the configuration.
>
> XMenu_wm should leave some kind of comment in the configuration files
> for the windowmanager to indicate that the lines were added
> automatically and should include a magic string which includes the
> package name which generated the text which follows the comment. This
> will be a problem for window managers whose configuration files cannot
> contain comments. XMenu_wm should only attempt to edit records which it
> generated.
>
>
> Operation
> ~~~~~~~~~
> The operation of XMenu for packages would be as follows:
>
> 1. On package install (pkg_add or make install), XMenu should be
> called, if installed and there is an XMENU file, with the -add
> option.
>
> 2. XMenu should then load the XMENU file, and the global and user
> configuration files. The rules listed should be applied to generate
> a final XMENU file which would then be passed via a pipe to the
> XMenu_wm programs for each installed window manager.
>
> 3. The XMenu_wm programs should update the window manager configuration
> files in /usr/X11R6/skel.
>
> Users should call 'XMenu -update' as part of their .xinitrc or .xsession
> file. Other modes of operation are fairly obvious.
>
> --
> | "In this world of temptation, I will stand for what is right.
> --+-- With a heart of salvation, I will hold up the light.
> | If I live or if I die, if I laugh or if I cry,
> | in this world of temptation, I will stand." -Pam Thum
>
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9902011022260.4262-100000>