DCF: Document Centered Framework


Original Draft by Michael A. Guttman, 3-Dec-2003


Comments: mg190@013.net.il

Please notify me if a similar draft was already suggested/implemented,

whether its applicable or not or if the same title was used

to describe a different issue.

Just to make things clear: I only represent myself.



When Starting a a DCF-Application:


No File-Menu in any DCF Application.

Whenever Starting a DCF-App., a new (premature) document file

is generated instantly in the 'new documents' folder (Incubator).

Premature file is a normal document file except that its filename,

 (and location), were automatically assigned.

File naming would be arbitrary or according to configured rules.

Filename extension would be as configured for the appropriate DCF-App.


Advanced Notable Shell UI


From The File-Shell (Konqueror etc.) a document would be Noticed by:

 1. Content Preview Window

 2. Advanced Animated Thumbnail Icons

                 (e.q.: An animated peep-hole scanning the text inside file).

 3. Colors Style and Relative Time configurations e.g.:

                 * A File created today or Yesterday could read "Today"

                             or Yesterday in its time-field instead of, say: 3-12-2003.

                 * A file created in the last hour could have a red time-label

                 * A File created the same weekday could have a blue labeled time.

                 * A Text file's name could be in different color/style than a binary

                   And so on...


Document Templates


Each DCF Applications could use its appropriate 'template-file' from 'templates folder'

as document's initial contents.




From The File-Shell (Konqueror etc.) Any DCF-Document may always be:

* 'Create'd: Same as when Starting the App (see above) but no App. Is Started.

   Any folder is basically ok for creating a filename. default=Incubator.

* 'Index'ed to (Re)name & move a premature document from Incubator to any folder

* 'Open'ed

* 'Read-Only Open'ed: the System (File-Shell) will-never issue save command

   for a Read-Only-Opened DCF file. The DCF-Application Itself Has no right

   to initiate Save command by-definition.

* 'Save'd = With 'Undo-History'. Notice that its a File Shell command since there is no File-Menu.

* 'Publish'ed = Save another Copy without 'Undo-History'. Initial Default folder is 'publish'.

* 'Index-Publish'ing The same as 'Index' but for published document (no undo).

* 'Delete'd

* 'Copy'ed

* 'Move'd

* 'Rename'd

* 'Print'ed



DCF App as a Server Model(and File-Shell  as its 'client')


All the above Commands would only be issued by the File-Shell (Konqueror etc.) and some (Open,Save etc.) would depend on DCF-App Response by the document component of the DCF-App.

Again, there is NO File menu within the DCF-App. itself.

Whenever, an edited-file is changed from outside - the editing DCF-App. must be synchronized.




Periodically, the system should signal the Editing-DCF App. to save changes (Save is ALWAYS automatic).

When exiting a DCF-App., document changes are ALWAYS saved.

Saving undo-history of its own documents is an Application responsibility.

However The distinction between 'save' (with undo-data) and 'publish' (w/o)

 is by a separate message/signal from system/file-shell/other-certified-app.


 Why Adopt this approach?


 1. Because This will give Linux a serious gain over Windows in Desktop

     ease-of-use which is still considered Linux's weak point.

 2. Auto-Save means Less Data Losses due to user miss-type or power failure.

 3. No Choice:'save/discard/cancel' = No dilemma ,no time wasting, no click errors.

 4. Basically, The user doesn't have to 'invent' filenames.

 5. Quick Notice of Files by colorful and relative time Stamp - not just long-names.

 6. Matches a Linux principle that each module should do its job the best way.

 7. Want to inspect a file but afraid from unintentional damage?: open-read-only.





,Yours Truly

Mickey Guttman

: 064-804194