|
From: Rieder <har...@im...> - 2004-06-09 09:46:19
|
Hello, > Message: 2 > From: Dave Fancella <dav...@co...> > 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 Oh yes. Seems to be much work!!! > 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. I am wanting but progress is not as fast as I thought... See below. > 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 I'll try... > wait six months to send in your work, and all the interfaces change in the > meantime, I personally won't be all that sympathetic. ;) Normally I would update from CVS and recompile the merged sources before checkin in my work. What do you mean with "send in". Isn't that CVS checkin ? > From: joakim verona <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 current matrix editor would support color schemes which the user may select and probably some other settings (3D drawing style, shape of note heads, bodies, tails, ...)(persistent default settings [and - would be nice - per song][and - if it really makes sense - per track]). The new midi-event matrix editor rather would be a "print preview" showing my notation layouted on N pages. I do not see the necessity to allow editing in this new view, since it would mean work and you already have the possibility to edit in the current matrix editor. In this new view you could adjust the borders, headline, footline and you would have a "print" button. There must be also a sort of filter dialog allowing the user to select which tracks and channels he wants to print. The filter settings should be persistent per song. Another nice thing would be a cursor for the current position when playing the song. Or a cursor propagating according to the data received from MIDI input (so a keyborder doesn't need to leave around the pages while playing since the software can do that). Even more exiting would be an algorithm that can fine-tune a whole song to get optimum intervals (i.e. clean intervals, not the 2^N/12 approximations). The latter point however surely means so much work as developping a complete sequencer from scratch. > On the other hand you will be very reliant on the wxwindows drawing > interfaces, > and they can change between releases. Yes. This is the experience I made with serveral open source libs. Interface change more fast than on commercial software. In the meantime I got the Jazz++ sources. I installed wxWidgets 2.4.2 for Windows. I compiled the library, some wx sample programs and demos and they work. I must study yet their tutorial since I'm not familiar with this GUI lib... I tried to generate a Makefile with autoconf but got 3 different confusing error messages with 3 different versions of these tools (2 cygwin on Windows and 1 on SuSE 8.2 Linux). Finally I decided to build a MSVC++ 6.0 project (+ workspace) from scratch. After some adaptations I could compile my first module jazz.cpp. Then I compiled also player.cpp and song.cpp. Now I have too many open points to continue work: Since I did not use autoconf, there is no config.h file, but it gets #included. I created a new config.h file to satisfy the existing sources and put it into this "mswin" directory I found. Was this correct ? What is the sense of this jazzdll.cpp file in the mswin directory ? Is there a DLL to be built in the jazz project ? I had to #define a JAZZ_DATADIR (I did it in the new config.h) to get jazz.cpp compiled. What is the meaning of it and how should it work on Windows: as on UNIX or different ? What are the wxProperty... things ? You can only use them if macro "wxUSE_PROPSHEET" is not 0. In the file lib/msw/wx/setup.h it is #defined to be 0! I had to add "$(WXWIN)/lib/msw" to my inlucde path - like in the wxWidgets sample programs - to get things compiled. I had to change the value to 1 in the wxWidgets source, but I guess it's not the way it is meant by the inventors. But what is correct ? Not to use wxProperty... classes in Windows programs ?? The most confusing things are these wx_... macros. For example I started to change wx_msw into __WXMSW__. I believed that wx_msw might be the wxWindows old way and __WXMSW__ the new way (see wxWidgets platform.h). Then I discovered other such macros like wx_xt and wx_xview. I asked myself: why should you be able to compile the jazz sources with so many old macros and I not ? Did you generate these macros with autoconf/automake and I am missing something ? The amount of specific code for Windows I saw up to now was frightening! I had the hope that the OS interface is covered by wxWidgets (neary completely). Isn't that the case ? Looking forward to your answers Harald |