jazzplusplus-devel

[jazzplusplus-devel] Re: jazzplusplus-devel digest, Vol 1 #42 - 3 msgs

[Harald R. <Har...@im...>]

Hello Dave and Joakim,

encouraged by your answers I'll checkout the sources and try to get them 
compiled on Windows. Then I'll start integrating my features...

Yet 2 questions:

1. which person(s) coordinate(s) the development ?
2. are there any stable software interfaces inside Jazz++ I can rely on ?

ad 1.: some changes to the user interface I want to make might have to follow 
some common guidelines - which I don't know ? And I need some persistent data 
for my features. Where to place them ?
ad 2.: I don't want to checkout a version, integrate my features, and later find 
out that checking in is nearly impossible because other developers changed all 
interfaces I used. I have limited time, so this is a probable case because of 
long periods between chechout and checkin.

Kind Regards
Harald

Re: [jazzplusplus-devel] Re: jazzplusplus-devel digest, Vol 1 #42 - 3 msgs

[Dave F. <dav...@co...>]

On Tuesday 01 June 2004 02:52 am, Harald Rieder wrote:
> Hello Dave and Joakim,
>
> encouraged by your answers I'll checkout the sources and try to get them
> compiled on Windows. Then I'll start integrating my features...
>
> Yet 2 questions:
>
> 1. which person(s) coordinate(s) the development ?

Well, there's only like four of us (five?  how many of us are there, anyway?), 
and we haven't felt the need to have one specific person coordinating 
development.  For the most part, though, Patrick sets the rules and nags us 
when we screw up.  So I guess that makes him the "Project Coordinator".  In 
other words, Jazz++ is developed like a regular ol' traditional jazz jam.  
Everybody just plays what they want.  ;)  There's so much work to get the 
thing finished ported to wxWidgets 2.4 that there's very little overlap 
between us right now, and we're all generally on the same page (as in, 
whenever we argue, we wind up discovering that we agreed and the argument was 
pretty stupid to begin with ;)  ).

> 2. are there any stable software interfaces inside Jazz++ I can rely on ?

gProject, which is the global instance of jppProject.  It's a global interface 
declared in Project.h (it may be in a subdirectory, it's been a little while 
since I cracked it open).  The only thing it's missing right now is complete 
selection support.  Right now selection is supported by a hack using tFilter, 
and that interface should be deprecated, but without a new interface....  
Anyway, jppProject inherits from tSong, which contains most of the stuff for 
loading project files and so forth.

> ad 1.: some changes to the user interface I want to make might have to
> follow some common guidelines - which I don't know ? And I need some
> persistent data for my features. Where to place them ?

Depending on the actual data itself, it probably belongs in gProject.  It may, 
however, belong in tConfig.  If you're wanting to take a crack at it, tConfig 
needs to be rewritten to use wxWidgets' config classes, and we need a new 
preferences dialog that takes all the existing global settings (that are 
currently stacked in the Misc menu) and sticks them all into one nice dialog.

As far as interface, the only real guideline we have is that we're all 
committed to using XRC for GUI declarations.  Joakim will no doubt have more 
information on this than I (I've been working on the gProject object and 
nothing else ;)  )  We also have a sorta guideline along the lines of "Easy 
to use, discoverable, and so forth", but that's pretty ambiguous.  Just don't 
do any of the regular open source stupid GUI designs, ok?  Quick and dirty to 
test the feature is fine, because we all do that.  ;)  It also gets the 
feature into the code where we can all test it and debate the best possible 
UI for the feature.  SO don't be shy about it, but don't be surprised if 
someone comes back and says "Can you make it, er, easier?"  ;)

> ad 2.: I don't want to checkout a version, integrate my features, and later
> find out that checking in is nearly impossible because other developers
> changed all interfaces I used. I have limited time, so this is a probable
> case because of long periods between chechout and checkin.

This is your lucky day!  We have all been so inactive that you're very likely 
to find that nothing's changed.  The rule of thumb is, if the interface you 
want currently exists in a class with a jpp prefix, it's probably not going 
to change for awhile.  If it exists in a class with a t prefix, it may or may 
not change.  If you depend on any global variables other than gProject, then 
expect the interface to completely disappear when I get my next Jazz++ 
timeslice.  (Except any new config implementation, which probably also needs 
to be global, but I'm definitely trying to eliminate as many global variables 
as possible)

The other rule is to submit patches regularly so someone can checkin the 
patch.  The only rule there is that it has to build.  Not necessarily run :) 
, but at least build.  I suspect we'll probably change this at some point and 
say "It also has to run", but we haven't yet.  The code is too, um, er, 
likely not to run right now for such a rule to be practical.  ;)  (Except it 
runs right now, I think)  Actually, it's not exactly a hard and set rule that 
you have to send the patches regularly so we can check them in, but if you 
wait six months to send in your work, and all the interfaces change in the 
meantime, I personally won't be all that sympathetic.  ;)

Hmm, finally, the only coding standard I can remember right now that we have 
is that new classes get the jpp prefix, and they're 
jppCamelCaseNamesThatAreSomewhatDescriptiveOfWhatTheyDoButNotLongLikeMicrosoftInterfaceNames.  
Do we have any indenting standards and braces and stuff?  Mm, as a general 
convention I usually use an mMember for private members, and I'm hard-core 
addicted to Getters and Setters, but that's me.  I also tend to steal from 
Python's thread interface and make a ->Run method for classes that have such 
appropriate methods, threaded or not.  (yadayada, I know Python's thread 
interface is in turn stolen from somewhere else)

Dave

> Kind Regards
> Harald
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel

-- 
Visit my website!
http://www.davefancella.com/?event=em

Classical music is the kind we keep thinking will turn into a tune.
		-- Kin Hubbard, "Abe Martin's Sayings"

Re: [jazzplusplus-devel] Re: jazzplusplus-devel digest, Vol 1 #42 - 3 msgs

[joakim v. <jo...@ve...>]

Dave summed it up pretty well, but just a little further note:

In your case, you are making something like a new midi-event matrix 
editor right?
(ok, not the same layout and so on, but technically the same)

The jazz++ interfaces you use should then be fairly thin, and thus 
resilient to changes.

On the other hand you will be very reliant on the wxwindows drawing 
interfaces,
and they can change between releases.

Heres hoping that we will never face a change like that from wx 1.68 to 
wx 2 again :-)
I do think that there wont be changes like that again.

You can try making a copy of the matrix editor in your own class and 
start changing that
to match you needs. I think thats the easiest way to get started.

You will probably find the drawing code quite convoluted, but if your 
from an MFC background
you will find it familiar.

/Joakim

Harald Rieder wrote:

> Hello Dave and Joakim,
>
> encouraged by your answers I'll checkout the sources and try to get 
> them compiled on Windows. Then I'll start integrating my features...
>
> Yet 2 questions:
>
> 1. which person(s) coordinate(s) the development ?
> 2. are there any stable software interfaces inside Jazz++ I can rely on ?
>
> ad 1.: some changes to the user interface I want to make might have to 
> follow some common guidelines - which I don't know ? And I need some 
> persistent data for my features. Where to place them ?
> ad 2.: I don't want to checkout a version, integrate my features, and 
> later find out that checking in is nearly impossible because other 
> developers changed all interfaces I used. I have limited time, so this 
> is a probable case because of long periods between chechout and checkin.
>
> Kind Regards
> Harald
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> jazzplusplus-devel mailing list
> jaz...@li...
> https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel