Phil, you're idea is good, and thx for trying to help, but I think we need to start off from scratch and stop messing with amsn1, it's the only way we're gonna have a good design with no constraints and we'll be able to make a good product (with fast development) without breaking the main branch... drop the idea, although it was interesting... apart from that, as I said, there isn't 2 layers.. only one telepathy2GUI, the XML2GUI is a GUI component...
here's an example :
socket -> we receive from msn someone got online
libmsn -> send 'user-online' on d-bus
telepathy -> send 'user-online' to tel2GUI
tel2GUI -> call the appropriate functions : create_notify + update_CL
----
possibility 1 :
------
GUI component -> create_notify needs to create a new window, instead of a lonnnng list of commands with packs, blablabla, it would do a :
::XML2GUI::Show [XML2GUI::buildComponent notifyWindow] $x $y
XML2GUI::buildCompoennt : would read the XML file, understand what the notify window should contain, create the widgets using the toolkit generator and return an identifier to the new window...
-----
possibility 2 :
-----
GUI component -> create_notify calls a megawidget from Tom's work [::Notify::Create] .. and that's it...
-------
The end...


problem with possibility 2, if we want to use a gtk toolkit, we'll have to rewrite the whole code to create a notify window in gtk widgets.. while using the XML2GUI it's totally transparent.. as long as the generator is written.. updated to the XML will affect all toolkits...
an example of a generator is
set b [::${toolkit_generator}_generator::createButton $parent $name]
::${toolkit_generator}_generator::modifyProperty $b background $newcolor

