A Suggestion Draft
DCF: Document Centered Framework Original Draft by Michael A. Guttman, 3-Dec-2003 * Comments: [EMAIL PROTECTED] 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
[Ruper] Incubation setup phase
Finally Ruper is a project in Incubation at Apache. :-) http://incubator.apache.org/projects/index.html Our incubation status page is here: http://incubator.apache.org/projects/ruper.html What has to be done now? We are in the Project Setup phase. http://incubator.apache.org/projects/ruper.html#Project+Setup * all contributors to Krysalis Ruper and to Krysalis Version, please send a grant for the codebases in question as here: http://www.apache.org/licenses/software-grant.txt (specifying that is't about the part of these codebase on SF that you have committed, and with what ID) As for Greebo, we'll see if it's needed to access the codebase after some discussion, or if it can simply work as a reference to look at. * please change all files so that they have the ASF 1.1 copyright in the header * please change all packages to be org.apache.ruper.* We can use Refactor-It which is free for both krysalis and Apache projects (follow the logo link on krysalis.org) The initial committers will be: # Adam Jack ([EMAIL PROTECTED], [EMAIL PROTECTED]) # Anou Manavalan ([EMAIL PROTECTED], [EMAIL PROTECTED]) # Markus M. May ([EMAIL PROTECTED]) # Nick Chalko ([EMAIL PROTECTED], [EMAIL PROTECTED]) The only one that is not yet an Apache committer is Markus. Please send a CLA by fax as explained in the CAL itself below linked: http://www.apache.org/licenses/cla.pdf Please also tell me what Unix id you will like to use (mmay I guess). Give me three choices in order, and do not use only the name or surname. After the above items are done, I'l have infastructure set up the project, import the code, and we can start. For the Avalon developers that want to join development and eventually merge their efforts, we can start discussing and collaborating as soon as the mailing lists are setup (it should not take much). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
