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