Re: [bme-develop] Dirctory structure and filenames

[Daniel G. <al7...@ma...>]

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