Re: [Harbour] Re: hbqt: a couple of questions
BTW what are exactly : hbqt: a couple of questions ? 1) is there some reason for having s_slots and s_events handled by the programmer and not hidden someway ? 2) how can I translate 1:1 from c++ QObject::connect( quit, SIGNAL(clicked()), a, SLOT(quit()) ); to harbour/Qt ... I was translating some C++ sample code in order to do some basic tests and a simple 8 lines c++ code translated in 20 harbour lines including the handling of the s_slots variable Also, I could not translate the connect call - I know owr connect is better but how can I translate ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Very intresting! 2010/4/9 francesco perillo fperi...@gmail.com BTW what are exactly : hbqt: a couple of questions ? 1) is there some reason for having s_slots and s_events handled by the programmer and not hidden someway ? 2) how can I translate 1:1 from c++ QObject::connect( quit, SIGNAL(clicked()), a, SLOT(quit()) ); to harbour/Qt ... I was translating some C++ sample code in order to do some basic tests and a simple 8 lines c++ code translated in 20 harbour lines including the handling of the s_slots variable Also, I could not translate the connect call - I know owr connect is better but how can I translate ? Francesco ___-- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi Pritpal, 1) is there some reason for having s_slots and s_events handled by the programmer and not hidden someway ? Yes, because in Harbour we are calling Qt classes by function calls instead of class/method calls. We cannot call Qt classes directly. Though my explanation may appear a bit tough but this is how Harbour bindings for Qt are implemented. We are calling Qt classes from PRG level and not from C++ level. Is it be possible to add slots and events holder variables to QApplication class? If technically possible, IMO it should be done to clean this part of QT. It wouldn't even be an incompatible change, just convenience, since these two holders are always needed for QT apps. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi Pritpal 1) is there some reason for having s_slots and s_events handled by the programmer and not hidden someway ? Yes, because in Harbour we are calling Qt classes by function calls instead of class/method calls. We cannot call Qt classes directly. Though my explanation may appear a bit tough but this is how Harbour bindings for Qt are implemented. We are calling Qt classes from PRG level and not from C++ level. I understand that we are using Harbour functions to call C++ functions like HB_FUNC( QT_SLOTS_CONNECT ) that call a static function connect_signal that finally does the real connect, for example: if( signal == ( QString ) clicked() ) return object-connect( object, SIGNAL(clicked()), t_slots, SLOT( clicked()), Qt::AutoConnection ); We are passing s_slots from Harbour to connect_signal where it is HBSlots * t_slots... and this is my concern: WHY are you passing s_slots back/forth between Harbour and C++ ? Since from example number 2 slots are used (a Qt program without slots/events is almost useless..., just a basic display perhaps...) WHY don't change hbqt_slots.cpp to include a file-wide static variable s_slots, completely handled by Qt (so no Harbour GC hassle) and then remove harbour level s_slots variables ? I know it is a non compatible change (well, it may become compatible if you check number of parameters in QT_SLOTS_CONNECT) but it frees the programmer from the s_slots burden... There may be only one problem: if Qt may handle multiple slots lists... something I sincerely don't know... but, properly changing QT_SLOTS_CONNECT this may be handled too. Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Is it be possible to add slots and events holder variables to QApplication class? If technically possible, IMO it should be done to clean this part of QT. It wouldn't even be an incompatible change, just convenience, since these two holders are always needed for QT apps. Perhaps not. The reason is, we need to manipulate this mechanism on thread level, which, at this moment, is not mature unfortunately. But I do not want to rob-off this possibility in any way. Moreover, slots can be initiated per class instance basis which is a big productivity boost. In a super class we can initialize it without the intervention of the user and can designate a destructor and as such it will be managed by the class object. Events, however, are different beast, have to be controlled centralized. But still in that case, I cannot imagine how we can attach to QApplication under the scenario it is implemented currently. Perhaps: VAR events // in QApplication instead of: STATIC s_events Former is much cleaner. QApplication class seems to be a requirement for any HBQT app so it seems doable. Anyway just ignore this like most other suggestions from me. For me it's not a problem. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Perhaps: VAR events // in QApplication instead of: STATIC s_events Former is much cleaner. QApplication class seems to be a requirement for any HBQT app so it seems doable. Anyway just ignore this like most other suggestions from me. For me it's not a problem. Or please tell us clearly why this is not possible... I believe Qt is a great framework, a lot more than a framework and your work (hbide for example) shows how powerfull it is. And more, Qt is really documented: web sites, books and a lot of source code available to study on and it is a REAL PLUS for a harbour gui framework But if hbqt deviates too much from standard Qt a lot of docs won't match, code portability from c++ will not be easy ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Is it ok just agree on the list with intent to influence the decision? I agree with Francesco and Viktor. I hope I will use HBQt a lot. []'s Maniero ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi All, I assume you have some framework in mind to achieve what you say. Do you ? If yes, please post the code here for review and if the group agrees, we will follow that pattern. Also keep in mind that it must be backward compatible. I think until we have the basics right, it's not a reasonable goal to set current patterns or API in stone. Unfortunately more and more code is created with current pattern, which makes it just more and more difficult to fix the basic problems in low-level code while keeping higher level code updated (not to mention invisible for us code outside our SVN). This has been exactly the problem I've been trying to shade a light on since many many months. Bazaar is a nice thing, but if someone builds an Eiffel Tower on top of the bazaar, it's just not trivial to swap the foundation without troubling the Tower. All this means that there is less and less chance (= more and more required effort) to ever make f.e. HBQT's memory management right, or to fix centralized slots system, just to name two crucial issues. This in turn means that the original high expectations for HBQT becoming the GUI for Harbour are vanishing. Given the effort put into this and the importance of a GUI in general, this is a pity. It's my two cents. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi Pritpal, This in turn means that the original high expectations for HBQT becoming the GUI for Harbour are vanishing. Given the effort put into this and the importance of a GUI in general, this is a pity. I agree with all your assertions in toto. But the bottom-line is, I am unable to find a solution to coordinate when Qt destroys an object and when Harbour request it to destroy. Unless someone more gifted join this effort, like Istavin tried and offered some constructs, I do not see much progress. Time-and-again I try with a new concept, but at points it fails. The current implementation is the best so far. Easy to say it, but since you probably know the typical cases that need to be covered, so maybe it'd help to start off with a very limited set of wrappers, just to cook the right wrapping methods. For sure you'll need to employ the concept of GC references. Without it, it will never be right. It would also help just by itself, if you could create self-contained examples of the typical construct/destruct/detach/attach situations. This would make it easy for everyone to experiment with it in a swift fashion (without dealing with the huge HBQT libs). Just an idea. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi Pritpal I think that there is some misunderstanding... I'm not a native english speaker so I may be confusing some time... I will try to be more clear i n the future. A bit about me: I was a programmer, up to about year 2000 my income was from programming. No more. I only have one copy of a big application running (started in 1986 in dBase III+) that I ported to Harbour more for a personal pleasure than for a friend request (friend, not client). So my point of view may be a bit different from who uses harbour to earn a living. I want to add that I spent really many nights on hwgui. I wanted to use it for a small program I needed for my own use and found myself involved in its development since I found more and more missing bits... implementing activeX and filling the many missing bits in the browse after months of work I didn't use hwgui as the framework because I still fell is missing something and it misses the most important part: there is NO documentation ! So when I read about hbqt I was curious, when I tried demoqt I become interested and when I tried hbide I become addicted ! So I got a couple of books from the many available on Qt and read them in a few days. There are more than 20 books listed on Amazon ! So my brain started to think that Qt could solve all my need: a multi-platform GUI, well documented, well developed, with lots of goodies inside, with lots of sample code available, tutorials, faq, etc... and most important to be used like an external library, a black-box, something that I should not work on. but nonetheless I offered my help to trace the memory problem (till the comunication stopped) because I feel that Qt and hbqt is the road to go ! Sorry for the long intro but I though it was due. I assume you have some framework in mind to achieve what you say. Do you ? No, I don't have any framework in my mind... Qt is a framework for me. I don't want to use hbxpp or hbqtcommand at the moment... I'd like to use pure Qt. If yes, please post the code here for review and if the group agrees, we will follow that pattern. Also keep in mind that it must be backward compatible. Sorry, Pritpal, I don't have any code since I don't have any framework in mind... or are you referring to the proposal to hide s_slots in the code ? I think it is a bit too early for me to modify your code, I have really basic knowledge about everything works... Infact I proposed to put s_slots in c++ code and you said that - if I understood correctly - this is not possible since multitasking applications may have different s_slots lists... Viktor proposed to hide s_slots as a VAR in QApplication (actually in TQApplication.prg) but Qt docs says: For any GUI application using Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any given I never used MT with harbour so I can't say more on the subject... From what I understood from your message it seems that s_events is unique and so it may be hidden inside harbour class QApplication. But hiding in a VAR means you have this GC variable passed back and forth in the calls... why not keep it in C++ code ? Totally handled by Qt ? But if you expect this overhaul from me, I am sorry, I did my level best to reach to this level and I know how much it is difficult to establish code flow to acheive final results something like hbIDE. Alternatively, you can start parallel development on this segment and send the code here. I am sure someone more conversant with C++ will join this effort. For now I am only concentrated on hbIDE. We all say thank you for your job, we are almost all programmers here and we know and respect the work you put into hbqt and hbide. About your idea of concentrating on hbIDE... I respect it but permit me to not agree with you it seems to me like crossing a river during a japanese tv game show... one of the stones may be fake and the runner drop into the water... To reach your level of knowledge it will take me more than a month, too much to catch up, and I still miss all the harbour internals ! ... so my proposal is that you shortly document in some way how all the stuff is supposed to run, from a qB := QPushButton():new() to the different cases of object destruction ( qB:destroy(), qB := NIL, qB out of scope ). With this overview we have this benefits: - everybody knows how it is supposed to work - everybody can verify if it really works this way and propose changes, for example Viktor that has a more in-depth knowledge of harbour GC internals may spot some missing or inconsistent bits.. What do you think ? Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
This would make it easy for everyone to experiment with it in a swift fashion (without dealing with the huge HBQT libs). Just an idea. It is not easy to just start from small code. Even to execute few lines, you need the full framework working. The only change will be couple of classes to experiment instead of 302 we have at this time. And this does not make any difference either. In my opinion in makes a huge difference. Currently any experimenting pass requires a huge amount of time (change generator, build generator, run generator, rebuild all HBQT libs), and finding out the exact root of any problem takes a huge amount of time as well, simple because of the amount of code involved. I know that because I tried it in the past. The point to emphasis is: if I write from scratch, I have to visualize the ways how the other way is, which after an year of heavy dwelling into exiting code fragmenents, I find difficult if not impossible. This type of approach is more suitable to one who starts afresh, has not any affinity to existing code. Whatever I will do will be influenced by existing protocols. I may not be able to find another solution at all, and at the end, new code will look a shadow of the original one. It is human nature and I am not the exception. Maybe you're right, but my impression is that you never really dwelled into the details we're currently discussing. At least not before implementing the whole heavy wrapper infrastructure. Hence my suggestion to step back and look at the thing, now that you know the perspective and the problems to look for. [ It's also worth reading Przemek's last e-mail regarding the matter, as I'm almost sure there are actual answers hidden there. ] The biggest bug at present is object destructions and this part will be the last one if we develop another approach. So we will come to know about whether we could resolve this issue or not ? And what If we could not. I think you just can't state that. Object destruction to me looks like a symptom, not the root cause. IOW to make proper object destruction, you need more precise tracking of what to destruct and when, you also need to understand when and where things are _constructed_. For that you need additional logic at all involved points. (f.e. when assigning one object to another object var). All other components are working perfectly all right so far. In a nut-shell: someone with new thinking process has to step-in. This puts HBQT in a risky position. Looks like nobody is interested to touch current large and heavy code. If you have Przemek in mind (who surely could help), even to get his help, it would be much better to start off with something simple and up to the point. I think there is not much chance to expect from him to create a pret-a-porter commit for current huge codebase. On a small example we could all understand the problems, find the principal solution and implement that solution on actual HBQT code. It won't be a one time commit. At the same time you should stop masking found problems by workarounds, and instead mark all these problem parts with TOFIX markers with description of the problem. (ideally this should be done for all past problems already masked) Another thing which may help you move forward from current position is to install Linux (Ubuntu f.e.) in a VirtualBox (free) VM and experiment with HBQT and HBIDE. You will have the full power of valgrind, plus it's fun to check other platforms for real. It helped me a lot with hbmk2. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Fisrt, ^C Francesco words and ^V as my words :-) I really hope HBQt comes to be the most important non-core Harbour component. My decision about return to xBase programming was helped by HBQt introducing, but today I couldn't put HBQt in my production code. IMHO HBQt needed an overhauling to reach Harbour quality level. HbIDE is a tool which I want work in future and I will post some suggestions about it, but I think if HBQt have problems, HbIDE always will have problem. Pritpal, I am pretty sure about difficulties to improve HBQt and about your good work until now. I think that all of us are putting our trust in you to lift HBQt to a place where it deserves be. I agree with Viktor when he says today HBQt is a risky component to use. And sorry if my english be confusing. []'s Maniero ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbqt: a couple of questions
Hi Why clicked() is not a codeblock? []'s Maniero 2010/4/8 Pritpal Bedi bediprit...@hotmail.com francesco perillo wrote: So I started to ask myself the necessity to have s_slots and s_events (whatever you call them) defined and handled by the programmer. And (I understand that QT_SLOTS_CONNECT has a more powerfull syntax since it doesn't require you to create SLOT handlers in objects) was thinking about the correct way to translate the line QObject::connect( quit, SIGNAL(clicked()), a, SLOT(quit()) ); in harbour/Qt ... Harbour's signal/slot handelling is superior then Qt itself. We can attach a codeblock with it and in the calling code we can update n number of objects visible into that class/function. Whereas in Qt it is one-to-one mechanism. The other way around is also there in Qt but that is little cumbersome. So, why do you want to translate the QObject::connect( quit, SIGNAL(clicked()), a, SLOT(quit()) ); in another way ? - enjoy hbIDEing... Pritpal Bedi http://hbide.vouch.info/ -- View this message in context: http://n2.nabble.com/hbqt-a-couple-of-questions-tp4874292p4874392.html Sent from the harbour-devel mailing list archive at Nabble.com. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
