| [mail2lj] Did you know? |
[Feb. 1st, 2007|03:43 am] |
It's not needed to read web version of this community or add it to
your friends. You don't even need a LJ account to read this news.
Just use your favorite RSS program and add the feed
http://community.livejournal.com/tkabber/data/rss
to it.
Also, it should be available as tkabber_lj@rss.jabber.ru but this
one seems non-functioning at the moment of this writing. |
|
|
| [mail2lj] [Looking back] New-style logging |
[Feb. 1st, 2007|03:30 am] |
Since 2006-12-26 Tkabber enjoys rewritten logging subsystem which
was created by Sergei Golovan.
The old (present in the current stable release 0.9.9) scheme used
one directory for storing all "running" logfiles -- one file per
JID. Then, upon the user's request for a contact's (or group's) history
the corresponding file got "archived", i.e. parsed, split by dates
and stored in chunks under the corresponding "year/month"
subdirectories.
This scheme was slow on opening rarely used history files.
Also the messages' bodies were kept "as is" -- with embedded
linebreaks, which, coupled with line-oriented buffering on log
files, might lead to unreadable logfiles in the cases of "brutal"
Tkabber shutdowns or hardware power outages.
Now all logs are kept directly under the appropriate "year/month"
subdirectories, and each message being logged is represented by
exactly one line of text (embedded newlines being escaped).
This improves both history access speed and logging robustness.
The old log dir is automatically converted into the new format at
the first run of a Tkabber featuring the logging subsystem in
subject. The old data is backed up first.
---
One issue with long filenames on NTFS file system remained.
The workaround was found but I'm unsure about its status.
Will report later. |
|
|
| [mail2lj] Introduced support for "MUC ignoring" |
[Jan. 27th, 2007|04:36 am] |
Today's commit introduced support for ignoring activity of any
room occupants in groupchats.
A user of Tkabber may at any time start to ignore the in-room messages
from a particular occupant and/or her private messages. The
ignoring may be cancelled at any time, also.
Ignored private messages are dropped, ignored in-room messages are
recorded but hidden. When ignoring for the in-room messages is
cancelled, all messages came from that occupant while she having been
ignored, are shown. If such ignoring is re-applied that messages
get hidden again -- this allows for "quick picking" into what the
ignored person is posting to the room.
The ignore rules are stored into the Customize database (unless the
"transient_rules" option is set) and restored on the next run of Tkabber.
The ignore mechanism binds to the occupants' full JIDs if they are
available or to their nicks, otherwise. Nick changes are traced.
The MUC ignore actions are available from the groupchat roster
context menu an from the menu of a private chat.
What's currenly missing (but planned to be implemented eventually):
* Support for storing the rules in the server's private storage (if
available) and using the Customize database only as a fallback;
* Generalized ruleset editor -- not bound to rooms and occupants.
WATCH OUT: this is a completely client-side feature, it doesn't
implement any XMPP RFC or XEP. So it should be taken with a
grain of salt. Some things you should observe:
* Ignoring in non/semi-anonymous rooms (when you has no permission
to see the full JIDs of occupants) is done based on nicks. So it is
possible to ignore some nick and then some *other* person will
appear using this nick in the same room -- and will be ignored.
(If you fear this happening, opt for transient rules).
* It's not currently possible to view/edit the whole ruleset (well,
one can, of course, view/edit the Customize database file directly).
Anyway, testing and feedback is appreciated. |
|
|
| [mail2lj] Some news on panicking wish when changing color depth at runtime on Win32 |
[Jan. 25th, 2007|03:50 am] |
An excerpt from the recent chat in the tclers' chatroom:
[02:40]<kostix> tclguy: BTW, someone here once said you had some
hacks to avoid Tcl_Panic in Tk when the screen depth changes at run
time on Win32. can you comment on this? (some Tkabber users still
complain on this problem)
[02:41]<tclguy> well, I made some fixes that are now in the core
[02:41]<tclguy> but I think I had others that were never commited
[02:41]<tclguy> (I have lots of code like that ... :/ )
[02:41]<tclguy> the latter handled images
[02:41]<tclguy> if you have no images, Tk handled everything right
[02:42]<kostix> we have lots of images :)
[02:42]<tclguy> there was/is something wrong with image palette
depth refreshing
[02:42]<kostix> all those [image photo] icons
[02:42]<tclguy> mumble mumble ... have to search around again
[02:42]<tclguy> probably still an open bug on it
[02:43]<dkf_> IIRC, there was something horrible in Visual
management
[02:43]<dkf_> but the problem was split up over too many source
files for me to really grok it
[02:43]<tclguy> I think I got distracted by wanting to completely
rewrite the Windows wm stuff
[02:43]<tclguy> and never finished that
[02:43]<tclguy> to add things like true multi-monitor awareness,
events for depth and color change, etc
----
So someone should probably step forward and test this on a recent
CVS version of 8.5 :) |
|
|
| Abstract |
[Dec. 26th, 2006|02:43 am] |
The idea is to use LJ for providing some info about how the Tkabber is evolving. I mean: changes in the code, new ideas, new articles on the wiki and some related info.
This is *not* intended to be some kind of helpdesk (see http://tkabber.jabber.ru/forum for tis).
This is to quickly provide some information about the Tkabber project which is easily accessible (via RSS and in the usual "friends" form).
Any member is allowed to post.
Let's see how it will go... |
|
|
