Well since I may or may not have the time to do the things I had in mind in
the time span I had hoped, I would also suggest reading Microsoft
Messenger's Plug-in API. It is a concise document that brings new insight
into the messenger and how the "extra functionality" (Even built-in
functionality) is implemented with expansion in mind. It describes voice,
email, notifications etc. Look in particular at the interface classes (doc)
and the methods they expose. It is a good document and such an
implementation would get rid of some of the mess we have inherited from the
original CCMSN.
Do notice also that the Export Contact List option saves in two formats. One
is the XML format that the real MSN MEssenger uses so it can be used to
import into a Windows messenger. The other format that is saved at the same
time is the custom format I had implemented originally. This one I have to
convert to XML, but for now the important thing is that this format I
implemented preserves group information (the MSN simply ignores all grouping
and you have to regroup everything after import). At the moment we don't
have an import either. Anyway I should add this to the list of todo but is
low priority.
Cheers!
Emilio
Should I expect Santa Claus to bring me a job???
----- Original Message -----
From: "Alvaro J. Iradier" <airadier@...>
To: <amsn-devel@...>
Sent: Thursday, December 12, 2002 2:21 AM
Subject: Re: [Amsn-devel] Three main points in our way to amsn 1.0
Yeah of course, comments are good, I wrote many comments for my new
procedures, so they can be easily understood.
Abstraction is necessary too. And every procedure must make one small thing,
but it has to make it good, no errors, it should check everything is ok, and
we should make sure it's always called right.
Greets. Alvaro.
El Mié 11 Dic 2002 23:38, Burger escribió:
> Hey,
>
> Ok I agree with all your points, just 1 issue I think you forgot..
> Comments... I think we should comment every single new function (function
> header) with descritpion + parameters + return value descriptions). I know
> comments are annoying, but they are extremly important, specially since
> amsn is getting complex. Some old procedures are also very hard to
> understand and if they where commented would take 1/2 the time to
> understand them and do whatever we want with them. I might even comment
> those old complex functions while im understanding them.
>
> Anyways I guess it's ur turn to study soon and mine to keep developping :)
> By the 22nd I'll be in Kuwait and i'll have a whole month of nice free
time
> to code. So thats all good.
>
> Laterz
> Burger
>
> On Wed, 11 Dec 2002 19:05:35 +0100
>
> "Alvaro J. Iradier" <airadier@...> wrote:
> > Ok, so now we have a new aspect for amsn in some windows, a new GUI and
> > protocol layer that should fix the multiple windows problem, and message
> > queueing... amsn has everything you could wish in a good microsoft
> > messenger clone...
> >
> > But...
> >
> > We have some (maybe many) bugs.
> > We have too much lines of old dirty code.
> > We have many old-style windows, with different aspects, different font
> > sizes, and no skin support.
> > We have a big to-do list with many wanted features.
> >
> > I think we should center on three points:
> >
> > 1. We should first test and fix bugs, so we can at least release some
> > kind of version, as we have plenty of new features.
> >
> > 2. By the way, we should start moving every piece of old code into
> > separated namespaces. We should do a modular code, where everything is
> > checked (I prefer checking than "catching" errors, so we now when a
error
> > will happen and what to do, instead of just hidding it) and everything
is
> > consistent. We shouldn't repeat code (for example sometimes the same
> > piece of code, like a command, is repeated three times in a button
> > command, a binding, and a keypress, it happens in the chat window), but
> > use procedures for complex commands that are used more than once. This
> > should really help in bug fixing. If we add new features, we should add
> > them this way, with clean code. This will also make a plugin system
> > easier (I think we should make a plugins namespace, with procedures that
> > are called when relevant events happen, so plugins can register to some
> > events, and they'll be called when it happens).
> >
> > 3. We should move every piece of code related to windows into the GUI
> > namespace (::amsn). We should make them have a consistent look & feel.
We
> > could provide procedures from the themes namespace to get default
options
> > and colors. We should avoid creating images with the "image create"
> > command, but use a ::skin::createImage XXX procedure that will load a
> > different file depending on the skin, or use the default one if no
> > available.
> > We should start making a unified preferences window.
> >
> > When this is finished, we are ready to release 1.0. ;)
> >
> > I've been very active these days, but now it's time to study, and i have
> > much work to do so I'll probably be more quiet from Christmas to
> > February.
> >
> > Have a nice Christmas.
> >
> > Greets. Alvaro.
> >
> > --
> >
> > (:==============================:)
> > Alvaro J. Iradier Muro
> > airadier@...
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Amsn-devel mailing list
> > Amsn-devel@...
> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
> -------------------------------------------------------------------
> _ _ _ __ __ _ _ _
> /\/\ _ _| | |_(_) / /\ \ \___| |__/\ /(_)___(_) ___ _ __
> / \| | | | | __| \ \/ \/ / _ \ '_ \ \ / / / __| |/ _ \| '_ \
> / /\/\ \ |_| | | |_| |\ /\ / __/ |_) \ V /| \__ \ | (_) | | | |
> \/ \/\__,_|_|\__|_| \/ \/ \___|_.__/ \_/ |_|___/_|\___/|_| |_|
> Internet Services
>
> Knowledge is Power... so is Linux
> -------------------------------------------------------------------
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@...
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
--
(:==============================:)
Alvaro J. Iradier Muro
airadier@...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
Amsn-devel mailing list
Amsn-devel@...
https://lists.sourceforge.net/lists/listinfo/amsn-devel
|