Re: [bme-develop] Dirctory structure and filenames

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

> 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