Skip to main content

digest

Development digest #7

Posted in

This week's changelog is rather small, but we have two major new features: somewhat working Jingle and support for ad-hoc commands in Azoth.

So, moving on to the changes list:

  • Implemented support for Jingle in Azoth Xoox (so LeechCraft requires Speex and QtMultimedia now).
  • Overall support for media calls in Azoth, with selectable input/output audiodevices, call manager and such.
  • Impemented support for ad-hoc commands (XEP-0050) in Azoth Xoox.
  • Added Azoth Rosenthal plugin, which implements Hunspell-based spellchecking in Azoth.
  • Added support for showing images directly in chat window into Azoth EmbedMedia (thanks Nobodyzzz).
  • Added Poshuku Keywords plugin for URL shortcuts (thanks Nobodyzzz).
  • Support for animated icons in Azoth (for example, for "connecting" icon or "incoming file").
  • Fixed a couple of funny bugs in Azoth Herbicide.
  • Finally respect background color from system palette in Aggregator.
  • Saner error messages in Azoth, with reason string instead of reason code.

Development digest #6

Posted in

Last 10 days we mostly focused on Azoth and, in particular, on implementing various handy and fancy XEPs in the XMPP implementation. Plugins for embedding media elements into Azoth chats, antispam and ignore plugin have also been added. So, the features list follows:

  • Support IM protocols in Azoth supporting user mood, user activity and user tune, with the ability to change them as well.
  • PubSub/PEP support in Azoth Xoox, in particular:
  • Added Azoth Xtazy, plugin for publishing current user tune. Supports MPRIS-compatible players and file data source.
  • Support for in-band registration (XEP-0077) in Azoth Xoox.
  • Privacy lists support in Azoth Xoox (XEP-0016).
  • Introduced a new plugin for embedding media objects like YouTube videos into chat windows (thanks Nobodyzzz).
  • Added Azoth Autopaste plugin for automatically sending long messages to pastebins and sending the link to the paste instead of the text itself.
  • Azoth Depester, plugin for ignoring specific participants in multiuser chatrooms.
  • Azoth Herbicide, a basic antispam plugin.
  • Reworked handling of contacts that have just requested authorization or that aren't present in our contact list at all. In particular, messages from unauthorized contacts or from contacts that haven't been added are handled now.
  • Support for legacy Entity Time XEP (XEP-0090) in Azoth Xoox with a small easter egg.
  • Azoth: implemented protocol console, in particular, XML console for the XMPP protocol plugin.
  • Azoth Xoox now supports legacy forms when registering on gateways and on XMPP servers.
  • Fixed regexp for detecting links in Azoth chats, so that, for example, magnet or git links are also detected now (thanks Akon32).
  • Azoth p100q plugin now allows to unsubscribe from psto directly from comments or posts (thanks Ignotus).
  • Improved insertion of nicks in message line edit in Azoth (thanks Akon32).
  • Fixed some segfaults and UI bugs in Azoth: it doesn't segfault now on empty contact addition.

Development digest #5

Posted in

This week in LeechCraft:

General viewGeneral view

Concrete pageConcrete page

  • LeechCraft settings moved from a dialog to a tab (and to be honest, the idea of the tab is borrowed from KDE's systemsettings). See the screenshot on the right.
  • Service discovery requests and VCard requests are now queued in Azoth Xoox (previously they were requested all at once), and that should fix some issues with slow and buggy servers like GTalk.
  • Fixed some bugs in Azoth p100q with handling and display of messages from psto.net (thanks Ignotus).
  • Inline image display is now optional in Azoth p100q (thanks Ignotus).
  • Azoth now supports scrolling the chat window from the keyboard via Shift+PgUp and Shift+PgDown shortcuts.
  • Azoth now allows to configure what hotkey is used for sending messages: just Enter, Ctrl+Enter or Shift+Enter.
  • Azoth ChatHistory now correctly handles HTML tags in messages.
  • Azoth ChatHistory now also shows the direction of the messages, which is handy for copypasting.
  • Azoth Xoox doesn't request capabilities of clients with old entity caps XEP like Psi+ (since it's senseless).
  • Fixed too paranoid download detection in Poshuku, so, for example, it's safe to go to Habrahabr.ru now without the risk of being flooded with download requests about mb_timezone.
  • Fixes in Poshuku CleanWeb for correctly hiding blocked elements in Qt 4.7.
  • Statuses with line breaks are displayed correctly in the contact list now.
  • And rather technical one: services from the Core are provided as if Core was plugin for itself: that eases and unificates a lot of things. For example, Core just provides another instance object for itself, and this instance object returns Core's XmlSettingsManager, settings tab, and such.

Advanced Notifications

And there is another change, even more technical, so we've decided to move it out of the list. We've begun the work on the Advanced Notifications framework, an upgrade to existing notifications framework, that would allow to implement persistent notifications, notifications grouping and reducing, and a lot of other tasty things. Let's overview them briefly.

Persistent notifications

Up until now, a notification was only shown by system means (via libnotify) or by our nice Kinotify plugin, but after the notification had disappeared, user had no way of knowing that something had occured.

Persistent notifications fix that. They allow, for example, to implement a plugin that would collect events like incoming unread messages, conference highlights or incoming file transfer requests and display a persistent notification (for example, as an icon in the system tray) for them until the user reacts to the event or manually dismisses the notification.

