[devel at quassel-irc.org: Re: Kubuntu and Quassel]

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

Hi Jonathan,

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  
this.

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  
previously in?

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 
http://amarok.kde.org/blog/categories/18-freespirit

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  
difference?

> 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.

Best regards,

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.
>
>https://wiki.kubuntu.org/KubuntuKarmicIrc
>
>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
>https://wiki.kubuntu.org/KarmicReleaseSchedule
>
>Jonathan
>