On Sat, January 4, 2014 9:59 pm, Jacob Dawid wrote: >> I'm QT newbie, I'm not much interested to learn it even more, so I >> can't even defend ( or not ) current approach. >> I only think that, because H2 is internally modularized, you can do >> your job in H2 domain - let's say in gui2 directory. There is already >> player, cli etc, so one module more is not a problem. OFC you can >> work >> in your branch/fork - and when you close some stage we can even >> release H2 with both - new and old GUI. > > Qt is not a GUI framework, it's an application framework and an > extension of the C++ language by OO features. It's an "evolution" of > C++. Most people get that wrong, thinking Qt is a GUI-only thing. That > is where the modularization already fails. This leads to strange code > like the mixer widget that needs polling. Usually this is done via > signals and slots. > > Also, you are using Qt3 legacy classes, like QHttp. I am already > building with Qt5, which does not support theses classes anymore. > > There are some fundamental questions in our ways I think. For example > the build system, which should be qmake for a Qt application imho. I > always prefer to do things like they were intended to be done. The > directory structure, coding style, license and so on. For example, I > will rather release my fork under GPLv3 or later. > >> One real benefit of such approach is that if you hit some problem in >> core module we can fix it here for both versions. Your fork stay >> consistent with official release and we can work together - because >> our goals about cleaning code are the same. > > I fear they are not, because the road to achieve clean code leads > through unstable versions of Hydrogen. That's why I say it's good there > are people like you providing patches that make Hydrogen stable. But > these are rather minor changes and I would advise you to not put to much > efforts into establishing new concepts. Of course, you are free to do > whatever you want to :P > > Intentionally, I started this fork, because I gave Hydrogen to our > (music theory experienced) drummer so that he can program in our songs > for practice. He noticed a couple things he would like to have > different, so in a certain way I am scratching a personal itch here. I > want to use Hydrogen and I improve it based on what a drummer thinks can > be improved. > >>> That's up to you. Just give me final decision on that. >> >> I'm not sure who exactly should make such decision. My opinion is >> that - if you want rewrite GUI , improve core code etc. then there is >> place to work in current domain. If you want rewrite entire app , or >> most .. then this will be no longer hydrogen - and it shouldn't >> confuse users... but IMHO it's better to work together anyway. >> >> hydrogen future is not in fork - but in cleaning mess in code and >> recruiting more contributors , official fork can only confuse >> community. >> >> P. >> > > Okay, I will rename it as soon as there is a possible release > candidate. >
In the past other forks of other apps such as zynadsubfx to yoshimi have resulted in significant improvements to the fork which were rolled back (in part) to the original source but it was mostly driven by one developers motivation. However the fork was originally started as a result of complete lack of feedback from the core developer which caused the developer of the fork to have to go it alone if he wanted to make any progress. It seems to me that you are more interested in building the features that you personally want rather than contributing to the development of the Hydrogen project as a team effort so IMO a fork would be more appropriate as that way you don't have to debate or compromise your development plans and/or ruffle any feathers if your vision is different from the rest of the Hydrogen team. BTW, there is already a fork of Hydrogen called Composite which also provides the Tritium library and can be run as an LV2 plugin. If you haven't already looked into it you might find that there is some useful code in there too. On the other hand your development so far seems mostly cosmetic and useful for the core functionality of Hydrogen as a drum sequencer so it could be hosted in the Hydrogen repo and tagged as a new development branch for example Hydrogen-3.0. However that could end up with a similar outcome to JACK where we have jack1 and jack2. IMO, if you are not making significant changes to the core functionality of the app then a fork would be bad manners as it would cause some hassle for the core devs to integrate your additions at a later date and bypass the effort that has been put into building the Hydrogen codebase and community to this point. In the end it doesn't really matter as long as people can build and use the new functionality. Drama or not. if the code is good some people will appreciate it. Cheers -- Patrick Shirkey Boost Hardware Ltd ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Hydrogen-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hydrogen-devel
