Pre-wishlist musings: Nested Text Buffers, and a Docking Documentation Subsystem

Steven T. Hatton hattons at globalsymmetry.com
Fri Mar 5 07:06:06 UTC 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm thinking this might be worth putting in as a wish list item, but I don't 
really want to feed the feature creep, unless it really avails the user.  
Part of the problem with the idea is that it doesn't apply to all programming 
languages equally.  Here's what I'm thinking.  Source code, and other user 
work buffer widgets would be contained in a in a tab distinct from the one 
containing the documentation. 

There would be a next layer of tabs one for each document (or document view if 
the multi-view buffer is ever realized.)  In the case of C++, I will propose 
the be subdivided even further into tab pairs, one for the header, the other 
for source.

An option for being able to display the header/source pairs in a split pane 
rather than one over the other would be nice, but would most likely entail 
customization at the Qt/KDE level.

In addition to these features I all envision a documentation subsystem that 
takes it's buffers with the documentation tree when the tree is un-docked.  I 
find having documentation that cannot easily be viewed along with the source 
hard to use.  Having all the documentation and source buffers in the same tab 
dialog (I assume that's what the text buffers are children of) seems 
cluttered, and makes it harder to use both the edittor, and the viewer.

Ok, and one more feature.  An editable help dialog that could be switch to 
read only at compile time (if that is desired).  That would enable coders to 
quickely capture parts of the help documentation when they go to use a tool.

This is how Mathematica handles documentation, though their text editor never 
locks from input, it just doesn't save.  _BAD_! _BAD_! _BAD_!.  Mathematica 
is a whole lot like another list based programming/programmable editor (which 
happens the share that undesirable feature, in places).  The original 
"extensible, customizable, self-documenting real-time display editor.".  
Allowing the novice user to modify things such as help files, or even worse, 
source files for the product, can frighten a person concerned about damaging 
something they don't know how to fix, even if that can't save the inadvertent 
changes they make.  It's a nice capability for the experience coder, but it 
should be possible to completely disable it.

Any reactions to my suggestions are welcome.  If people thing the ideas have 
merit, I'll bugzilla it.
STH
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFASBizwX61+IL0QsMRAh17AKCE61CRyrL0OZaZlcNNZ5NI5RPaHgCfTFwQ
xEZsRjIO8/SpJo1j1VssjGc=
=8aD9
-----END PGP SIGNATURE-----




More information about the KDevelop-devel mailing list