Bug #49
Introduction of some kind of Nick-Class or IRC-User-Class
0%
Description
To make the best of the current version of quassel, which is called by me "never stop that code refactoring", we should introduce a new class to represent an irc user.
The current solution gives me the creeps: there is a wild VarMap passed around the project, which has a value set that is neither intuitive nor well (is it at all?!?) documented...
Therefore - as mentioned above - I propose the introduction of a new class, to store the basic infos like away status, other "whois"-information, and a list of joined channels and modes.
The bad Side: the refactoring is not the easiest since this varmap is used across the whole project and cannot be identified by the type and sadly there are different variable names used... like props or n...
History
#1 Updated by Sputnick over 17 years ago
This VarMap is used as a hash containing the information about the IRC user. I believe (;-)) it has three keys, "Channels", "User" and "Host". Well yeah, we could/should probably change that into a class instead. When this was first implemented, I did not know yet how to make QVariant take custom-defined types, so I chose to use a VarMap (which can be passed around in signals and slots and QVariant and stuff). It's one of these really old artifacts...
Refactoring this stuff (which basically changes the nick storage in the client as well) should probably go together with implementing the MVC pattern for nicks and nicklist widget in the client. IOW, the whole fugly nick handling in the client should be replaced by a model that works on top of the proposed IRC user class, and the bufferwidget's nicklist widget into a view on that model.
Once this is done, the rest shouldn't be too hard. Since EgS is our MVC expert, I propose assigning this task to him :-) Of course I am willing to help with understanding my antique fugly code.
#2 Updated by EgS almost 17 years ago
fixed in the current svn... actually quite some time ago... :)