back to top-level page
2. Compatibility | 3. Caveats | 4. Features Overview | Copyright |
Kaw.7
is a no-frills framework for storing arbitrary word / image / action content in hierarchical structures that reflect personal knowledge spaces. Its intention is to provide services allowing organized knowledge-document creation, where such documents are easily retrieved, manipulated, and shared. How good is it? Well the proximate benchmark for "good" (i.e., the one that makes evolution work) is its current form being better than its last form; the ultimate benchmark is its current form relative to the application not existing. That's a hard thing to judge and is also use dependent. I'm still looking for uses for it, but I think it sometimes helps me in non-trivial way.
Kaw.7
is supposed to address, and the application is a context in which to get concrete about the problem. Conceptual (and implementational) details of Kaw.7
et. al. is also provided at about this project and the summary sections (below). 1.7.0_01
) under Windows™ XP and 7. The older Javas (1.4.x) are not supported; more recent Javas may work partially (with some repair and recompile).
Kaw.7
has evolved in a specific environment and probably won't work despite platform independence (i.e. Java-based) without at least some work.
A selective list of application features and a glossary.
This is the frame holding a bunch of hierarchically nested tabs, or GUI tree structure, built by a kawDoc designer. Some tabs have green-corner square icons and the green-arrow icons, indicating the tab has structure, or treePaths in it. Square shape means the tab is not in an application-specific focus; whereas arrow shape means the tab is in focus (i.e., can be manipulated in some way). Blue-corner icons indicate a "terminal" document at the bottom of a treePath being viewed.
KawDocs are jTabbed and jTree viewable/navigable. The view generated from JTABBEDPANES is a single-selection structure, so only ONE path down the tree is "lighted up" or visible at a time. There is ALWAYS a document GUI visible at the end of the path (even if it's empty).
![]() |
If a nester or a terminus has the arrow icon in its corresponding tab (e.g. in the picture above "3 Flavors of Documents and how to get them" has it), you can copy or cut the subtree starting with that tab to a different part of the kawDoc or to a different open kawDoc.
Terminal documents consist of two (specialized) JTextPanes in left and right view areas of a JSplitPane. However, you can elect to use only one of the JTextPanes. In the example below, a single-terminus kawDoc is shown with a "Large Document Navigator and Control" replacing the JTree view.
The second textPane (the right one) is still there, but collapsed over. This non-displayed textPane might still be doing work in the sense of holding format information about how the displayed textPane should be displayed.
![]() |
![]() |
When text is selected in a Terminus's textPane, right clicking in the textPane gets a textTool. The textTool is a "utility pack" containing functions that use the selected text. Some of these functions operate on the text selected, some perform actions (e.g. launch other kawDocs, jump to another tab).
The kaw Frame (top square frame with title "kaw") is always created when you start
|
![]() |
. |
![]() ![]() |
The Debug Log is shown behind the kaw Frame and is also created on application start. One closes this window to end the session (i.e. AFTER saving). My application will never ask if you want to save something; you have to set the kawDoc you're working on to "save with a standard close" via a top-tab (root tab) popup menu request. Then, when you do a standard close of the kawDoc (click the X button belonging to the SPECIFIC kawdoc), it saves its current form. The application is tolerably fast at doing multiple open and closes for reasonably sized kawDocs. |
Terminal documents and general kawDoc appearance
Terminal Documents can be searched as can the kawDoc as a whole.
There are two independent ways of pre-formatting/setting terminal documents (e.g. font size, scroll points, splitPane splits) when you first encounter them after opening a kawDoc.
The first way is through a kawDoc-wide set of preferences for all the terminal documents set by an XML fragment <preferences .... />, which is typed in the rightPane of the rightMost tab of the kawDoc. Some non-obvious qualities can be pre-set this way (e.g., xml output paths, HTML style info, and specific kawDoc abilities).
The second way is a format specification (again an xml-fragment: <saves .... /> ) written at the end of the right textPane of the terminal document, which takes priority over the kawDoc-wide preferences format.
TextTool
If the text selected is an <!Directive associateFile ... > a textTool menu choice "exec" can launch that file using its host application (i.e. separate Operating System process). This ONLY works for Windows XP™ (and probably later Windows™), and only for file types that the OS recognizes as double-clickable in Windows Explorer™. I would hope it could be made to work elsewhere, but I can't explore that issue. Hence, Kaw.7
can perhaps interact with other applications in useful or interesting ways (e.g. organize their documents).
Thanks to Michael Daconta's website (www.daconta.net) for the excellent pedagogy and code samples on Java APIs relevant to exec-ing OS processes from within Java.
<!Directive activate ... > is a Java generalization for the associateFile/exec directive described last. Java Reflection is used to run (activate) the class specified in the directive. The activated class can either be in its own JFrame, which would make it an "OuterApp", or could run in a JPanel that replaces (one of) the TextPane panels of the Terminus that contains the directive. For the latter, you can think of the activated class as an "InnerApp" (i.e., it looks like Terminus content of the kawDoc).
Within-kawDoc "jumping" from a terminal doc to a different part of the kawDoc is done via "tabPaths", a textual description of a kawDoc location.
For instance:
♥♦kaw_manual♦basic functions♦TextTool♦modifyContent...♦menu options♠0:insertImage:1♠
can be used to jump to the tab location described, and scroll to and highlight (first occurrence of) the term "insertImage".
TabPaths can define simple location toggles for a kawDoc, more extensive tabCycles (i.e. repeating "slide shows"), or once-traversable (i.e. reversable) tab "trails".
See manual for more.
TextTool has many functions "guesses" about what you've selected in a textPane and provides a best guess subMenu, with a "backToMain..." option if it guesses wrong. It also has a "recents..." subMenu that allows collection of frequently re-used commands.
kaw Frame
The green Plus provides plug-in applications on a simple "launch frame" (figure presented previously). These are notional applications, though they are sometimes useful: an XML reader that reads XML as a kawDoc, a MidiPlayer
application, an app that reads system properties into a scrollable text area, and a notional help application that generates a kawDoc on- the-fly using an html file as input.
The Copyright button can be set up to display a kawDoc specific copyright notice for the kawDoc that is "on top" (i.e. being viewed). This is done via a kawDoc "preference" mechanism (above).
XML interaction
Kaw.7
as a simple XHTML editor (see kaw_manual_7
for more).
A lot of the translation methods (kawDoc to XML and vice versa) entails a lot of kludgy (but necessary) made up convention on my part. Some examples:
If you are using a kawDoc as a quick and dirty XML editor, creating a tab whose title begins and ends with a MINUS sign (e.g. -comment- ) creates a "bounded comment". These tabs are usually a nester so that they can "mentally scope" some XML defined by the kawDoc and prevent you from getting "lost in the tree" (or at least help you find your way back). The XML file generated by the kawDoc converts these "minus" nesters into two labeled and matching <!-- ... --> style comments that bound the analogous XML markup.
Another convention: attributes are specified as the first tab, which must be a terminus, under a markup tab (with title "attributes" and attribute content written in the left textPane).Better XML managment is a goal of the application. There is some attention to XSLT via a wrapper that allows kawDocs to transform xml according to styleSheets. I've not used this much.
Miscellaneous Features
And lots of other neat stuff. The kaw_manual_7
tries to remember it all.