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