incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "מיקי גוטמן" <mg...@013.net.il>
Subject A Suggestion Draft
Date Wed, 03 Dec 2003 11:39:20 GMT
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. 

 

Operations

==========

>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.

 

Auto-Save

=========

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




Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message