subject:"Re\: \[Amsn\-devel\] aMSN2 \- Second design draft"

no, that was a PLUGIN, and it uses a dbus-whatever command line utility to 
listen to dbus... I'm talking about writing a C extension to add 
new commands to the Tcl interpreter... it's not the same.. we'll need jonne to 
answer us, but I do think he started working on that..
KKRT

On Fri, Aug 18, 2006 at 10:49:19PM -0400, J?r?me Gagnon-Voyer wrote:
 It was a plugin to RECEIVE dbus binding, not send... The plugin was  
 on SVN last time I looked
 
 J?r?me
 Courriel:  [EMAIL PROTECTED]
 MSN Messenger:  [EMAIL PROTECTED]
 iChat  AIM:  [EMAIL PROTECTED]
 Skype: germinator5000
 
 
 Le 18 ao?t 2006 ? 22:11, Philippe Khalaf a ?crit :
 
 also, I think Jonne (or was it someone else) was already working  
 on the DBUS bindings and I think the work was in
 progress (but not completed).
 Ah really? Is the code online somewhere? Would be interesting to see
 the progress as this is essential.
 

 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Amsn-devel mailing list
 Amsn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/amsn-devel


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft


On Fri, Aug 18, 2006 at 10:11:38PM -0400, Philippe Khalaf wrote:
 On Fri, 18 Aug 2006 21:37:45 -0400
 [EMAIL PROTECTED] (Youness Alaoui) wrote:
 
  AFAIK there are some tools that automatically generate C code for binding 
  any function from a C library, this can be 
  used in order to quickly generate the bindings... 
 What tools? They will generate bindings for TCL from C? What about
 from C++ (wx)? When wrapping an OO API in a non OO language I doubt
 automated tools will do the job. But hell I don't know maybe if I had a
 look at the tools.
 

it's 4:15 AM and I'm too tired to answer fully, just search for 'C Tcl/Tk 
wrapper code generator' on google, I think you'll find 
something... if you add 'site::wiki.tcl.tk' it will be easier to find the 
appropriate pages!
about OO, I don't know! I think it's doable with some progs, not sure though.. 
+ why C++ ? and why wxWidgets ? who said we wants wx? what's 
the pros and cons ?

  I don't think it's a huge issue anyways... 
 Think again :)
 

not now :p

  also, I think Jonne (or was it someone else) was already working on the 
  DBUS bindings and I think the work was in 
  progress (but not completed).
 Ah really? Is the code online somewhere? Would be interesting to see
 the progress as this is essential.
 

as I said, I think.. so Jonne will need to answer us about this... but it 
should definitely be put on SVN 'just in case' his PC burns.. we 
won't loose the code...so jonne.. please

  About the GUI, the Tcl code won't need to interact with wx or whatever, all 
  it will do is send events to the GUI layer 
  which will do all the GUI stuff.. there is no need for bindings or little 
  work to do on that matter...
  Maybe I'm wrong... it would be good to sum up everything that was 
  previously said about the different layers/structures 
 What will the GUI layer be written in? C? If so then you still need to
 design the interface between aMSN and the GUI layer. This is a
 lot of work and you will probably end up just mirroring the wx API
 This is equivalent to writing bindings.
 
 Regards,
 Philippe

nah, it's not like that, I really am too tired to explain, but let me try to be 
bried for once :
MSN server-NLN AWY [EMAIL PROTECTED] - telepathy - DBUS - Tcl - update 
data about the user (his status for example) - DBUS/event 
API - 'logic' C code that catches the event - from C call the GUI stuff... 
so when we do the DBUS to 'receive' and 'send' from telepathy to the 'core 
Tcl', we will also be doing the 'Tcl' to 'GUI' because we'll 
simply use the same way... 
Tcl will be used for most of the logic, and mostly for storing the data.. which 
means the list of users, their info, status... in short, the 
abook.. and the GUI will have its own C module which access that Data and uses 
it to draw the GUI..
and if you say 'you need bindings to get the GUI module to 'get' the data out 
of the Tcl core'... I say.. no... you simply do a :
Tcl_GetVariable();
or Tcl_Eval (array names $array);
for example.. don't forget Tcl has a very good C library that can be used.. so 
we're set!
Anyways, that's how I think I see it.. maybe tomorrow with both of my eyes 
opened I'll realize I don't see it this way, but in any case, I 
don't see how complicated it can be...

+ the GUI will be a module, so if you want to write a Tcl module using Tk, you 
can do it, if you want to write a C code using GTK+ or QT, 
then do it, if you want python and wxWidgets, then do it.. all you need is DBUS 
to receive 'GUI notification messages' and you need to be 
able to use the Tcl procs (core API) to get the data you want...
A HUGE discussion was over this and noone wants to leave Tcl and I do agree, 
development in Tcl is FAST, easy and many of us already know 
Tcl, so there is no need for a change... also, we can reuse some of the 
existing code... I don't want to repeat what was said, so read that 
thread and that's it.
ps: python: I simply HATE it, idnentation part of the syntax, WTF!!!... and 
perl is unmaintable.. so Tcl is better (faster development needs 
scripting language or Java...)