(this is an example.. this allows a single API to work with all toolkits.. the generator code will take care of creating the widgets and changing their attributes (or ignore attributes if not supported by the toolkit, or use a workaround to simulate the same attribute) in the language of your choice...
SOMETHING LIKE THAT!!!

hope it's clear enough now...
design is not YET done.. so no long thread about "ohh, but what if you want to do this", or "would it work like that"...

KaKaRoTo



On Tue, 13 Dec 2005 13:43:40 -0500, Le Philousophe - Phil <[EMAIL PROTECTED]> wrote:

 *  aMSN Team (amsn1).............(everyone)
 *  aMSN2 Team (amsn2)
     *RnD
         - libmsn team ....................(Youness, GrdScarabe,Phil)
         - D-bus for Tcl team .............(Karol)
         - telepathy to GUI layer team ....(?)
         - XML2GUI team ...................(Youness, Vivia)
         - GUI team .......................(Tom, Lee)
     * Web/Documentation.......(Lee, Diego, Yves)
     * QA..............................(Alberto, Thomas)
     * Management (+design)................(Youness, Burger, Harry)

I want to be one of yours !!!
I can help on several things but I think I can be useful for MSN protocol
since I studied it. I wouldn't like to have learnt for nothing ;).
But here is my trouble : it seems that nobody read my mail !!
I spoke about a special thing : as we have a layer between telepathy and GUI we can plug this layer as a module. Like that we can have another module (in
TCL) that supports MSN protocol without telepathy and we could go
progressively to Telepathy. Anyway, I don't understand : we have
Telepathy2GUI and XML2GUI ????? (Thanks to Harry for the answer)
Here is a little draw to explain my thoughts

GUI <-> Core Event system <-> aMsn 2 Telepathy <-> Telepathy........
GUI <-> Core Event system <-> aMsn MSN Protocol layer

Like that we keep the old idea to make it multiprotocol and Telepathy is a protocol like others. For more protocols we should be able able to load "aMsn
2 Telepathy" several times !
Phil

Le Tuesday 13 December 2005 19:24, Youness Alaoui a écrit :
Ok, cool... I got 3 answers so far, all 3 answers were one-liners... it
seems I made people relax a little... lol, damn I hate looong useless
discussions (but do love looonnnggg emails, hopefeully useful)
by the way, those one-liners meant "we're ok with everything you said" or
did they mean "I didn't get anything from what you said, was it even
english?", hehe...

ok, so here's the teams assignations so far... please answer directly by
modifying this list :


*  aMSN Team (amsn1).............(everyone)
*  aMSN2 Team (amsn2)
    *RnD
        - libmsn team ....................(Youness, GrdScarabe)
        - D-bus for Tcl team .............(Karol)
        - telepathy to GUI layer team ....(?)
        - XML2GUI team ...................(Youness, Vivia)
        - GUI team .......................(Tom, Lee)
    * Web/Documentation.......(Lee, Diego, Yves)
    * QA..............................(Alberto, Thomas)
    * Management (+design)................(Youness, Burger, Harry)


KaKaRoTo


On Tue, 13 Dec 2005 12:56:48 -0500, Alberto Diaz <[EMAIL PROTECTED]>

wrote:
> I volunteer for Q&A so, contact me if u want.
>
> Alberto
>
> El Tuesday, 13 de December de 2005 05:57, Youness Alaoui escribió:
>> ok, ok everyone, relax... I already said in a previous email that I had
>> a
>> plan to organize all this and that it would be (partially) based on the
>> system we use at my job.. with the difference that it would take into
>> consideration that it is no professional product and we do this in our
>> free time...
>> My idea is to have three more teams actually :
>> 1 - general administration
>> 2 - QA (Quality of Assurance.. basically testers with professional
>> behavior and tasks)
>> 3 - Documentation
>>
>> + a global 'RnD' team, which would consist of the teams listed below...
>>
>> I would like to set up a system for the work to be done, once a design
>> is
>> comleted we'll have hunderds of tasks, and I'll probably create a sample >> code for everyone to start with (the interface of each class at least as
>> well as documented API within the code) now.. you have a simple task
>> like
>> "enter code for this functionality".. with detailed discussion on it, so
>> we can keep track of everything said on it (no copy paste of emails,
>> someone in charge of this would enter a few lines to summarize the
>> important points).. you would do it, and send an email to a mailing list
>> saying "completed task XXX" with the number of the task... we'll use
>> trac
>> for this kind of job... we will also use SF.net's 'tasks' system...
>> we'll
>> see all that in time...
>> now, here's the thing.. you implement a feature, so you send an email to
>> say 'I finished this', EACH commit, should have the 'ticket number'
>> which
>> means you are NOT ALLOWED to commit anything if it's not already entered
>> in the system as a ticket... so if you want a new feature, you would
>> send
>> a mail to the admin (me) with an explanation of what you want and ask
>> for
>> a new ticket to be created.. once it's accepted and created, I'll send a
>> mail telling you "here's your ticket", then you have the right to add
>> your
>> feature and commit your change with the ticket number in the comments of
>> the commit...
>> Each commit that would create a new feature OR have a feature change
>> (new
>> command line option, new API function, build number changed which makes >> our internal config file incompatible with a new version (from key/value >> pairs to XML for config.xml for example)) you would have to CC the doc
>> manager in your 'completed' email..
>> I will send templates for these kind of files... so something like :
>> =========================================================
>> Ticket : 1043975 - Request to have a command line option for whatever...
>> Fix date : octeber 10th 2010
>> Fixed by : Kakaroto
>> Fix information : PARTIALLY FIXED || FIXED
>>
>> To complete the feature request, I added a new option -d to be able to
>> do
>> this...
>> note that if the -d option is supplied, it will override the -c
>> option...
>>
>> What to test : command line options with -d and -c, permutations, and
>> other options, and this ... behavior when having/not having the option
>> enabled in the command line...
>> =========================================================
>>
>>
>> ok, so that's an example.. this email would go to a mailing list with a
>> CC
>> to the QA manager and the doc manager and myself (and the requester of
>> the
>> feature if any)... a copy should be pasted in the ticket information on
>> trac, and the ticket set to "needs to be tested"... the doc manager
>> would
>> automatically update his documentation based on this and the QA manager
>> would automatically test it, make sure it introduced no side effect
>> bugs,
>> and then close the ticket if it's perfect...
>>
>> this will assure us that the docs are always up to date, that everything
>> is documented in the meaning that you are to fix a bug, and you see
>> "humm.. to fix the bug I have to remove this bit of code, but that code
>> is
>> there specifically to do something, why was it added in the first place
>> ???", you look at CVS history, you get the commit, if you don't have
>> enough info from the commit log, you can see the ticket number, go to
>> trac, search for the ticket, and see detailed info about the bug/feature >> that was requested, also, about who fixed it, who asked for it, when was
>> it done, etc...
>>
>> This is what I meant by we need people to be serious, because I don't
>> want
>> to send an email to someone in docs and never get a reply after a month
>> or
>> two... and never see a change... we need people to be ORGANISED! which >> mean an email client where incoming mail would go to a certain dir, when >> you finish something, you move the mail to a 'done' dir, you tag emails
>> as
>> 'TODO' and have a followup directory, and if after a week you didn't get >> the chance to document something in your followup dir, answer the poster
>> and say 'hey, I got your mail, don't worry, it's not lost somewhere,
>> I'm a
>> bit busy, I'll take care of it when I can, but don't worry, it's in my >> followup directory'.. so we're not like 'when is the work gonna be done
>> ???'
>>
>> Anyways, this is my fast explanation of a model at almost 1AM and I'm
>> completly exhausted... so please, just stop talking about this.. we're
>> not
>> yet into programming, not yet into documenting.. for the moment we're in >> designing the teams, then we'll be designing the structure, then choose
>> a
>> language, then design the tasks, then divide and assign the tasks, then
>> start coding, then the documentation comes after that, then the
>> testing...
>>
>> This model can be very loose, it can be modified to fit everyone's
>> needs,
>> it will be discussed long enough so everyone can get a
>> working/efficient/trouble-free system to have a great project... so
>> please
>> don't panic and say "ahhh, I don't want to write emails" or "ahhhh, I
>> want
>> to add whatever feature I wantttt"... we'll see that in time, for now...
>>
>> honestly, now I don't know what I was talking about, I'm really tired..
>> so
>> really, sorry, but I'll leave it as it is..
>> my main point was "stop worrying about irelevant things for now... and
>> concentrate on what really matters"..
>>
>> >> *  aMSN Team (amsn1 ?).............(everyone)
>> >> *  aMSN2 Team (amsn2)
>> >>       - libmsn team ....................(Youness, GrdScarabe)
>> >>       - D-bus for Tcl team .............(Karol)
>> >>       - telepathy to GUI layer team ....(?)
>> >>       - XML2GUI team ...................(Youness)
>> >>       - GUI team .......................(Tom, Lee)
>> >>       - Web/Documentation.......(Lee, Diego, Yves)
>> >>       - QA..............................(?)
>>
>> I will need someone to help me for the XML2GUI project, I think Phil on
>> the libmsn team (confirm please) and someone for the layer between
>> telepathy and the GUI... Karol, you think you'll need help ? Tom, Lee,
>> good luck, I think you're on the right track already... web/doc,
>> perfect,
>> we'll assign managers of each team later... QA who wants to ?
>>
>> ohh.. there were some questions from scarabe too :
>> > The questions are :
>> >  - Do these groups correspond to the work we have to do ?
>>
>> yes, of course, what do you mean ?
>>
>> >  - Who are the responsibles/leaders of each group ?
>>
>> we'll see, we don't even know who's in the groups... but basically, I'll
>> be the manager of everything, I can be manager of all groups + of all
>> individual group
>>
>> >  - How do they refer with each others ?
>>
>> what do you mean ? they will be individual projects.. the only thing
>> that
>> needs to understand the other projects is the telepathy2GUI layer, which
>> will be easy to do as long as the public interfaces that we define in
>> the
>> design phase NEVER change...
>>
>> >  - What are the artifacts that will preserve us from interfacing
>> > problems ?
>>
>> what do you mean ?
>>
>> >  - How will every team refer to the global leader (Youness ?)
>>
>> also what do you mean ? refer to ? there are emails... hehe, I didn't
>> get
>> your question
>>
>> >  - How will documentations/specifications live together ?
>>
>> I think I just explained it
>>
>> >  - Do we create a new list to preserver each branch from the
>>
>> development
>>
>> > of the other (this list is quite missy now  ) ?
>>
>> yes of course, a new list... a new list for all discussions, maybe a
>> list
>> for each individual project + one for all projects + one for specific
>> tasks (like for documentation-TODO and for 'ticket-completed',etc...)
>> everyone should be subscribed so this way we all get the same messages, >> but we would have the messages filtered in an easy way (and we may have
>> a
>> bot listening to some lists, like the doc and which would organise
>> things... like a 'add-to-wiki' mailing list which would have a bot
>> subscribed and which would add to the wiki directly and answer you with
>> a
>> link, you would only have to link to the page from wherever you want)
>>
>> > - How insuring code quality/clarity in the new branch ? (cvs masters
>>
>> ?)
>>
>> I never understand your questions!!!
>>
>> and lastly, about chat logs, no, it's not automatic, it's not stored
>> anywhere either.. it's actually the log of the bot, which can be
>> transformed into an html log file using a script (reads the bot-log file
>> and create a chat-log file).. I would need a cron job to do it, and
>> basically a script that would make sure the file is in .gz format (which >> means the log file is completed) and wasn't already extracted (logs are
>> stored per day 20051210.gz 20051211.gz, etc... and you do a
>> ./createchatlog 20051210 for example)... once I have that and create a
>> cron job, we'll be able to have per-day chat logs...
>>
>>
>> KaKaRoTo
>>
>> On Mon, 12 Dec 2005 23:21:32 -0500, Lee Olson <[EMAIL PROTECTED]>
>>
>> wrote:
>> > On 12/12/05, GrdScarabe <[EMAIL PROTECTED]> wrote:
>> >> -----BEGIN PGP SIGNED MESSAGE-----
>> >> Hash: SHA1
>> >>
>> >> >>Personnally I'd like to work on libmsn with Youness if everybody
>> >>
>> >> agree ...
>> >>
>> >> *  aMSN Team (amsn1 ?).............(everyone)
>> >> *  aMSN2 Team (amsn2)
>> >>       - libmsn team ...................(Youness, GrdScarabe)
>> >>       - D-bus for Tcl team .............(Karol)
>> >>       - telepathy to GUI layer team ....(?)
>> >>       - XML2GUI team ...................(Youness)
>> >>       - GUI team .......................(Tom, Lee)
>> >>       - Web/Documentation.......(Lee, Diego, Yves)
>> >>
>> >> >>Do we continue working on the list ... I'm not against the IRC but
>> >> >>
>> >> >> - there is no historic of what is said
>> >> >
>> >> > I think Youness is logging it all with his bot.
>> >>
>> >> That's cool ! Are the logs published somewhere ?
>> >>
>> >> I'm ok to work on documentation too if needed ...
>> >>
>> >> What do you think, instead of a team "documentation" to have a
>> >> responsible for documentation/relations in each team ?
>> >>
>> >> It will be easier for someone involved in the coding to document a
>>
>> part
>>
>> >> that someone totally out of the development !
>> >>
>> >> I'm also thinking to litterate coding ... but I don't know how all of
>> >> you consider this method ...
>> >
>> > I would appreciate your help in documentation. Once I have more time >> > to get things organized, I would like to start assigning documentation >> > tasks, but until then, we need to clean up what we currently have on
>> > the wiki and other places.
>> >
>> > Developers will need to consult with a documentation manager so that
>> > we can merge documentation from the developer when they are adding
>> > something new to aMSN, or documenting something technical that a
>> > documentation member would not necessarily be able to explain quite as
>> > well.  I like the idea of having documentation relations with each
>> > team, but we must also think of how the documentation will all come
>> > together as a whole.
>> >
>> > I suppose each documentation relation from each team would combine the >> > documentation which they receive and give it to the head documentation >> > manager, who would organize everything and make sure it's presented in
>> > a clear, readable, and standard way.
>> >
>> > We must also consider how the wiki is maintained.  Maybe we need to
>> > establish a maintainer for that just to make sure that things are
>> > being kept organized and up to date.
>> >
>> > ~Lee
>> >
>> >> GrdScarabe
>> >> -----BEGIN PGP SIGNATURE-----
>> >> Version: GnuPG v1.4.2 (GNU/Linux)
>> >> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>> >>
>> >> iD8DBQFDnkTbPmfsnt4Id3wRAtDCAJ9K+UlmXmybnQfsurbSJmr4sy1p3QCfWJv+
>> >> /oGwEn5x6nu7n/o8nbehdcY=
>> >> =lK8P
>> >> -----END PGP SIGNATURE-----
>> >>
>> >>
>> >> -------------------------------------------------------
>> >> This SF.net email is sponsored by: Splunk Inc. Do you grep through
>>
>> log
>>
>> >> files
>> >> for problems? Stop! Download the new AJAX search engine that makes
>> >> searching your log files as easy as surfing the  web.  DOWNLOAD
>>
>> SPLUNK!
>>
>> >> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
>> >> _______________________________________________
>> >> Amsn-devel mailing list
>> >> Amsn-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>> >
>> > -------------------------------------------------------
>> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log
>> > files
>> > for problems? Stop! Download the new AJAX search engine that makes
>> > searching your log files as easy as surfing the  web.  DOWNLOAD
>>
>> SPLUNK!
>>
>> > http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
>> > _______________________________________________
>> > Amsn-devel mailing list
>> > Amsn-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel



--
KaKaRoTo


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Reply via email to