Sounds like an improvement, a few things can be polished further:
- Fold sel /selcolors and /normcolors into a single /colors file (separate the two values by a new line, a : or whatever) Any reason we need this at all, an env var could probably work just fine, but IIRC that idea was discarded for some reason. - Get rid of dirs under [lr]bar, it is only needed because LABEL/color, and that is a flimsy reason. - Any reason <class:instance:name> is needed in /tag/*/[0-9] for anything? - Not sure the geometry is needed for anything either, except maybe having a pager app somewhere, but I would rather just add it later if it makes sense. - I still have to see a good reason why an index file per tag with the format: <colnr or ~ for float> <clientid>\n would not be enough, I guess adding the geometry for the client after that should be OK too. But I guess this is not too different from what you proposed. Always think that it is easier to add stuff to the fs later if you actually need it than it is to remove it, and if you add it when you need it you will have a much better chance of providing a sane interface than if you try to guess what might make sense in the future. uriel On 6/9/06, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
Hi, when discussing about simplifying the filesystem last night in IRC, I want to make a proposal how the new file system could look like: Old (just for reference): /def/ /def/border /def/font /def/selcolors /def/normcolors /def/tagrules /def/keys /def/grabmod /def/colrules /bar/ /bar/lab/ /bar/lab/data /bar/lab/colors /client/ /client/1/ /event /ctl /tag /tag/X/ /tag/X/ctl /tag/X/name /tag/X/index /tag/X/sel/ /tag/X/1/ /tag/X/1/ctl /tag/X/1/mode /tag/X/1/sel/ /tag/X/1/1/props /tag/X/1/1/index /tag/X/1/1/name /tag/X/1/1/tags /tag/X/1/geom /tag/X/1/ctl New (proposal): [The idea is to remove the column-representation in the fs-hierarchy, because this is not used.] /client/ /client/N /client/N/ctl /client/N/props /client/N/tags /colrules /ctl /event /font /keys /lbar/ /lbar/LABEL/ /lbar/LABEL/data /lbar/LABEL/colors /grabmod /normcolors /rbar/ /rbar/LABEL/ /rbar/LABEL/data /rbar/LABEL/colors /selcolors /tagrules /tag/NAME/0 (floating clients) (*) /tag/NAME/1 (column 1) (*) /tag/NAME/ctl (*) Each tag contains a file pro area (0 == floating area, 1,... == columns), whereas each line looks as follows: N <x> <y> <w> <h> <class:instance:name>\n N is the global client index equivalent to /client/N/ The number of lines defines the number of clients in the area. The selected client will be indicated with N==sel. <x> <y> <w> <h> indicates the geometry of this client in this area, the rest is equivalent to /client/N/props (however might be of use). Commands like quit are executed in /ctl, commands which are client specific like kill are executed in /client/sel/ctl (resp. /client/N/ctl). view-specific commands are executed in: /tag/sel/ctl (resp. /tag/NAME/ctl) The bar is divided into a left bar and a right bar (whereas the first label of the right bar is expanded and right-aligned like in wmii-3). Regards, -- Anselm R. Garbe ><>< www.ebrag.de ><>< GPG key: 0D73F361 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
_______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
