From owner-freebsd-hackers Mon Feb 1 06:15:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA24649 for freebsd-hackers-outgoing; Mon, 1 Feb 1999 06:15:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from shale.csir.co.za (shale.csir.co.za [146.64.46.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA24630; Mon, 1 Feb 1999 06:15:22 -0800 (PST) (envelope-from reg@shale.csir.co.za) Received: (from reg@localhost) by shale.csir.co.za (8.9.2/8.9.2) id QAA64082; Mon, 1 Feb 1999 16:15:04 +0200 (SAT) (envelope-from reg) Date: Mon, 1 Feb 1999 16:15:04 +0200 From: Jeremy Lea To: freebsd-hackers@FreeBSD.ORG Cc: The Hermit Hacker , Terry Lambert Subject: XMenu - adding ports to the desktop [was: From Slashdot...] Message-ID: <19990201161504.E3184@shale.csir.co.za> References: <80831.917849002@zippy.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <80831.917849002@zippy.cdrom.com>; from Jordan K. Hubbard on Sun, Jan 31, 1999 at 10:03:22PM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 : Causes XMenu to read and process the file /var/db/pkg//+XMENU. This would add this package to the default configuration. -remove : Causes XMenu to remove the package from the default configuration. -install : Allow XMenu to manage configuration for . 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 to ${HOME}. This could be called as a final stage from all ports in x11-wm. -deinstall : 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_) 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 : Causes XMenu_wm to read the XMENU file for from stdin, and make the changes to the config files -remove : 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message