KKRT

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
 On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:
 
 On Sat, 19 Aug 2006 00:21:15 +0200
 Harry Vennik [EMAIL PROTECTED] wrote:
 
  Hi all,
 
  Finally I found some time to document some of my ideas in more detail.
 The
  result is this new draft. Quite a lot changed since the previous one,
 and it
  will change again in the next drafts (at least on those places where it
 just
  contains some vague suggestions). But I think things already are a lot
 better
  and more clear now.
 
  Any feedback is appreciated!
 
  Harry
 
 I've read your draft. It's good and I think can be followed
 successfully, but there are a few issues.
 
 First of all, you don't need to talk to Farsight directly. Telepathy
 has a stream-engine component that takes care of Farsight. You only
 need to request StreamedMedia channels and you are good to go. So no
 bindings required there.
 
 Before going to the next point I want to say that I think any proposals
 to write our own cross-platform toolkit are absurd. That is a HUGE
 project by itself and involves a ridiculous amount of time to
 undertake. I am sorry to say that no one in this project has the skill,
 time or experience to do it.
 
 The last serious issue is with the choice of using TCL. TK is
 getting dumped, so might as well dump TCL. Why? Your proposal involves
 writing a lot of bindings! Bindings for D-Bus and bindings for
 wxWindows. These will take a lot of time and energy to complete.
 Imagine all the time saved working with something that already has
 those bindings. If you guys want to keep the high level language thing
 going for aMSN, then we need to think of Python. It has good D-Bus
 bindings as well as wxWindows bindings. It is better and more popular
 than TCL. It seems like the logical and correct solution to take.
 People who don't know it can learn it, new developers who already know
 it will be interested/join, and those who are unable to learn it can
 still work on aMSN1. Added avantage is easy porting to another toolkit.
 If someone decides he wants a GTK+ aMSN2, he can fork the Python core
 and write his own UI.
 
 
 I agree wholeheartedly with all the points raised by Philippe. I would just
 like to add that I've got experience with the wxWidgets python bindings, and
 they're great. I can say the same about the dbus and gstreamer bindings as
 well. And please believe me, you do not want to write dbus nor wxWidgets (or
 any other UI toolkit) bindings from scratch just to get started. It's rather
 obvious why wrapping a whole UI toolkit is a lot of work, but probably not
 as obvious for the dbus bindings. Telepathy makes extensive use of recursive
 types and really push the existing bindings to their limits, and getting all
 of this right while at the same time writing everything from scratch is more
 work than I'm sure anyone on this project is willing and able to devote to
 it (after all it's not where the fun is).
 

who needs bindings to wxWidgets ? who needs bindings to Telepathy or gstreamer 
or whatever.. all we need is bindings for DBUS.

 That said, I really hope this doesn't turn into another language X vs
 language Y thread. :-) There's pros and cons to every possible choice, but
 all things considered, I think python is a great choice for the following
 practical reasons (I won't go into subtle language details):

that already happened and you can read the thread if you want... but as you 
said, pros and cons for everything, but I think in our situation 
Tcl has a far greater pros/cons ratio than any other language (I'm talking 
about the 'logic core, data storage' ONLY).

 - existing, mature bindings for dbus, wxWidgets, gstreamer, Linux desktop
 APIs, Win32 APIs (to give you an idea of how extensive this support is I've
 written a cross-platform wxPython multimedia app that embeds a Windows Media
 Player control in the UI on win32 (using COM), with lots of custom drawing
 in the overall UI, 100% skinned. no native code involved at all.)

We don't need that.. any GUI code will be in the C GUI module anyways... the 
Tcl part will only be if/else/switch/for/while.. a LOGICAL 
unit... + a way to store DATA...
The project will consist of multiple layers, most of them in C and the logic + 
data layer will be in Tcl...

 - a majority of aMSN's contributors were new to coding and learnt the
 language on the fly, and this pro still stands with python. it would however
 be lost if moving to a lower level language.

it's not the same, Tcl is a language that can be learned so fast, you can't 
compare it to other languages.. + many of us were FORCED to 
learn Tcl to work with aMSN, but now that we have a choice.. we don't want 
those other solutions.. and in my case especially python!!!

 - lots of experienced developers are familiar with python, and I think
 there's a reason why nobody writes tcl-bindings for stuff nowadays :-)

who needs them :P lol.. I mean we have a lot of

Re: [Amsn-devel] aMSN2 - Second design draft

Hi all,

I read the thread, and I already see that it is not particularly going in the 
right direction. Why? Python vs. TCL is not the thing to be discussed here. 
Of course Python has a lot of very very useful bindings, and TCL is missing 
some, but, what about the knowledge in the team? And, yes, then Youness' 
remark about the python syntax.. he's totally right! So those bindings are 
probably the only pro for Python.

What bindings do we need?
- D-BUS, that is for sure. I am curious if Jonne really has been working on 
that already. I have experimented with it too, and I think it can be done 
quite easily. Most difficult is the lazy typing in the Tcl core, which makes 
it difficult to find a reliable way to determine the type of a value. (The 
lazy typing means that the type is always 'string' until the value is used in 
some place that requires another type.)
- GUI. It is hard to tell now what these should be like. Just like Youness I'd 
like to have no direct dependencies between the logic core and the GUI, but 
only events being fired and handled. The event system I proposed should be 
able to handle that. But still, there are some difficulties with that. 

Youness: About the Tcl Data Layer, I did not literally talk about it, but it 
is very much the same as the Telepathy client code. 

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

Hi,
I will try to reply to all mails in one... But Youness already did many 
replies.
First when you proposed Python, I was sure that Youness won't be agree with 
that :p (By the way, you should maybe try Python once because I think it's a 
really good language). But it's clear I think it will be simpler to keep 
TCL...
About all bindings you said Youness already replied, the only one binding 
required is DBus and Jonne was working on it...
About wxWidgets, you are thinking we want to do a binding for that... But you 
misread the draft ! WxWidgets was only a proposal from Harry (which I refused 
for my part)... The better solution was to write an engine that transforms 
XML in widgets so it won't be a binding... It will only be only a library 
that takes XML as input and creates widgets with the library it is designed 
for... So it won't be a huge task... Maybe for GTK GUI use a aMSN2XML - 
Glade converter and pass it to a binding for GTK+
QT has already a XML system so maybe it will be a converter too...
The remaining thing is aMSN2XML - Tk and aMSN2XML - Win32 and IMO if the 
design for XML is well done won't be too hard...
Phil
P.S. Philippe if the the code for DBus binding isn't on SVN is because we 
haven't any directory to put it... Organization of the repository is still in 
discussion


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

Sorry, accidental send. it's not quite complete...

Op zaterdag 19 augustus 2006 13:07, schreef Harry Vennik:
 Hi all,

 I read the thread, and I already see that it is not particularly going in
 the right direction. Why? Python vs. TCL is not the thing to be discussed
 here. Of course Python has a lot of very very useful bindings, and TCL is
 missing some, but, what about the knowledge in the team? And, yes, then
 Youness' remark about the python syntax.. he's totally right! So those
 bindings are probably the only pro for Python.

 What bindings do we need?
 - D-BUS, that is for sure. I am curious if Jonne really has been working on
 that already. I have experimented with it too, and I think it can be done
 quite easily. Most difficult is the lazy typing in the Tcl core, which
 makes it difficult to find a reliable way to determine the type of a value.
 (The lazy typing means that the type is always 'string' until the value is
 used in some place that requires another type.)
 - GUI. It is hard to tell now what these should be like. Just like Youness
 I'd like to have no direct dependencies between the logic core and the GUI,
 but only events being fired and handled. The event system I proposed should
 be able to handle that. But still, there are some difficulties with that.

 Youness: About the Tcl Data Layer, I did not literally talk about it, but
 it is very much the same as the Telepathy client code.

 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
 Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Amsn-devel mailing list
 Amsn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/amsn-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

Op zaterdag 19 augustus 2006 13:09, schreef Philippe Valembois - Phil:
 Hi,
 I will try to reply to all mails in one... But Youness already did many
 replies.
 First when you proposed Python, I was sure that Youness won't be agree with
 that :p (By the way, you should maybe try Python once because I think it's
 a really good language). But it's clear I think it will be simpler to keep
 TCL...
 About all bindings you said Youness already replied, the only one binding
 required is DBus and Jonne was working on it...
Little correction: DBus is the only thing we'll need for sure. We'll probably 
need some bindings for the GUI too, although we are doing something wrong if 
we end up with complete wxWidgets bindings or something as huge as that.

 About wxWidgets, you are thinking we want to do a binding for that... But
 you misread the draft ! WxWidgets was only a proposal from Harry (which I
 refused for my part)... The better solution was to write an engine that
 transforms XML in widgets so it won't be a binding... It will only be only
 a library that takes XML as input and creates widgets with the library it
 is designed for... So it won't be a huge task...
Sounds nice, but the question is: is it really that simple? I'm afraid not... 
How to bind the GUI events (e.g. the user pressing a button) to code? How to 
handle all kind of widget options, which can be quite different on various 
toolkits? How to make it not only look native, but also feel native?

 Maybe for GTK GUI use a aMSN2XML - Glade converter and pass it to a binding
 for GTK+ QT has already a XML system so maybe it will be a converter too...
 The remaining thing is aMSN2XML - Tk and aMSN2XML - Win32 and IMO if the
 design for XML is well done won't be too hard...
Convert to Glade? You ever looked at GladeXML??? You could as well generate 
the C code from our XML and compile it... I don't believe it is as simple as 
you're saying. That is why I proposed wxWidgets as a possible solution, 
because it will provide a single toolkit, which is implemented in native 
widgets on various platforms, so there will be no need for us to care about 
which platform we're on, and thus make coding the GUI layer much easier, 
while still using native widgets.

And here we get exactly to where I was in my other mail when I accidentally 
pressed the send button. We need to get that GUI thing set. It has been 
discussed a thousand of times now, so it's time to get it in some direction. 
To put it in a few questions:

- What is our goal? XML2GUI, or nativeness on various platforms? (I.e.: If we 
have another way to serve all platforms with native widgets, would we go 
without XML?)
- What do we want to code, and what don't we want to code?
- How will we support plugins that want to add menu items and/ or buttons to 
the aMSN GUI? (That appears to be the most overlooked thing)
- Do we want to implement de GUI module in Tcl or C/C++?

Harry

 Phil

 P.S. Philippe if the the code for DBus binding isn't on SVN is because we
 haven't any directory to put it... Organization of the repository is still
 in discussion
I propose to do the same as Sander did with libmsn. Commit it into a fresh dir 
in trunk, and we'll svn move it when the directory structure gets set up.



 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job
 easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
 Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Amsn-devel mailing list
 Amsn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/amsn-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

2006-08-19 Thread Vivia Nikolaidou

I just got up just to see a big thread so I can't say I read
everything carefully, but IIRC (before I switched kde's language to
English) I couldn't get wxWidgets to display utf-8 characters. Does
anyone have any experience on that? IIRC audacity uses wxWidgets
(yeah, looks ugly to me), so please: if it can display utf-8, tell me
how because I need it here, if it cannot, it has to be rejected.
Besides, I remember trying to compile wxWidgets on Slackware and it
was an unbelievable hassle, I gave up. However, I haven't actually
*used* it, I just used programs that use it, so I might be way off
here.

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

On Fri, 18 Aug 2006 19:50:37 -0400
Philippe Khalaf [EMAIL PROTECTED] wrote:

 still work on aMSN1. Added avantage is easy porting to another toolkit.
 If someone decides he wants a GTK+ aMSN2, he can fork the Python core
 and write his own UI.
s/GTK+/QT

Regards,
Philippe

 
 Regards,
 Philippe
 
 -
 Using Tomcat but need to do more? Need to support web services, security?
 Get stuff done quickly with pre-integrated technology to make your job easier
 Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
 ___
 Amsn-devel mailing list
 Amsn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/amsn-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

On Fri, 18 Aug 2006 21:37:45 -0400
[EMAIL PROTECTED] (Youness Alaoui) wrote:

 AFAIK there are some tools that automatically generate C code for binding any 
 function from a C library, this can be 
 used in order to quickly generate the bindings... 
What tools? They will generate bindings for TCL from C? What about
from C++ (wx)? When wrapping an OO API in a non OO language I doubt
automated tools will do the job. But hell I don't know maybe if I had a
look at the tools.

 I don't think it's a huge issue anyways... 
Think again :)

 also, I think Jonne (or was it someone else) was already working on the DBUS 
 bindings and I think the work was in 
 progress (but not completed).
