Hi Angel, >> I don't know where the misconception comes from about my POV on this, but >> I'd like to stop it now. > > Hi Viktor ! > > Well first of all my english is not very good so I could be misunderstood. > I've said I was in disagree with you when refering backward compatibility > among xbase++ and harbour. For me xbase++ is more like a "philosofy of work" > than a rigid set of rules. If compatibiliy risks the viability of the qt GUI > we need, then I think we can and we should break it. I insist: It's only my > personaly POV.
The whole movement started from creating an _Xbase++ compatible GUI class_, which says it clear. (Hence the name of the lib: hbxbp) If we were starting a GUI class "inspired by" Xbase++, or "contains elements of" Xbase++, or "loosely based" on Xbase++, the situation would for sure be different, but this wasn't the original statement / goal. >> If make Xbase++ users life more difficult to move to Harbour, it means >> Harbour userbase can't grow the way it otherwise would. Which isn't very >> good. > > I don´t think hords of xbase users will come here since they are so Windows > headed. They like things like OLE, skins, owner drawn parts, GUI fancy > objects, all kind of non multiplatform M$ toys. Also the false feeling of > support you get when you pay for something. We can force no one to come here and we don't want to. However, if we start to mess up compatibility we for sure lock out all potential users from ever migrating. This is quite bad, as we don't thrive in large user base regarding Harbour, and the best thing we can do is attract users from other parts of the xbase (not the product) arena to keep the project alive and with some sort of purpose. > Anyway the whole idea and consistency of the xbase++ GUI framework is a good > model to follow. It's yet to prove if it's easy to integtrate tools like > qtcreator and qt development style in this model or we'll have to invent a > whole new development philosofy derived from the zillion c++ examples they > have on their page. Yes, I agree. We have other possibilities to achieve this, just to name a few: 1) Create another contrib which is "based-on" or even completely different from hbxbp and build our own general (preferably) or hbqt orientated GUI classes. 2) Solve interoperation of _addons libs_ (classes) and direct hbqt objects with hbxbp. There is more. >> [ about a few technical aspects of extending wisely and in documented way, >> pls see my recent msg. ] > > Yes I've read it and I trust your judjement and the vision of quality you > have imprinted into Harbour project. > This post was only a very personal POV ( I insist ) and has no intention to > harm anyone. No problem at all, and your opinion is very welcome, I just wanted to make it clear that the original proposition about my opinion was wrongly put :) > My best regards and continue with your superb managing of the project. Thank you. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
