Hi Pritpal, On 2010 Jan 28, at 07:29, Pritpal Bedi wrote:
> > > Viktor Szakáts wrote: >> >> If this is the case, there is nothing wrong in asking >> these things specifically. I very often ask such >> question on the list (and not always, but sometimes >> I even get answers), and IMO this should be the >> proper way, instead of staying silent, or sweeping >> a problem under the carpet and/or introduce >> a shortcut, which will "cost" a lot more to fix >> sometimes in the future. These are possibly the >> worse actions that can be made in such cases. >> > > To be noted point is, a human cannot pay > attention to everyhing coming your way all the time. > I got indulged in hbQT* implementation to the point > where my wife and children got neglected. It is highly > likely that I must have missed some posts you are > referring to. The main problem with Qt is the > insufficient knowldge how it handles the object > destruction. Istvan forwarded some help > but it seems even those are not sufficient, we need > more hands. Rest are cosmatic affairs. You should definitely not neglect other things, since we should never forget the fun part and that we do Harbour because it gives us something. But it's fully up to you how to balance. If it starts to ruin other things, just stop. Never anybody called for a deadline or asked for anything to be there now and never will (or simply turn it down if anything like that happens.) It's also about priorities: IMO development is not just pouring new code. It's about stabilizing what we have. It may be less fun at times, but only this way anything can become a serious product at the end. So in Harbour we tend to prioritize bug fixes over adding new features. IOW there is no point in having any feature rich product with a lose base and bugs lurking. Overall for me the only important thing is that we're on the right (agreed) track and speak on the same terms. >> Sometimes it's possible that an approach or >> solution will look right to the developer, but >> others "outside the box" will see its shortage or >> potential problem. In this case IMO it's essential >> to allow for discussion and make required corrections >> _in time_ and without taking it personally. That's >> where the power of peer review and joint development >> is. >> > > Then perhaps it is the moral duty of the visualizer > to fix them. Developer tends to go by his vision, it is normal. You could notice that I've fixed quite some things, but it's certainly not my duty to fix everything I happen to notice. Besides not my (or testers') duty, it's many times not possible, since a tester/reviewer doesn't also know what's the proper way, but can only tell that's something is wrong (this scenario happens when we get a bug report from user f.e.). HBQT is only one contrib, and we have lots of other things in Harbour to take care of. Plus its size is huge. And since you're the "father" of these components, you have to show care also when things are rough and problems are found. This is part of development. Also for me it _has_ been though but I went and fixed all reported hbmk2 issues to make it good and accepted. Believe me it was though sometimes to read 15 bullet points and get to the end of each of them, and reiterate, but it's worth it. In fact you can be grateful to anyone giving any sort of valuable feedback, it means that they care. >> BTW I have a few reference counting questions pending >> in hbwin lib, and I hope to get answers to them; even >> if the answer is that even the question is silly. Could >> be, but everything is useful which will help us to >> find the ideal solution. >> > > Right now, no attention to Windows development > so I cannot forward anything meaningful. I know > above statement is not targetted on me, still I > feel a few I could have resolved if paid attention to. It's actually not Windows dependent matter at all, it's the same problem-set as in HBQT: How to handle the case when we assign GC collected pointers to low-level structures. How to ensure the object won't be freed by GC until it's used by low level structure? How to make sure it's getting released when it's not used anymore? Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
