RE: [bme-develop] Code imported into CVS

[Simon T. <sim...@ga...>]

> Aloha Daniel,
> 
> >Hello. I found a few problem with some of the changes.
> >The problem lays in that the MSN protocol uses the charset=3DUTF8 and 
> > so
> >does BeOS for all the GUI text displaying classes. The problem is 
> > that
> >BString cannot handle UTF8. So when you get the message body like 
> > this:
> >	BString im;
> >	message->FindString("body",&im);
> >you get some problems for most of other non ascii characters, for
> >example =E1,=E9,=ED,=F3,=FA, =F1 (If you don't see this character change the
> >encoding of the e-mail to Latin-1). I use these chars a lot since 
> > most
> >of my conversations are in spanish. I think the best way to handle
> >messages is to use char pointers instead of BStrings, to avoid any
> >problems with character encodings.
> Ohoh...didn't know that...the guys at BeShare said that the BStrings 
> would 
> handle UTF8 well....so it does not...I never experienced those 
> problems 
> because those characters aren't used much here...I changed it to 
> BString 
> because the BString code is better organized, has more options and is 
> a lot 
> easier than those c methods, which I find quite difficult to 
> use....but if 
> it can't be done with BStrings then we have to use char* code...btw, 
> what 
> about c++ strings=3F can they be used, they are object oriented to and 
> have 
> most of the methods a BString has...or maybe implement our own 
> version of a 
> BString using the c methods=3F

I'm too late; I see Daniel already has it figured out. A BString is 
really just a variable size char array, with some extra methods and 
things, but it makes no assumptions about the encoding, so CountChars 
just returns the number of bytes. It's no big deal to add UTF-8 
handling, as Daniel has done.

About using BStrings at all - if there is a lot of string manipulation 
to be done, I agree that BStrings are easier (I used it quite a lot in 
my emoticon-enabled text view), but if you don't need to do much to the 
string I would prefer if it was kept as a char* to reduce overhead. 

> >
> >On a separate note, some suggetions for changes
> >
> >Maybe move the "\r\n" replacing code to the MsnSBHandler to make the
> >MsnChatter easier, clearer more straight forward, doing all the hard
> >work in the Protocol classes.
> >
> Ah ok! it was more a quick fix for those problems, your suggestion is 
> better...btw, we have to try if we have to change the sending code 
> to...so 
> we change the beOS \n to \r\n....so testing is needed where one 
> person uses 
> MSN 6.0...

Beat me to that as well! I was going to mention converting from \n to \
r\n before sending, and moving it into the protocol code. Great minds 
think alike :D
 
> >into this:
> >	rgb=5Fcolor rgb =3D rgb=5Fcolor();
> >    	msg.AddData("color",B=5FRGB=5FCOLOR=5FTYPE,(const void*)&
> >rgb,sizeof(rgb));
> >	...
> >	const rgb=5Fcolor *rgb; ssize=5Ft sz=5Fcolor;
> >	message->FindData("color",B=5FRGB=5FCOLOR=5FTYPE,(const void**)&rgb,&
> >sz=5Fcolor);
> >
> I just copied your code...let's change it to this indeed...where is 
> the 
> rgb=5Fcolor code located btw=3F maybe I then can work on choosing a color 
> ,font, 
> etc too...
> 
> >Create two methods in common.cpp
> >char 	 *	getDateStr(char *str, const char *format, int size);
> >char	 *	getTimeStr(char *str, const char *format, int size);
> >
> >What do tou guys think=3F
> >
> Ok with me...btw another suggestion from me...I'm working on another 
> beOS 
> project and I use constants in this way:
> 
> namespace Messages
> {
> 	const uint32 START=5FSIMULATION =3D 'STsi';
> 	const uint32 STOP=5FSIMULATION =3D 'SPsi';
> 	const uint32 SIMULATION=5FSETTINGS =3D 'SIse';
> 
> 	const uint32 SET=5FSIMULATION=5FSETTINGS =3D 'STss';
> 	const uint32 NEW=5FCAMERA=5FDATA =3D 'NEcd';
> 
> 	const uint32 UPDATE=5FMSG =3D 'UPms';
> 	const uint32 UPDATE=5FFAILURE =3D 'UPfa';
> 	const uint32 NEW=5FCOORDINATES =3D 'NEco';
> }

Erm I suppose that's OK - uses more memory though I think.
 
> other constants are in other namespace, I personally prefer this 
> approach to 
> the c #define part because it's easier to understand...what do you 
> think=3F 
> also I would prefer putting the methods in common.cpp in a namespace 
> because 
> you can see that it's a method from common.cpp a lot easier:
> 
> old: thismethod();
> new: Common::thismethod();

Yes have the common stuff in a new namespace, I'd like to reduce the 
number of "common" methods and things as much as possible though.
 
> what do you think=3F I know it's  quite a job to change all the 
> #defines to 
> namespace...but I'm willing to change the code in that way...if you 
> agree 
> with it....

OK by me.
 
> regards,
> 
> Tim