bme-develop Mailing List for Be-messeng-er (Page 10)
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: Hector D. G. <al7...@ma...> - 2004-03-26 14:45:19
|
Hello, -- Mensaje Original -- >If I do this: > >cvs -d:ext:si...@cv...:/cvsroot/bme commit -m > >I get something like this: > >CVS: -------------------------------------------------------------------= --- >CVS: Enter Log. Lines beginning with `CVS:' are removed automatically >CVS: >CVS: Committing in . >CVS: >CVS: Modified Files: >CVS: Bme.proj src/Exceptions.h src/MsnApp.cpp >CVS: src/MsnProtocol/NetworkHandlers/MsnSBHandler.cpp >CVS: src/UserInterface/MsnChatter.cpp >CVS: src/UserInterface/MsnChatter.h >CVS: src/UserInterface/MsnLoginWindow.h >CVS: src/UserInterface/MsnNoticeWindow.h >CVS: src/UserInterface/MsnPreferencesWindow.h >CVS: -------------------------------------------------------------------= --- > When you do a commit without a message, you cvs will go into vi (the text= editor) mode, so you can enter the message into the log. There is a messa= ge on the log for every commit. Do you know who to use vi? It a command base= editor, type "a" to append text, "i" to insert, ":wq" to save and close the log. Regards, Daniel |
|
From: Sir M. <obe...@ho...> - 2004-03-26 10:50:40
|
Hi, >My compiler has the same problem, even with Be's headers. So we have to remember that we include a newline after each files...we can't change the Be headers, so we leave them as is....but it there should be a lot less warnings if we do it in our own files! >Did you commited your changes to the cvs? I am not seeing your changes >on the code. >To see if the status of the repository I am using the following command > cvs -d:ext:the...@cv...:/cvsroot/bme status * >This compares the code on your hard drive to the one on the repository. >All the files appear as up-to-date, so your changes have not been >commited. Try > cvs -d:ext:the...@cv...:/cvsroot/bme commit -m >"Message log" file1 file2 >Update will download the latest version on sourceforge to your hard >drive. If I do this: cvs -d:ext:si...@cv...:/cvsroot/bme commit -m I get something like this: CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Committing in . CVS: CVS: Modified Files: CVS: Bme.proj src/Exceptions.h src/MsnApp.cpp CVS: src/MsnProtocol/NetworkHandlers/MsnSBHandler.cpp CVS: src/UserInterface/MsnChatter.cpp CVS: src/UserInterface/MsnChatter.h CVS: src/UserInterface/MsnLoginWindow.h CVS: src/UserInterface/MsnNoticeWindow.h CVS: src/UserInterface/MsnPreferencesWindow.h CVS: ---------------------------------------------------------------------- and then the system hangs...nothing gets updated...I did update the MsnSBHandler.cpp and MsnChatter.cpp/.h files...the rest will be probably be added newlines... weird, any idea what's wrong? regards, Tim _________________________________________________________________ Play online games with your friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Daniel G. <al7...@ma...> - 2004-03-25 23:43:15
|
Hi there. > I tried to upload some of the files I modified to cvs but it didn't > seem to > work...I updated Daniel's code with the changes I made earlier...time > is in > front of the message now, font effects work(but not entirely) and I > changed > insertIm in the MsnChatter class to insertIM(BMessage *msg)... > Oh...can someone check if my code is in cvs...I tried the sf cvs > page, but > only Daniel showed up as the one who commited code...oh one kind > request...since my compiler here gives out warnings when a file is > not ended > in a read line...could you just place an enter at then end of each > file when > coding? that way probably only the warnings I truely need turn up > My compiler has the same problem, even with Be's headers. Did you commited your changes to the cvs? I am not seeing your changes on the code. To see if the status of the repository I am using the following command cvs -d:ext:the...@cv...:/cvsroot/bme status * This compares the code on your hard drive to the one on the repository. All the files appear as up-to-date, so your changes have not been commited. Try cvs -d:ext:the...@cv...:/cvsroot/bme commit -m "Message log" file1 file2 Update will download the latest version on sourceforge to your hard drive. Daniel |
|
From: Sir M. <obe...@ho...> - 2004-03-24 19:40:21
|
hello, I tried to upload some of the files I modified to cvs but it didn't seem to work...I updated Daniel's code with the changes I made earlier...time is in front of the message now, font effects work(but not entirely) and I changed insertIm in the MsnChatter class to insertIM(BMessage *msg)...Simon you might have a look at this code when starting on the new chat-window code...I also included a line of code that changes the \r\n windows enters to \n...because often I do get some blocks in my received messages, representing, I think, the \r part....Also I would recommend not making entirely new UI classes but using the old ones...in that way we can work together on the UI code, otherwise we would end up having to wait for each other... Oh...can someone check if my code is in cvs...I tried the sf cvs page, but only Daniel showed up as the one who commited code...oh one kind request...since my compiler here gives out warnings when a file is not ended in a read line...could you just place an enter at then end of each file when coding? that way probably only the warnings I truely need turn up regards, Tim > > The checkout didn't complete for me though (well it appears to have > > got > > all the files, but it had to be killed at the end). Thanks for > > importing the sources anyway Daniel. > > >Same problem for me. On all cvs commands it hangs at the end, and have >to kill it. But seems to get the job done. >Has anyone tried from windows or other OS? _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Daniel G. <al7...@ma...> - 2004-03-24 05:01:10
|
Hola! > > >You have to type "yes" in full - it should then prompt you for a > > >password. > > > > > Ok done this...but when I enter my password(the same as for the > > admin > > tool > > on sf, that works), the program responds with "Permission > > denied"....any > > ideas? > > It worked fine for me. > > Check case sensitivity and the fact that you've got your username > correct too? > I had similar problems the first time. I had to change my sf password on the souceforge website, after that I could connect through the ssh, and after that to the cvs repository. > > The checkout didn't complete for me though (well it appears to have > got > all the files, but it had to be killed at the end). Thanks for > importing the sources anyway Daniel. > Same problem for me. On all cvs commands it hangs at the end, and have to kill it. But seems to get the job done. Has anyone tried from windows or other OS? > > Simon > Daniel |
|
From: Simon T. <sim...@ga...> - 2004-03-23 14:45:27
|
> Hi, > > >You have to type "yes" in full - it should then prompt you for a > >password. > > > Ok done this...but when I enter my password(the same as for the admin > tool > on sf, that works), the program responds with "Permission > denied"....any > ideas? It worked fine for me. Check case sensitivity and the fact that you've got your username correct too? The checkout didn't complete for me though (well it appears to have got all the files, but it had to be killed at the end). Thanks for importing the sources anyway Daniel. Simon |
|
From: Sir M. <obe...@ho...> - 2004-03-23 12:17:41
|
Hi, >You have to type "yes" in full - it should then prompt you for a >password. > Ok done this...but when I enter my password(the same as for the admin tool on sf, that works), the program responds with "Permission denied"....any ideas? regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Simon T. <sim...@ga...> - 2004-03-23 11:43:08
|
> Hi Daniel, > > I have some problems logging in, I do this: > > ssh -l sirmik cvs.sourceforge.net > > and this is what it says: > > Host key not found from the list of known hosts. > Are you sure you want to continue connecting (yes/no)? You have to type "yes" in full - it should then prompt you for a password. > if I choose yes or no I get the same message again. Do you know what > I'm > doing wrong. Btw, if I have the code from cvs I will make a doxygen > file for > it. Then we maybe should also make a directory for the docs generated > by > doxygen, Sounds cool. > regards, > > Tim Simon |
|
From: Sir M. <obe...@ho...> - 2004-03-23 11:19:42
|
Hi Daniel, I have some problems logging in, I do this: ssh -l sirmik cvs.sourceforge.net and this is what it says: Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)? if I choose yes or no I get the same message again. Do you know what I'm doing wrong. Btw, if I have the code from cvs I will make a doxygen file for it. Then we maybe should also make a directory for the docs generated by doxygen, regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Daniel G. <al7...@ma...> - 2004-03-23 09:21:37
|
Hey guys, I have imported the source code into the cvs repository. Please checkout the code, the module name is Bme. First step is to login to the server to create a home directory for your user. You will need ssh for this. You will be prompted for your SF password. ssh -l the_taki cvs.sourceforge.net export CVS_RSH=ssh; cvs -d:ext:the...@cv...:/cvsroot/bme checkout Bme Then commit any changes you've made to the source. If connection refuses, keep trying until you are able to connect. Thanks, Daniel |
|
From: Simon T. <sim...@ga...> - 2004-03-22 10:44:12
|
> Good morning (evening here) my fellow programmers!!
Mornin' all (or evening, or night, or whatever),
> > > I agree with the FirstLettersCapitalised naming scheme.
> > >
> > > Me too. Since I mainly a java programmer I'm already accustomed
> > > to
> > > this....one question though, do we also use the java convention
> > > to
> > > start
> > > method name with a non-capitalised character? that is also
> > > important
> > > I
> > > think, to agree on that...so Be or Java way...I agree on
> > > separating
> > > every
> > > class into it's own header and source file...
> >
> > I go for the Be way - methods are FirstLetterCapitalised, data
> > members
> > are firstWordSmall (I've also gone for the fPrivateVariable scheme
> > in
> > some of my code too).
> If we go with the Be approach, do we change the current methods? That
> involves a lot of changes.
> Or would this be from this point forward?
I don't mind. CVS allows these kind of changes without any problems, so
we don't have to fix all of these issues before we do the checkin.
> >
> > > > Another thing is the directory structure, so far there is
> > > > only a src/
> > > >
> > > >directory and all the code is in there. We could organize it a
> > > > little
> > > >better, as Simon suggested. I have attached my suggestion, take
> > > > a
> > > >look.
> > >
> > > This is much better.
> > >
> > > maybe also separate the headers and the source into different
> > > subdirectories...
> >
> > Yes, that might be a good idea.
> Do you mean all the headers in one place? or a headers folder in each
> subdirectory?
> I like both headers and source in the same folder, although a headers
> folder will come in handy if the number of classes starts getting
> larger.
Keep the headers in the same place then. That's how I usually work
anyway. I don't think we'll have more than 10 source files in each
directory really.
> >
> > > Just a few changes:
> > > - Project files (.proj and .rsrc) should be "Bme.proj" (we also
> > > need
> > > to
> > > decide between "bme" "Bme" "BMe" or "BME"!)
> > > haha don't mind what it should be called...though I have a little
> > > preference
> > > for Bme and bme....
> >
> > OK, go with "Bme" then? It always annoys me when people use small
> > letters for everything.
> >
> > > - Remove spaces in folder names ("Msn Protocol" to either
> > > "MsnProtocol"
> > > or just "Protocol" (I don't see us supporting multi protocols,
> > > although
> > > I could be wrong)).
> > > I believe cvs also can't handle dirs with spaces, but I can be
> > > wrong....we
> > > also need a directory for the icons...I'll attach the zip to this
> > > email....
> >
> > We will also have other graphics, such as logo, actual program
> > icons,
> > maybe some standard display pictures, backgrounds?, etc
> Ok. Bme it is. I have made the change along with the spaces in the
> folders names.
> Maybe better to have a graphics folder, inside which we could have,
> icons, backgounds, etc.
> I know Jess will be happy to help us with any graphics we need.
Yes, a graphics folder is a good idea.
> > > - I don't know if we want seperate folders for old and new
> > > UI.
> > > I want
> > > to change quite a lot, add some windows and remove some others,
> > > but
> > > I
> > > could just edit the existing files I suppose. However that means
> > > any
> > > work-in-progress stuff won't have a full CVS history. For
> > > example,
> > > the
> > > conv window will use a new BListView sytle - this will probably
> > > take
> > > a
> > > while until it works as well as a BTextView approach, so either
> > > we
> > > will
> > > be left with a CVS version that doesn't work very well for a
> > > while,
> > > or
> > > I will have to develop it until it's finished and then commit it
> > > all
> > > at
> > > once. Neither of these are very good solutions IMHO, so I'd
> > > prefer
> > > two
> > > directories - a "New_UI" one and a "BeMSN_UI" one. That way we
> > > can
> > > work
> > > together on the new UI in CVS, without having to sacrafice the
> > > current
> > > UI, which works fine already.
> > >
> > > Problem with this approach is that you're working with two
> > > different
> > > UI
> > > codes....things will get broken anyway in the near future...and
> > > in
> > > this way
> > > we can get confused on what code we should work...If we go for
> > > this
> > > approach I think we have to make some good descisions on how to
> > > carry
> > > out
> > > the further programming,
> >
> > So what is your prefered approach? Directly edit the old UI to
> > transform it into the new one?
> I think is better to have two separate folders when the time comes,
> and
> two project files each using one of the GUIs, so we can work in other
> areas of the project without having to wait for the new GUI. We just
> have to agree on what is going to change in the new GUI, and start
> working on the it as soon as possible so we don't waist efforts with
> the old one.
I agree.
The work I'm doing at the moment is for a BListView of network traffic,
but I'm writting a BListItem with features I can reuse in the
conversation window (for example, automatic text wrapping).
I don't think the old GUI needs any more work, certainly we shouldn't
implement any new UI features for the old UI.
So I think we're about ready to commit the source to CVS. Daniel, I'll
leave it to you :-)
Simon
|
|
From: Daniel G. <al7...@ma...> - 2004-03-22 06:47:34
|
Good morning (evening here) my fellow programmers!!
> > I agree with the FirstLettersCapitalised naming scheme.
> >
> > Me too. Since I mainly a java programmer I'm already accustomed to
> > this....one question though, do we also use the java convention to
> > start
> > method name with a non-capitalised character? that is also
> > important
> > I
> > think, to agree on that...so Be or Java way...I agree on separating
> > every
> > class into it's own header and source file...
>
> I go for the Be way - methods are FirstLetterCapitalised, data
> members
> are firstWordSmall (I've also gone for the fPrivateVariable scheme in
> some of my code too).
If we go with the Be approach, do we change the current methods? That
involves a lot of changes.
Or would this be from this point forward?
>
> > > Another thing is the directory structure, so far there is
> > > only a src/
> > >
> > >directory and all the code is in there. We could organize it a
> > > little
> > >better, as Simon suggested. I have attached my suggestion, take a
> > >look.
> >
> > This is much better.
> >
> > maybe also separate the headers and the source into different
> > subdirectories...
>
> Yes, that might be a good idea.
Do you mean all the headers in one place? or a headers folder in each
subdirectory?
I like both headers and source in the same folder, although a headers
folder will come in handy if the number of classes starts getting
larger.
>
> > Just a few changes:
> > - Project files (.proj and .rsrc) should be "Bme.proj" (we also
> > need
> > to
> > decide between "bme" "Bme" "BMe" or "BME"!)
> > haha don't mind what it should be called...though I have a little
> > preference
> > for Bme and bme....
>
> OK, go with "Bme" then? It always annoys me when people use small
> letters for everything.
>
> > - Remove spaces in folder names ("Msn Protocol" to either
> > "MsnProtocol"
> > or just "Protocol" (I don't see us supporting multi protocols,
> > although
> > I could be wrong)).
> > I believe cvs also can't handle dirs with spaces, but I can be
> > wrong....we
> > also need a directory for the icons...I'll attach the zip to this
> > email....
>
> We will also have other graphics, such as logo, actual program icons,
> maybe some standard display pictures, backgrounds?, etc
Ok. Bme it is. I have made the change along with the spaces in the
folders names.
Maybe better to have a graphics folder, inside which we could have,
icons, backgounds, etc.
I know Jess will be happy to help us with any graphics we need.
> > - I don't know if we want seperate folders for old and new
> > UI.
> > I want
> > to change quite a lot, add some windows and remove some others, but
> > I
> > could just edit the existing files I suppose. However that means
> > any
> > work-in-progress stuff won't have a full CVS history. For example,
> > the
> > conv window will use a new BListView sytle - this will probably
> > take
> > a
> > while until it works as well as a BTextView approach, so either we
> > will
> > be left with a CVS version that doesn't work very well for a while,
> > or
> > I will have to develop it until it's finished and then commit it
> > all
> > at
> > once. Neither of these are very good solutions IMHO, so I'd prefer
> > two
> > directories - a "New_UI" one and a "BeMSN_UI" one. That way we can
> > work
> > together on the new UI in CVS, without having to sacrafice the
> > current
> > UI, which works fine already.
> >
> > Problem with this approach is that you're working with two
> > different
> > UI
> > codes....things will get broken anyway in the near future...and in
> > this way
> > we can get confused on what code we should work...If we go for
> > this
> > approach I think we have to make some good descisions on how to
> > carry
> > out
> > the further programming,
>
> So what is your prefered approach? Directly edit the old UI to
> transform it into the new one?
I think is better to have two separate folders when the time comes, and
two project files each using one of the GUIs, so we can work in other
areas of the project without having to wait for the new GUI. We just
have to agree on what is going to change in the new GUI, and start
working on the it as soon as possible so we don't waist efforts with
the old one.
>
> > regards,
> >
> > Tim
>
> Simon
>
Daniel
|
|
From: Simon T. <sim...@ga...> - 2004-03-21 16:10:02
|
[snip]
> I agree with the FirstLettersCapitalised naming scheme.
>
> Me too. Since I mainly a java programmer I'm already accustomed to
> this....one question though, do we also use the java convention to
> start
> method name with a non-capitalised character? that is also important
> I
> think, to agree on that...so Be or Java way...I agree on separating
> every
> class into it's own header and source file...
I go for the Be way - methods are FirstLetterCapitalised, data members
are firstWordSmall (I've also gone for the fPrivateVariable scheme in
some of my code too).
> > Another thing is the directory structure, so far there is
> > only a src/
> >
> >directory and all the code is in there. We could organize it a
> > little
> >better, as Simon suggested. I have attached my suggestion, take a
> >look.
>
> This is much better.
>
> maybe also separate the headers and the source into different
> subdirectories...
Yes, that might be a good idea.
> Just a few changes:
> - Project files (.proj and .rsrc) should be "Bme.proj" (we also need
> to
> decide between "bme" "Bme" "BMe" or "BME"!)
> haha don't mind what it should be called...though I have a little
> preference
> for Bme and bme....
OK, go with "Bme" then? It always annoys me when people use small
letters for everything.
> - Remove spaces in folder names ("Msn Protocol" to either
> "MsnProtocol"
> or just "Protocol" (I don't see us supporting multi protocols,
> although
> I could be wrong)).
> I believe cvs also can't handle dirs with spaces, but I can be
> wrong....we
> also need a directory for the icons...I'll attach the zip to this
> email....
We will also have other graphics, such as logo, actual program icons,
maybe some standard display pictures, backgrounds?, etc
> - I don't know if we want seperate folders for old and new UI.
> I want
> to change quite a lot, add some windows and remove some others, but I
> could just edit the existing files I suppose. However that means any
> work-in-progress stuff won't have a full CVS history. For example,
> the
> conv window will use a new BListView sytle - this will probably take
> a
> while until it works as well as a BTextView approach, so either we
> will
> be left with a CVS version that doesn't work very well for a while,
> or
> I will have to develop it until it's finished and then commit it all
> at
> once. Neither of these are very good solutions IMHO, so I'd prefer
> two
> directories - a "New_UI" one and a "BeMSN_UI" one. That way we can
> work
> together on the new UI in CVS, without having to sacrafice the
> current
> UI, which works fine already.
>
> Problem with this approach is that you're working with two different
> UI
> codes....things will get broken anyway in the near future...and in
> this way
> we can get confused on what code we should work...If we go for this
> approach I think we have to make some good descisions on how to carry
> out
> the further programming,
So what is your prefered approach? Directly edit the old UI to
transform it into the new one?
> regards,
>
> Tim
Simon
|
|
From: Sir M. <obe...@ho...> - 2004-03-21 13:22:21
|
Aloha!
It looks like I can't send attachment to our mail list, I'll send you the
icon file seperately in a minute....
>Is important to standardize the filenames, classes etc. So far there
>where two types different names for classes, I had MSNClassName from
>the first versions of the code, then I incorporated the
>BMsnServerHandlers. I like the java standard for class names where
>each
>word of the name is capitalized, MsnClassName, and that would be the
>name of the file, just adding the extension .h/.cpp
>Also, I was thinking to take MsnOtherWindows.h/.cpp and put every
>class
>in it's own file.
I agree with the FirstLettersCapitalised naming scheme.
Me too. Since I mainly a java programmer I'm already accustomed to
this....one question though, do we also use the java convention to start
method name with a non-capitalised character? that is also important I
think, to agree on that...so Be or Java way...I agree on separating every
class into it's own header and source file...
> Another thing is the directory structure, so far there is only a src/
>
>directory and all the code is in there. We could organize it a little
>better, as Simon suggested. I have attached my suggestion, take a
>look.
This is much better.
maybe also separate the headers and the source into different
subdirectories...
Just a few changes:
- Project files (.proj and .rsrc) should be "Bme.proj" (we also need to
decide between "bme" "Bme" "BMe" or "BME"!)
haha don't mind what it should be called...though I have a little preference
for Bme and bme....
- Remove spaces in folder names ("Msn Protocol" to either "MsnProtocol"
or just "Protocol" (I don't see us supporting multi protocols, although
I could be wrong)).
I believe cvs also can't handle dirs with spaces, but I can be wrong....we
also need a directory for the icons...I'll attach the zip to this email....
- I don't know if we want seperate folders for old and new UI. I want
to change quite a lot, add some windows and remove some others, but I
could just edit the existing files I suppose. However that means any
work-in-progress stuff won't have a full CVS history. For example, the
conv window will use a new BListView sytle - this will probably take a
while until it works as well as a BTextView approach, so either we will
be left with a CVS version that doesn't work very well for a while, or
I will have to develop it until it's finished and then commit it all at
once. Neither of these are very good solutions IMHO, so I'd prefer two
directories - a "New_UI" one and a "BeMSN_UI" one. That way we can work
together on the new UI in CVS, without having to sacrafice the current
UI, which works fine already.
Problem with this approach is that you're working with two different UI
codes....things will get broken anyway in the near future...and in this way
we can get confused on what code we should work...If we go for this
approach I think we have to make some good descisions on how to carry out
the further programming,
regards,
Tim
_________________________________________________________________
MSN Search, for accurate results! http://search.msn.nl
|
|
From: Simon T. <sim...@ga...> - 2004-03-21 10:53:21
|
> Hello guys!
Hi!
> I want to check this with you before I import anything into the cvs
> repository.
>
> Is important to standardize the filenames, classes etc. So far there
> where two types different names for classes, I had MSNClassName from
> the first versions of the code, then I incorporated the
> BMsnServerHandlers. I like the java standard for class names where
> each
> word of the name is capitalized, MsnClassName, and that would be the
> name of the file, just adding the extension .h/.cpp
> Also, I was thinking to take MsnOtherWindows.h/.cpp and put every
> class
> in it's own file.
I agree with the FirstLettersCapitalised naming scheme.
> Another thing is the directory structure, so far there is only a src/
>
> directory and all the code is in there. We could organize it a little
> better, as Simon suggested. I have attached my suggestion, take a
> look.
This is much better.
Just a few changes:
- Project files (.proj and .rsrc) should be "Bme.proj" (we also need to
decide between "bme" "Bme" "BMe" or "BME"!)
- Remove spaces in folder names ("Msn Protocol" to either "MsnProtocol"
or just "Protocol" (I don't see us supporting multi protocols, although
I could be wrong)).
- I don't know if we want seperate folders for old and new UI. I want
to change quite a lot, add some windows and remove some others, but I
could just edit the existing files I suppose. However that means any
work-in-progress stuff won't have a full CVS history. For example, the
conv window will use a new BListView sytle - this will probably take a
while until it works as well as a BTextView approach, so either we will
be left with a CVS version that doesn't work very well for a while, or
I will have to develop it until it's finished and then commit it all at
once. Neither of these are very good solutions IMHO, so I'd prefer two
directories - a "New_UI" one and a "BeMSN_UI" one. That way we can work
together on the new UI in CVS, without having to sacrafice the current
UI, which works fine already.
Thoughts?
> Please let me know what you think.
> Thanks,
> Daniel
Simon
|
|
From: Daniel G. <al7...@ma...> - 2004-03-21 04:13:52
|
Hello guys! I want to check this with you before I import anything into the cvs repository. Is important to standardize the filenames, classes etc. So far there where two types different names for classes, I had MSNClassName from the first versions of the code, then I incorporated the BMsnServerHandlers. I like the java standard for class names where each word of the name is capitalized, MsnClassName, and that would be the name of the file, just adding the extension .h/.cpp Also, I was thinking to take MsnOtherWindows.h/.cpp and put every class in it's own file. Another thing is the directory structure, so far there is only a src/ directory and all the code is in there. We could organize it a little better, as Simon suggested. I have attached my suggestion, take a look. Please let me know what you think. Thanks, Daniel |
|
From: Simon T. <sim...@ga...> - 2004-03-18 17:29:42
|
> Hi, > > >For me the GPL is too restrictive. The LPGL is less-so, but still > >fairly complicated. > > > GPL means that the software should be distribute freely, and that all > software that uses code from this program should also be distributed > under > gpl right=3F what's LGPL=3F GPL stops people from taking the code for whatever purpose - and forces them to release whatever they write also under the GPL. That makes it harder for people like the IM Kit to take our code - as they'd be forced to use GPL too in that case. Designed to ensure the code stays free, but it doing that it restricts some of the freedoms IMHO. LGPL is less restrictive (not quite sure why) - I think it allows LGPL'ed libraries to be used in non-LGPL software. > >My choice would be MIT/BSD (I think that's how I registered the > > project > >on sf, although it's no problem to change it). The license basically > >says - "Here's the code, do anything you want with it, but don't sue > > us > >if it doesn't work". The problem is it doesn't stop anyone taking > > all > >of our code and selling it commercially. I really don't think that's > >likely to happen with BeOS software though, so I'd go with the > >simplicity of the MIT license. > > But, I believe that MIT also says something about acknowledging the > makers > of the program! Maybe, not sure. The OBOS license says that it must be reproduced with any complete copies or substantial portions of the software, I guess that means credit must be given. //--------------------------------------------------------------------- --------- // Copyright (c) 2001-2003, OpenBeOS // // Permission is hereby granted, free of charge, to any person obtaining a // copy of this software and associated documentation files (the "Software"), // to deal in the Software without restriction, including without limitation // the rights to use, copy, modify, merge, publish, distribute, sublicense, // and/or sell copies of the Software, and to permit persons to whom the // Software is furnished to do so, subject to the following conditions: // // The above copyright notice and this permission notice shall be included in // all copies or substantial portions of the Software. // // THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR // IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, // FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE // AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER // LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING // FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER // DEALINGS IN THE SOFTWARE. //--------------------------------------------------------------------- --------- > > > >I think we just need to add a comment at the top of each file. This > > is > >from one of the OBOS files: > >/* > >** Copyright 2002-2003, Axel D=F6rfler, ax...@pi.... All > >rights reserved. > >** Distributed under the terms of the OpenBeOS License. > >*/ > > > > Ok hope that is everything....we have to be sure though Is it really that crucial=3F I don't see millions of people waiting to steal our code in case we choose the wrong license! > > > > > I will say for now to post their feedback in the forums. Let's > > > wait > > > until we are a little more organized on the source, the cvs > > > server, > > > license, and everything else. How about you, what do you think=3F > > > >I agree. Wait until we're a bit more organised. > > > Oke...told one tester already. Daniel one little remark....we have to > change > that....if you send a IM message you use "message" in the BMessage, > and if > you receive one you use "body"! > > regards, > > Tim Simon |
|
From: Sir M. <obe...@ho...> - 2004-03-18 16:56:03
|
Hi, >For me the GPL is too restrictive. The LPGL is less-so, but still >fairly complicated. > GPL means that the software should be distribute freely, and that all software that uses code from this program should also be distributed under gpl right? what's LGPL? >My choice would be MIT/BSD (I think that's how I registered the project >on sf, although it's no problem to change it). The license basically >says - "Here's the code, do anything you want with it, but don't sue us >if it doesn't work". The problem is it doesn't stop anyone taking all >of our code and selling it commercially. I really don't think that's >likely to happen with BeOS software though, so I'd go with the >simplicity of the MIT license. But, I believe that MIT also says something about acknowledging the makers of the program! > >I think we just need to add a comment at the top of each file. This is >from one of the OBOS files: >/* >** Copyright 2002-2003, Axel Dörfler, ax...@pi.... All >rights reserved. >** Distributed under the terms of the OpenBeOS License. >*/ > Ok hope that is everything....we have to be sure though > > > I will say for now to post their feedback in the forums. Let's wait > > until we are a little more organized on the source, the cvs server, > > license, and everything else. How about you, what do you think? > >I agree. Wait until we're a bit more organised. > Oke...told one tester already. Daniel one little remark....we have to change that....if you send a IM message you use "message" in the BMessage, and if you receive one you use "body"! regards, Tim _________________________________________________________________ Talk with your online friends with MSN Messenger http://messenger.msn.nl/ |
|
From: Simon T. <sim...@ga...> - 2004-03-18 10:34:08
|
> bme team, > > > > > What do you think=3F > > > > > >Yes, put all of it on sourceforge if you're happy doing that. > > > > > Precisely, but do we have to agree on a license before we put it on > > sourceforge=3F and how do we post something under a license=3F just > > paste > > the > > license header above the file=3F Or can we restrict the sourceforge > > cvs > > access > > until we've agreed on a license.... > Yes most definitely we need to agree on a license. Honestly I don't > know much about open source licenses, GPL, LGPL, and all the others, > I > will have to do some research on the topic. What are your > recommendations=3F And I don't think there is a way to restrict access > to > the cvs, once it's there, it's for everyone. For me the GPL is too restrictive. The LPGL is less-so, but still fairly complicated. My choice would be MIT/BSD (I think that's how I registered the project on sf, although it's no problem to change it). The license basically says - "Here's the code, do anything you want with it, but don't sue us if it doesn't work". The problem is it doesn't stop anyone taking all of our code and selling it commercially. I really don't think that's likely to happen with BeOS software though, so I'd go with the simplicity of the MIT license. I think we just need to add a comment at the top of each file. This is from one of the OBOS files: /* ** Copyright 2002-2003, Axel D=F6rfler, ax...@pi.... All rights reserved. ** Distributed under the terms of the OpenBeOS License. */ > > >I will probably start the new GUI from scratch, so maybe we could > > > split > > >the code into folders: > > >-Network > > >-OldGUI > > >-NewGUI > > > > > >I think it is quite hard to get stuff deleted from CVS. > > > > > >Renaming might also be a problem, so I will ask now: Is there any > > >reason for the "B" on the start of the network classes=3F > Yes renaming stuff on cvs can be a problem. The reason of the B for > the > server handlers is that I was going to change everything with a B in > front of it. Much like the Be API classes, but I never did it. So I > ended up with two standards for class naming. We should decide which > one to follow, BMsnClassName or MSNClassName, or leave it as is. When I write code, I use the "B" to remind me that I'm using one of the classes provided by Be. I'd prefer "MsnClassName" or "MSNClassName" (don't mind either of those). > > > > > Mmm, which classes are you gonna start on=3F because the problem is > > I'm > > also > > working on some of those classes...couldn't you change the code of > > Daniel's > > classes, or would that be too much trouble=3F > > > > >I think other people have mentioned it. I just often get the > > > feeling > > >that less people reply to me when I'm on BeMSN, I guess that's due > > > to > > >messages not arriving. > > > > > >Also, mik was on BeOS and I was using MSN 6, and we experienced a > > > few > > >times where we didn't get each others messages. > > > > > I doesn't happen too often, I'm using BeMSN almost the whole time > > now...since I'm working on BeOS for my M. Sc. now...it's a lot > > stabler now, > > I'm also getting reports from people at BeShare about that...btw, > > we > > two > > people now, who offered to be beta testers...should I ask them to > > join this > > list=3F or post their feedback in the forums=3F > I will say for now to post their feedback in the forums. Let's wait > until we are a little more organized on the source, the cvs server, > license, and everything else. How about you, what do you think=3F I agree. Wait until we're a bit more organised. > Regards > > Daniel Simon |
|
From: Daniel G. <al7...@ma...> - 2004-03-18 06:48:34
|
bme team, > > > What do you think? > > > >Yes, put all of it on sourceforge if you're happy doing that. > > > Precisely, but do we have to agree on a license before we put it on > sourceforge? and how do we post something under a license? just paste > the > license header above the file? Or can we restrict the sourceforge cvs > access > until we've agreed on a license.... Yes most definitely we need to agree on a license. Honestly I don't know much about open source licenses, GPL, LGPL, and all the others, I will have to do some research on the topic. What are your recommendations? And I don't think there is a way to restrict access to the cvs, once it's there, it's for everyone. > >I will probably start the new GUI from scratch, so maybe we could > > split > >the code into folders: > >-Network > >-OldGUI > >-NewGUI > > > >I think it is quite hard to get stuff deleted from CVS. > > > >Renaming might also be a problem, so I will ask now: Is there any > >reason for the "B" on the start of the network classes? Yes renaming stuff on cvs can be a problem. The reason of the B for the server handlers is that I was going to change everything with a B in front of it. Much like the Be API classes, but I never did it. So I ended up with two standards for class naming. We should decide which one to follow, BMsnClassName or MSNClassName, or leave it as is. > > > Mmm, which classes are you gonna start on? because the problem is I'm > also > working on some of those classes...couldn't you change the code of > Daniel's > classes, or would that be too much trouble? > > >I think other people have mentioned it. I just often get the feeling > >that less people reply to me when I'm on BeMSN, I guess that's due > > to > >messages not arriving. > > > >Also, mik was on BeOS and I was using MSN 6, and we experienced a > > few > >times where we didn't get each others messages. > > > I doesn't happen too often, I'm using BeMSN almost the whole time > now...since I'm working on BeOS for my M. Sc. now...it's a lot > stabler now, > I'm also getting reports from people at BeShare about that...btw, we > two > people now, who offered to be beta testers...should I ask them to > join this > list? or post their feedback in the forums? I will say for now to post their feedback in the forums. Let's wait until we are a little more organized on the source, the cvs server, license, and everything else. How about you, what do you think? Regards Daniel |
|
From: Sir M. <obe...@ho...> - 2004-03-17 12:18:14
|
Aloha, > > What do you think? > >Yes, put all of it on sourceforge if you're happy doing that. > Precisely, but do we have to agree on a license before we put it on sourceforge? and how do we post something under a license? just paste the license header above the file? Or can we restrict the sourceforge cvs access until we've agreed on a license.... >I will probably start the new GUI from scratch, so maybe we could split >the code into folders: >-Network >-OldGUI >-NewGUI > >I think it is quite hard to get stuff deleted from CVS. > Mmm, which classes are you gonna start on? because the problem is I'm also working on some of those classes...couldn't you change the code of Daniel's classes, or would that be too much trouble? >I think other people have mentioned it. I just often get the feeling >that less people reply to me when I'm on BeMSN, I guess that's due to >messages not arriving. > >Also, mik was on BeOS and I was using MSN 6, and we experienced a few >times where we didn't get each others messages. > I doesn't happen too often, I'm using BeMSN almost the whole time now...since I'm working on BeOS for my M. Sc. now...it's a lot stabler now, I'm also getting reports from people at BeShare about that...btw, we two people now, who offered to be beta testers...should I ask them to join this list? or post their feedback in the forums? regards, Tim _________________________________________________________________ MSN Search, for accurate results! http://search.msn.nl |
|
From: Simon T. <sim...@ga...> - 2004-03-17 10:26:42
|
> Hello. > > > Hi, > > > > Daniel - is your CVS server just hosted on your machine? I think we > > should begin making use of the CVS server at sourceforge. If you do > > not > > want to check in all the GUI code, maybe we could at least work on > > the > > network code in CVS, and we can add the GUI files there as we > > create > > them. > Yes, the cvs server is just hosted on my machine. I agree with you, > it's time to go open source with the project. I don't have a problem > importing the whole thing, do you? I prefer to have everything there > because we will be working with protocol and GUI, as Mik is doing > now. > What do you think? Yes, put all of it on sourceforge if you're happy doing that. I will probably start the new GUI from scratch, so maybe we could split the code into folders: -Network -OldGUI -NewGUI I think it is quite hard to get stuff deleted from CVS. Renaming might also be a problem, so I will ask now: Is there any reason for the "B" on the start of the network classes? > > > > Website; Something simple will be fine - php + mySQL would be good > > (submit a sf.net service request if you still can't access the DB > > Tim), > > otherwise plain-vanilla HTML will suffice for a while. > > > > I'm going to start on the GUI soon, however first I would like to > > get > > to the bottom of the strange network code bugs (me + tim > > experienced > > the messages not arriving phenomenon the other day). A text log can > > be > > useful, but it isn't live - I'm going to create a class derived > > from > > BNetEndpoint that creates a BWindow with a BListView when > > constructed, > > and any bytes sent or received will be instantly logged to the > > BListView. Then if we can arrange a time to test, one of you can > > log > > in > > with the official client and we can play around for a bit, while > > I'm > > looking at a "live" view of the actual network traffic. > I like your idea for the live view of network traffic. It will come > in > handy when debugging the protocol code and file transfers. > Have you heard complains from other users about this issue (messages > not arriving)? I ask because it does not happen to me, but I can't > say > I use MSN that much now, nor that I have tested it that much, just > curious if anyone else has these problems. I think other people have mentioned it. I just often get the feeling that less people reply to me when I'm on BeMSN, I guess that's due to messages not arriving. Also, mik was on BeOS and I was using MSN 6, and we experienced a few times where we didn't get each others messages. I will sign up for a new "testing" passport account, and then we can try and arrange a time for some serious network debugging when I've got the live view BNetEndpoint working properly. > > > > Simon > > > > Thanks, > Daniel |
|
From: Daniel G. <al7...@ma...> - 2004-03-17 07:01:09
|
Hello. > Hi, > > Daniel - is your CVS server just hosted on your machine? I think we > should begin making use of the CVS server at sourceforge. If you do > not > want to check in all the GUI code, maybe we could at least work on > the > network code in CVS, and we can add the GUI files there as we create > them. Yes, the cvs server is just hosted on my machine. I agree with you, it's time to go open source with the project. I don't have a problem importing the whole thing, do you? I prefer to have everything there because we will be working with protocol and GUI, as Mik is doing now. What do you think? > > Website; Something simple will be fine - php + mySQL would be good > (submit a sf.net service request if you still can't access the DB > Tim), > otherwise plain-vanilla HTML will suffice for a while. > > I'm going to start on the GUI soon, however first I would like to get > to the bottom of the strange network code bugs (me + tim experienced > the messages not arriving phenomenon the other day). A text log can > be > useful, but it isn't live - I'm going to create a class derived from > BNetEndpoint that creates a BWindow with a BListView when > constructed, > and any bytes sent or received will be instantly logged to the > BListView. Then if we can arrange a time to test, one of you can log > in > with the official client and we can play around for a bit, while I'm > looking at a "live" view of the actual network traffic. I like your idea for the live view of network traffic. It will come in handy when debugging the protocol code and file transfers. Have you heard complains from other users about this issue (messages not arriving)? I ask because it does not happen to me, but I can't say I use MSN that much now, nor that I have tested it that much, just curious if anyone else has these problems. > > Simon > Thanks, Daniel |
|
From: Daniel G. <al7...@ma...> - 2004-03-17 06:44:42
|
Hi guys. The different timezones are becoming an issue with communication... jeje. I try to check my mail from work but have been very busy these couple of days. > Hi, > > >You are working on the GUI side only right? or are you working with > >IMgs from the MSN protocol? > >We should probably add a few parameters to the > >BMessage(MSN_SEND_MESSAGE) in order to include these effects. > >It would also be nice to choose different fonts and colors, right > > now > >every msg is hardcoded Arial black on the protocol side. > > > Uhm yes I changed a bit of code in the BMsnSBHandler class (and the > MSNChatter class)...I changed to also parse the EF command and wrap > the > command part (I=italic, B=bold, U=underscore, S = Strikeout, and > combinations of it) into the MSN_SEND_MESSAGE...hope that isn't a > problem, > I'll attach the new code... maybe it's also a better idea to change > the > insertIM(const char *fname, const char *im, rgb_color rgb, const char > * > effect) in MSNChatter to insertIM(BMessage *message) or isn't that > possible, > because of weird message things? In that we way don't have to pass > all the > parameters in the BMessage separately... No problem. Just wanted to make sure I understood exactly where you are working on. I have seen the code and it looks good to me. I agree with changing the insertIM method to insertIM(BMessage *message) go a head a do it. I know the the cvs on my machine is not working correctly. We might want to go open source with the project and start using SF. > > I know now that Bold and/or Italic work, the font is properly > changed...major thanx to a friend of mine, who helped me testing > this...he > also offered to be a beta tester...as I said the other two > (underscore and > strikeout) aren't implemented by be...we can provide a work around > for that, > but that may be difficult to realise...we'll see about that...I'm > also > thinking of installing some windows fonts in beOS to implement the > font > handling code(if the font isn't found, change back to a beOS > font)...btw > there is also a lot of info in the msn messages about what kind of > font > class (times new roman like, arial like) the message uses, maybe we > can use > that as well...to select an appropriate font, when the font itself > isn't > selected.... Yes, all of that sounds great! Good work. > > Yesterday I also continued my work on parsing the icon prefs > file...I'm > making a StringTokenizer for that, and that piece of code, has some > problems > with it, hope I'll figure it out today though... > Looks like we are making good progress guys. I should get back to work on the file transfer protocol as soon as I get a chance, I hope I can get some work done this weekend. > >I don't think I can get us one. Sorry. If we had java for BeOS > >maybe... jaja =) > >That would rock!! > > > That would rock indeed! Well then I suggest using the sourceforge > webspace...have to learn some php then, so it can take some time > before I > have something decent...can send you the mockup of the page I flinged > together last week...if you want (Simon already saw it)...then if we > agree > we can use that... > > regards, > > Tim > > _________________________________________________________________ > Protect your PC - get McAfee.com VirusScan Online > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 > > > > ------------------------------------------------------- > 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...@ga...> - 2004-03-16 17:27:49
|
Hi, Daniel - is your CVS server just hosted on your machine? I think we should begin making use of the CVS server at sourceforge. If you do not want to check in all the GUI code, maybe we could at least work on the network code in CVS, and we can add the GUI files there as we create them. Website; Something simple will be fine - php + mySQL would be good (submit a sf.net service request if you still can't access the DB Tim), otherwise plain-vanilla HTML will suffice for a while. I'm going to start on the GUI soon, however first I would like to get to the bottom of the strange network code bugs (me + tim experienced the messages not arriving phenomenon the other day). A text log can be useful, but it isn't live - I'm going to create a class derived from BNetEndpoint that creates a BWindow with a BListView when constructed, and any bytes sent or received will be instantly logged to the BListView. Then if we can arrange a time to test, one of you can log in with the official client and we can play around for a bit, while I'm looking at a "live" view of the actual network traffic. Simon |
