[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    TODO - suggestions for 3.1
From:       Anders Lund <anders () alweb ! dk>
Date:       2002-03-14 3:36:54
[Download RAW message or body]

Hi all,
As some of us agreed on irc to post summarys of our idears for 3.1 on the 
list, here is my contribution.

1) Config options for iconborder usage
Checkboxes for choosing
	if the iconborder should be on pr default
	if line numbers should be 
		on pr default
		turned on automatic (when the first mark is set, off when last is unset
	if the state should be copied when a new view is created for a document
Apart from the settings of cause the code to realize the required actions.

2) File selector: options to open non-text files with the default app
it could be made possible to open them in kate using CTRL when activating the 
item. The setting could be limited to selected file types or global.

3) File selector filter options
a) the small filter icon should be a toggle button, in when thf filter is 
different from nothing or "*", and the filter unset when it was released.
b) I could make something similar to the konnqueror filter plugin, but with a 
listbox popping up with check boxes for each file type in the current 
directory, to make it easy to create filters.

4) Drag from file selector/file list
The idear is to make it possible to drag a file from one of the lists to an 
other frame than the currently active

5) Locking of frames
When working with split frames, i often wants to view all other files but the 
one i work at in a not active frame. If a frame could be locked to a 
document, kate could automatically choose the nearest frame to display 
documents activated in the file list, selector or otherwise requested opened. 
It should of cause be impossible if there was only one frame.
Sometimes I work with headers in a frame on the top and implementation files 
in a frame below it. If it were possible to lock frames to a file filter, i 
wouldn't have to activate the right frame before clicking a document (i often 
forgets...)
Maybe locking a frame to a directory + children of that
... there may be more options.

6) Enable binding plugins to a mimetype/extension/hl mask
This just means hiding the GUI elements (and accels) of a plugin when a file 
not matching the mask is active, or maybe just disable them. Currently that 
is only relevant for the XML plugin, but i think we can expect other file 
type related plugins - at least i plan a perl plugin...
This also includes deciding on how to configure that aspect.

7) utilize the bookmark types. Currently kwrite/kate only uses type01, for 
bookmarks. But there are debugger interfaces and such coming up... A perl -c 
would make use of one to display warnings and one for errors and so on.
It requires a manager, and a desiccion of what to do if we run out of free 
types, as well as a way to supply an icon for the icon border, decide if the 
user can set marks of this type and so on.

8) Displaying bookmarks as tree items in the file list??
(I don't really know if it makes much sense)

9) Bookmarks should be sorted by line number in the menu (imo, could be 
configurable) Btw, bookmarks where the text includes an ampersand looks funny 
in the menu - should be fixed

10) The document menu gets accels based on index - should not happen above 9 
(or 10, but then #10 requires special treatment)

11) the order in the file list should be sortable (alpha asc/desc, opening). 
It would conflict with the next/prev commands, so those should maybe follow 
the active sorting fo the list.

12) The grep tool shoule be turned into a docking window (and deleted when 
closed), and we should prepare for handling of docked windows provided by 
plugins.

13) Export HTML should use the available interface, and it needs a fix for 
better HTML imo - using a style sheet, no empty span tags. It should be able 
to handle a selection, to include a syntax map, and to put it's code to other 
places than a file - for example the clip board, another document or ...

14) Printing should be able to use default colors (for white background) and 
maybe no highlightning, to handle a selection and wrapping should be 
configurable - if not chosen, pages should be printed until the width is 
covered.

15) It should be possible to store data strings related to a specific context, 
enabling dynamic delimiters, nested ranges, embedding of other hl's etc. 
(don't ask me how, still)

16) commands to select text based on contents at cursor position, for example 
"to next mark", "to matching bracket" and so on. similar for "go to" style 
commands.

17) a email file(s) action (easy, and i almost have it done)

18) and include (text from) file command has been requested

19) spell checking based on context - for example avoid spell check XML tags, 
only spell check comments in source code an so.

20) templates - for example new-> HTML file, CPP class etc. more or less 
advanced, preferably in combination.

21) Some settings shoudl be configurable based on a mimetype/extension/hl 
mask, for example indent char/amount (4 spaces for perl, 2 for cpp, 1 tab for 
python... just as the user prefers). Resonable default values could be 
included in the hl files, in the general section.

22) we should be able to parse some emacs and vi(m) tags (configurable, if the 
user wants it).

... I could think of more, just not right now...
And this is of cause just my contribution, hopefully the rest of you have 
idears and wishes too:)

-anders
_______________________________________________
kwrite-devel mailing list
kwrite-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]