[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [Kopete-devel] [Bug 52260] New: metacontact history (would be a merge of each subcontact's histo
From:       Martijn Klingens <klingens () kde ! org>
Date:       2002-12-27 12:32:44
[Download RAW message or body]

On Thursday 26 December 2002 23:32, Olivier Goffart wrote:
> >About the question of a unique ID, we can just take the name of the meta
> >contact. I don't think people keep a same name for 2 different meta
> >contacts. This has the advantage that the log file has the same name
> >than the contact. If you rename a contact, just check if it doesn't
> >already exist and rename the log file.
>
> mmmm :-s
> Using a display name as file name is dangerous:  the displayname can
> contains charactère like * / \ ? . or other
> I don't think if rename the logfile is a good idea.
> And the possibility of two metacontact with the same display name is
> _possible_ (kopete allow that)

I don't like the idea of display names either. Same reasons as Olivier btw ;-)

> Also for me, a channel is *not* a contact.
> than, what is said on a channel is keeped on a separate logfile
> Currently, (that's my opinion) irc is not realy integreted in kopete
> And for me, a channel shouldn't be a KopeteContact. I'm for implementing
> something like KopeteChannel which is not a contact, not a metacontact,
> just a channel
> (and then, special logfile) (a channel logfile is generaly verry big, and
> also verry less important)

Please, before introducing even more classes and APIs, clean up libkopete 
first. I'm still convinced that we do _NOT_ need an extra class for this if 
libkopete is properly refactored. I see no reason why KopeteContact can't be 
made fit, or at least be subclassed rather than introducing a new class aside 
from it, and here's why:

- The contact list contains of groups and meta contacts, nothing else.
- Groups contain other meta contacts
- IRC Channels are basically contacts that contain child contacts. The child
  contacts are added and removed dynamically, and not stored in
  contactlist.xml.
- So all we need is some code for a KopeteContact to contain child contacts,
  and we're basically done. This requires only some minor additions to
  KopeteContact, like void addChildContact( KopeteMetaContact * ),
  void removeChildContact( KopeteMetaContact * ), QPtrList<KopeteMetaContact>
  childContacts() and some supporting signals.

Simple, elegant, and easy, and it keeps the API size down. I chose 
KopeteMetaContacts over KopeteContacts on purpose, because if 'spaze' is on a 
channel on a server for which an IRCContact is created (i.e. FreeNode) 
Kopeter should recognize me being the same person and show the full meta 
contact there.

Since 99% of kopete code doesn't care about all this new functions at all, it 
requires only a few changes to existing code:

- The contact list view should be able to show channel members as child
  elements, like the metacontactlvi's beneath a grouplvi currently. Code
  can be reused, only the contact list needs to track some more data to
  properly updating the list for people joining and leaving a channel.

- The chat view should show child contacts as chat members and always operate
  in group mode for contacts with children. Same holds for the core KMM code.

> I don't know myself how to keep the history.
> But there is what is important for me:
> - (The history should be easy readable without kopete, just reading the
> file)

I beg to differ. For two reasons:

1. It doesn't allow us to change the file format later without upsetting
    users, which is rather inflexible.
2. The history is in $KDEDIRS/share/apps/kopete. If there's anything to say
    about files in $KDEDIRS, it'd be that those are strictly for developers,
    sysadmins and power users, but not even remotely for end users. _NO_ KDE
    application _EVER_ invites people to dive into $KDEDIRS to find the
    required data. Kate doesn't save files there, Konqueror doesn't start
    there in file management mode, etc. Instead, I'd much prefer an
    'Export...' function that would allow the user to stay away from $KDEDIRS
    and us to change our file format.

> - Groups chat log should be avaliable from each concerning contact, and
> easy to find (which a mention of the contact id for others)

Mention <group-chat filename="..." /> in the per-contact history?

-- 
Martijn

_______________________________________________
Kopete-devel mailing list
Kopete-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/kopete-devel
[prev in list] [next in list] [prev in thread] [next in thread]