Ah really? Is the code online somewhere? Would be interesting to see
the progress as this is essential.

 About the GUI, the Tcl code won't need to interact with wx or whatever, all 
 it will do is send events to the GUI layer 
 which will do all the GUI stuff.. there is no need for bindings or little 
 work to do on that matter...
 Maybe I'm wrong... it would be good to sum up everything that was previously 
 said about the different layers/structures 
What will the GUI layer be written in? C? If so then you still need to
design the interface between aMSN and the GUI layer. This is a
lot of work and you will probably end up just mirroring the wx API
This is equivalent to writing bindings.

Regards,
Philippe

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

2006-08-19 Thread Ole André Vadla Ravnås

On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote:
On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote: On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:
On Sat, 19 Aug 2006 00:21:15 +0200 Harry Vennik [EMAIL PROTECTED] wrote: Hi all, Finally I found some time to document some of my ideas in more detail.
The result is this new draft. Quite a lot changed since the previous one, and it will change again in the next drafts (at least on those places where it just
contains some vague suggestions). But I think things already are a lot better and more clear now. Any feedback is appreciated!
Harry I've read your draft. It's good and I think can be followed successfully, but there are a few issues. First of all, you don't need to talk to Farsight directly. Telepathy
has a stream-engine component that takes care of Farsight. You only need to request StreamedMedia channels and you are good to go. So no bindings required there. Before going to the next point I want to say that I think any proposals
to write our own cross-platform toolkit are absurd. That is a HUGE project by itself and involves a ridiculous amount of time to undertake. I am sorry to say that no one in this project has the skill,
time or experience to do it. The last serious issue is with the choice of using TCL. TK is getting dumped, so might as well dump TCL. Why? Your proposal involves writing a lot of bindings! Bindings for D-Bus and bindings for
wxWindows. These will take a lot of time and energy to complete. Imagine all the time saved working with something that already has those bindings. If you guys want to keep the high level language thing
going for aMSN, then we need to think of Python. It has good D-Bus bindings as well as wxWindows bindings. It is better and more popular than TCL. It seems like the logical and correct solution to take.
People who don't know it can learn it, new developers who already know it will be interested/join, and those who are unable to learn it can still work on aMSN1. Added avantage is easy porting to another toolkit.
If someone decides he wants a GTK+ aMSN2, he can fork the Python core and write his own UI. I agree wholeheartedly with all the points raised by Philippe. I would just like to add that I've got experience with the wxWidgets python bindings, and
they're great. I can say the same about the dbus and gstreamer bindings as well. And please believe me, you do not want to write dbus nor wxWidgets (or any other UI toolkit) bindings from scratch just to get started. It's rather
obvious why wrapping a whole UI toolkit is a lot of work, but probably not as obvious for the dbus bindings. Telepathy makes extensive use of recursive types and really push the existing bindings to their limits, and getting all
of this right while at the same time writing everything from scratch is more work than I'm sure anyone on this project is willing and able to devote to it (after all it's not where the fun is).
who needs bindings to wxWidgets ? who needs bindings to Telepathy or gstreamer or whatever.. all we need is bindings for DBUS.Well, just as an example it's very handy to have GStreamer bindings in case you want to construct a custom pipeline. Say you want an incoming webcam stream to be used as an outgoing stream as well, while at the same time logging it to disk. Or in another pipeline you might want to insert an effects element so that you get PhotoBooth-style effects on one of your outgoing video streams, and for example audio effects applied to one of your voice conversations. With GStreamer the possibilities are endless.
That said, I really hope this doesn't turn into another language X vs
language Y thread. :-) There's pros and cons to every possible choice, but all things considered, I think python is a great choice for the following practical reasons (I won't go into subtle language details):
that already happened and you can read the thread if you want... but as you said, pros and cons for everything, but I think in our situationTcl has a far greater pros/cons ratio than any other language (I'm talking about the 'logic core, data storage' ONLY).
Hypothetically if you're right, is it worth the months/years it takes to write all the prerequisities and all the time needed to maintain them?
- existing, mature bindings for dbus, wxWidgets, gstreamer, Linux desktop APIs, Win32 APIs (to give you an idea of how extensive this support is I've written a cross-platform wxPython multimedia app that embeds a Windows Media
Player control in the UI on win32 (using COM), with lots of custom drawing in the overall UI, 100% skinned. no native code involved at all.)We don't need that.. any GUI code will be in the C GUI module anyways... the Tcl part will only be if/else/switch/for/while.. a LOGICAL
unit... + a way to store DATA...The project will consist of multiple layers, most of them in C and the logic + data layer will be in Tcl...And all of this is implementable in

Re: [Amsn-devel] aMSN2 - Second design draft

Op zaterdag 19 augustus 2006 16:38, schreef Ole André Vadla Ravnås:
 that already happened and you can read the thread if you want... but as you
 said, pros and cons for everything, but I think in our situation Tcl has a
 far greater pros/cons ratio than any other language (I'm talking about the
 'logic core, data storage' ONLY).

 Hypothetically if you're right, is it worth the months/years it takes to
 write all the prerequisities and all the time needed to maintain them?
That question is here too early... nobody knows yet what those prerequisites 
will be, apart from D-BUS bindings. So I think this discussion about 'Python 
or TCL' is completely senseless now. If and only if we reach the point that 
it becomes clear that the prerequisites for aMSN2 logic being implemented in 
TCL can really not be met, then there can be any discussion about using 
something else. And in that case, I'd prefer a low level language to solve 
the problem.

 You're obviously judging a language that you've never really given a try.
 The indentation syntax tends to be met with prejudice, even I misliked that
 until I had used it for 20 minutes. Aside from the lowered potential for
 errors (having one way to have a block of statements instead of two, like in
 C), it also provides the benefit of consistency -- you literally force the
 developers to indent their code and stick to one style, resulting in clean,
 readable and maintainable code all across the project.   
What would be the second way to have a block of statements in C? There is only 
{ } isn't it?

And about Python: what happens if a line just gets too long, so I want to 
break it in two? Somehow I'd expect it would break not only visually, but 
also syntactically in Python :-P And oh yes, breaking a line in TCL often 
requires a backslash before the linebreak too. That already irritates me. 
Whitespace is whitespace, and that simply shouldn't have a meaning.


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

2006-08-19 Thread Ole André Vadla Ravnås

On 8/19/06, Harry Vennik [EMAIL PROTECTED] wrote:
Op zaterdag 19 augustus 2006 16:38, schreef Ole André Vadla Ravnås: that already happened and you can read the thread if you want... but as you said, pros and cons for everything, but I think in our situation Tcl has a
far greater pros/cons ratio than any other language (I'm talking about the 'logic core, data storage' ONLY). Hypothetically if you're right, is it worth the months/years it takes to write all the prerequisities and all the time needed to maintain them?
That question is here too early... nobody knows yet what those prerequisiteswill be, apart from D-BUS bindings. So I think this discussion about 'Pythonor TCL' is completely senseless now. If and only if we reach the point that
it becomes clear that the prerequisites for aMSN2 logic being implemented inTCL can really not be met, then there can be any discussion about usingsomething else. And in that case, I'd prefer a low level language to solve
the problemand thus leaving contributors without a software development background in the dark.
You're obviously judging a language that you've never really given a try. The indentation syntax tends to be met with prejudice, even I misliked that until I had used it for 20 minutes. Aside from the lowered potential for
errors (having one way to have a block of statements instead of two, like in C), it also provides the benefit of consistency -- you literally force the developers to indent their code and stick to one style, resulting in clean,
readable and maintainable code all across the project.What would be the second way to have a block of statements in C? There is only{ } isn't it?Sorry that sentence was all wrong; what I meant to say was: having one way to have a block of one or more statements, instead of two depending on one vs many, like in C.
And about Python: what happens if a line just gets too long, so I want tobreak it in two? Somehow I'd expect it would break not only visually, but
also syntactically in Python :-P And oh yes, breaking a line in TCL oftenrequires a backslash before the linebreak too. That already irritates me.Whitespace is whitespace, and that simply shouldn't have a meaning.
You'd use a backslash.-
Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Amsn-devel mailing listAmsn-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/amsn-devel

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

On Sat, Aug 19, 2006 at 01:59:12PM +0200, Harry Vennik wrote:
 Op zaterdag 19 augustus 2006 13:09, schreef Philippe Valembois - Phil:
  Hi,
  I will try to reply to all mails in one... But Youness already did many
  replies.
  First when you proposed Python, I was sure that Youness won't be agree with
  that :p (By the way, you should maybe try Python once because I think it's
  a really good language). But it's clear I think it will be simpler to keep
  TCL...
  About all bindings you said Youness already replied, the only one binding
  required is DBus and Jonne was working on it...
 Little correction: DBus is the only thing we'll need for sure. We'll probably 
 need some bindings for the GUI too, although we are doing something wrong if 
 we end up with complete wxWidgets bindings or something as huge as that.
 

We'll need bindings for the GUi only if we code the GUI with Tcl, but my 
understanding is that the GUI will either be a C module that 
commmunicates with Tcl through :
1 - events being sent (dbus?)
2 - using the Tcl library for C (Tcl_GetStringFromObj(), Tcl_Eval())
or it will be a Tk module written in Tk, in which case, no need for 
'bindings'...

  About wxWidgets, you are thinking we want to do a binding for that... But
  you misread the draft ! WxWidgets was only a proposal from Harry (which I
  refused for my part)... The better solution was to write an engine that
  transforms XML in widgets so it won't be a binding... It will only be only
  a library that takes XML as input and creates widgets with the library it
  is designed for... So it won't be a huge task...
 Sounds nice, but the question is: is it really that simple? I'm afraid not... 
 How to bind the GUI events (e.g. the user pressing a button) to code? How to 
 handle all kind of widget options, which can be quite different on various 
 toolkits? How to make it not only look native, but also feel native?
 

that, I don't know.. that's where a proof of concept would come in handy... in 
theory, what I had in mind is that the XML for the GUI would 
contain a 'name' for each thing, and once you click on a button for someting, 
its name is sent to the GUI layer which knows what's its 
purpose.. if nothing needs to access protocol or change data, then it will 
process everything in the GUI module, if it needs to access 
protocol, it will send the appropriate/corresponding event... 

  Maybe for GTK GUI use a aMSN2XML - Glade converter and pass it to a binding
  for GTK+ QT has already a XML system so maybe it will be a converter too...
  The remaining thing is aMSN2XML - Tk and aMSN2XML - Win32 and IMO if the
  design for XML is well done won't be too hard...
 Convert to Glade? You ever looked at GladeXML??? You could as well generate 
 the C code from our XML and compile it... I don't believe it is as simple as 
 you're saying. That is why I proposed wxWidgets as a possible solution, 
 because it will provide a single toolkit, which is implemented in native 
 widgets on various platforms, so there will be no need for us to care about 
 which platform we're on, and thus make coding the GUI layer much easier, 
 while still using native widgets.
 
ok, that's why wxWidget is wanted... I see, well, I don't know, Vivia gave us 
some good points, I never used wx or tried it or used a 
program that uses it, so I don't know anything about it.. and what vivia said 
might be 'outdated' ... 
a converter from our XML to another XML format is out of the question, it 
removes our modularity, simplicity etc... 

 And here we get exactly to where I was in my other mail when I accidentally 
 pressed the send button. We need to get that GUI thing set. It has been 
 discussed a thousand of times now, so it's time to get it in some direction. 
 To put it in a few questions:
 
 - What is our goal? XML2GUI, or nativeness on various platforms? (I.e.: If we 
 have another way to serve all platforms with native widgets, would we go 
 without XML?)
 - What do we want to code, and what don't we want to code?
 - How will we support plugins that want to add menu items and/ or buttons to 
 the aMSN GUI? (That appears to be the most overlooked thing)
 - Do we want to implement de GUI module in Tcl or C/C++?
 
 Harry

ok, this I started thinking about it earlier in your mail, but you go exactly 
to the point I wanted to say 
What is our goal ? nativeness on various platforms ? not even that! the goal 
was to stop people saying why not QT ? and why not GTK? .. 
and I think that maybe, if we choose one toolkit, which looks better than Tk, 
then people won't complain AT ALL... so I don't know.. the 
purpose was to please the users and stop receiving complaints...
now it gives us two choices : 
1 - use one toolkit and only one...
2 - wxwidgets which looks native to everyone
3 - many toolkits as many modules so everyone gets what he wants... 

more precisely, what I wanted to say is that our goal is indeed nativeness, NOT 
XML2GUI.. the whole XML2GUI was meant to

Re: [Amsn-devel] aMSN2 - Second design draft

This looks like a flame war between python and tcl... and I don't want to start 
the debate again.
You looked offended by my mail, I have no idea why, but in that case, sorry.
I'll stop the discussion there as none of us can be convinced of who is right, 
and noone really knows who is right...

KKRT

On Sat, Aug 19, 2006 at 04:38:10PM +0200, Ole Andr? Vadla Ravn?s wrote:
 On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote:
 
 On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
  On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:
  
  On Sat, 19 Aug 2006 00:21:15 +0200
  Harry Vennik [EMAIL PROTECTED] wrote:
  
   Hi all,
  
   Finally I found some time to document some of my ideas in more
 detail.
  The
   result is this new draft. Quite a lot changed since the previous one,
  and it
   will change again in the next drafts (at least on those places where
 it
  just
   contains some vague suggestions). But I think things already are a
 lot
  better
   and more clear now.
  
   Any feedback is appreciated!
  
   Harry
  
  I've read your draft. It's good and I think can be followed
  successfully, but there are a few issues.
  
  First of all, you don't need to talk to Farsight directly. Telepathy
  has a stream-engine component that takes care of Farsight. You only
  need to request StreamedMedia channels and you are good to go. So no
  bindings required there.
  
  Before going to the next point I want to say that I think any proposals
  to write our own cross-platform toolkit are absurd. That is a HUGE
  project by itself and involves a ridiculous amount of time to
  undertake. I am sorry to say that no one in this project has the skill,
  time or experience to do it.
  
  The last serious issue is with the choice of using TCL. TK is
  getting dumped, so might as well dump TCL. Why? Your proposal involves
  writing a lot of bindings! Bindings for D-Bus and bindings for
  wxWindows. These will take a lot of time and energy to complete.
  Imagine all the time saved working with something that already has
  those bindings. If you guys want to keep the high level language thing
  going for aMSN, then we need to think of Python. It has good D-Bus
  bindings as well as wxWindows bindings. It is better and more popular
  than TCL. It seems like the logical and correct solution to take.
  People who don't know it can learn it, new developers who already know
  it will be interested/join, and those who are unable to learn it can
  still work on aMSN1. Added avantage is easy porting to another toolkit.
  If someone decides he wants a GTK+ aMSN2, he can fork the Python core
  and write his own UI.
 
 
  I agree wholeheartedly with all the points raised by Philippe. I would
 just
  like to add that I've got experience with the wxWidgets python bindings,
 and
  they're great. I can say the same about the dbus and gstreamer bindings
 as
  well. And please believe me, you do not want to write dbus nor wxWidgets
 (or
  any other UI toolkit) bindings from scratch just to get started. It's
 rather
  obvious why wrapping a whole UI toolkit is a lot of work, but probably
 not
  as obvious for the dbus bindings. Telepathy makes extensive use of
 recursive
  types and really push the existing bindings to their limits, and getting
 all
  of this right while at the same time writing everything from scratch is
 more
  work than I'm sure anyone on this project is willing and able to devote
 to
  it (after all it's not where the fun is).
 
 
 who needs bindings to wxWidgets ? who needs bindings to Telepathy or
 gstreamer or whatever.. all we need is bindings for DBUS.
 
 
 Well, just as an example it's very handy to have GStreamer bindings in case
 you want to construct a custom pipeline. Say you want an incoming webcam
 stream to be used as an outgoing stream as well, while at the same time
 logging it to disk. Or in another pipeline you might want to insert an
 effects element so that you get PhotoBooth-style effects on one of your
 outgoing video streams, and for example audio effects applied to one of your
 voice conversations. With GStreamer the possibilities are endless.
 
 That said, I really hope this doesn't turn into another language X vs
  language Y thread. :-) There's pros and cons to every possible choice,
 but
  all things considered, I think python is a great choice for the
 following
  practical reasons (I won't go into subtle language details):
 
 that already happened and you can read the thread if you want... but as
 you said, pros and cons for everything, but I think in our situation
 Tcl has a far greater pros/cons ratio than any other language (I'm talking
 about the 'logic core, data storage' ONLY).
 
 
 Hypothetically if you're right, is it worth the months/years it takes to
 write all the prerequisities and all the time needed to maintain them?
 
 - existing, mature bindings for dbus, wxWidgets, gstreamer, Linux desktop
  APIs, Win32 APIs (to give you an idea of how extensive this

Re: [Amsn-devel] aMSN2 - Second design draft

Le Saturday 19 August 2006 21:47, Youness Alaoui a écrit :
 On Sat, Aug 19, 2006 at 01:59:12PM +0200, Harry Vennik wrote:
  Op zaterdag 19 augustus 2006 13:09, schreef Philippe Valembois - Phil:
   Hi,
   I will try to reply to all mails in one... But Youness already did many
   replies.
   First when you proposed Python, I was sure that Youness won't be agree
   with that :p (By the way, you should maybe try Python once because I
   think it's a really good language). But it's clear I think it will be
   simpler to keep TCL...
   About all bindings you said Youness already replied, the only one
   binding required is DBus and Jonne was working on it...
 
  Little correction: DBus is the only thing we'll need for sure. We'll
  probably need some bindings for the GUI too, although we are doing
  something wrong if we end up with complete wxWidgets bindings or
  something as huge as that.

 We'll need bindings for the GUi only if we code the GUI with Tcl, but my
 understanding is that the GUI will either be a C module that commmunicates
 with Tcl through :
 1 - events being sent (dbus?)
 2 - using the Tcl library for C (Tcl_GetStringFromObj(), Tcl_Eval())
 or it will be a Tk module written in Tk, in which case, no need for
 'bindings'...

   About wxWidgets, you are thinking we want to do a binding for that...
   But you misread the draft ! WxWidgets was only a proposal from Harry
   (which I refused for my part)... The better solution was to write an
   engine that transforms XML in widgets so it won't be a binding... It
   will only be only a library that takes XML as input and creates widgets
   with the library it is designed for... So it won't be a huge task...
 
  Sounds nice, but the question is: is it really that simple? I'm afraid
  not... How to bind the GUI events (e.g. the user pressing a button) to
  code? How to handle all kind of widget options, which can be quite
  different on various toolkits? How to make it not only look native, but
  also feel native?

 that, I don't know.. that's where a proof of concept would come in handy...
 in theory, what I had in mind is that the XML for the GUI would contain a
 'name' for each thing, and once you click on a button for someting, its
 name is sent to the GUI layer which knows what's its purpose.. if nothing
 needs to access protocol or change data, then it will process everything in
 the GUI module, if it needs to access protocol, it will send the
 appropriate/corresponding event...

   Maybe for GTK GUI use a aMSN2XML - Glade converter and pass it to a
   binding for GTK+ QT has already a XML system so maybe it will be a
   converter too... The remaining thing is aMSN2XML - Tk and aMSN2XML -
   Win32 and IMO if the design for XML is well done won't be too hard...
 
  Convert to Glade? You ever looked at GladeXML??? You could as well
  generate the C code from our XML and compile it... I don't believe it is
  as simple as you're saying. That is why I proposed wxWidgets as a
  possible solution, because it will provide a single toolkit, which is
  implemented in native widgets on various platforms, so there will be no
  need for us to care about which platform we're on, and thus make coding
  the GUI layer much easier, while still using native widgets.

 ok, that's why wxWidget is wanted... I see, well, I don't know, Vivia gave
 us some good points, I never used wx or tried it or used a program that
 uses it, so I don't know anything about it.. and what vivia said might be
 'outdated' ... a converter from our XML to another XML format is out of the
 question, it removes our modularity, simplicity etc...

  And here we get exactly to where I was in my other mail when I
  accidentally pressed the send button. We need to get that GUI thing set.
  It has been discussed a thousand of times now, so it's time to get it in
  some direction. To put it in a few questions:
 
  - What is our goal? XML2GUI, or nativeness on various platforms? (I.e.:
  If we have another way to serve all platforms with native widgets, would
  we go without XML?)
  - What do we want to code, and what don't we want to code?
  - How will we support plugins that want to add menu items and/ or buttons
  to the aMSN GUI? (That appears to be the most overlooked thing)
  - Do we want to implement de GUI module in Tcl or C/C++?
 
  Harry

 ok, this I started thinking about it earlier in your mail, but you go
 exactly to the point I wanted to say What is our goal ? nativeness on
 various platforms ? not even that! the goal was to stop people saying why
 not QT ? and why not GTK? .. and I think that maybe, if we choose one
 toolkit, which looks better than Tk, then people won't complain AT ALL...
 so I don't know.. the purpose was to please the users and stop receiving
 complaints...
 now it gives us two choices :
 1 - use one toolkit and only one...
 2 - wxwidgets which looks native to everyone
 3 - many toolkits as many modules so everyone gets what he wants...

 more precisely, what

Re: [Amsn-devel] aMSN2 - Second design draft

   And here we get exactly to where I was in my other mail when I
   accidentally pressed the send button. We need to get that GUI thing
   set. It has been discussed a thousand of times now, so it's time to get
   it in some direction. To put it in a few questions:
  
   - What is our goal? XML2GUI, or nativeness on various platforms? (I.e.:
   If we have another way to serve all platforms with native widgets,
   would we go without XML?)
   - What do we want to code, and what don't we want to code?
   - How will we support plugins that want to add menu items and/ or
   buttons to the aMSN GUI? (That appears to be the most overlooked thing)
   - Do we want to implement de GUI module in Tcl or C/C++?
  
   Harry
 
  ok, this I started thinking about it earlier in your mail, but you go
  exactly to the point I wanted to say What is our goal ? nativeness on
  various platforms ? not even that! the goal was to stop people saying
  why not QT ? and why not GTK? .. and I think that maybe, if we choose
  one toolkit, which looks better than Tk, then people won't complain AT
  ALL... so I don't know.. the purpose was to please the users and stop
  receiving complaints...
  now it gives us two choices :
  1 - use one toolkit and only one...
  2 - wxwidgets which looks native to everyone
  3 - many toolkits as many modules so everyone gets what he wants...
 
  more precisely, what I wanted to say is that our goal is indeed
  nativeness, NOT XML2GUI.. the whole XML2GUI was meant to be a solution to
  the nativeness, but the more I think about it, the more I see that it
  won't be such a full solution... maybe it can, but it will become a huge
  messy thing...
  I think that we should maybe develop a module that takes care of the GUI,
  using one toolkit, full, pure C code and that will only exchange 'ideas'
  with the Tcl core through events...
  If we want another toolkit, then it has to be rewritten as a new
  module... we 'could' start with a Tk-tile GUI module for those who want
  to keep Tk code... (Tk-tile has many nice themes, native in windows and
  native for qt with tile-qt theme, but no 'real' GTK+ support yet).. and
  I'm talking about directly using Tile, without any wrapping chameleon
  plugin or anything... the thing is that we can develop a module and any
  experienced user could work on another toolkit if they feel like it, the
  important thing is that it needs to be 100% modular, NOT mixed with
  anything else, not depending on anything, only EVENTS, no direct function
  calls, or else it will be a mess to create another GUI module...
  Now the cons of this, the big problem is that a 'new' GUI module will be
  specific, it won't look the same as another GUI module.. yes it's nice to
  be able to have the 'ok' button on the right on the win32 GUI module and
  not the left like the QT GUI module (just an example) so it looks and
  feels native... but what if a user says hey, I can't create a custom
  away state, the option doesn't exist answer ohh, you have to use THIS
  other GUI module because it is more complete...
  also, adding a new option/feature will require updating all the GUI
  module...

 Euh Why don't you like XML2GUI ? We could create some templates
 supported by GUI modules (ie one template with an OK and a Cancel button,
 one with only a OK button) and add our widgets in a frame in the center of
 the window... This way, if you want to create a new window, no need to
 upgrade GUI modules...
It is not about liking XML2GUI or not, it is about: what is the important 
thing. I raised the question because I felt that over time XML2GUI has become 
the goal, instead of a way to realize a goal. And that is not to get rid of 
the XML2GUI idea. We may still decide to do it, but it should get back to the 
proper place in the overall picture.

But anway, I think you are wrong in saying 'This way, if you want to create a 
new window, no need to upgrade GUI modules.' They will need to be updated to 
include a command to show the new window, as well as to handle events from 
the window when it is shown.

 Hum, I just thought about something : each window has a name and a class
 and if a GUI module wants to modify some widgets properties it could detect
 this name and/or this class and act in consequence like inverting two
 buttons etc...
 By the way I agree totally to the fact that we need to throw events to not
 call directly the core...
Wait a minute...

Should the core handle GUI events? - No!
Should the GUI layer handle events from the core? - Yes!

So:
The core fires an event - the GUI uses the data passed with the event to 
update the visible data.
The user does something that requires action from the core - in response to 
the GUI event triggered by the user's action, the GUI module calls a method 
in the core (which is a call to another context, that will need one extra 
command in the runtime...)

Why? Because:
- Events are fired if something has happened
- Method calls tell that

Re: [Amsn-devel] aMSN2 - Second design draft

Le Saturday 19 August 2006 23:24, Harry Vennik a écrit :
And here we get exactly to where I was in my other mail when I
accidentally pressed the send button. We need to get that GUI thing
set. It has been discussed a thousand of times now, so it's time to
get it in some direction. To put it in a few questions:
   
- What is our goal? XML2GUI, or nativeness on various platforms?
(I.e.: If we have another way to serve all platforms with native
widgets, would we go without XML?)
- What do we want to code, and what don't we want to code?
- How will we support plugins that want to add menu items and/ or
buttons to the aMSN GUI? (That appears to be the most overlooked
thing) - Do we want to implement de GUI module in Tcl or C/C++?
   
Harry
  
   ok, this I started thinking about it earlier in your mail, but you go
   exactly to the point I wanted to say What is our goal ? nativeness
   on various platforms ? not even that! the goal was to stop people
   saying why not QT ? and why not GTK? .. and I think that maybe, if
   we choose one toolkit, which looks better than Tk, then people won't
   complain AT ALL... so I don't know.. the purpose was to please the
   users and stop receiving complaints...
   now it gives us two choices :
   1 - use one toolkit and only one...
   2 - wxwidgets which looks native to everyone
   3 - many toolkits as many modules so everyone gets what he wants...
  
   more precisely, what I wanted to say is that our goal is indeed
   nativeness, NOT XML2GUI.. the whole XML2GUI was meant to be a solution
   to the nativeness, but the more I think about it, the more I see that
   it won't be such a full solution... maybe it can, but it will become a
   huge messy thing...
   I think that we should maybe develop a module that takes care of the
   GUI, using one toolkit, full, pure C code and that will only exchange
   'ideas' with the Tcl core through events...
   If we want another toolkit, then it has to be rewritten as a new
   module... we 'could' start with a Tk-tile GUI module for those who want
   to keep Tk code... (Tk-tile has many nice themes, native in windows and
   native for qt with tile-qt theme, but no 'real' GTK+ support yet).. and
   I'm talking about directly using Tile, without any wrapping chameleon
   plugin or anything... the thing is that we can develop a module and any
   experienced user could work on another toolkit if they feel like it,
   the important thing is that it needs to be 100% modular, NOT mixed with
   anything else, not depending on anything, only EVENTS, no direct
   function calls, or else it will be a mess to create another GUI
   module... Now the cons of this, the big problem is that a 'new' GUI
   module will be specific, it won't look the same as another GUI module..
   yes it's nice to be able to have the 'ok' button on the right on the
   win32 GUI module and not the left like the QT GUI module (just an
   example) so it looks and feels native... but what if a user says hey,
   I can't create a custom away state, the option doesn't exist answer
   ohh, you have to use THIS other GUI module because it is more
   complete...
   also, adding a new option/feature will require updating all the GUI
   module...
 
  Euh Why don't you like XML2GUI ? We could create some templates
  supported by GUI modules (ie one template with an OK and a Cancel button,
  one with only a OK button) and add our widgets in a frame in the center
  of the window... This way, if you want to create a new window, no need to
  upgrade GUI modules...

 It is not about liking XML2GUI or not, it is about: what is the important
 thing. I raised the question because I felt that over time XML2GUI has
 become the goal, instead of a way to realize a goal. And that is not to get
 rid of the XML2GUI idea. We may still decide to do it, but it should get
 back to the proper place in the overall picture.

 But anway, I think you are wrong in saying 'This way, if you want to create
 a new window, no need to upgrade GUI modules.' They will need to be updated
 to include a command to show the new window, as well as to handle events
 from the window when it is shown.
No ! You don't see what I mean... The GUI module will export a function 
CreateWindow(string XMLdata)
and when an event will occur it will do a Tcl_exec(fireevent, theevent)
So when we will want to create a new window we will simply create a new XML 
data with all widgets we want described in it...
Phil


  Hum, I just thought about something : each window has a name and a class
  and if a GUI module wants to modify some widgets properties it could
  detect this name and/or this class and act in consequence like inverting
  two buttons etc...
  By the way I agree totally to the fact that we need to throw events to
  not call directly the core...

 Wait a minute...

 Should the core handle GUI events? - No!
 Should the GUI layer handle events from the core? - Yes!

 So:

Re: [Amsn-devel] aMSN2 - Second design draft

2006-08-19 Thread Ole André Vadla Ravnås

On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote:
This looks like a flame war between python and tcl... and I don't want to start the debate again.You looked offended by my mail, I have no idea why, but in that case, sorry.I'll stop the discussion there as none of us can be convinced of who is right, and noone really knows who is right...
LOL, no hard feelings, trust me! :-D It was just that I wrote my replies in a hurry and thus they were a little slim on smilies -- sorry about that. :-) But it's true, it's rather pointless discussing taste. :-) Anyway, my initial point was just that I support Philippe's suggestions, and high-level language preferences aside I think it's a great choice because everything's already been made, and I'm against re-inventing the wheel, sparetime projects are about doing fun stuff after all. :-)
Regards,Ole AndréKKRTOn Sat, Aug 19, 2006 at 04:38:10PM +0200, Ole Andr? Vadla Ravn?s wrote:
On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote: On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:On Sat, 19 Aug 2006 00:21:15 +0200
Harry Vennik [EMAIL PROTECTED] wrote: Hi all, Finally I found some time to document some of my ideas in more
detail. The result is this new draft. Quite a lot changed since the previous one, and it will change again in the next drafts (at least on those places where
it just contains some vague suggestions). But I think things already are a lot better and more clear now.
Any feedback is appreciated! HarryI've read your draft. It's good and I think can be followed
successfully, but there are a few issues.First of all, you don't need to talk to Farsight directly. Telepathy has a stream-engine component that takes care of Farsight. You only
need to request StreamedMedia channels and you are good to go. So no bindings required there.Before going to the next point I want to say that I think any proposals
to write our own cross-platform toolkit are absurd. That is a HUGE project by itself and involves a ridiculous amount of time to undertake. I am sorry to say that no one in this project has the skill,
time or experience to do it.The last serious issue is with the choice of using TCL. TK is getting dumped, so might as well dump TCL. Why? Your proposal involves
writing a lot of bindings! Bindings for D-Bus and bindings for wxWindows. These will take a lot of time and energy to complete. Imagine all the time saved working with something that already has
those bindings. If you guys want to keep the high level language thing going for aMSN, then we need to think of Python. It has good D-Bus bindings as well as wxWindows bindings. It is better and more popular
than TCL. It seems like the logical and correct solution to take. People who don't know it can learn it, new developers who already know it will be interested/join, and those who are unable to learn it can
still work on aMSN1. Added avantage is easy porting to another toolkit. If someone decides he wants a GTK+ aMSN2, he can fork the Python core and write his own UI.
I agree wholeheartedly with all the points raised by Philippe. I would just like to add that I've got experience with the wxWidgets python bindings,
and they're great. I can say the same about the dbus and gstreamer bindings as well. And please believe me, you do not want to write dbus nor wxWidgets (or
any other UI toolkit) bindings from scratch just to get started. It's rather obvious why wrapping a whole UI toolkit is a lot of work, but probably not as obvious for the dbus bindings. Telepathy makes extensive use of
recursive types and really push the existing bindings to their limits, and getting all of this right while at the same time writing everything from scratch is
more work than I'm sure anyone on this project is willing and able to devote to it (after all it's not where the fun is). who needs bindings to wxWidgets ? who needs bindings to Telepathy or
gstreamer or whatever.. all we need is bindings for DBUS. Well, just as an example it's very handy to have GStreamer bindings in case you want to construct a custom pipeline. Say you want an incoming webcam
stream to be used as an outgoing stream as well, while at the same time logging it to disk. Or in another pipeline you might want to insert an effects element so that you get PhotoBooth-style effects on one of your
outgoing video streams, and for example audio effects applied to one of your voice conversations. With GStreamer the possibilities are endless. That said, I really hope this doesn't turn into another language X vs
language Y thread. :-) There's pros and cons to every possible choice, but all things considered, I think python is a great choice for the following practical reasons (I won't go into subtle language details):
that already happened and you can read the thread if you want... but as you

