Thread: Re: [bme-develop] Dirctory structure and filenames
Status: Planning
Brought to you by:
sirmik
Menu
▾
▴
bme-develop
|
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 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: 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-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
|