So, yes, we will finally have a system tray icon for new incoming messages in Azoth.

Notifications grouping

Advanced Notifications carry informating about their category, type, Semantic Event ID (SEID), and such. This way, it is possible to group all notifications from a single category into one tray icon or menu, for example. This way, notifications from our IM client and from a hypothetical Twitter client could be all placed into one menu of one icon. Of course, with a proper plugin, user is able to tweak the settings of grouping.

Notification category is the most general grouping criteria. For example, it could be IM, File download, News, and such. Type is used for more precise categorization withing a category. For example, for an IM-category notification it could be IncomingMessage, IncomingMUCMessage, FileTransferRequest, AttentionRequest or AuthorizationRequest. Event ID is used for extremely fine-grained categorization (and some other tasks). For example, event ID would be the same for two messages coming from the same IM contact, but incoming message notification and file transfer request notification have different event IDs event if they originate from the same contact.

Notifications reducing

Up until now a plugin that displays notifications had no way of knowing if two notifications actually notify about the same thing, and if an IM client sends out a hundred notifications about new messages from a single contact, you would have to click trough all those notifications, despite they are semantically equivalent.

Now, thanks to event IDs, a proper notification plugin can detect that there is no need in displaying next 99 notifications after first one about new incoming messages has been shown.

Actions

Of course, notifications carry actions with them. So, you could open a chat or grant authorization right from the persistent notifications' menu.

Customizability

Advanced Notifications carry a lot of context information, like source contact, contact group, message body and such for an IM message notification. This allows to configure how an Advanced Notifications plugin would notify about different events.

For example, it would be possible to configure the plugin so that visual notifications are displayed for every message in your favorite conference, and sound is played only for incoming messages from contacts in "Personal" group, and attention requests are ignored for all contacts except the one with JID yourgf@gmail.com, and all notifications from contacts in group "Bots" are ignored at all, but only if the message doesn't contain the word "LeechCraft".

Of course, different plugins which are the sources of notifications can expose different context information, since an RSS reader, for example, has completely different set of parameters than an IM client, and, in fact, all those parameters aren't known to the notificator in compile-time. For that, notification source plugins must also implement an interface that allows them to provide semantics of those parameters, so an Advanced Notifications plugin is able to provide a sensible GUI for configuring the rules.

Try it out!

If you want to be on the bleeding edge and see how Advanced Notifications framework is progressing, you can build the Advanced Notifications plugin from our git by passing -DENABLE_ADVANCEDNOTIFICATIONS=True flag to cmake, since this plugin is disabled by default. Please note that it depends heavily on the API and implementation of LeechCraft, so it's better to build LeechCraft itself from source as well.

Currently only Azoth supports some basic Advanced Notifications, and only tray notifications are working.

Development digest #4

Posted in

This week we mostly focused on Azoth and packaging for RPM distros (and we got included into OpenSUSE as consequence, but that's another story). So, without any more intro words, let's get to major changes:

  • Azoth Xoox now supports following XEPs:
  • Work on XEP-0158: Data Forms has also begun.
  • Azoth supports drawing attention and notifing about attention requests from other contacts.
  • Azoth now also supports visual notifications (in the chat window) about message receipts.
  • Default altenative nick for MUC conflicts has been added in Azoth Xoox.
  • Azoth now supports zooming the chat window by Ctrl+Wheel.
  • BitTorrent plugin now has a nicer torrent removal dialog (thanks Akon32).
  • Contact list now has a separate mode, where only participants of current MUC are shown.

Development digest #3

Posted in

Last week or so something great has happened: EiskaltDC++ is now working again in LeechCraft, thanks Negativ, the author and main developer of EiskaltDC++, for porting it to the new LeechCraft's tabs system. And, of course, despite finals, there are some other changes. So, a bit more detailed list follows:

  • EiskaltDC++ was synced with upstream (new features and bugfixes!) and adapted to the new LeechCraft tabs system introduced a month ago or so (thanks Negativ).
  • Support for recursive Service Discovery in Azoth Xoox.
  • Azoth Xoox now supports registering on gateways to other protocols, and, of course, working with the gateways.
  • Kinotify plugin supports links in notifications and opens them as it should.
  • Aggregator finally saves columns width (thanks Akon32).
  • And, once again, one more user-invisible change. Core changed a bit semantics of notifications handling. Now notifications are really broadcast. This enables us to implement things like audio notifications for different events in addition to already present visual ones, and such.

And, maybe the last change, the broadcast notifications, should be better explained.

Previously, all entities in inter-modular LeechCraft bus were not broadcast, and the first plugin that accepted an entity was fed with that entity, and the processing stopped after that. Now, if the entity is not a delegation request and there are no downloaders that are ready to accept that entity, the entity is fed to all the plugins that accepted it, not the first one.

Taking the user notifications example, previously, only visual notifications plugin or audio notifications plugin (assuming the latter is present) could handle the entity, but not both. You would either get sound or get a nice popup, but you could never get them at once. Now, the corresponding entity is fed to both of these plugins, so it is possible to have to a visual notification and hear a sound simultaneously from the same event.

There is also a small downside of this change. Previously, if two different visual notifications plugins were used, like, libnotify one and Kinotify, only the first one was used. Now, you would get notifications through both libnotify and Kinotify, unless you explicitly disable one of them (or unless your system doesn't support libnotify).

Syndicate content