D
Dimiter_Popoff
Guest
I am close(r...) to finishing the new dps browser, at least as its
function as a file browser. I have been working on it on and off for
a few years now, between other tasks of higher priority.
Now I have reached a point where I have to decide how to store
each directory viewing details, those which are unique per directory,
like column widths, view mode (details with hieroglyphs (icons),
thumbnails etc).
To put them in the \"global store\" (one can save and retrieve various
record types there, an app can initialize the active/default/factory
records it needs in only a few lines of code with plenty of available
variations) does not appeal to me, that will be a record per directory
and would take maintaining coherency with the directories etc. I don\'t
like it. Has anyone seen it done like that? (e.g. MS in their
\"registry\" though I doubt they do it there?)
The option I think I\'ll go for is to have a file in each directory
carrying this info. It is not a lot, 1k will be plenty I guess..
I have a . and a .. file carrying the path as text and the path
above since the dawn of dps (back in 1994 I think, may be 95).
These have never been used, they only get created when creating a
directory. Dps keeps the directory files for the entire path
of a directory which is open open so there is no need to refer to
these. What if I squeeze that info into the . file? I\'ll preserve
its present contents, just past it. It will take up no disk space,
a typical cluster is a few kilobytes so the . file won\'t allocate
anything in addition to what it already has.
Anyone seen that done this way? Or similar? Any thoughts on why
not to do it this way?
I am resigned to the fact that this will mean inability to remember
the directory view mode on non writable media.
I know this is lengthy and not quite on topic but everyone here
uses that sort of thing and there is quite a diversity of experiences,
I guess I have made up my mind (in a great part while writing the above)
but I am still in head scratching mode and someone saying something
might prove important to what I do next with this.
======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/
Dimiter
function as a file browser. I have been working on it on and off for
a few years now, between other tasks of higher priority.
Now I have reached a point where I have to decide how to store
each directory viewing details, those which are unique per directory,
like column widths, view mode (details with hieroglyphs (icons),
thumbnails etc).
To put them in the \"global store\" (one can save and retrieve various
record types there, an app can initialize the active/default/factory
records it needs in only a few lines of code with plenty of available
variations) does not appeal to me, that will be a record per directory
and would take maintaining coherency with the directories etc. I don\'t
like it. Has anyone seen it done like that? (e.g. MS in their
\"registry\" though I doubt they do it there?)
The option I think I\'ll go for is to have a file in each directory
carrying this info. It is not a lot, 1k will be plenty I guess..
I have a . and a .. file carrying the path as text and the path
above since the dawn of dps (back in 1994 I think, may be 95).
These have never been used, they only get created when creating a
directory. Dps keeps the directory files for the entire path
of a directory which is open open so there is no need to refer to
these. What if I squeeze that info into the . file? I\'ll preserve
its present contents, just past it. It will take up no disk space,
a typical cluster is a few kilobytes so the . file won\'t allocate
anything in addition to what it already has.
Anyone seen that done this way? Or similar? Any thoughts on why
not to do it this way?
I am resigned to the fact that this will mean inability to remember
the directory view mode on non writable media.
I know this is lengthy and not quite on topic but everyone here
uses that sort of thing and there is quite a diversity of experiences,
I guess I have made up my mind (in a great part while writing the above)
but I am still in head scratching mode and someone saying something
might prove important to what I do next with this.
======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/
Dimiter