bme-develop Mailing List for Be-messeng-er (Page 8)
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: Simon T. <sim...@nt...> - 2004-04-12 16:49:58
|
Personally I would favour waiting until we have the full new UI before releasing the first version of "Bme". If we fix problems though, we can always release updated versions of "BeMSN" in the mean time. ps Tim: Good work on the website. Maybe we could get a news page up and add a few items about what we're doing? Simon > Depends on what kind of release you mean :D....I think the first > release of > Bme will take a few months. But we could decide on releasing some > versions > in between.....For example a version that shows grouped contacts or > has some > emoticon support... > > regards, > > Tim > > > >From: "Daniel Guajardo" <al7...@ma...> > >Reply-To: bme...@li... > >To: "bme DevMail List" <bme...@li...> > >Subject: [bme-develop] BeMSN Progress (fwd) > >Date: Sun, 11 Apr 2004 14:18:46 -0500 CDT > > > >Hello, I received this email from Jess. > >What do you think? We are still a few months before a release, > > right? > > > >------ Forwarded Message: ------ > >To: al7...@ma... > >From: "Jess Tipton" <jt...@m0...> > >Subject: BeMSN Progress > >Date: Sun, 11 Apr 2004 08:09:54 -0600 CST > > > >Hey, > >I was just wondering if you guys had a date for a new release? > >- Jess > > > > > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: IBM Linux Tutorials > >Free Linux tutorial presented by Daniel Robbins, President and CEO > > of > >GenToo technologies. Learn everything from fundamentals to system > >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > > > > >_______________________________________________ > >bme-develop mailing list > >bme...@li... > >https://lists.sourceforge.net/lists/listinfo/bme-develop > > _________________________________________________________________ > Play online games with your friends with MSN Messenger > http://messenger.msn.nl/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > bme-develop mailing list > bme...@li... > https://lists.sourceforge.net/lists/listinfo/bme-develop > |
|
From: Simon T. <sim...@nt...> - 2004-04-12 16:49:24
|
3rd attempt to send this... > aloha fellow bme brothers, Hiya > >Well the handler could create an IconLoader in its constructor. All > > of > >that will be done before any messages are processed anyway. > > > Done! > > The emoticon code is working almost entirely now! it also processes > messages > like "Tim says bladiebla :D..." to a MessageItem that represents this > text, > and the place for the emoticon. The code is in CVS, so have a look at > it. > It's not finished yet, though! I use windowLengths to scan the > string...those windowLengths are the different emoticon string > lengths.... > :D has windowLength 2, whereas :-) has windowLength 3...the code that > adds > those windowLenghts automatically from the read emoticon strings I > still > have to add.... > > and then....it's GUI time!!! 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 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) > regards, > > Tim > > Btw: I already tested this code in a BWindow + BView! Cool Simon |
|
From: Sir M. <obe...@ho...> - 2004-04-12 09:26:33
|
Depends on what kind of release you mean :D....I think the first release of Bme will take a few months. But we could decide on releasing some versions in between.....For example a version that shows grouped contacts or has some emoticon support... regards, Tim >From: "Daniel Guajardo" <al7...@ma...> >Reply-To: bme...@li... >To: "bme DevMail List" <bme...@li...> >Subject: [bme-develop] BeMSN Progress (fwd) >Date: Sun, 11 Apr 2004 14:18:46 -0500 CDT > >Hello, I received this email from Jess. >What do you think? We are still a few months before a release, right? > >------ Forwarded Message: ------ >To: al7...@ma... >From: "Jess Tipton" <jt...@m0...> >Subject: BeMSN Progress >Date: Sun, 11 Apr 2004 08:09:54 -0600 CST > >Hey, >I was just wondering if you guys had a date for a new release? >- Jess > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >bme-develop mailing list >bme...@li... >https://lists.sourceforge.net/lists/listinfo/bme-develop _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Daniel G. <al7...@ma...> - 2004-04-11 19:21:10
|
Hello, I received this email from Jess. What do you think? We are still a few months before a release, right? ------ Forwarded Message: ------ To: al7...@ma... From: "Jess Tipton" <jt...@m0...> Subject: BeMSN Progress Date: Sun, 11 Apr 2004 08:09:54 -0600 CST Hey, I was just wondering if you guys had a date for a new release? - Jess |
|
From: Sir M. <obe...@ho...> - 2004-04-10 19:54:27
|
aloha fellow bme brothers, >Well the handler could create an IconLoader in its constructor. All of >that will be done before any messages are processed anyway. > Done! The emoticon code is working almost entirely now! it also processes messages like "Tim says bladiebla :D..." to a MessageItem that represents this text, and the place for the emoticon. The code is in CVS, so have a look at it. It's not finished yet, though! I use windowLengths to scan the string...those windowLengths are the different emoticon string lengths.... :D has windowLength 2, whereas :-) has windowLength 3...the code that adds those windowLenghts automatically from the read emoticon strings I still have to add.... and then....it's GUI time!!! regards, Tim Btw: I already tested this code in a BWindow + BView! _________________________________________________________________ Hotmail en Messenger on the move http://www.msn.nl/communicatie/smsdiensten/hotmailsmsv2/ |
|
From: Sir M. <obe...@ho...> - 2004-04-07 18:11:25
|
Hey guys, I think this is the time we should fantasize some content for our hompage together...It's possible to load different htmlpages in the table now...so we just have to add some links and content....let me know what you think, regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Simon T. <sim...@ga...> - 2004-04-06 17:42:58
|
> Hi, > > >Yes, I wouldn't call methods from different threads. However instead > > of > >passing a pointer to the List itself, pass a pointer to the actual > > data > >(can be obtained from BList::Items()) along with the number of > > items. > >Then each thread will have their own independent pointer to the > > data, > >and providing the actual list data is not changed, they can both > > read > >the actual items in the list at the same time. > > > Ah right, I'll pass a pointer to the Items them...we probably only > need this > list in the emoticon choosing view(the emoticon matrix) in the chat > window > right? Yeh, can't think of anywhere else that would need it. > >I would have the IconHandler deal with everything. So in the main > > bme > >code we just need > >iconHandler = new IconHandler(); > >and then the icon handler constructor takes care of creating the > > other > >classes it needs, creating a list of emoticons, populating it, > > managing > >the list, etc. > > > Mmm, problem I have with this approach is that the Handler will be > loading > the icon's...a task it should do....we also can't separate the > loading of > the icons and the starting of the handler, which maybe necessary! Well the handler could create an IconLoader in its constructor. All of that will be done before any messages are processed anyway. Why would we want to seperate the loading of the icons from having a handler? That would mean we would have all the emoticons loaded in memory, but no way of doing anything with them?? > regards, > > Tim Simon |
|
From: Sir M. <obe...@ho...> - 2004-04-06 17:24:24
|
Hi, >Yes, I wouldn't call methods from different threads. However instead of >passing a pointer to the List itself, pass a pointer to the actual data >(can be obtained from BList::Items()) along with the number of items. >Then each thread will have their own independent pointer to the data, >and providing the actual list data is not changed, they can both read >the actual items in the list at the same time. > Ah right, I'll pass a pointer to the Items them...we probably only need this list in the emoticon choosing view(the emoticon matrix) in the chat window right? >I would have the IconHandler deal with everything. So in the main bme >code we just need >iconHandler = new IconHandler(); >and then the icon handler constructor takes care of creating the other >classes it needs, creating a list of emoticons, populating it, managing >the list, etc. > Mmm, problem I have with this approach is that the Handler will be loading the icon's...a task it should do....we also can't separate the loading of the icons and the starting of the handler, which maybe necessary! regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Sir M. <obe...@ho...> - 2004-04-06 17:20:24
|
Hehe, so we just have to make sure our app is so good, that no one wants to use the IMkit for MSN ;) regards, Tim >From: "Simon Taylor" <sim...@ga...> >Reply-To: bme...@li... >To: bme...@li... >Subject: [bme-develop] Competition! >Date: Tue, 06 Apr 2004 11:34:24 +0100 BST > >Hi guys, > >Just spotted over at www.iscomputeron.com that the IMKit now has >support for MSN! > >It's a shame the number of deluded people who are working on the IMKit >(I still can't see why I would want to use Tracker to manage live >contacts), when they could be helping us. Ah well! > >Simon > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >bme-develop mailing list >bme...@li... >https://lists.sourceforge.net/lists/listinfo/bme-develop _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Simon T. <sim...@ga...> - 2004-04-06 10:33:48
|
Hi guys, Just spotted over at www.iscomputeron.com that the IMKit now has support for MSN! It's a shame the number of deluded people who are working on the IMKit (I still can't see why I would want to use Tracker to manage live contacts), when they could be helping us. Ah well! Simon |
|
From: Simon T. <sim...@ga...> - 2004-04-06 09:58:22
|
> Hi, > > > > You > > > would only see problems if a particular object holds some kind of > > > internal state, where multiple/simultaneous calls would cause the > > > internal state to misbehave. I am not sure if the BLists hold any > > > internal state, but that would be something you would find in the > > > BeBook, so I am guessing BLists are multithreading safe, the > > > problem > > > would be the BString objects, where the BeBook warns about it not > > > being > > > multithreading safe. I think it would be ok as long as you don't > > > modify > > > the contents of the BString from different threads. Maybe limit > > > the > > > Emoticons public access to the BStrings. > > > >I'm not sure BLists are thread-safe for write operations (maybe > > that's > >why the user with the fast connection experienced a crash on logging > >in?). Passing a pointer to the actual list of items along with the > > the > >number of items should be fine for reading though. > > > My thought about the multi threading issues is as follows: if you > have a > pointer to an object it is possible that a method of an object say > Items() > is called twice a the same moment resulting in a crash....(at least > that's > why you have to synchronize methods in java....to prevent the method > from > being called twice a the same moment)....If BeOS does handle this > calling > fine, we are allright...because the BList and the Emoticon objects in > it are > online loaded once! then they aren't changed anymore.... Yes, I wouldn't call methods from different threads. However instead of passing a pointer to the List itself, pass a pointer to the actual data (can be obtained from BList::Items()) along with the number of items. Then each thread will have their own independent pointer to the data, and providing the actual list data is not changed, they can both read the actual items in the list at the same time. Otherwise you can use a semaphore to make sure only one thread accesses the BList at any time (see the kernel kit documentation in the BeBook). However, the first solution is better IMHO, as we know that the data won't change after it's loaded. > btw Simon you're right about the IconManager/IconHandler stuff....I > did this > for this reason: the list loaded by IconLoader should be passed to > the > IconManager, which will be passed to the IconHandler....but I can > also make > it more safe(in deleting) to pass the List to the Handler and > construct the > IconManager in the handler, I will change it! I would have the IconHandler deal with everything. So in the main bme code we just need iconHandler = new IconHandler(); and then the icon handler constructor takes care of creating the other classes it needs, creating a list of emoticons, populating it, managing the list, etc. > regards, > Tim Simon |
|
From: Sir M. <obe...@ho...> - 2004-04-06 09:36:14
|
Hi, > > You > > would only see problems if a particular object holds some kind of > > internal state, where multiple/simultaneous calls would cause the > > internal state to misbehave. I am not sure if the BLists hold any > > internal state, but that would be something you would find in the > > BeBook, so I am guessing BLists are multithreading safe, the problem > > would be the BString objects, where the BeBook warns about it not > > being > > multithreading safe. I think it would be ok as long as you don't > > modify > > the contents of the BString from different threads. Maybe limit the > > Emoticons public access to the BStrings. > >I'm not sure BLists are thread-safe for write operations (maybe that's >why the user with the fast connection experienced a crash on logging >in?). Passing a pointer to the actual list of items along with the the >number of items should be fine for reading though. > My thought about the multi threading issues is as follows: if you have a pointer to an object it is possible that a method of an object say Items() is called twice a the same moment resulting in a crash....(at least that's why you have to synchronize methods in java....to prevent the method from being called twice a the same moment)....If BeOS does handle this calling fine, we are allright...because the BList and the Emoticon objects in it are online loaded once! then they aren't changed anymore.... btw Simon you're right about the IconManager/IconHandler stuff....I did this for this reason: the list loaded by IconLoader should be passed to the IconManager, which will be passed to the IconHandler....but I can also make it more safe(in deleting) to pass the List to the Handler and construct the IconManager in the handler, I will change it! regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Sir M. <obe...@ho...> - 2004-04-06 09:31:12
|
Hey Daniel, I added the <status> </status> section for that... it isn't used yet but if you pass me the icons used for status I can add them to the file, and make user customization possible...personally I am not too fond of the BeOS people icon....but it can be realized....maybe ask jess(he offered to do some graphics, you said, right?) to make some cool looking icons, regards, Tim >From: "Daniel Guajardo" <al7...@ma...> >Reply-To: bme...@li... >To: "bme DevMail List" <bme...@li...> >Subject: [bme-develop] looks of BeMSN (fwd) >Date: Mon, 05 Apr 2004 22:21:08 -0500 CDT > >Hello this are some suggestions I received from one of our users. > >Regards, >Daniel > >------ Forwarded Message: ------ >To: <al7...@ma...> >From: "Rob Tijssen" <rob...@ti...> >Subject: looks of BeMSN >Date: Tue, 6 Apr 2004 19:43:37 +0200 > >Is it possible to use more Be-like icons (look at the inserted image >for >an example) as on-/off-line/away information on the main window? > >Would be very cool, (use a Red People icon for offline and a green one >for offline or something like that :-)). > > Greets, Rob > > ><html xmlns:o="urn:schemas-microsoft-com:office:office" >xmlns:w="urn:schemas-microsoft-com:office:word" >xmlns="http://www.w3.org/TR/REC-html40"> > ><head> ><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"> > > ><meta name=ProgId content=Word.Document> ><meta name=Generator content="Microsoft Word 10"> ><meta name=Originator content="Microsoft Word 10"> ><link rel=File-List href="cid:filelist.xml@01C3FF25.ACC880C0"> ><!--[if gte mso 9]><xml> > <o:OfficeDocumentSettings> > <o:DoNotRelyOnCSS/> > </o:OfficeDocumentSettings> ></xml><![endif]--><!--[if gte mso 9]><xml> > <w:WordDocument> > <w:SpellingState>Clean</w:SpellingState> > <w:GrammarState>Clean</w:GrammarState> > <w:DocumentKind>DocumentEmail</w:DocumentKind> > <w:EnvelopeVis/> > <w:Compatibility> > <w:BreakWrappedTables/> > <w:SnapToGridInCell/> > <w:WrapTextWithPunct/> > <w:UseAsianBreakRules/> > </w:Compatibility> > <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> > </w:WordDocument> ></xml><![endif]--> ><style> ><!-- > /* Font Definitions */ > @font-face > {font-family:Wingdings; > panose-1:5 0 0 0 0 0 0 0 0 0; > mso-font-charset:2; > mso-generic-font-family:auto; > mso-font-pitch:variable; > mso-font-signature:0 268435456 0 0 -2147483648 0;} > /* Style Definitions */ > p.MsoNormal, li.MsoNormal, div.MsoNormal > {mso-style-parent:""; > margin:0cm; > margin-bottom:.0001pt; > mso-pagination:widow-orphan; > font-size:12.0pt; > font-family:"Times New Roman"; > mso-fareast-font-family:"Times New Roman";} >a:link, span.MsoHyperlink > {color:blue; > text-decoration:underline; > text-underline:single;} >a:visited, span.MsoHyperlinkFollowed > {color:purple; > text-decoration:underline; > text-underline:single;} >span.EmailStijl17 > {mso-style-type:personal-compose; > mso-style-noshow:yes; > mso-ansi-font-size:10.0pt; > mso-bidi-font-size:10.0pt; > font-family:Arial; > mso-ascii-font-family:Arial; > mso-hansi-font-family:Arial; > mso-bidi-font-family:Arial; > color:windowtext;} >span.SpellE > {mso-style-name:""; > mso-spl-e:yes;} >span.GramE > {mso-style-name:""; > mso-gram-e:yes;} >@page Section1 > {size:612.0pt 792.0pt; > margin:72.0pt 90.0pt 72.0pt 90.0pt; > mso-header-margin:35.4pt; > mso-footer-margin:35.4pt; > mso-paper-source:0;} >div.Section1 > {page:Section1;} >--> ></style> ><!--[if gte mso 10]> ><style> > /* Style Definitions */ > table.MsoNormalTable > {mso-style-name:Standaardtabel; > mso-tstyle-rowband-size:0; > mso-tstyle-colband-size:0; > mso-style-noshow:yes; > mso-style-parent:""; > mso-padding-alt:0cm 5.4pt 0cm 5.4pt; > mso-para-margin:0cm; > mso-para-margin-bottom:.0001pt; > mso-pagination:widow-orphan; > font-size:10.0pt; > font-family:"Times New Roman";} ></style> ><![endif]--> ></head> > ><body lang=EN-US link=blue vlink=purple style='tab-interval:36.0pt'> > ><div class=Section1> > ><p class=MsoNormal><span class=GramE><font size=2 face=Arial><span >style='font-size:10.0pt;font-family:Arial'>Is</span></font></span><font >size=2 >face=Arial><span style='font-size:10.0pt;font-family:Arial'> it possible to >use >more Be-like icons (look at the inserted image for an example) as >on-/off-line/away >information on the main window?<o:p></o:p></span></font></p> > ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt; >font-family:Arial'><o:p> </o:p></span></font></p> > ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt; >font-family:Arial'>Would be very cool, (use a Red People icon for offline >and a >green one for offline or something like <span class=GramE>that ></span></span></font><font >size=2 face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings; >mso-ascii-font-family:Arial;mso-hansi-font-family:Arial;mso-bidi-font-family: >Arial;mso-char-type:symbol;mso-symbol-font-family:Wingdings'><span >style='mso-char-type:symbol;mso-symbol-font-family:Wingdings'>J</span></span></font><font >size=2 face=Arial><span >style='font-size:10.0pt;font-family:Arial'>).<o:p></o:p></span></font></p> > ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt; >font-family:Arial'><o:p> </o:p></span></font></p> > ><p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt; >font-family:Arial'><span style='mso-spacerun:yes'> </span><span >style='mso-spacerun:yes'> </span>Greets, >Rob<o:p></o:p></span></font></p> > ></div> > ></body> > ></html> > > ><< people.gif >> _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Simon T. <sim...@ga...> - 2004-04-06 08:30:52
|
> > Hi all, > Hello > > > I've done a bit of integration of my WatchNetEndpoint class with > > bme. > > It's shown up the fact that the protocol code (in > > MsnServerHandler::receive) only gets 1 byte at a time from the > > BNetEndpoint. I think this should be changed as it is not very > > efficient to keep calling the net_server like this; and it may > > explain > > some of the instability experienced by people with fast > > connections. > > What does anybody think? > > > You're right, it is really inefficient to have so many receive calls, > it's been something I always wanted to change, but have never put > much > effort into it, mainly because the MsnServerHandler::receive method > should copy only one Msn command to the buffer. I never came up with > a > good solution to this problem, only the easy but inefficient way we > have now. Do you have any suggestions for this? I read something about it in the hypothetic.org FAQ: http://www.hypothetic.org/docs/msn/resources/faq.php I'll have a go at something like this. > > Also, because my WatchNetEndpoint class adds a "received" item > > after > > each call to BNetEndpoint::Receive, the current code creates a very > > messy-looking log: > > > > http://si-msn.port5.com/netwatch.png > > > It looks good!!, that will help me sending the P2P messages. I've not added the hex support yet, I'll fix the server handlers to get a larger buffer first, then look at that side of things. > Daniel. Simon |
|
From: Simon T. <sim...@ga...> - 2004-04-06 08:24:32
|
> Hello > > > > I'm > > > expecting major program crashes because of simultanious accessing > > > the > > > BList(via a pointer passed in the message) and the Emoticon > > > structure....I > > > think simultanious methods calls will cause that...so we have to > > > test > > > for > > > that....I have a solution for the Emoticon Structure....archiving > > > it > > > into > > > the message(yeah I know that would increase the memory > > > usage...but > > > if > > > it > > > isn't possible in another way...)....the BList of emoticons will > > > be > > > a > > > problem though...since a BList can't be archived...:S any > > > suggestions? > > > > Hmm the BList shouldn't chage after it's been loaded right? I can't > > see > > why there would be a problem with 2 threads accessing the list at > > the > > same time (as long as they use different pointers, owned by the > > threads > > themselves). Saying that, I don't think you should call BList > > methods > > from other threads, but providing the BList doesn;t change, you > > should > > be able to pass the pointer returned by BList::Items() along with > > the > > number of items returned by BList::CountItems(). > > > > I'm know very little about multithreaded issues though, so I may be > > wrong. > > > I agree with Simon, there should be no problem sending pointers to > Emoticons or to the BList. Actually that is how the MsnBuddy and > MsnList work. Everywhere I need a MsnBuddy object for something I > request it to the MsnList through the Common::getMsnBuddy(cont char* > ,BHandler) method and it returns a pointer to the MsnBuddy object. > You > would only see problems if a particular object holds some kind of > internal state, where multiple/simultaneous calls would cause the > internal state to misbehave. I am not sure if the BLists hold any > internal state, but that would be something you would find in the > BeBook, so I am guessing BLists are multithreading safe, the problem > would be the BString objects, where the BeBook warns about it not > being > multithreading safe. I think it would be ok as long as you don't > modify > the contents of the BString from different threads. Maybe limit the > Emoticons public access to the BStrings. I'm not sure BLists are thread-safe for write operations (maybe that's why the user with the fast connection experienced a crash on logging in?). Passing a pointer to the actual list of items along with the the number of items should be fine for reading though. > Regards, > Daniel Simon |
|
From: Simon T. <sim...@ga...> - 2004-04-06 08:21:53
|
> Hello this are some suggestions I received from one of our users. > > Regards, > Daniel > > ------ Forwarded Message: ------ > To: <al7...@ma...> > From: "Rob Tijssen" <rob...@ti...> > Subject: looks of BeMSN > Date: Tue, 6 Apr 2004 19:43:37 +0200 > > Is it possible to use more Be-like icons (look at the inserted image > for > an example) as on-/off-line/away information on the main window? > > Would be very cool, (use a Red People icon for offline and a green > one > for offline or something like that :-)). We will have support for custom themes anyway (looking at the iconprefs file), but this seems like a good idea for the default. The current status icons are not very nice (where did you get them from Daniel?) |
|
From: Daniel G. <al7...@ma...> - 2004-04-06 03:21:53
|
Hello this are some suggestions I received from one of our users. Regards, Daniel ------ Forwarded Message: ------ To: <al7...@ma...> From: "Rob Tijssen" <rob...@ti...> Subject: looks of BeMSN Date: Tue, 6 Apr 2004 19:43:37 +0200 Is it possible to use more Be-like icons (look at the inserted image for an example) as on-/off-line/away information on the main window? Would be very cool, (use a Red People icon for offline and a green one for offline or something like that :-)). Greets, Rob |
|
From: Daniel G. <al7...@ma...> - 2004-04-06 03:19:37
|
> Hi all, Hello > I've done a bit of integration of my WatchNetEndpoint class with bme. > It's shown up the fact that the protocol code (in > MsnServerHandler::receive) only gets 1 byte at a time from the > BNetEndpoint. I think this should be changed as it is not very > efficient to keep calling the net_server like this; and it may > explain > some of the instability experienced by people with fast connections. > What does anybody think? > You're right, it is really inefficient to have so many receive calls, it's been something I always wanted to change, but have never put much effort into it, mainly because the MsnServerHandler::receive method should copy only one Msn command to the buffer. I never came up with a good solution to this problem, only the easy but inefficient way we have now. Do you have any suggestions for this? > Also, because my WatchNetEndpoint class adds a "received" item after > each call to BNetEndpoint::Receive, the current code creates a very > messy-looking log: > > http://si-msn.port5.com/netwatch.png > It looks good!!, that will help me sending the P2P messages. Daniel. |
|
From: Daniel G. <al7...@ma...> - 2004-04-06 02:33:02
|
Hello > > I'm > > expecting major program crashes because of simultanious accessing > > the > > BList(via a pointer passed in the message) and the Emoticon > > structure....I > > think simultanious methods calls will cause that...so we have to > > test > > for > > that....I have a solution for the Emoticon Structure....archiving > > it > > into > > the message(yeah I know that would increase the memory usage...but > > if > > it > > isn't possible in another way...)....the BList of emoticons will be > > a > > problem though...since a BList can't be archived...:S any > > suggestions? > > Hmm the BList shouldn't chage after it's been loaded right? I can't > see > why there would be a problem with 2 threads accessing the list at the > same time (as long as they use different pointers, owned by the > threads > themselves). Saying that, I don't think you should call BList methods > from other threads, but providing the BList doesn;t change, you > should > be able to pass the pointer returned by BList::Items() along with the > number of items returned by BList::CountItems(). > > I'm know very little about multithreaded issues though, so I may be > wrong. > I agree with Simon, there should be no problem sending pointers to Emoticons or to the BList. Actually that is how the MsnBuddy and MsnList work. Everywhere I need a MsnBuddy object for something I request it to the MsnList through the Common::getMsnBuddy(cont char* ,BHandler) method and it returns a pointer to the MsnBuddy object. You would only see problems if a particular object holds some kind of internal state, where multiple/simultaneous calls would cause the internal state to misbehave. I am not sure if the BLists hold any internal state, but that would be something you would find in the BeBook, so I am guessing BLists are multithreading safe, the problem would be the BString objects, where the BeBook warns about it not being multithreading safe. I think it would be ok as long as you don't modify the contents of the BString from different threads. Maybe limit the Emoticons public access to the BStrings. Regards, Daniel |
|
From: Simon T. <sim...@ga...> - 2004-04-05 16:27:09
|
Hi all, I've done a bit of integration of my WatchNetEndpoint class with bme. It's shown up the fact that the protocol code (in MsnServerHandler::receive) only gets 1 byte at a time from the BNetEndpoint. I think this should be changed as it is not very efficient to keep calling the net_server like this; and it may explain some of the instability experienced by people with fast connections. What does anybody think? Also, because my WatchNetEndpoint class adds a "received" item after each call to BNetEndpoint::Receive, the current code creates a very messy-looking log: http://si-msn.port5.com/netwatch.png Simon |
|
From: Simon T. <sim...@ga...> - 2004-04-05 15:15:51
|
> Hi, > > >had to change line 55 in IconManager.cpp, from: > >BBitmap *emoticon = manager->findEmoticon(&subString); > >to > >Emoticon *emoticon = manager->findEmoticon(&subString); > > > Right! my fault!!! I changed the code...and didn't compile all > files....anyway if you pass ":D" it should return a smiling emoticon > in the > emoticon structure....but I haven't tested this yet! I will continue > on the > code this week and hope I will have it finished...one problem though! > I'm > expecting major program crashes because of simultanious accessing > the > BList(via a pointer passed in the message) and the Emoticon > structure....I > think simultanious methods calls will cause that...so we have to test > for > that....I have a solution for the Emoticon Structure....archiving it > into > the message(yeah I know that would increase the memory usage...but if > it > isn't possible in another way...)....the BList of emoticons will be a > problem though...since a BList can't be archived...:S any > suggestions? Had a bit more of a chance to look at the code. I'm a little confused by the ownership model - for example the IconManager gets deleted in the destructor of the IconHandler; but gets constructed somewhere else. Any reason why this can't be created by the IconHandler? Same for some other bits. Hmm the BList shouldn't chage after it's been loaded right? I can't see why there would be a problem with 2 threads accessing the list at the same time (as long as they use different pointers, owned by the threads themselves). Saying that, I don't think you should call BList methods from other threads, but providing the BList doesn;t change, you should be able to pass the pointer returned by BList::Items() along with the number of items returned by BList::CountItems(). I'm know very little about multithreaded issues though, so I may be wrong. > >Haven't really looked at the code yet. > Also it it isn't finished yet :D lol > regards, > > Tim Simon |
|
From: Sir M. <obe...@ho...> - 2004-04-05 12:15:11
|
Hi, >had to change line 55 in IconManager.cpp, from: >BBitmap *emoticon = manager->findEmoticon(&subString); >to >Emoticon *emoticon = manager->findEmoticon(&subString); > Right! my fault!!! I changed the code...and didn't compile all files....anyway if you pass ":D" it should return a smiling emoticon in the emoticon structure....but I haven't tested this yet! I will continue on the code this week and hope I will have it finished...one problem though! I'm expecting major program crashes because of simultanious accessing the BList(via a pointer passed in the message) and the Emoticon structure....I think simultanious methods calls will cause that...so we have to test for that....I have a solution for the Emoticon Structure....archiving it into the message(yeah I know that would increase the memory usage...but if it isn't possible in another way...)....the BList of emoticons will be a problem though...since a BList can't be archived...:S any suggestions? >Haven't really looked at the code yet. Also it it isn't finished yet :D 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-04-05 11:05:56
|
> Hi guys!, > > >You only commited Bme.proj, iconprefs.txt and constats.h > >If you wanted to commit the StringTokenizer an IconManger code you > >first have to add to the repository and the do the commit. > > > They should be in the repository now...hope it worked :D Got the files, but it doesn't compile: had to change line 55 in IconManager.cpp, from: BBitmap *emoticon = manager->findEmoticon(&subString); to Emoticon *emoticon = manager->findEmoticon(&subString); Haven't really looked at the code yet. |
|
From: Simon T. <sim...@ga...> - 2004-04-05 08:56:26
|
> > Hello, > > > > > > Simon how is the BNetEndpoint logger class going?. I would like > > > > to > > > > have > > > > it to debug my P2P replys. Right now every time I send a P2P > > > > message > > > > my > > > > chatting session is disconnected, I might be sending wrong > > > > stuff. > > > > I > > > > would be great if the view would log in hex format also, to be > > > > able > > > > to > > > > view the binary information of P2P messages. > > > > > > I am getting to the stage of integrating it. It seems to work for > > > the > > > DS handler, but no windows get created for the other > > > BNetEndpoints. > > > I > > > couldn't really see where they were created though (I think they > > > were > > > not done with "new", which may be a problem). > > > > > > Is the P2P stuff sent as simple binary data then? Hmm, I can't > > > think > > > how to detect what is ASCII and what is binary - any ideas? > > > > > Actually all P2P messages have a binary header and footer. But the > > data > > could be either text or binary depending on the message. I think, > > for > > now it would be good to have an option to display the traffic > > either > > as > > text or hex format. Or have both views like the hex viewer > > DiskProbe > > in BeOS. I'll see what I can do. > I forgot to tell you the other BNetEndpoints get created in the base > class for the network handlers in MsnServerHandler, and they are > created with new, but don't know why that would be a problem. I tried a mulitple-file search for "BNetEndpoint", and only found the one for the DS handler. I'll have a better look later, and try to get something working by this afternoon. > Daniel Simon |
|
From: Daniel G. <al7...@ma...> - 2004-04-05 06:22:04
|
> Hello, > > > > Simon how is the BNetEndpoint logger class going?. I would like > > > to > > > have > > > it to debug my P2P replys. Right now every time I send a P2P > > > message > > > my > > > chatting session is disconnected, I might be sending wrong stuff. > > > I > > > would be great if the view would log in hex format also, to be > > > able > > > to > > > view the binary information of P2P messages. > > > > I am getting to the stage of integrating it. It seems to work for > > the > > DS handler, but no windows get created for the other BNetEndpoints. > > I > > couldn't really see where they were created though (I think they > > were > > not done with "new", which may be a problem). > > > > Is the P2P stuff sent as simple binary data then? Hmm, I can't > > think > > how to detect what is ASCII and what is binary - any ideas? > > > Actually all P2P messages have a binary header and footer. But the > data > could be either text or binary depending on the message. I think, for > now it would be good to have an option to display the traffic either > as > text or hex format. Or have both views like the hex viewer DiskProbe > in BeOS. > I forgot to tell you the other BNetEndpoints get created in the base class for the network handlers in MsnServerHandler, and they are created with new, but don't know why that would be a problem. Daniel |
