Contents
XMPP
Interface for pubsub
Create visual interface for pubsub.
Elaborate on its API to make creation of pubsub components easy. Possibly implement "User tune" XEP.
IQ/IBB
Push IQ/IBB to the state of full compliance to its XEP.
xmpp: URIs
Improve handling of "xmpp:" URIs, both on command-line and in chat windows (via rich-text facility).
Private storage
Implement some visual interface for private storage (simple tasks like storing web bookmarks or quick notes). Probably with user-defined auto-expiration (at startup).
Internals
Virtual events
Re-implement all actions bound to keyboard/mouse events as Tk virtual events.
Also: possibly create some framework providing a way to create simple workarounds for buggy keycode reporting for non-Latin-1 symbols on win32.
Searching
Searching should be made more generic (as it is now for listboxes).
Roster code improvements
The roster code should be cleaned up to be understandable.
Redundant triggering of "item entered" events on horizontal hovers should be eliminated.
Filtering (with instant redisplay) should be implemented to allow implementing of quick roster lookups (via ext. code).
(Provide for keyboard traversal?)
"MUC Ignoring" ruleset editor
Implement generic editor for rulesets created by the "MUC Ignoring" internal plugin.
(This may as well conut as "UI improvement".)
UI improvements
Chats history
- Add possibility to delete specified parts of chats history, i.e. context menus + "delete" command bound to Del (or, better, to <<DeleteChatsHistoryItem>>) in the "JID list" and "Logs" views;
- Consult roster for aliases of known JIDs. This will greatly help when coping with certain "gated" contacts (with unreadable JIDs like those of ICQ).
Generalize "chat window UI" API
There's a recurring issue with somewhat tricky implementation of any visual additions to chat windows (such as like the "send" button aside from chat input window).
So the idea is to:
- Provide several procs to complement well-established
chat::chat_win,chat::input_win, etc. These procs should allow accessing to the containers of these windows such as (a quick sketch):chat::input_pane— container holding the input window;chat::log_pane— container holding the log window;chat::roster_pane— container holding the group roster window.
This will provide for easy and consistent adding of own windows to the chat displauys.
Such implementation will immediately make creation of such 3rd-party plugins like "send button" and "avatars in chat window" more easy to implement.
Potential problem: different 3rd-party plugins will anyway have hard time cooperating WRT packing/gridding their windows.
File transfers
Reimplement file transfer dialogs as toplevels/tabs (via add_win command) so that they don't clutter the display and are more manageable.
Implement some hooks, if needed, to hook to "file transfer started" and "file transfer finished (cancelled)" events. This will allow creating trackers for file transfers (like the Mozilla/Opera "downloads" window).
Possibly implement display of filetransfers in one (paned) window akin to Opera/Mozilla's FT dialogs.
Handling of "normal" messages
Implement "mailbox" style handling for normal messages (and possibly headlines also):
- Received message should go into the "mailbox" silently and Tkabber should generate some kind of visual and/or audible hint on this event;
- The user has access to that kind of "mailbox".
Access to the message archive should be made faster.
x:oob tags of normal messages should be handled in some more sane way than they do now.
Searching
Implement searching in the "Message archive".
(See also ``Handling of "normal" messages_ above.)_
Improve nick coloring
Nick coloring algorithm should be improved.
The main idea is to change the ways default colors are generated for nicks.
See this page for details (in Russian).
Omniscent context menus
Certain manipulations of text in all widgets supporting text reading/editing should be accessible via context menus.
Possible implementation: develop some generic code for handling bindtags (i.e. inserting/deleting/reordering) and use bindtags for assigning menus.
Problems: existing menus should continue to work as expected (WRT hooks, etc).
Accelerated menus
Develop some way to make menu entries accelerated.
Possible implementation: subverted menu command which parses its command line looking for the "-label" option and parsing its argument for "&" and "&&" symbols (akin to win32 API) then extending the option list with appropriate "-underline" options.
BWidget
Hack BWidget's splitters (activators).
Buttonbar improvements
Generic labels (may be)
Implement generic interface for labels akin to FVWM's menu items: the ButtonBar widget may have a format string assigned to it which is used to calc what's displayed on the labels, and how.
The main idea:
- Provide placeholders for some bits of data:
- Contact type/status icon;
- Contact (nick)name;
- Number of unread messages;
- You-name-it...
- Provide anchors for these bits of data (?);
- Provide for custom "ellipsis" string ("..." may occupy too much space on certain fixed-width fonts rendering its whole idea useless).
A quick sketch of possible (ugly, Tcl'ish) implementation:
option add *ButtonBar.LabelFormat \
"-icon {} -verb { } -contact {-compressible yes -ellipsis ^} -verb { (} -numberofmessages {} -verb )" userDefault
This should result in the label constructed out of:
- Status icon;
- The space character;
- Contact name, which is compressible, using the "^" character as the ellipsis;
- The space character following by an opening paren;
- Number of unread messages;
- Closing paren.
Plugins
Move some plugins to the trunk
Some plugins should possibly go into the trunk: XEP browsing, Open URL, ctcomp.
New plugins
Several plugins would be "nice to have":
- "Attention line" (being developed by kostix).
- Some plugin for extensive controlling of the sound facilities:
- Choosing of the sound hardware (with saving and fallback-on-the-next-start facility);
- Controlling the sound volume(s).