bme-develop Mailing List for Be-messeng-er (Page 7)
Status: Planning
Brought to you by:
sirmik
Menu
▾
▴
bme-develop — Mailing list for developmental issues
You can subscribe to this list here.
| 2004 |
Jan
(7) |
Feb
(15) |
Mar
(45) |
Apr
(46) |
May
(18) |
Jun
(6) |
Jul
(12) |
Aug
(45) |
Sep
(7) |
Oct
(9) |
Nov
(37) |
Dec
(24) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jixt <jan...@pa...> - 2004-05-24 15:47:31
|
>Yes sure! I didn't mean to sound too annoyed at your comments :) > >It might take you a while to learn where we're heading to >(http://si-msn.port5.com/bmeMockup2.png may give you an idea) > >Any thoughts on what you want to do first? > Looks very nice the mockups ;) (I've watched the bmeMockup.png also :p). = If you tell me who is doing what, then I know what I don't have to do. On= ce I know that, I can tell you what I want/may do. I thought I could chan= ge the logging in way(GUI) and preferences.... greets Jixt |
|
From: Simon T. <sim...@ga...> - 2004-05-24 15:34:05
|
> Ok thanx! I only have to say one thing before I start coding ;). > > I dont want to say how you all should do it, you all have a vision about BeMSN and I respect > that and I will follow that. I will tell how I think about some things but that does not mean > that they have to be done like the way I think about it. We all program here for fun ;) and > lets keep it like that ;) Yes sure! I didn't mean to sound too annoyed at your comments :) It might take you a while to learn where we're heading to (http://si-msn.port5.com/bmeMockup2.png may give you an idea) Any thoughts on what you want to do first? > P.S: I agree with the Be way of programming and that is good! We do not need the Windoze and > Linux crap ;). I disagree in the way that we have to mimic it a littlebit first. With that I > mean that we have to make sure that we have all the features that the windoze version has ;). > After that we can build extra nice features for BeOs users only :p Ah ok, I understand. We are kind of limited by the protocol for what features to support - but yes, we will support all the same features as msn in windows. I mean how we present those features to the user will be rethought. eg for user pics - the area of the top of the list will be used, as this represents how other contacts see you. If you drag a new jpg or whatever onto the user pic, a new window will pop up with the ability to adjust smoothing, resizing, croping options (maybe brightness and stuff too). So we will provide the same feature of user pics as in windows, but we will present it better to the user. That's the idea anyway :D Simon ________________________________ 15 Mbytes Free Web-based and POP3 Sign up now: http://www.gawab.com |
|
From: Jixt <jan...@pa...> - 2004-05-24 15:15:51
|
Ok thanx! I only have to say one thing before I start coding ;). I dont want to say how you all should do it, you all have a vision about = BeMSN and I respect that and I will follow that. I will tell how I think = about some things but that does not mean that they have to be done like t= he way I think about it. We all program here for fun ;) and lets keep it = like that ;) greets Jixt P.S: I agree with the Be way of programming and that is good! We do not n= eed the Windoze and Linux crap ;). I disagree in the way that we have to = mimic it a littlebit first. With that I mean that we have to make sure th= at we have all the features that the windoze version has ;). After that w= e can build extra nice features for BeOs users only :p >Hi Jixt, > >Very busy with exams atm, so I'll make this quick... more will >come later. > >[snip] > >> >I agree with you here...double work is something the beOS community i= s good >> >in ;) So you already did some work on an MSN client....is there some = code we >> >would be able to re-use in this project? Btw you must know we want to= make >> >this messenger the Be way, not mimic the windoze MSN, but trying to s= urpass >> >it...especially in user friendliness.... >> >> I agree and disagree a bit with that. Comments will come later ;) > >Sorry, you can't really disagree with that. It's fairly >fundamental to the whole way we have planned the project. Think >about what needs doing, think and discuss the absolute best way >of realising it, then implement it. I'm never going to clone any >software in my life. > >> >>I can say that I am good in c++( I love it!!) and I like solving dif= ficult >> >>problems ;). Maybe some of >you know I am the creator of the BeDiGiC= am, so >> >>that is the experience I have in developing in ?>BeOs. I can say tha= t I'm >> >>not new in developing applications under BeOs. >> >I know the app, doesn't work with my Fuji Finipix sad enough...good i= n c++ >> >is nice...I am only starting to get the hang of it... > >My c++ isn't great, but just about gets the job done. > >> I've seen some things that could change(login procedure...) in the GUI= . Chat screen need some bug-fixes.... > >I personally vote to have logging in on the main window - like >with Jabber for BeOS. > >> 1) When a Windoze MSN'er sends a file the BeMSN craches. >> 2) It is also possible to send empty messages. >> 3) When a chat screen opens, it is opened in 'small' in the left corne= r. You need to resize it and drag it to the middle of the screen. >> 4) ... > >The new GUI will pretty much rewrite the whole chat window code; >so don't worry too much about little bug fixes to the old GUI. > >> I think a test-procedure should be created(readable for beta-testers) = and there should be a >> good developing-plan. Milestones are needed. This accelerates developm= ent. A >> bug-reporting-system is also needed to have control over the bugs. And= it should be very handy >> that every developper has his own part of code to develop. > >For now we have sf's bug tracker - although a lot of the code >will be reworked before bme version 1. We have milestones - it's >called version 1 :) > >At the moment Daniel is working on the network side of things, >and me and Tim are working on the GUI. > >> I mean that every developer does development of some component (ex: ch= at screen) and testd the >> component of another developer during alpha testing. In the alfa testi= ng every feature that >> should be in a certain release should be implemented. After alfa testi= ng, a Beta should be >> released to the beta testers. This is a structured way of working and = will bring much progress >> to this project ;) > >I'm sure you don't mean to sound critical of the way we are >working, but that's kind of how I read it. What will bring >progress to the project is us having some free time to develop >(should come soon) - it's not a lack of structure that is >holding development back IMHO. > >Testing strategies are always good though - but we have to be >careful we don't test too soon - as I say above a lot of the >code in CVS will probably not be in bme version 1. > >> It is just my way of thinking, I don't now what you all think about it= ;) > >Generally I think it fits well with our attitude about creating >a really high quality, professional program. > >Welcome to the project! > > >Simon |
|
From: Simon T. <sim...@ga...> - 2004-05-24 14:29:09
|
Hi Jixt, Very busy with exams atm, so I'll make this quick... more will come later. [snip] > >I agree with you here...double work is something the beOS community is good > >in ;) So you already did some work on an MSN client....is there some code we > >would be able to re-use in this project? Btw you must know we want to make > >this messenger the Be way, not mimic the windoze MSN, but trying to surpass > >it...especially in user friendliness.... > > I agree and disagree a bit with that. Comments will come later ;) Sorry, you can't really disagree with that. It's fairly fundamental to the whole way we have planned the project. Think about what needs doing, think and discuss the absolute best way of realising it, then implement it. I'm never going to clone any software in my life. > >>I can say that I am good in c++( I love it!!) and I like solving difficult > >>problems ;). Maybe some of >you know I am the creator of the BeDiGiCam, so > >>that is the experience I have in developing in ?>BeOs. I can say that I'm > >>not new in developing applications under BeOs. > >I know the app, doesn't work with my Fuji Finipix sad enough...good in c++ > >is nice...I am only starting to get the hang of it... My c++ isn't great, but just about gets the job done. > I've seen some things that could change(login procedure...) in the GUI. Chat screen need some bug-fixes.... I personally vote to have logging in on the main window - like with Jabber for BeOS. > 1) When a Windoze MSN'er sends a file the BeMSN craches. > 2) It is also possible to send empty messages. > 3) When a chat screen opens, it is opened in 'small' in the left corner. You need to resize it and drag it to the middle of the screen. > 4) ... The new GUI will pretty much rewrite the whole chat window code; so don't worry too much about little bug fixes to the old GUI. > I think a test-procedure should be created(readable for beta-testers) and there should be a > good developing-plan. Milestones are needed. This accelerates development. A > bug-reporting-system is also needed to have control over the bugs. And it should be very handy > that every developper has his own part of code to develop. For now we have sf's bug tracker - although a lot of the code will be reworked before bme version 1. We have milestones - it's called version 1 :) At the moment Daniel is working on the network side of things, and me and Tim are working on the GUI. > I mean that every developer does development of some component (ex: chat screen) and testd the > component of another developer during alpha testing. In the alfa testing every feature that > should be in a certain release should be implemented. After alfa testing, a Beta should be > released to the beta testers. This is a structured way of working and will bring much progress > to this project ;) I'm sure you don't mean to sound critical of the way we are working, but that's kind of how I read it. What will bring progress to the project is us having some free time to develop (should come soon) - it's not a lack of structure that is holding development back IMHO. Testing strategies are always good though - but we have to be careful we don't test too soon - as I say above a lot of the code in CVS will probably not be in bme version 1. > It is just my way of thinking, I don't now what you all think about it ;) Generally I think it fits well with our attitude about creating a really high quality, professional program. Welcome to the project! Simon ________________________________ 15 Mbytes Free Web-based and POP3 Sign up now: http://www.gawab.com |
|
From: Jixt <jan...@pa...> - 2004-05-24 14:15:04
|
>Aloha Jixt, Hoi hoi again ;) > >>This is my first mail (test test...). >To answer this with a quote of one of Belgium's most famous comedians >"ikels...ikels" :D Hmm, Belgium comedian... which one? :-O > >>I've followed the developing of the BeMSN project since the beginning. = I >>thought I already send a >mail to one of you to ask if the project was = >>still alive and that I wanted to help with the >development. The reason= why >>I want to help is because I like MSN and many of us here in >Belgium us= e >>it. Some years ago I've started to create a BeMSN myself, but I could n= ot >>finish it >because of a lack of time. Now I see you are busy with BeMSN= and >>because I do not >like 'reinventing the weel' and 'double work', I want= to >>help you. >I agree with you here...double work is something the beOS community is g= ood >in ;) So you already did some work on an MSN client....is there some cod= e we >would be able to re-use in this project? Btw you must know we want to ma= ke >this messenger the Be way, not mimic the windoze MSN, but trying to surp= ass >it...especially in user friendliness.... I agree and disagree a bit with that. Comments will come later ;) > >>I can say that I am good in c++( I love it!!) and I like solving diffic= ult >>problems ;). Maybe some of >you know I am the creator of the BeDiGiCam,= so >>that is the experience I have in developing in ?>BeOs. I can say that I= 'm >>not new in developing applications under BeOs. >I know the app, doesn't work with my Fuji Finipix sad enough...good in c= ++ >is nice...I am only starting to get the hang of it... > >>What I want to do for BeMSN deppends on what you give me ;). I want to = >>change the >preferences screen, but if there are some other things that= are >>more urgent, then I'd like to >develop them for you. So tell me what I = have >>to do and I will create it with pleasure! I don't know >how we are goin= g to >>do it with the CVS-access and all stuff around, but we can discuss that= >> >later ;) >Preferences view and the way preferences(like login) are handled have to= be >changed indeed, so it's an area we need some work in....but we also have= to >discuss how we want to handle preferences(a Handler for example?)...The = >login preferences are saved with the entire window that represents them,= so >they need a lot of work.... one problem though is that we don't have too= >much features for preferences...so does anyone know another job for >Jixt...the UI also needs a lot of work...and I think maybe Daniel would = like >some assistance on the protocol side, am I right about that...cvs access= >won't be a problem, we can arrange that soon enough... I've seen some things that could change(login procedure...) in the GUI. C= hat screen need some bug-fixes.... 1) When a Windoze MSN'er sends a file the BeMSN craches. 2) It is also possible to send empty messages. 3) When a chat screen opens, it is opened in 'small' in the left corner. = You need to resize it and drag it to the middle of the screen. 4) ... I think a test-procedure should be created(readable for beta-testers) and= there should be a good developing-plan. Milestones are needed. This acce= lerates development. A bug-reporting-system is also needed to have contro= l over the bugs. And it should be very handy that every developper has hi= s own part of code to develop. I mean that every developer does developme= nt of some component (ex: chat screen) and testd the component of another= developer during alpha testing. In the alfa testing every feature that s= hould be in a certain release should be implemented. After alfa testing, = a Beta should be released to the beta testers. This is a structured way o= f working and will bring much progress to this project ;) It is just my way of thinking, I don't now what you all think about it ;)= > >regards, > >Tim(aka Sir Mik) > greets Jixt |
|
From: Sir M. <obe...@ho...> - 2004-05-24 11:56:47
|
Aloha Jixt, >This is my first mail (test test...). To answer this with a quote of one of Belgium's most famous comedians "ikels...ikels" :D >I've followed the developing of the BeMSN project since the beginning. I >thought I already send a >mail to one of you to ask if the project was >still alive and that I wanted to help with the >development. The reason why >I want to help is because I like MSN and many of us here in >Belgium use >it. Some years ago I've started to create a BeMSN myself, but I could not >finish it >because of a lack of time. Now I see you are busy with BeMSN and >because I do not >like 'reinventing the weel' and 'double work', I want to >help you. I agree with you here...double work is something the beOS community is good in ;) So you already did some work on an MSN client....is there some code we would be able to re-use in this project? Btw you must know we want to make this messenger the Be way, not mimic the windoze MSN, but trying to surpass it...especially in user friendliness.... >I can say that I am good in c++( I love it!!) and I like solving difficult >problems ;). Maybe some of >you know I am the creator of the BeDiGiCam, so >that is the experience I have in developing in ?>BeOs. I can say that I'm >not new in developing applications under BeOs. I know the app, doesn't work with my Fuji Finipix sad enough...good in c++ is nice...I am only starting to get the hang of it... >What I want to do for BeMSN deppends on what you give me ;). I want to >change the >preferences screen, but if there are some other things that are >more urgent, then I'd like to >develop them for you. So tell me what I have >to do and I will create it with pleasure! I don't know >how we are going to >do it with the CVS-access and all stuff around, but we can discuss that > >later ;) Preferences view and the way preferences(like login) are handled have to be changed indeed, so it's an area we need some work in....but we also have to discuss how we want to handle preferences(a Handler for example?)...The login preferences are saved with the entire window that represents them, so they need a lot of work.... one problem though is that we don't have too much features for preferences...so does anyone know another job for Jixt...the UI also needs a lot of work...and I think maybe Daniel would like some assistance on the protocol side, am I right about that...cvs access won't be a problem, we can arrange that soon enough... regards, Tim(aka Sir Mik) _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Jixt <jan...@pa...> - 2004-05-24 08:43:49
|
Hi,
This is my first mail (test test...). I've followed the developing of the=
BeMSN project since the beginning. I thought I already send a mail to on=
e of you to ask if the project was still alive and that I wanted to help =
with the development. The reason why I want to help is because I like MSN=
and many of us here in Belgium use it. Some years ago I've started to cr=
eate a BeMSN myself, but I could not finish it because of a lack of time.=
Now I see you are busy with BeMSN and because I do not like 'reinventing=
the weel' and 'double work', I want to help you.
I can say that I am good in c++( I love it!!) and I like solving difficul=
t problems ;). Maybe some of you know I am the creator of the BeDiGiCam, =
so that is the experience I have in developing in BeOs. I can say that I'=
m not new in developing applications under BeOs.
What I want to do for BeMSN deppends on what you give me ;). I want to ch=
ange the preferences screen, but if there are some other things that are =
more urgent, then I'd like to develop them for you. So tell me what I hav=
e to do and I will create it with pleasure! I don't know how we are going=
to do it with the CVS-access and all stuff around, but we can discuss th=
at later ;)
greets
Jixt
> Just talked to Jixt at BeShare who also downloaded our sources from cvs=
.
> Seems my post at bebits to let people now we"re still busy developing b=
me
> (and more importantly they can download the sources themselves from cvs=
) has
> had some impact. Jixt offered assistance on programming Bme, I think we=
> certainly could use it. I suggested he"d become a member of this mailin=
g
> list! so we"ll probably receive a post of him sooner or later...Anyone =
ideas
> on what he can do if/when he has joined? He offered to make a new
> preferences view....and I think we need one :D
>
> regards,
>
> Tim
|
|
From: Sir M. <obe...@ho...> - 2004-05-23 18:34:40
|
Just talked to Jixt at BeShare who also downloaded our sources from cvs. Seems my post at bebits to let people now we're still busy developing bme (and more importantly they can download the sources themselves from cvs) has had some impact. Jixt offered assistance on programming Bme, I think we certainly could use it. I suggested he'd become a member of this mailing list! so we'll probably receive a post of him sooner or later...Anyone ideas on what he can do if/when he has joined? He offered to make a new preferences view....and I think we need one :D regards, Tim _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Sir M. <obe...@ho...> - 2004-05-23 18:04:13
|
Hi, >MYOB sent me. > Talk to him about it in BeShare... >I replied to most of it. I agree with his comments about project >files though, they could do with reorganising. > I also agree with most of his comments >Theres some serious problems with Bme's BeIDE project files. One >of >them is speed - searching all of /boot/home/config/lib causes >biiiig >problems if you have all of VLC's build tools and Python >installed. Not >that thats a problem, just an "issue". This can be solved by >making >people symlink cryptib into the /boot/develop/lib/x86 folder and >removing the /boot/home/config/lib access path > I think we should do this, if it speeds up compiling >Also, most of the system libraries are included wrong. They >should not >be included from /boot/beos/system/lib, they should be included >from / >boot/develop/lib, and with the correct architechture first (x86/ >or ppc >/). > This should be fixed too. Also I think we can delete some files from the project file, for example libmail.so! why is it necessary? Daniel, I think it's best you do that, since you know what files are truly necessary.... >Also, the path to the cryptlib header isn't in the file, and it >probably should be included as <cryptlib/cryptlib.h> and not >just as >cryptlib.h. > I had a problem with that too...bme didn't compile until I copied the cryptlib header to the /boot/develop/headers/be folder....where should we place this header to prevent using entire paths in the #includes? >Also, it might not be a good idea to have the Net*.cpp files in >the >project file, as they're not in CVS... > That's my fault, I included them to test against it...but we all have Simon's classes and the project files were meant for us in the first place....although he has a point....we should upload Simon's debugging classes into cvs...could you do that Simon? >Another suggestion might be to have a BONE project file - you're >not >meant to like to libnetapi.so on BONE, it should be libbnetapi. That's what I'm doing...and I have to change the project file back to the old files before uploading into cvs...a r5 and a bone version of the project is a better solution...How did you do it anyway, Daniel? compiling against libnetapi on my r5 with Bone7a doesn't work, moreover I had to change some of the Be net classes headers, to get it to work. >You also don't need to add the headers to a project file. It >might >speed up coding a little, but you can always get to the headers >by >right-clicking the little arrow to the side of the file that >includes >the header. Not having the header minorly speeds up the opening >parse >time. > This is a personal opinion of his, and therefore I do not agree...I like to have the headers in the project file, it's nice and easy to open them in that way, and you have all sources bundled in one project file....the little arrow works, I know, but it isn't clear exactly what headers belong to the project.... >For purely asthetic regions, I'd move Bme.rsrc up the libraries. >Its >another linktime item, so its logical there > Ok! >All this is based off using "BeMSN.proj". This seemed like the >right >choice of project file, having three is a liitle confusing :-) > Ok BeMSN.proj was there for use with the old gui....Simon's idea to make a new folder for the new GUI and making a new project file to have at all times a working version with the old GUI was a good one....if it wasn't for the changes to the server code it may have worked....now I think it won't work anymore...so I suggest deleting all proj files but bme_x86 from cvs along with the old UI files....We could then make another proj file...bme_x86 would be the r5 one and say bme_x86_BONE the bone one...eventually we may have a bme_ppc proj file.... >None of this is meant to be critical mind, you're doing a great >job >with Bme. I'm still looking into a ppc port BTW :-) Although I >do have >more pressing issues (getting sound to work on my laptop, etc) >to deal >with first. Nice to hear that, I like having a ppc build around....would he have to change a lot to make our sources compile on ppc? >I'm also interested in how the Hotmail integration is going to >work - >I've written this before even compiling Bme or looking at the >code. >Considering NetPositive doesn't do JScript, and Mozilla/Firefox >still >has the "first-window-doesn't-show-requested-page" when running >as >native browser, I'm very interested in how an app can use >Hotmail >easily > As far as I know, hotmail integration in m$n is handled by making an html file with a lot of params in it an opening that in a browser... I don't know too much about it, but I think it'll open in both net+ and Mozilla FireFox...and eventually FireFox won't have that bug anymore so I isn't an issue I think....I will start at it soon btw...first the control to open mails and then the making of the html-file... >As goes webcam and voice chat support, this is an area I'm >interested >in, as I have a large number of friends overseas who seem to >assume MSN >is the defacto standard for video and audio conferencing. To >confirm >what one of the dev team said in the TBJ interview - yes, >supported >webcams (CPIA parellel ones) do work as media nodes in exactly >the same >was a capture card with a TV camera on it does. Unfortunately my >CPIA >camera bit the dust a long time ago and my USB one is, clearly, >unsupported. Also R5's USB kit just *does not* have the kit >required >for USB webcams. So when OBOS R1 is out, contact me and bug me >over >webcam support :-) > Hehe, would be nice to have webcam support....but let's concentrate on more important issues first...like getting a r1 of bme out...judging from the feedback and reactions on BeShare a lot of people would like to see that, and a lot of people are now experimenting with builds from cvs...So we have to clean up the cvs first I think, and communicate more with the community, to let them now we're still working on it. >PS: Just compiling now, the code doesn't like BONE 7A here. Or >it could >be my headers. But all the BNetEndpoint stuff doesn't compile, >MsnList.cpp has casting issues, and IconHandle.cpp has >prototyping >issues. Some of this could be down to my hacking around with the >project file though :-) Bone 7a had some issues, I explained MYOB he had to add a line to the NetAddress header and it should work...MsnList doesn't exist anymore in our new bme.... Oh btw, daniel I have made a UserPicView....and want to have a look at adding support for userpics...is that already possible....anyway I want to do at least the UI side of this...and I saw you had a beos.jpg at first for the user pic? How do you want to integrate this support, do you have any idea? we should at least have a talk about that before I can continue my work on the userview, regards, Tim _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Simon T. <sim...@ga...> - 2004-05-21 21:18:32
|
Guys, MYOB sent me. I replied to most of it. I agree with his comments about project files though, they could do with reorganising. I've told him to use the other project file, should fix his compile issues. -------Forwarded mail below--------------- Simon Theres some serious problems with Bme's BeIDE project files. One of them is speed - searching all of /boot/home/config/lib causes biiiig problems if you have all of VLC's build tools and Python installed. Not that thats a problem, just an "issue". This can be solved by making people symlink cryptib into the /boot/develop/lib/x86 folder and removing the /boot/home/config/lib access path Also, most of the system libraries are included wrong. They should not be included from /boot/beos/system/lib, they should be included from / boot/develop/lib, and with the correct architechture first (x86/ or ppc /). Also, the path to the cryptlib header isn't in the file, and it probably should be included as <cryptlib/cryptlib.h> and not just as cryptlib.h. Also, it might not be a good idea to have the Net*.cpp files in the project file, as they're not in CVS... Another suggestion might be to have a BONE project file - you're not meant to like to libnetapi.so on BONE, it should be libbnetapi. Although under OpenBeOS they'll probably just one file with the other symlinked... You also don't need to add the headers to a project file. It might speed up coding a little, but you can always get to the headers by right-clicking the little arrow to the side of the file that includes the header. Not having the header minorly speeds up the opening parse time. For purely asthetic regions, I'd move Bme.rsrc up the libraries. Its another linktime item, so its logical there All this is based off using "BeMSN.proj". This seemed like the right choice of project file, having three is a liitle confusing :-) None of this is meant to be critical mind, you're doing a great job with Bme. I'm still looking into a ppc port BTW :-) Although I do have more pressing issues (getting sound to work on my laptop, etc) to deal with first. Although my PPC box is my most unadulterated system (running a horrible hyrbid R5 BONE/Dano/OBOS R1 mash up here), so its the only box I have that makes R5 compatible builds :-) I'm also interested in how the Hotmail integration is going to work - I've written this before even compiling Bme or looking at the code. Considering NetPositive doesn't do JScript, and Mozilla/Firefox still has the "first-window-doesn't-show-requested-page" when running as native browser, I'm very interested in how an app can use Hotmail easily As goes webcam and voice chat support, this is an area I'm interested in, as I have a large number of friends overseas who seem to assume MSN is the defacto standard for video and audio conferencing. To confirm what one of the dev team said in the TBJ interview - yes, supported webcams (CPIA parellel ones) do work as media nodes in exactly the same was a capture card with a TV camera on it does. Unfortunately my CPIA camera bit the dust a long time ago and my USB one is, clearly, unsupported. Also R5's USB kit just *does not* have the kit required for USB webcams. So when OBOS R1 is out, contact me and bug me over webcam support :-) Cian / Kian "MYOB" Duffy PS: Just compiling now, the code doesn't like BONE 7A here. Or it could be my headers. But all the BNetEndpoint stuff doesn't compile, MsnList.cpp has casting issues, and IconHandle.cpp has prototyping issues. Some of this could be down to my hacking around with the project file though :-) ________________________________ 15 Mbytes Free Web-based and POP3 Sign up now: http://www.gawab.com |
|
From: Sir M. <obe...@ho...> - 2004-05-13 17:44:30
|
Hello Daniel(Simon already knows this :D), I've committed the new GUI code into CVS along with a new project file bme_x86.proj...use this for working on the project....The BeMSN.proj has the old UI files in it, but I doubt the code will still work(I also had to make some changes in the server code). I also added Simon's tooltip class, and he will be working on that...hope to speed up the code and improve it a bit here and there. So what's new: - All class names have been changed - Emoticon support in the contact list - Working font support(also windoze fonts if you have them installed) - Tooltips with email and status in them...but Simon will surprise you with that soon enough I hope :D Also I changed the ScreenNameWindow to ScreenNameView, to include it later in the MainWindow, so you can click and change your name...but this code isn't working yet, so in this version you can't change your name... ah also you can't see the selection in the contact list view, but that'll be figured out, also I had to install BONE on r5 and I probably added the wrong net library to the bme_x86 project, so it doesn't work on r5 without changing the lib, that has to be changed. Do you know what changes I have to make, and what library I have to include so it'll work on both BONE and net_server? regards, Tim _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Hector D. G. <al7...@ma...> - 2004-05-08 04:09:07
|
Hello guys. Sorry, I've been really busy lately, having to solve data dup= licates at work. I agree with your proposal to have the new UI code with different names, it would be easier to understand which one is being used. > >> Sorry for the slow reply....have bought a router, and installing it wa= s >a >> major pain in the ass...I had to install an other network card...and r5 > >> isn't working yet(but Dano is luckily)...so I can still develop bme *p= hew*! > >Good news! > >I think you need a router with a fixed IP, and then set the >"gateway" to that value? I've never tried it myself. > >[snip] > >> >I you are both in agreement, it would be good to make these >> >changes and get at least the New UI "skeleton" committed (as in >> >the old ui with different file names, plus some emoticon stuff) >> > >> I agree with the changes....Daniel if you agree, I will start implemen= ting > >> the changes and will upload them into cvs when they're done! I already= >have >> the contact list with emoticons implemented into the main program and >am now >> busy adding some font support! >> Yes I agree! =3D) >> >MsnChatter: >> > MsnChatter -> ConversationWindow >> > MsnChatterTextView -> ConversationHistoryView >> ConversationHistoryView is a bit long....any ideas for another name? > >We could change Conversation to just Conv: >ConvHistoryView any better? > ConversationLogView ?? I like either one, I leave it up to you. >> > MsnChatterMessagingView -> ConversationSendTextView // If you >> >can think of a better name than this, let me know! >> pfff what about just ConversationTextView > >or ConvTextView would be OK too, I added the "Send" to avoid >confusion with the history view. I'd be happy with either >though. "ConvSendTextView" is another possiblilty. > I like that last one, but we should consider having Conv for all the clas= ses instead of Conversation, don't you think? >> > MsnNoticeWindow -> NotificationPopupWindow // Or just >> >"NotificationWindow" - notification is a better description than >> >notice anyway >> > MsnNoticeView -> NotificationPopupView // As above - just >> >"NotificationView"? >> > >> Let's keep it short! I like the NotificationWindow/View names better! > >Yep, I agree. Think it's fairly clear what they are anyway. > >[snip] > >> > MsnWindow -> ContactListWindow >> Or MainWindow? > >Yes, it will have more than just the contact list in it, so >MainWindow is probably a sensible choice. > Yes, that sounds good to me too. |
|
From: Simon T. <sim...@ga...> - 2004-05-05 19:44:11
|
> Sorry for the slow reply....have bought a router, and installing it was a > major pain in the ass...I had to install an other network card...and r5 > isn't working yet(but Dano is luckily)...so I can still develop bme *phew*! Good news! I think you need a router with a fixed IP, and then set the "gateway" to that value? I've never tried it myself. [snip] > >I you are both in agreement, it would be good to make these > >changes and get at least the New UI "skeleton" committed (as in > >the old ui with different file names, plus some emoticon stuff) > > > I agree with the changes....Daniel if you agree, I will start implementing > the changes and will upload them into cvs when they're done! I already have > the contact list with emoticons implemented into the main program and am now > busy adding some font support! > > >MsnChatter: > > MsnChatter -> ConversationWindow > > MsnChatterTextView -> ConversationHistoryView > ConversationHistoryView is a bit long....any ideas for another name? We could change Conversation to just Conv: ConvHistoryView any better? > > MsnChatterMessagingView -> ConversationSendTextView // If you > >can think of a better name than this, let me know! > pfff what about just ConversationTextView or ConvTextView would be OK too, I added the "Send" to avoid confusion with the history view. I'd be happy with either though. "ConvSendTextView" is another possiblilty. > > MsnNoticeWindow -> NotificationPopupWindow // Or just > >"NotificationWindow" - notification is a better description than > >notice anyway > > MsnNoticeView -> NotificationPopupView // As above - just > >"NotificationView"? > > > Let's keep it short! I like the NotificationWindow/View names better! Yep, I agree. Think it's fairly clear what they are anyway. [snip] > > MsnWindow -> ContactListWindow > Or MainWindow? Yes, it will have more than just the contact list in it, so MainWindow is probably a sensible choice. Simon ________________________________ 15 Mbytes Free Web-based and POP3 Sign up now: http://www.gawab.com |
|
From: Sir M. <obe...@ho...> - 2004-05-05 19:23:07
|
Sorry for the slow reply....have bought a router, and installing it was a major pain in the ass...I had to install an other network card...and r5 isn't working yet(but Dano is luckily)...so I can still develop bme *phew*! >Playing with access paths doesn't solve the issue. > Well not entirely sure here...but having the same names twice in different directories can cause some very weird problems....better change the names! to be sure! >Other than that, I have would like to see a few other items >renamed to make their function clearer. > I agree we should use separate header and source files for every class, the groups in BeIDE can be used to group the functional parts of the program. I also agree changing names, also from practical point of view! >I you are both in agreement, it would be good to make these >changes and get at least the New UI "skeleton" committed (as in >the old ui with different file names, plus some emoticon stuff) > I agree with the changes....Daniel if you agree, I will start implementing the changes and will upload them into cvs when they're done! I already have the contact list with emoticons implemented into the main program and am now busy adding some font support! >MsnChatter: > MsnChatter -> ConversationWindow > MsnChatterTextView -> ConversationHistoryView ConversationHistoryView is a bit long....any ideas for another name? > MsnChatterMessagingView -> ConversationSendTextView // If you >can think of a better name than this, let me know! pfff what about just ConversationTextView? > MsnNoticeWindow -> NotificationPopupWindow // Or just >"NotificationWindow" - notification is a better description than >notice anyway > MsnNoticeView -> NotificationPopupView // As above - just >"NotificationView"? > Let's keep it short! I like the NotificationWindow/View names better! >MsnOtherWindows: >// Not sure about this - we won't have a "Change screen name" >window anyway, it will be done in the main contact list view. I think most of those windows will be dropped indeed...we'll see about that.... >MsnTransferWindow: > // Don't bother with this in the new ui folder, transfers will >be viewed in the conversation as a seperate messageitem > > MsnWindow -> ContactListWindow Or MainWindow? regards, Tim _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 |
|
From: Simon T. <sim...@ga...> - 2004-05-02 19:33:36
|
Hi guys, Just been talking to Tim about some changes for the new UI. Having 2 project files seems to work OK, although having files for the new UI with the same names as the old UI files seems to create some problems, with the wrong headers being loaded, etc. Playing with access paths doesn't solve the issue. However, I would like to see certain changes made to the names of the files for the UI anyway, so now seems the perfect time to do it. It would mean the NewUI folder could happily co-exist with the old UI files, as well as having better names. There are 2 basic things I want to change: 1) Have all classes in seperate files (within reason: the wavefilter can stay with the Prefs window, for example). For example split MsnChatter into 4 files. 2) Remove the "Msn" prefix - the UI isn't necessarily Msn specific, and I don't think the prefix adds any meaning. Other than that, I have would like to see a few other items renamed to make their function clearer. A full list of the changes proposed is below (// = comments). I you are both in agreement, it would be good to make these changes and get at least the New UI "skeleton" committed (as in the old ui with different file names, plus some emoticon stuff) Cheers, Simon [aaarrrrggggh exams in 5 weeks] ----- MsnChatter: MsnChatter -> ConversationWindow MsnChatterTextView -> ConversationHistoryView MsnChatterMessagingView -> ConversationSendTextView // If you can think of a better name than this, let me know! MsnChatterStautsBar -> ConversationStatusBar MsnDeskbarView -> DeskbarView MsnList -> ContactListView MsnLoginWindow -> LoginWindow // Although I prefer a si-mSN approach of having the login options in the main contact list window (like Jabber for BeOS if anyone's ever used that), so a "LoginWindow" would not be needed. MsnNoticeWindow: MsnNoticeWindow -> NotificationPopupWindow // Or just "NotificationWindow" - notification is a better description than notice anyway MsnNoticeView -> NotificationPopupView // As above - just "NotificationView"? MsnOtherWindows: // Not sure about this - we won't have a "Change screen name" window anyway, it will be done in the main contact list view. For now just split out to: MsnScreenNameWindow -> ScreenNameWindow MsnAddContactWindow -> AddContactWindow MsnPreferencesWindow - > PreferencesWindow MsnTransferWindow: // Don't bother with this in the new ui folder, transfers will be viewed in the conversation as a seperate messageitem MsnWindow -> ContactListWindow ________________________________ 15 Mbytes Free Web-based and POP3 Sign up now: http://www.gawab.com |
|
From: Sir M. <obe...@ho...> - 2004-04-27 19:22:04
|
Guys just noticed, if a new contact add you...you do get notified of it....but can't add this person to your contact list: approve or decline this user....we must not forget to add this option! regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Simon T. <sj...@ca...> - 2004-04-18 07:04:41
|
> Apart from this issue, have you found any other problems with the new
> code? Last time Bme crash after I left it connected for the whole
> day,
> I couldn't identify what caused the problem, if it was a particular
> command, or if after a long while the MsnBuffer gets messed up.
I had a very strange crash yesterday - let me type 1 message, then the
next 1 would cause an instant crash.
I managed to fix it my changing messaging->SetText(NULL);
to messaging->SetText(""); in MSNChatter, line 260.
Weird though.
I used it on my fast net connection for a few hours without any crashes
either - the old version always used to go to 100% in the SBReceive
threads after a few minutes of a conversation. Probably thanks to the
bigger buffer. Great work!
I'll let you know if I spot anything else.
Simon
|
|
From: Daniel G. <al7...@ma...> - 2004-04-17 05:51:53
|
Hello all,
> > Hi guys,
> >
> > I traced a bug that keeps showing the sign in window also when
> > doing
> > other
> > things...
> > the bug is caused by line 390 of the handleServerCommand in
> > MsnServerHandler.cpp:
> >
> > 389 }catch(const NetworkException &netEx){
> > 390 //
> > Common::msnSingInWindowMessenger.SendMessage(MSN_SIGNIN_FAILED);
> > 391 netEx.fprint(Common::log_file);
> > 392 int error = netEx.getError();
> > 393 if ((error == ECONNRESET) // Connection reset by
> > peer
> > 394 || (error == ENOTCONN) // Not connected
> > 395 || (error == -2147459072)){ // Bad file descriptor
> > 396 logoff();
> > 397 }
> > 398 }
> >
> > I commented out this line...and no sign in window gets shown at
> > weird
> > moments...commenting out wouldn't be the solution...and as I do not
> > entirely
> > understand the code, maybe you (Daniel) can squash this bug,
>
Yes, that line does not belong there, I copy those lines from the
authentification code and forgot to remove the line.
> Well discovered.
>
> I looked in the log, there are a lot of:
> "Exception thrown: ERROR while receiving message: Interrupted system
> call - 8000000A"
>
> I think this is probably caused when a message is sent by a socket
> that
> is currently waiting to receive data. The receive operation would
> have
> to be stopped, probably throwing an exception.
>
> Daniel? :D
>
You are right Simon, that is the cause of the exception.
The receiving thread will block on Receive and when you send something
the call will be interrupted causing an error.
I didn't notice this because, before I uploaded to CVS I was validating
that there was data pending to be received. Good thing I changed that,
otherwise we wouldn't find the bug, that line should not be there.
Before the changes the thread blocked on receive just like it does now,
but then it did not throw exceptions, just returned false.
Apart from this issue, have you found any other problems with the new
code? Last time Bme crash after I left it connected for the whole day,
I couldn't identify what caused the problem, if it was a particular
command, or if after a long while the MsnBuffer gets messed up.
Regards,
Daniel
|
|
From: Sir M. <obe...@ho...> - 2004-04-16 13:40:25
|
Hi Simon, could you please send me that list code with emoticon support, you mentioned? then I can start adding/testing the emoticon code for the contact list this weekend, regards, Tim P.s. also removed the bug causing the stripes/lines in the list view...it was indeed an overlap of the BStringView and the ListView...will upload it into cvs soon! _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/ |
|
From: Simon T. <sim...@nt...> - 2004-04-15 13:03:39
|
> Hi guys,
>
> I traced a bug that keeps showing the sign in window also when doing
> other
> things...
> the bug is caused by line 390 of the handleServerCommand in
> MsnServerHandler.cpp:
>
> 389 }catch(const NetworkException &netEx){
> 390 //
> Common::msnSingInWindowMessenger.SendMessage(MSN_SIGNIN_FAILED);
> 391 netEx.fprint(Common::log_file);
> 392 int error = netEx.getError();
> 393 if ((error == ECONNRESET) // Connection reset by
> peer
> 394 || (error == ENOTCONN) // Not connected
> 395 || (error == -2147459072)){ // Bad file descriptor
> 396 logoff();
> 397 }
> 398 }
>
> I commented out this line...and no sign in window gets shown at weird
> moments...commenting out wouldn't be the solution...and as I do not
> entirely
> understand the code, maybe you (Daniel) can squash this bug,
Well discovered.
I looked in the log, there are a lot of:
"Exception thrown: ERROR while receiving message: Interrupted system
call - 8000000A"
I think this is probably caused when a message is sent by a socket that
is currently waiting to receive data. The receive operation would have
to be stopped, probably throwing an exception.
Daniel? :D
Simon
|
|
From: Sir M. <obe...@ho...> - 2004-04-15 11:58:30
|
Hi guys,
I traced a bug that keeps showing the sign in window also when doing other
things...
the bug is caused by line 390 of the handleServerCommand in
MsnServerHandler.cpp:
389 }catch(const NetworkException &netEx){
390 //Common::msnSingInWindowMessenger.SendMessage(MSN_SIGNIN_FAILED);
391 netEx.fprint(Common::log_file);
392 int error = netEx.getError();
393 if ((error == ECONNRESET) // Connection reset by peer
394 || (error == ENOTCONN) // Not connected
395 || (error == -2147459072)){ // Bad file descriptor
396 logoff();
397 }
398 }
I commented out this line...and no sign in window gets shown at weird
moments...commenting out wouldn't be the solution...and as I do not entirely
understand the code, maybe you (Daniel) can squash this bug,
regards,
Tim
_________________________________________________________________
Play online games with your friends with MSN Messenger
http://messenger.msn.nl/
|
|
From: Simon T. <sim...@nt...> - 2004-04-13 10:10:01
|
> Aloha... > > grmf....took me a while to notice this email...hotmail decided it was > junk....:S I've missed a few too; found out how to disable junk filter now. Now I can't send mails from my subscribed account, as the postmaster address is full, an sf checks that before sending the mails to the list. Grr. > >Nice work! > > > >I will have a look at the code later. What are the window lengths > > for? > >Isn't it easier just to do a loop: > >for each emoticonString > > if BString::FindFirst(textToScan, emoticonString) != NULL > > addEmot > >loop > > > Yep that's easier....but a lot slower...if you scan the text like > that you > have to: > -search through the entire text > -search through the entire emoticon list > No I'm doing something like this: > > loop through text > loop through windowLengths > subString = text[currentPos, currentPos + windowLength] > Emoticon emot = findEmoticon(subString) > if not null > add to emoticon list(emot) > currentPos += windowLenght > currentPos++ > > Ok we still have to loop through the entire text...but that can't be > prevented....But! I implemented findEmoticon with a so called > binarySearch...this search has a complexity of (if I remember it > correctly) > 2 log n...and roughly has to search only half of the emoticons or > even > less....this will be a great improvement in speed! therefore it's a > bit more > complex... Ah ok then, I see. > >Sorry to say I've been very busy recently, so I've not managed to > >change the protocol code to use a bigger buffer yet. I may get round > > to > >it soon (although exams are now fast approaching, so I will be a bit > >busier for the next few months :s) > > > No problem! Well Daniel has fixed the bigger buffer, as you may have > read in > his email...we'll see you back after your exams...oh I will see what > I can > do about that news section! Thanks. Tried the new code Daniel - it seems to work although the sign in window keeps popping up at every NSServer command. It looks nicer with my log window though. If you want to see the connection logging, I have uploaded the files here: http://si-msn.port5.com/NetWatch.zip Unzip somewhere, open the project file and drag all the files apart from the NetWatchApp one into the bme project. This will add the files and the paths. Now go into the MSNServerHandler and change the first line of the constructor: conexion = new BNetEndpoint(); to: conexion = new WatchNetEndpoint(name); You'll need to #include "WatchNetEndpoint.h" in that file too. Have fun, and don't close the window while the endpoint is still connected and sending data. Simon |
|
From: Sir M. <obe...@ho...> - 2004-04-13 09:34:29
|
Aloha...
grmf....took me a while to notice this email...hotmail decided it was
junk....:S
>Nice work!
>
>I will have a look at the code later. What are the window lengths for?
>Isn't it easier just to do a loop:
>for each emoticonString
> if BString::FindFirst(textToScan, emoticonString) != NULL
> addEmot
>loop
>
Yep that's easier....but a lot slower...if you scan the text like that you
have to:
-search through the entire text
-search through the entire emoticon list
No I'm doing something like this:
loop through text
loop through windowLengths
subString = text[currentPos, currentPos + windowLength]
Emoticon emot = findEmoticon(subString)
if not null
add to emoticon list(emot)
currentPos += windowLenght
currentPos++
Ok we still have to loop through the entire text...but that can't be
prevented....But! I implemented findEmoticon with a so called
binarySearch...this search has a complexity of (if I remember it correctly)
2 log n...and roughly has to search only half of the emoticons or even
less....this will be a great improvement in speed! therefore it's a bit more
complex...
>Sorry to say I've been very busy recently, so I've not managed to
>change the protocol code to use a bigger buffer yet. I may get round to
>it soon (although exams are now fast approaching, so I will be a bit
>busier for the next few months :s)
>
No problem! Well Daniel has fixed the bigger buffer, as you may have read in
his email...we'll see you back after your exams...oh I will see what I can
do about that news section!
regards,
Tim
_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl
|
|
From: Sir M. <obe...@ho...> - 2004-04-13 08:45:46
|
Good Morning :D, >- To simplify access to these arguments I created another class to >access the token list, StringList, this class saves us the constant >casting of BString pointers, also has the [] operator to access the >strings and a static method to delete all strings in a list. Nice! You also could have changed the code to using a vector<BString>...although I know the iterator stuff isn't too nice to work with...therefore I mostly use the BList object...anyway, I'm curious to see how you implemented it... >- Added a destructor to StringTokenizer to delete its list object (just >the object, not its contents). >- Changed getTokens() to return a copy of the list, since the new >destructor will delete the list object. > Ah ok...I sometimes find the deleting of objects a little awkward...*sigh* wish we had a garbage collector ;) >Tim, the only class affected by the changes in StringTokenizer is >IconLoader, and is only in the (BString*) casting, so I took the >liberty of making the changes, I hope you don't mind. > Nope, not at all :D...I have begun by testing my code by building it into the contact list...(just testing, the code is kinda dirty now :D)...no success thus far, I have some problems with it, but will have a look at it this evening...I will also add some code to the Icon classes, and then I suggest that I will move on to improving the contact list, if you don't mind... I want to include groups, leave away people that you deleted, and most importantly: cache the list, to speed up things... >So far works fine, but needs more intensive testing. This should be in >the CVS by the time you read this, the code for MsnBuffer is in the >MsnServerHandler.cpp/h files. >Let me know what you think. > All sounds great! I think we've already come far into improving BeMSN!!! Btw, I'm thinking of setting up a small tutorial on downloading our sources and compiling them, for betatesters, on our page! what do you think? regards, Tim _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Daniel G. <al7...@ma...> - 2004-04-13 03:45:39
|
Hello. I've been busy improving the network code. I've made quite a few changes in order to change the previous inefficient way of receiving messages. Changes involve: - New class MsnBuffer, to cache everything received from the servers. From it, its possible to obtain the msn command or message that has not been processed, a FIFO for commands and messages. - Other changes in the way messages are process to incorporate the new class. - Now the messages' arguments are split via a new contructor in the StringTokenizer class. - To simplify access to these arguments I created another class to access the token list, StringList, this class saves us the constant casting of BString pointers, also has the [] operator to access the strings and a static method to delete all strings in a list. - Added a destructor to StringTokenizer to delete its list object (just the object, not its contents). - Changed getTokens() to return a copy of the list, since the new destructor will delete the list object. Tim, the only class affected by the changes in StringTokenizer is IconLoader, and is only in the (BString*) casting, so I took the liberty of making the changes, I hope you don't mind. So far works fine, but needs more intensive testing. This should be in the CVS by the time you read this, the code for MsnBuffer is in the MsnServerHandler.cpp/h files. Let me know what you think. Regards, Daniel |
