> 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. ------------------------------------------------------------------------------ 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