Re: [Amsn-devel] aMSN2 - Second design draft

Op zaterdag 19 augustus 2006 23:34, schreef Philippe Valembois - Phil:
  But anway, I think you are wrong in saying 'This way, if you want to
  create a new window, no need to upgrade GUI modules.' They will need to
  be updated to include a command to show the new window, as well as to
  handle events from the window when it is shown.

 No ! You don't see what I mean... The GUI module will export a function
 CreateWindow(string XMLdata)
 and when an event will occur it will do a Tcl_exec(fireevent, theevent)
 So when we will want to create a new window we will simply create a new XML
 data with all widgets we want described in it...
 Phil

Yes of course... What I actually meant with the 'command to show the new 
window' was the call to the CreateWindow. But anyway, I think I get it now. 
What you want to do is implement XML2GUI itself (and the event pass-through) 
in C, and all the rest in TCL and XML files.

So from TCL you do something like:

load_resource rsrc my_window.xml
window create w $rsrc   ;# Calls CreateWindow at C level
amsn::handler ${w}_btnOK_click ButtonOKClicked

proc ButtonOKClicked { button } {
   # do some stuff
}


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

You get the principle but I would like to do something better than using 
callbacks for events... Or at least use an event layer between GUI and proc 
that do the things...
I think XML2GUI should be a relatively simple thing to do isn't it ?
The hard work is to begin the spec for the XML and after that we could create 
a Tk engine to have a base of work...
Phil

