Menu
▾
▴
Re: [jazzplusplus-devel] Re: jazzplusplus-devel digest, Vol 1 #42 - 3 msgs
|
From: Dave F. <dav...@co...> - 2004-06-01 10:21:06
|
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" |
