[devel at quassel-irc.org: Re: Kubuntu and Quassel]
jriddell at ubuntu.com
Tue Jun 16 02:02:57 BST 2009
----- Forwarded message from Marcus Eggenberger <devel at quassel-irc.org> -----
Cc: kubuntu-devel at lists.ubuntu.com, devel at quassel-irc.org
From: Marcus Eggenberger <devel at quassel-irc.org>
To: Jonathan Riddell <jriddell at ubuntu.com>
Subject: Re: Kubuntu and Quassel
Date: Mon, 15 Jun 2009 20:41:01 +0200
thanks for your e-mail. We appreciate the collaboration with Kubuntu
and KDE developers ourselves.
There is no proper release schedule for Quasel. And due to some real
life constraints we are currently unable to put as much time into
Quassel as we would like to.
So let me comment on your list of missing things. Please note, that
this is my personal point of view. I'd also like Sput to comment on
the list aswell.
> There is no way to send files with DCC.
As most of you are aware Quassel was developed with the server/client
concept in mind. Sadly this makes some things way harder than they
would be in a monolithic client. DCC is one of those. The DCC protocol
itself is very simple and is not a limitation here. Implementing DCC
is definitely on our todo list, but there are some basic design
questions that need to be resolved first. Here are some of them, so
you get the picture of it:
1.) Should files be stored in the Core or should the be directly sent
to the Client?
Storing the files in the Core has the advantage that the DCC transfer
is not interrupted by a disconnecting Quassel Client (from the Core).
On the other hand forwarding the DCC connection directly to the client
would take load away from the Core and would reduce impacts on the
regular communication between Core and Client
2.) Sending a file over our internal connection could block all other
communications. The SignalProxy (this is where all the magic happens)
is currently not prepared for something like that.
3.) Storing files in the Core raise the need for additional support
structures in Quassel Core like ACLs and Quota support.
I am aware that Kubuntu primarily bundles the monolithic Quassel so in
theory those constraints would not apply. But the monolithic client is
just a Quassel Core and Quassel Client wrapped into one binary. Well
and the SignalProxy no longer communicate over sockets anymore and are
connected directly to each other. This allows us to have no duplicate
development processes and we honestly like to keep it that way as it's
a hell of a timesaver :)
> It is hard to configure the toolbars, using KDE toolsbars would fix
No clue about that. Sput - our Linux / KDE guy - has to answer this.
But I think this should be minimal effort.
> Users are confused that there is no way to set a list of autojoined
channels, make it more clear that it joins the channels you were
Any suggestions? :)
> When joining a channel the window does not change to that channel.
I don't see real issues that would hinder fixing this.
> Translations are incomplete for some menu items.
Well... Sput and I we both speak two languages: english and german.
Aka: we depend on the work and support of others to fix this. Maybe we
could tap into Kubuntus or KDEs translator resources here?
> Setting up server connections is hidden away under "Misc", it
should be the first think the setup takes you to
The reason why it's under "Misc" is, that our the settings are
organized as a tree and we have no proper category where it would fit
in otherwise. We're open to suggestions here.
Side note: the first run wizard should help here too.
> The dockwidgets are ugly and draw too many boxes. There is an
Amarok patch to fix this which could be incorporated
Honesty: I don't get this. But perhaps this is because I'm developing
on Mac OS. :) Could someone supply a screenshot that illustrates the
> The terminology "buffer" is confusing, something more
understandable should be found.
That's a classic. :) From time to time we are looking for a fitting
umbrella term that covers regular chats in channels, queries (aka:
pm), and the server notifications.
> Links in topic don't look like links.
Yes that's also one of the classics. We intend a full rewrite of the
topic widget to address this issue.
> Ability to place windows side by side instead of one over the other
That's quite some work... Has been mentioned quite a couple of times
due to the resuling work, but is definitely on our list. Though
probably not in the near future.
> After using it for a while on freenode it has chat windows open
with three freenode servers, but there is nothing in them, why is this?
There are two types of server messages: real server messages (those
are typically numeric coded irc messages) and normal messages that a
server sends to you like any other user can (those are privmsgs or
notices). Some people (usually net admins) like to keep those
separated as it can clutter up one buffer and you can miss important
stuff in a wall of notifications that a user has connected to or
disconnected from your server.
To cope with both flavors Quassel supports what we call "message
redirection". The message is stored with the original sender (the
server). The client then sees that it's a notice coming from a server
and redirects this message to the statusbuffer, leaving the actual
buffer the message belonged to empty.
The result is obviously a bit confusing. This is also not a new one,
but I've been thinking about a solution here. This should be fixable
in time for the Karmic release.
> Keyboard shortcuts should be available, for example quickly
browsing through channels.
We haven't figured out an intuitive method here. This is basically due
to the fact, that you can have multiple buffer views open. So if you
have three buffer views open, one showing all channels, one all pms,
and one showing your conversations in bitlbee, then what would be the
next / previous channel?
We are open for feedback here.
As a side note: the git version of Quassel has a new feature that fits
into this category: you can jump to the channel with the oldest unread
message. (Like Alt-A in irssi or Weechat).
> Netsplit detection should be as good as in irssi.
Well we can not guarantee "as good". But we are planning on
implementing Netsplit detection.
> Global away shortcut.
This should be a five minutes job.
Again: this is my personal point of view. I think you can expect a
commented list from Sput in the near future.
Marcus Eggenberger - EgS
Am 15.06.2009 um 17:17 schrieb Jonathan Riddell:
>Hi Quassel devs
>The Kubuntu developers are very happy to have had a productive last
>cycle with yourselves as friendly upstreams.
>At the Ubuntu summit we looked at Quassel and its competition and came
>up with a list of features we feel are missing most.
>Do you have a release schedule for your next release? How could
>these features fit into that? What state do you think Quassel will
>be in for the Kubuntu release schedule which needs upstreams to be
>in a shippable state by start of October
More information about the kubuntu-devel