Le Sunday 20 August 2006 00:11, Harry Vennik a écrit :
 Op zaterdag 19 augustus 2006 23:34, schreef Philippe Valembois - Phil:
   But anway, I think you are wrong in saying 'This way, if you want to
   create a new window, no need to upgrade GUI modules.' They will need to
   be updated to include a command to show the new window, as well as to
   handle events from the window when it is shown.
 
  No ! You don't see what I mean... The GUI module will export a function
  CreateWindow(string XMLdata)
  and when an event will occur it will do a Tcl_exec(fireevent, theevent)
  So when we will want to create a new window we will simply create a new
  XML data with all widgets we want described in it...
  Phil

 Yes of course... What I actually meant with the 'command to show the new
 window' was the call to the CreateWindow. But anyway, I think I get it now.
 What you want to do is implement XML2GUI itself (and the event
 pass-through) in C, and all the rest in TCL and XML files.

 So from TCL you do something like:

 load_resource rsrc my_window.xml
 window create w $rsrc ;# Calls CreateWindow at C level
 amsn::handler ${w}_btnOK_click ButtonOKClicked

 proc ButtonOKClicked { button } {
# do some stuff
 }


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel

Re: [Amsn-devel] aMSN2 - Second design draft

On Sat, 19 Aug 2006 15:51:44 -0400
[EMAIL PROTECTED] (Youness Alaoui) wrote:

 This looks like a flame war between python and tcl... and I don't want to 
 start the debate again.
 You looked offended by my mail, I have no idea why, but in that case, sorry.
 I'll stop the discussion there as none of us can be convinced of who is 
 right, and noone really knows who is right...
This is hopeless... I don't know what to say anymore. The whole
project is going to be in C or Glib. Only the core will be in TCL,
(and it won't be that large), the whole project is going to
take 2 times as long for such a decision... And people will be stuck
doing boring bindings instead of coding and learning a new (and much
better) language.

I will not take this discussion any further.

Good luck with aMSN2.

Regards,
Philippe

 
 KKRT
 
 On Sat, Aug 19, 2006 at 04:38:10PM +0200, Ole Andr? Vadla Ravn?s wrote:
  On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote:
  
  On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
   On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:
   
   On Sat, 19 Aug 2006 00:21:15 +0200
   Harry Vennik [EMAIL PROTECTED] wrote:
   
Hi all,
   
Finally I found some time to document some of my ideas in more
  detail.
   The
result is this new draft. Quite a lot changed since the previous one,
   and it
will change again in the next drafts (at least on those places where
  it
   just
contains some vague suggestions). But I think things already are a
  lot
   better
and more clear now.
   
Any feedback is appreciated!
   
Harry
   
   I've read your draft. It's good and I think can be followed
   successfully, but there are a few issues.
   
   First of all, you don't need to talk to Farsight directly. Telepathy
   has a stream-engine component that takes care of Farsight. You only
   need to request StreamedMedia channels and you are good to go. So no
   bindings required there.
   
   Before going to the next point I want to say that I think any proposals
   to write our own cross-platform toolkit are absurd. That is a HUGE
   project by itself and involves a ridiculous amount of time to
   undertake. I am sorry to say that no one in this project has the skill,
   time or experience to do it.
   
   The last serious issue is with the choice of using TCL. TK is
   getting dumped, so might as well dump TCL. Why? Your proposal involves
   writing a lot of bindings! Bindings for D-Bus and bindings for
   wxWindows. These will take a lot of time and energy to complete.
   Imagine all the time saved working with something that already has
   those bindings. If you guys want to keep the high level language thing
   going for aMSN, then we need to think of Python. It has good D-Bus
   bindings as well as wxWindows bindings. It is better and more popular
   than TCL. It seems like the logical and correct solution to take.
   People who don't know it can learn it, new developers who already know
   it will be interested/join, and those who are unable to learn it can
   still work on aMSN1. Added avantage is easy porting to another toolkit.
   If someone decides he wants a GTK+ aMSN2, he can fork the Python core
   and write his own UI.
  
  
   I agree wholeheartedly with all the points raised by Philippe. I would
  just
   like to add that I've got experience with the wxWidgets python bindings,
  and
   they're great. I can say the same about the dbus and gstreamer bindings
  as
   well. And please believe me, you do not want to write dbus nor wxWidgets
  (or
   any other UI toolkit) bindings from scratch just to get started. It's
  rather
   obvious why wrapping a whole UI toolkit is a lot of work, but probably
  not
   as obvious for the dbus bindings. Telepathy makes extensive use of
  recursive
   types and really push the existing bindings to their limits, and getting
  all
   of this right while at the same time writing everything from scratch is
  more
   work than I'm sure anyone on this project is willing and able to devote
  to
   it (after all it's not where the fun is).
  
  
  who needs bindings to wxWidgets ? who needs bindings to Telepathy or
  gstreamer or whatever.. all we need is bindings for DBUS.
  
  
  Well, just as an example it's very handy to have GStreamer bindings in case
  you want to construct a custom pipeline. Say you want an incoming webcam
  stream to be used as an outgoing stream as well, while at the same time
  logging it to disk. Or in another pipeline you might want to insert an
  effects element so that you get PhotoBooth-style effects on one of your
  outgoing video streams, and for example audio effects applied to one of your
  voice conversations. With GStreamer the possibilities are endless.
  
  That said, I really hope this doesn't turn into another language X vs
   language Y thread. :-) There's pros and cons to every possible choice,
  but
   all things considered, I think python is a great choice for the
  following

Re: [Amsn-devel] aMSN2 - Second design draft

On Sat, 19 Aug 2006 15:51:44 -0400
[EMAIL PROTECTED] (Youness Alaoui) wrote:

 This looks like a flame war between python and tcl... and I don't want to 
 start the debate again.
 You looked offended by my mail, I have no idea why, but in that case, sorry.
 I'll stop the discussion there as none of us can be convinced of who is 
 right, and noone really knows who is right...
This is hopeless... I don't know what to say anymore. The whole
project is going to be in C or Glib. Only the core will be in TCL,
(and it won't be that large), the whole project is going to
take 2 times as long for such a decision... And people will be stuck
doing boring bindings instead of coding and learning a new (and much
better) language.

I will not take this discussion any further.

Good luck with aMSN2.

Regards,
Philippe

 
 KKRT
 
 On Sat, Aug 19, 2006 at 04:38:10PM +0200, Ole Andr? Vadla Ravn?s wrote:
  On 8/19/06, Youness Alaoui [EMAIL PROTECTED] wrote:
  
  On Sat, Aug 19, 2006 at 03:48:06AM +0200, Ole Andr? Vadla Ravn?s wrote:
   On 8/19/06, Philippe Khalaf [EMAIL PROTECTED] wrote:
   
   On Sat, 19 Aug 2006 00:21:15 +0200
   Harry Vennik [EMAIL PROTECTED] wrote:
   
Hi all,
   
Finally I found some time to document some of my ideas in more
  detail.
   The
result is this new draft. Quite a lot changed since the previous one,
   and it
will change again in the next drafts (at least on those places where
  it
   just
contains some vague suggestions). But I think things already are a
  lot
   better
and more clear now.
   
Any feedback is appreciated!
   
Harry
   
   I've read your draft. It's good and I think can be followed
   successfully, but there are a few issues.
   
   First of all, you don't need to talk to Farsight directly. Telepathy
   has a stream-engine component that takes care of Farsight. You only
   need to request StreamedMedia channels and you are good to go. So no
   bindings required there.
   
   Before going to the next point I want to say that I think any proposals
   to write our own cross-platform toolkit are absurd. That is a HUGE
   project by itself and involves a ridiculous amount of time to
   undertake. I am sorry to say that no one in this project has the skill,
   time or experience to do it.
   
   The last serious issue is with the choice of using TCL. TK is
   getting dumped, so might as well dump TCL. Why? Your proposal involves
   writing a lot of bindings! Bindings for D-Bus and bindings for
   wxWindows. These will take a lot of time and energy to complete.
   Imagine all the time saved working with something that already has
   those bindings. If you guys want to keep the high level language thing
   going for aMSN, then we need to think of Python. It has good D-Bus
   bindings as well as wxWindows bindings. It is better and more popular
   than TCL. It seems like the logical and correct solution to take.
   People who don't know it can learn it, new developers who already know
   it will be interested/join, and those who are unable to learn it can
   still work on aMSN1. Added avantage is easy porting to another toolkit.
   If someone decides he wants a GTK+ aMSN2, he can fork the Python core
   and write his own UI.
  
  
   I agree wholeheartedly with all the points raised by Philippe. I would
  just
   like to add that I've got experience with the wxWidgets python bindings,
  and
   they're great. I can say the same about the dbus and gstreamer bindings
  as
   well. And please believe me, you do not want to write dbus nor wxWidgets
  (or
   any other UI toolkit) bindings from scratch just to get started. It's
  rather
   obvious why wrapping a whole UI toolkit is a lot of work, but probably
  not
   as obvious for the dbus bindings. Telepathy makes extensive use of
  recursive
   types and really push the existing bindings to their limits, and getting
  all
   of this right while at the same time writing everything from scratch is
  more
   work than I'm sure anyone on this project is willing and able to devote
  to
   it (after all it's not where the fun is).
  
  
  who needs bindings to wxWidgets ? who needs bindings to Telepathy or
  gstreamer or whatever.. all we need is bindings for DBUS.
  
  
  Well, just as an example it's very handy to have GStreamer bindings in case
  you want to construct a custom pipeline. Say you want an incoming webcam
  stream to be used as an outgoing stream as well, while at the same time
  logging it to disk. Or in another pipeline you might want to insert an
  effects element so that you get PhotoBooth-style effects on one of your
  outgoing video streams, and for example audio effects applied to one of your
  voice conversations. With GStreamer the possibilities are endless.
  
  That said, I really hope this doesn't turn into another language X vs
   language Y thread. :-) There's pros and cons to every possible choice,
  but
   all things considered, I think python is a great choice for the
  following

Re: [Amsn-devel] aMSN2 - Second design draft