Re: [Harbour] Re: Can be Harbour have tool like Glade working with it...?
my incomplete document about hbide http://docs.google.com/View?id=dhmtv9fs_235db6hz754 2010/1/27 Jerry Finuliar jerryfinul...@operamail.com: Hi, If its not asking too much. Can you provide a small demo with tutorial to do this? Even a video will do. Thanks, Jerry - Original Message - From: Pritpal Bedi bediprit...@hotmail.com To: harbour@harbour-project.org Subject: [Harbour] Re: Can be Harbour have tool like Glade working with it...? Date: Tue, 26 Jan 2010 13:10:50 -0800 (PST) marco bra wrote: I'm looking for some cross platform tool to quickly design user interface and then refine event methods and then compile it with harbour Something similar to this http://glade.gnome.org/ ( Glade + Python ) http://www.linuxjournal.com/article/7421 Can be a hbide future extension...? Why should we concentrate on GTK when all our future goals are planned for Qt ? I have on my TODO list, integration of Qt Creator through Hbp*() classes. Qt Creator generates a .ui file and hbIDE is already taking advantage of .ui files. We just need to polish this HbpQtUI() class to embed events, though practically you can do it right now. - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/Can-be-Harbour-have-tool-like-Glade-working-with-it-tp4463143p4463319.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 -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Viktor , Pritpal I think you have to consider that many people , including us, Bruno and Carozo are using HBQT to develope another library. Your disagreements can ruin a lot of work made in lasts months HBQT , HBIDE and HBXBP could become one of major GOALS of harbour community , without underestimate , the great work of all harbour community. I begg you all , to reconsider these changes , taking this in mind. I think that at least , HBQT must remain in Contrib, and with full support of Harbour Community as an oficial Graphic Library . I know that is opensource software and I can't clame to anybody But think about this Best Regards Bruno 2010/1/26 Viktor Szakáts harbour...@syenar.hu Hi Pritpal, I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. Upto you Viktor. You can delete these contributions from the SVN. Yes, it probably is a good idea to move them to separate project(s). The reason is that they grow in unbelievable rate, but even root problems are not solved and not even being dealt with (= ignored), and this I believe will take an unnecessarily huge amount of fixing work in a lot of existing code on all levels. In my view we should concentrate on the basics first and then build the upper levels on the this base. Plus it's also good if basic things agreed upon in the past are more or adhered to, or at least remembered. IMO we're at the point when moving HBQT, HBXBP and HBIDE to their own repositories would be of a benefit for all projects, without losing too much. Anyway I don't care is pretty much the opposite of how things are supposed to be done here in Harbour, particularly when it comes to basic system design methods. If you ignore these, the quality of these components will hardly be equal to that of Harbour. And if we want to keep quality image of Harbour intact (which is the result of 10 years of development in this spirit), all components should adhere to this. Please consider these, even if the heat of quick development is stronger these days. It's much harder to fix design problems afterwards. Brgds, Viktor ___ 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
Re: [Harbour] Re: hbpqtui class
Hi! Even today I have my own implementation of Qt for Harbour and I want to leave soon to use HBQT... I work with Pascal language in the Windows environment and I have an dream: develop an HCL like VCL using HBQT (even if it is for own use) Because this I think (me too) that at least , HBQT must remain in Contrib, and with full support of Harbour Community is the best choice. My 2 cents, Vailton Renato ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
I invite viktor and pritpal find the way of cooperation same way that have made in hbmk same modification for having a better hbide Harbour will help Pritpal find a better quality Pritpal can help harbour to have a GUI Please no division with a division we lost either part lost enforced by differences without split 2010/1/27 Viktor Szakáts harbour...@syenar.hu: Hi Pritpal, I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. Upto you Viktor. You can delete these contributions from the SVN. Yes, it probably is a good idea to move them to separate project(s). The reason is that they grow in unbelievable rate, but even root problems are not solved and not even being dealt with (= ignored), and this I believe will take an unnecessarily huge amount of fixing work in a lot of existing code on all levels. In my view we should concentrate on the basics first and then build the upper levels on the this base. Plus it's also good if basic things agreed upon in the past are more or adhered to, or at least remembered. IMO we're at the point when moving HBQT, HBXBP and HBIDE to their own repositories would be of a benefit for all projects, without losing too much. Anyway I don't care is pretty much the opposite of how things are supposed to be done here in Harbour, particularly when it comes to basic system design methods. If you ignore these, the quality of these components will hardly be equal to that of Harbour. And if we want to keep quality image of Harbour intact (which is the result of 10 years of development in this spirit), all components should adhere to this. Please consider these, even if the heat of quick development is stronger these days. It's much harder to fix design problems afterwards. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Hi, I think you have to consider that many people , including us, Bruno and Carozo are using HBQT to develope another library. Your disagreements can ruin a lot of work made in lasts months HBQT , HBIDE and HBXBP could become one of major GOALS of harbour community , without underestimate , the great work of all harbour community. I begg you all , to reconsider these changes , taking this in mind. I think that at least , HBQT must remain in Contrib, and with full support of Harbour Community as an oficial Graphic Library . I know that is opensource software and I can't clame to anybody All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) of a project (or library) won't make it less useful / sexy / used / developed or less desirable. It stays the same project, with same users and volunteer contributors. In fact, in separate repositories it can even flourish better, since there is no higher level or quality rules to adhere to, nor getting an agreement from other project maintainers. This give full freedom in the hands of developers. It also makes it that everyone can much better concentrate on the area he is interested in. It also makes things to scale much better. There are several good examples for this, in no particular order: HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't be fit to Harbour SVN, because our stricter rules or portability requirements. Yet they are useful, users keep using them, developers keep developing them. Sometimes even Harbour developers are participants in them. Being part of Harbour SVN is partly a deal: It has some benefits, f.e. you get support and attention from core developers (f.e. i've spent several weeks on HBQT altogether), you get quality control, a build infrastructure, you have free packaging a release service, more attention, etc. Most of these require a significant amount of time. So, in return IMO we rightfully expect for things to be more or less inline with basic project goals and rules and agreements. It also seems a natural thing that components like _Harbour core_ need much stricter quality control than upper level ones, since everything is based on them, and this is the key to the stability of the whole platform. While I personally believe that all components should have equally good quality to form a good quality end result, practice shows that this is sometimes not achievable in practice, due to limited resource or not enough interest in this area, even sometimes the time consumed would not be justified or even noticed at the end. I can accept that. At the end it comes out as: Is this deal worthwhile for all parties? If it's a time wasting struggle for quality on one end, and an uncomfortable feeling on the other end, what is the point? Users won't benefit either, since developers are wasting time instead of developing. The other option is to lower quality needs, not think about future, of redundancy of any form, priorities, or leaks, allow GPFs and allow design decisions which will have such a high cost in the future, that at that point nobody will be able to deal with it anymore. See HBWHAT32 for an example for that. For a solution IMO we should seriously consider to split Harbour into more parts, it has become huge and if this continues it will become unmanageable and rather sooner or later no quality can be guaranteed for some of its parts. BTW, HBQT related parts now account for nearly HALF of the size of all contribs. This is large. I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. I'm glad to hear opinions on how to solve these in other ways. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
On Jan 27, 2010, at 10:08 AM, Viktor Szakáts wrote: Hi, I think you have to consider that many people , including us, Bruno and Carozo are using HBQT to develope another library. Your disagreements can ruin a lot of work made in lasts months HBQT , HBIDE and HBXBP could become one of major GOALS of harbour community , without underestimate , the great work of all harbour community. I begg you all , to reconsider these changes , taking this in mind. I think that at least , HBQT must remain in Contrib, and with full support of Harbour Community as an oficial Graphic Library . I know that is opensource software and I can't clame to anybody All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) of a project (or library) won't make it less useful / sexy / used / developed or less desirable. It stays the same project, with same users and volunteer contributors. In fact, in separate repositories it can even flourish better, since there is no higher level or quality rules to adhere to, nor getting an agreement from other project maintainers. This give full freedom in the hands of developers. It also makes it that everyone can much better concentrate on the area he is interested in. It also makes things to scale much better. There are several good examples for this, in no particular order: HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't be fit to Harbour SVN, because our stricter rules or portability requirements. Yet they are useful, users keep using them, developers keep developing them. Sometimes even Harbour developers are participants in them. Being part of Harbour SVN is partly a deal: It has some benefits, f.e. you get support and attention from core developers (f.e. i've spent several weeks on HBQT altogether), you get quality control, a build infrastructure, you have free packaging a release service, more attention, etc. Most of these require a significant amount of time. So, in return IMO we rightfully expect for things to be more or less inline with basic project goals and rules and agreements. It also seems a natural thing that components like _Harbour core_ need much stricter quality control than upper level ones, since everything is based on them, and this is the key to the stability of the whole platform. While I personally believe that all components should have equally good quality to form a good quality end result, practice shows that this is sometimes not achievable in practice, due to limited resource or not enough interest in this area, even sometimes the time consumed would not be justified or even noticed at the end. I can accept that. At the end it comes out as: Is this deal worthwhile for all parties? If it's a time wasting struggle for quality on one end, and an uncomfortable feeling on the other end, what is the point? Users won't benefit either, since developers are wasting time instead of developing. The other option is to lower quality needs, not think about future, of redundancy of any form, priorities, or leaks, allow GPFs and allow design decisions which will have such a high cost in the future, that at that point nobody will be able to deal with it anymore. See HBWHAT32 for an example for that. For a solution IMO we should seriously consider to split Harbour into more parts, it has become huge and if this continues it will become unmanageable and rather sooner or later no quality can be guaranteed for some of its parts. BTW, HBQT related parts now account for nearly HALF of the size of all contribs. This is large. I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. I'm glad to hear opinions on how to solve these in other ways. Hello Viktor, I totally agree with your thinking. In fact I was restraining myself on moving wxHarbour to Harbour contrib for the very same reasons. best regards to all, Teo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
On Wed, Jan 27, 2010 at 5:08 PM, Viktor Szakáts harbour...@syenar.hu wrote: I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. I'm glad to hear opinions on how to solve these in other ways. IMHO HBQT+HBXBP+HBIDE need to be outlined and cleaned and should go into a separate project with a separate mailing list. best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. A GUI Framework without compiler leads it to death because lack of support. If you do that then no new users will come here. Vanity is not a good advisor. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13724] trunk/harbour
Revision: 13724 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13724view=rev Author: vouchcac Date: 2010-01-27 17:09:12 + (Wed, 27 Jan 2010) Log Message: --- 2010-01-27 08:58 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/idemisc.prg * contrib/hbide/ideprojmanager.prg * contrib/hbide/resources/projectproperties.ui + Implemented loading project from .hbp. Look for the button on top of Properties dialog. Please note that .hbp file is loaded with its whole contentents and then is sectionized as per .hbi protocol. So, the disadvantage is you loose the free-format implementation of .hbp. It has to be discovered how can we cover this aspect. Be careful when building the project as existing .hbp will be overwritten if you choose the Project Location of the project pointing to same folder where .hbp resides. Other than loosing -skip protocol of .hbp, I am sure we are loosing nothing else, please test. + Implemention Close Project and Remove Project options which can be invoked from context menu of project node. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/idemisc.prg trunk/harbour/contrib/hbide/ideprojmanager.prg trunk/harbour/contrib/hbide/resources/projectproperties.ui This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Angel Pais wrote: A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. You are right Angel. Harbour must have a multi-platform GUI support as an integral (core) component to succeed. IMHO There is some things to consider to achieve that: 1. Basic core GUI classes must be defined as 'Harbour own' classes, then, do wrappers to connect it to the GUI framework selected to do this development. Expose to users (Harbour programemrs) the QT, GTK (or whatever) API should be not a solution. As I've pointed in other posts, classes defined by Clipper 5.3 could be a good starting point. Another big advantage of this approach is that Clipper console applications could run (with minimal modifications) on NATIVE GUI MODE for ALL OSs supported by Harbour. IMHO this point is EXTREMELY IMPORTANT, since it will turn Harbour in the natural succesor to Clipper for all OSs without a doubt. 2. The GUI framework behind this scheme must be choosen carefully and afetr a deep evaluation. IMHO, QT is not a good choice. Compared with (ie) GTK, it is bigger, slower and more difficult. I don't want to start a flame with this, I understand that a lot of people think different. My opinions are based on my own tests only. 3. In the case that it be possible, the extension of these features to give to current and future Harbour users, some kind of native support to create web-enabled applications, should be considered. Desktop applications will not dissapear right now, but its use will decrease steadily in the next years, reducing the user base of products like Harbour, a lot. Regards, Roberto. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
On Wed, Jan 27, 2010 at 5:55 PM, Angel Pais amigo...@adinet.com.uy wrote: A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. A GUI Framework without compiler leads it to death because lack of support. If you do that then no new users will come here. I'm not saying Harbour doesn't need a GUI. There are many developers that create GUI apps with Harbour using FiveWin, HWGUI, minigui, xHGtk, ... best regards, Lorenzo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
I'm glad to hear opinions on how to solve these in other ways. Here is the only part of messages where agree Think for a developer how much is difficult give different and incompatible version, different installer MINIGUI have included harbour inside his distribution and imo this is not good way Viktor itself speaking with roberto have encontred same ot this (different version) ecc cause problem also if resolve other can be a solution Define rule of stricter quality control so is easy undestrand with rule is not respected hbqt + hbxbp+ hbide is a good part for harbour and i not undestrand why remove Development of hbide have cause same problem but also intesting produtc What Think Przemyslaw ? -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
+1 Please maitain one project 2010/1/27 Angel Pais amigo...@adinet.com.uy: A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. A GUI Framework without compiler leads it to death because lack of support. If you do that then no new users will come here. Vanity is not a good advisor. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
Angel Pais wrote: A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. A GUI Framework without compiler leads it to death because lack of support. If you do that then no new users will come here. Vanity is not a good advisor. very true. when when Pritpal said 'I don't care' I understood him saying 'I can't care', responding to Viktor's fears that in the future when somebody else will decide to build on top of hbqt/hbxbp they will run into difficulties. So Prinpal responded that at the _moment_ while hammering out hbqt/hbxbp/hbide (which still needs more regression, and getting there by the day) he _can't care_ for the unseen future. -- View this message in context: http://n2.nabble.com/hbpqtui-class-tp4464679p4468592.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
Re: Re: [Harbour] hbpqtui class
All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) of a project (or library) won't make it less useful / sexy / used / developed or less desirable. It stays the same project, with same users and volunteer contributors. This is true, but... In fact, in separate repositories it can even flourish better, since there is no higher level or quality rules to adhere to, nor getting an agreement from other project maintainers. This give full freedom in the hands of developers. It also makes it that everyone can much better concentrate on the area he is interested in. Yes, but i was thinking that HBQT would become the official multiplatform GUI for Harbour It also makes things to scale much better. There are several good examples for this, in no particular order: HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't be fit to Harbour SVN, because our stricter rules or portability requirements. Yet they are useful, users keep using them, developers keep developing them. Sometimes even Harbour developers are participants in them. Hum, the freedom from stricter rules results in a bad integration with the main project. I come from the HwGUI experience, where only the effective work of Przemek allows to tune and clean many dirty or dubbed code. When i begun my interest in HwGUI, the Harbour build was lost because the active developers was interested mainly in xHarbour implementation. Just you, Viktor, signaled me the thing and i discouvered the great advantages of Harbour vs. xHarbour. Being part of Harbour SVN is partly a deal: It has some benefits, f.e. you get support and attention from core developers (f.e. i've spent several weeks on HBQT altogether), you get quality control, a build infrastructure, you have free packaging a release service, more attention, etc. Most of these require a significant amount of time. So, in return IMO we rightfully expect for things to be more or less inline with basic project goals and rules and agreements. It also seems a natural thing that components like _Harbour core_ need much stricter quality control than upper level ones, since everything is based on them, and this is the key to the stability of the whole platform. While I personally believe that all components should have equally good quality to form a good quality end result, practice shows that this is sometimes not achievable in practice, due to limited resource or not enough interest in this area, even sometimes the time consumed would not be justified or even noticed at the end. I can accept that. I agree with the standard good quality for all components (contribs included) of the project, at the cost of a slower but effective development. At the end it comes out as: Is this deal worthwhile for all parties? If it's a time wasting struggle for quality on one end, and an uncomfortable feeling on the other end, what is the point? Users won't benefit either, since developers are wasting time instead of developing. The other option is to lower quality needs, not think about future, of redundancy of any form, priorities, or leaks, allow GPFs and allow design decisions which will have such a high cost in the future, that at that point nobody will be able to deal with it anymore. See HBWHAT32 for an example for that. For a solution IMO we should seriously consider to split Harbour into more parts, it has become huge and if this continues it will become unmanageable and rather sooner or later no quality can be guaranteed for some of its parts. BTW, HBQT related parts now account for nearly HALF of the size of all contribs. This is large. I don't want to think about the lack of collaboration between the main project and the HBQT... Just think to hbmk2 implementations to adhere to hbIDE needs... I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. Maybe HBQT by itself, if we stop to think to it as official GUI, but hbIDE project is very linked to main Harbour and HBQT, so a self growing and developing of HBQT could break the hbIDE work. I'm glad to hear opinions on how to solve these in other ways. No opinions, but the feel that a contrib part of Harbour project MUST obey to general rules and follow the general architecture of the main project. So, IMHO, Pritpal could consider the opinion of Viktor as effective, mainly if thought to medium-large time, and i hope he will return to strict collaboration as we saw in the last days. Just my 1.5 cents... Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour -- View this message in context: http://old.nabble.com/hbpqtui-class-tp27332809p27343957.html Sent from the Harbour - Dev mailing list archive at Nabble.com. ___ Harbour
Re: Re: [Harbour] hbpqtui class
+1 HBQT library, the oficial Harbour wrapper to accessing GUI multiplatform API CdQ On Wed, Jan 27, 2010 at 2:50 PM, Maurizio la Cecilia m.laceci...@gmail.comwrote: All users should see that the URL (f.e.: sf.net/harbour vs. sf.net/hbqt) of a project (or library) won't make it less useful / sexy / used / developed or less desirable. It stays the same project, with same users and volunteer contributors. This is true, but... In fact, in separate repositories it can even flourish better, since there is no higher level or quality rules to adhere to, nor getting an agreement from other project maintainers. This give full freedom in the hands of developers. It also makes it that everyone can much better concentrate on the area he is interested in. Yes, but i was thinking that HBQT would become the official multiplatform GUI for Harbour It also makes things to scale much better. There are several good examples for this, in no particular order: HWGUI, MINIGUI, WXHARBOUR, LETODB, XHGTK. Some of these wouldn't be fit to Harbour SVN, because our stricter rules or portability requirements. Yet they are useful, users keep using them, developers keep developing them. Sometimes even Harbour developers are participants in them. Hum, the freedom from stricter rules results in a bad integration with the main project. I come from the HwGUI experience, where only the effective work of Przemek allows to tune and clean many dirty or dubbed code. When i begun my interest in HwGUI, the Harbour build was lost because the active developers was interested mainly in xHarbour implementation. Just you, Viktor, signaled me the thing and i discouvered the great advantages of Harbour vs. xHarbour. Being part of Harbour SVN is partly a deal: It has some benefits, f.e. you get support and attention from core developers (f.e. i've spent several weeks on HBQT altogether), you get quality control, a build infrastructure, you have free packaging a release service, more attention, etc. Most of these require a significant amount of time. So, in return IMO we rightfully expect for things to be more or less inline with basic project goals and rules and agreements. It also seems a natural thing that components like _Harbour core_ need much stricter quality control than upper level ones, since everything is based on them, and this is the key to the stability of the whole platform. While I personally believe that all components should have equally good quality to form a good quality end result, practice shows that this is sometimes not achievable in practice, due to limited resource or not enough interest in this area, even sometimes the time consumed would not be justified or even noticed at the end. I can accept that. I agree with the standard good quality for all components (contribs included) of the project, at the cost of a slower but effective development. At the end it comes out as: Is this deal worthwhile for all parties? If it's a time wasting struggle for quality on one end, and an uncomfortable feeling on the other end, what is the point? Users won't benefit either, since developers are wasting time instead of developing. The other option is to lower quality needs, not think about future, of redundancy of any form, priorities, or leaks, allow GPFs and allow design decisions which will have such a high cost in the future, that at that point nobody will be able to deal with it anymore. See HBWHAT32 for an example for that. For a solution IMO we should seriously consider to split Harbour into more parts, it has become huge and if this continues it will become unmanageable and rather sooner or later no quality can be guaranteed for some of its parts. BTW, HBQT related parts now account for nearly HALF of the size of all contribs. This is large. I don't want to think about the lack of collaboration between the main project and the HBQT... Just think to hbmk2 implementations to adhere to hbIDE needs... I also think this community did it's job to help bring HBQT + parts to a nice, usable level now, and it can perfectly stand on its own. Maybe HBQT by itself, if we stop to think to it as official GUI, but hbIDE project is very linked to main Harbour and HBQT, so a self growing and developing of HBQT could break the hbIDE work. I'm glad to hear opinions on how to solve these in other ways. No opinions, but the feel that a contrib part of Harbour project MUST obey to general rules and follow the general architecture of the main project. So, IMHO, Pritpal could consider the opinion of Viktor as effective, mainly if thought to medium-large time, and i hope he will return to strict collaboration as we saw in the last days. Just my 1.5 cents... Maurizio ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour --
Re: [Harbour] Re: hbpqtui class
A compiler without a GUI Framework leads it to nitche apps: Servers, console and cgi apps. A GUI Framework without compiler leads it to death because lack of support. If you do that then no new users will come here. Vanity is not a good advisor. Calling it vanity when it doesn't serve your short-term purpose, but welcoming it when it produces a good quality product doesn't give too much to this topic. And I'm certainly not interested in going personal. We can agree that GUI is generally a good thing, without going into deeper analysis. Nothing tells though that the GUI needs to reside in the same physical repository, nor does anything tells, that core developers have to deal with it, too. Also nothing tells, that only one GUI should exist for one base system. Looking around the compiler market, I can't see similar compilers which have an integrated, built-in, selected GUI as part of core. Of course also nothing tells that Harbour can't have one core quality GUI that comes with it automatically while allowing also other options. And if you remember the discussions from the beginning, and seeing the amount of care from my side f.e., you could see that no so secretly I believed that HBQT could have become this selected GUI for Harbour. But, such selected GUI should be of core quality. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Pripal is going a Huge works so same reply can be read also as Please help me in same part when i can'have time or expertise 2010/1/27 AbeB abe.b...@att.net: when when Pritpal said 'I don't care' I understood him saying 'I can't care', responding to Viktor's fears that in the future when somebody else will decide to build on top of hbqt/hbxbp they will run into difficulties. So Prinpal responded that at the _moment_ while hammering out hbqt/hbxbp/hbide (which still needs more regression, and getting there by the day) he _can't care_ for the unseen future. -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
I agree 110% about core quality, but some desitions should be made by more than one person and with the right wording and you where mean in your answer to Pritpal. As you've seen there are many visions about the roadmap. This is not a personal attack in any way. We're in a group, so we must treat each other with respect. And yes, I agree with your original post about sepàrating hbpParts from xbpParts. As almost allways your vision of the big picture is right. And this: Calling it vanity when it doesn't serve your short-term purpose, but welcoming it when it produces a good quality product doesn't give too much to this topic. And I'm certainly not interested in going personal. was absolutely out of context and/or order. Brgrds Angel ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] decimal number in achoice causes error
proc main
mary := {;
11 ,;
22 ,;
33 ,;
44 ,;
55 ,;
66 ,;
77 ,;
88 ,;
99 ,;
aa ,;
bb ,;
cc ,;
}
//scroll down all the way up all the way
ACHOICE( 5,10, 12.5 , 60 , mary ,,, 0 ) // 12.5
//Error BASE/1132 Bound error: array access
Thanks
abe
--
View this message in context:
http://n2.nabble.com/decimal-number-in-achoice-causes-error-tp4469038p4469038.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
Re: [Harbour] Re: hbpqtui class
Hi Roberto I agree we need gui today and in long term web why a common class like xbase++ part (XHB also without hb extension) can't be a solution? Today this class is wrapped to hbQT and Tomorrow to gtk,minigui or fivewin we also implement a set syntax to that can reference this class instead of internal gui replacement syntax of gui This idea came from vianemo project not jet started 2010/1/27 Roberto Lopez rober...@gmail.com: Angel Pais wrote: 1. Basic core GUI classes must be defined as 'Harbour own' classes, then, do wrappers to connect it to the GUI framework selected to do this development. Expose to users (Harbour programemrs) the QT, GTK (or whatever) API should be not a solution. 3. In the case that it be possible, the extension of these features to give to current and future Harbour users, some kind of native support to create web-enabled applications, should be considered. Roberto. ___ -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] decimal number in achoice causes error
On 27/01/10 18:54, AbeB wrote:
proc main
mary := {;
11 ,;
22 ,;
33 ,;
44 ,;
55 ,;
66 ,;
77 ,;
88 ,;
99 ,;
aa ,;
bb ,;
cc ,;
}
//scroll down all the way up all the way
ACHOICE( 5,10, 12.5 , 60 , mary ,,, 0 ) // 12.5
//Error BASE/1132 Bound error: array access
Thanks
abe
Sounds correct - you must use integer.
___
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] decimal number in achoice causes error
I understand that, but it should be fixed in achoice -- View this message in context: http://n2.nabble.com/decimal-number-in-achoice-causes-error-tp4469038p4469331.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
Re: [Harbour] Harbour 2.0.0 stats after one month
Besides actively participating on Harbour dev... Thank you for your kind words, Viktor! are you welcome You have also good Xbase++ experiences Can you help us in refiniing hbxbp/hbide? Most probably not, Massimo, I'm sorry. I'm one of those submarine guys in the harbour, just popping up from time to time (and I hope that's okay!). I'm not doing any xbase programming these days, but I try to keep in sync with the developments within the Harbour project - and I can only express my deepest respect for what you guys have achieved so far... Cheers, Martin ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] decimal number in achoice causes error
In express (a xbase++ guy) is righe indicate decimal value in coordinate 1= one character 0,5 =a half characher 2010/1/27 AbeB abe.b...@att.net: I understand that, but it should be fixed in achoice -- View this message in context: http://n2.nabble.com/decimal-number-in-achoice-causes-error-tp4469038p4469331.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 -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Harbour 2.0.0 stats after one month
Chen Kedem wrote: Martin wrote: You guys may want to update Harbour's entry on freshmeat, on the FSF software list etc I wrote a few times in the past about this: http://lists.harbour-project.org/pipermail/harbour/2009-March/016556.html But no one had step in to update all these feeds. I agree. I had a quick look at them, but I did not feel competent enough to enter the correct information (otherwise I would have just done it!) Cheers, -Martin ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] hbpqtui class
Hi +1 HBQT library, the oficial Harbour wrapper to accessing GUI multiplatform API The progress of hbqt,hbIde,hbxbp is amazing. IMHO because of excelent cooperation of Pritpal,Victor,Przemysław and others, which are all experts. I am curently using minigui extended for my applications, which is perfect GUI, but it's only win32 oriented. I tried GTK (which is in transition to 3.0, and will get clutter as animation appi). I also tried wxWidgets. IMHO Qt is most mature GUI toolkit (best documentation, best ide, bigest comunity...). IMHO the future is in web UI (embeded browser, be it GECKO or WEBKIT) with javascritpt for scripting (in next version of Qt, there wil be QML). My dream platform is: Harbour+Qt+QtWebkit+OpenOffice (ODF documents). So please don't break the team apart, because of single statement. (probably missanderstanding). BRGS franček Bruno Luciani wrote: Viktor , Pritpal I think you have to consider that many people , including us, Bruno and Carozo are using HBQT to develope another library. -- View this message in context: http://old.nabble.com/hbpqtui-class-tp27332809p27346201.html Sent from the Harbour - Dev 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
Re: [Harbour] Harbour 2.0.0 stats after one month
submarine guys in the harbour is a very good definition compliment A high number of user , give very good words about harbour here I invite spread good Harbour opinion also out of this mailing list Harbour is modern and reliable solution for busines application based on database Imo follow good stat is due to of Large spectre of solution (dbf,sql,client server) (console or gui) (command line,visual version) (Single thread or multi thread) Hi hope that we maintain one project with hbqt but this is another thread 2010/1/27 Martin Vogel m-vo...@gmx.net: Besides actively participating on Harbour dev... are you welcome You have also good Xbase++ experiences Can you help us in refiniing hbxbp/hbide? Most probably not, Massimo, I'm sorry. I'm one of those submarine guys in the harbour, just popping up from time to time (and I hope that's okay!). I'm not doing any xbase programming these days, but I try to keep in sync with the developments within the Harbour project - and I can only express my deepest respect for what you guys have achieved so far... Cheers, Martin -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: Re: [Harbour] hbpqtui class
+3 franček have write what i think better than myself I can add only: qt is large because is very complete 2010/1/27 Franček Prijatelj francek.prijat...@siol.net: Hi +1 HBQT library, the oficial Harbour wrapper to accessing GUI multiplatform API The progress of hbqt,hbIde,hbxbp is amazing. IMHO because of excelent cooperation of Pritpal,Victor,Przemysław and others, which are all experts. I am curently using minigui extended for my applications, which is perfect GUI, but it's only win32 oriented. I tried GTK (which is in transition to 3.0, and will get clutter as animation appi). I also tried wxWidgets. IMHO Qt is most mature GUI toolkit (best documentation, best ide, bigest comunity...). IMHO the future is in web UI (embeded browser, be it GECKO or WEBKIT) with javascritpt for scripting (in next version of Qt, there wil be QML). My dream platform is: Harbour+Qt+QtWebkit+OpenOffice (ODF documents). So please don't break the team apart, because of single statement. (probably missanderstanding). BRGS franček -- Massimo Belgrano ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Massimo Belgrano escribió: Hi Roberto I agree we need gui today and in long term web why a common class like xbase++ part (XHB also without hb extension) can't be a solution? I only say that could be more convenient to establish a first modest goal for a basic, compact, multi-platform GUI bundled with Harbour and working out of the box. This way an user could download Harbour binaries for Windows, Linux, OS/2 or Mac and have native/basic GUI support for all those OSs. Being the first target a small set of GUI classes, the project could be working in the term of weeks (or months) and not years. It could be expanded in all imaginable ways (even xbase++ parts) in future Harbour versions. Regards, Roberto. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Qt* - A Mission Statement
Hello All, So, I think I stand a point to clarify what happened around in the last 21 hours. If you take otherwise please skip the message blow. This all started almost one year ago ( 10 months 10 days to be exact ) when someone floated the idea of having a multi-platform GUI in Harbour core and which, if proved to be the effective implementation, will be officially declared Harbour GUI framework. Then list looked for which GUI base system we were to adopt. Quicky arrived the solution that QT is the _cleanest_ of all implementations and we should go in this direction. I read some basic documentation of Qt and got convinced that this is achievable. The only hitch was how to start. Someone readily made available the base skeltons. I did some experiments with those skeletons and realized some results. The _idea_ fascinated me deeply and I confirmed to the list that I am ready to take this challenge. List approved it, decided on the name-space, repository location, and rest is the history. Everybody moved in this direction, thank you. The whole concept has barely born ( 9 months womb ) and we have _planned_ to re-habilitate it in some alien world, without considering the chances of its survival. I cannot imagine how cruel can we. All those 10m-10days I have lived into this project, day or night, office or home, awake or asleep, without any expectation or consideration, without any call for my personal needs, but simply with an urge of _creativity_ and a feeling that I must _return to the language_ which has given me my bread_and_butter all these years. I took the responsibility [ not that you forced ] to ease out the modern-day pressure of GUI demands on Harbour users and to provide a strong framework over which we could lay our futures. I do not know how much I have been successful, you are the better judge, but I am satisfied about the fact that the mission I had chosen, I sincerly worked hard to achieve. Today I am feeling I am much relieved of such, self-imposed, responsibility. I can feel I have the time to _stand and stare_. Did you ever thought that this action will send a strong message to the world that Harbour refrains from GUI, _please_ do not step-in. I am aware, and have ever followed the design goals of the project, and am committed not to over-step it in any way. But to be treated like this, without understanding the content of my message, just... Below is the text of messages sent on the list, in the context of my above emotions, for easy grasp. Bottom line: I will try to upload to _Harbour SVN_ whatever I could implement in Qt based gtqtc, hbQT, hbXBP and hbIDE twice a day, but if I could not, it will remain confined to my laptop. Regards Pritpal Bedi --- hbpqtui is a QT specific class, and while I understand the feature is useful, such class should reside in HBQT, not HBXBP, since it's not, or not easily portable functionality. Just think about the case if we'd like to create an HBXBP compatible library, but based on a different GUI subsystem (GTK, WX, whatever). -- It is scheduled to be compatible with Xbp framework. That is why I put it there. As I am only concerned with Qt at this moment I have decided it to be put under there only. Many more clsses are under pipeline as discussed earlier and I do not care what sub-sytems come in the future. So far nobody has even thought of them. -- I don't care? Great answer, so I don't care about HBQT + HBXBP + HBIDE either. That will free a lot of valuable time to spend on better things. -- Upto you Viktor. You can delete these contributions from the SVN. -- Yes, it probably is a good idea to move them to separate project(s). The reason is that they grow in unbelievable rate, but even root problems are not solved and not even being dealt with (= ignored), and this I believe will take an unnecessarily huge amount of fixing work in a lot of existing code on all levels. / In my view we should concentrate on the basics first and then build the upper levels on the this base. Plus it's also good if basic things agreed upon in the past are more or adhered to, or at least remembered. / IMO we're at the point when moving HBQT, HBXBP and HBIDE to their own repositories would be of a benefit for all projects, without losing too much. / Anyway I don't care is pretty much the opposite of how things are supposed to be done here in Harbour, particularly when it comes to basic system design methods. If you ignore these, the quality of these components will hardly be equal to that of
Re: [Harbour] Re: Can be Harbour have tool like Glade working with it...?
Massimo, my incomplete document about hbide http://docs.google.com/View?id=dhmtv9fs_235db6hz754 Thanks a lot Cheers, Jerry -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Qt* - A Mission Statement
Hi Pritpal, I've sent you a message outlining a problem with a serious problem with a QT specific extension in HBXBP (which is not meant to be QT specific in the first place). Even the name of the XBP class has QT in it. Your answer is generically to such problems is: I don't care. What did you exactly expect? I can imagine few worse reaction to such technical question. BTW, many of my similar mails were just a time waste, often with no answer. This doesn't convey a very good message. And I'm not inventing any of these problems/rules, we've agreed upon the basic ones before even one line had been written of HBQT and the green light was given. And now you're trying to threaten Harbour maintainers and users to stop all HBQT work if you can't get free benefits and the complete Harbour SVN environment to develop this project by your own rules, by your own mission statement, _inside Harbour SVN_. How is that? Harbour SVN is not a project repository service. We already have a missions statement. The mission statement of this project is still not to develop a GUI, but a compiler, and a good one. Harbour doesn't refrain from a GUI, it's just not its goal. Harbour is busy to offer a very strong API, which anybody can build upon, be it a GUI or anything else. If you want to be part of a project (or team, or club), I think you should play ball, work as a team and accept its rules, not creating your own ones. (and if you have difficulty: ask!) Or you can, but in this case you should seriously consider creating a new project, with your own mission statement. Brdgs, Viktor On 2010 Jan 28, at 00:45, Pritpal Bedi wrote: Hello All, So, I think I stand a point to clarify what happened around in the last 21 hours. If you take otherwise please skip the message blow. This all started almost one year ago ( 10 months 10 days to be exact ) when someone floated the idea of having a multi-platform GUI in Harbour core and which, if proved to be the effective implementation, will be officially declared Harbour GUI framework. Then list looked for which GUI base system we were to adopt. Quicky arrived the solution that QT is the _cleanest_ of all implementations and we should go in this direction. I read some basic documentation of Qt and got convinced that this is achievable. The only hitch was how to start. Someone readily made available the base skeltons. I did some experiments with those skeletons and realized some results. The _idea_ fascinated me deeply and I confirmed to the list that I am ready to take this challenge. List approved it, decided on the name-space, repository location, and rest is the history. Everybody moved in this direction, thank you. The whole concept has barely born ( 9 months womb ) and we have _planned_ to re-habilitate it in some alien world, without considering the chances of its survival. I cannot imagine how cruel can we. All those 10m-10days I have lived into this project, day or night, office or home, awake or asleep, without any expectation or consideration, without any call for my personal needs, but simply with an urge of _creativity_ and a feeling that I must _return to the language_ which has given me my bread_and_butter all these years. I took the responsibility [ not that you forced ] to ease out the modern-day pressure of GUI demands on Harbour users and to provide a strong framework over which we could lay our futures. I do not know how much I have been successful, you are the better judge, but I am satisfied about the fact that the mission I had chosen, I sincerly worked hard to achieve. Today I am feeling I am much relieved of such, self-imposed, responsibility. I can feel I have the time to _stand and stare_. Did you ever thought that this action will send a strong message to the world that Harbour refrains from GUI, _please_ do not step-in. I am aware, and have ever followed the design goals of the project, and am committed not to over-step it in any way. But to be treated like this, without understanding the content of my message, just... Below is the text of messages sent on the list, in the context of my above emotions, for easy grasp. Bottom line: I will try to upload to _Harbour SVN_ whatever I could implement in Qt based gtqtc, hbQT, hbXBP and hbIDE twice a day, but if I could not, it will remain confined to my laptop. Regards Pritpal Bedi ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Hi, I only say that could be more convenient to establish a first modest goal for a basic, compact, multi-platform GUI bundled with Harbour and working out of the box. This way an user could download Harbour binaries for Windows, Linux, OS/2 or Mac and have native/basic GUI support for all those OSs. Being the first target a small set of GUI classes, the project could be working in the term of weeks (or months) and not years. It could be expanded in all imaginable ways (even xbase++ parts) in future Harbour versions. +1 start small and end big Cheers, Jerry -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
I agree we need gui today and in long term web why a common class like xbase++ part (XHB also without hb extension) can't be a solution? I only say that could be more convenient to establish a first modest goal for a basic, compact, multi-platform GUI bundled with Harbour and working out of the box. This way an user could download Harbour binaries for Windows, Linux, OS/2 or Mac and have native/basic GUI support for all those OSs. Being the first target a small set of GUI classes, the project could be working in the term of weeks (or months) and not years. It could be expanded in all imaginable ways (even xbase++ parts) in future Harbour versions. Since it's very difficult to make an ultimate decision about the best GUI API as official Harbour, and as it's not very good to tie us exclusively to one vendor (like Nokia in case of QT), we - before beginning - decided to use separate abstraction layers to ease switching components in the future. Specifically we decided that HBXBP should be a layer which implements Xbase++ compatible GUI classes, with future provision that the underlying GUI engine can be changed, so f.e. we can have HBXBPGTK or HBXBPWX as plugin replacements. This assumes/requires that HBXBP can have _no_ QT, GTK or WX specific parts, simply because if we introduce such things, we break this idea, and reimplementing HBXBP for GTK or WX becomes impossible. (who will implement an emulator for QT UILOADER class...?) Another rule we agreed upon is that HBXBP is pure .prg code. [This is adhered, but shortcuts are made by implementing HBXBP specific parts inside HBQT, which is not the best.] Instead, the proper solution is to implement all QT specific functionality in HBQT, implement all Xbase++ compatible functionality in HBXBP (with possible extensions, which are strictly QT/GTK/etc _independent_). Finally we have HBIDE, which can basically use any functionality which is provided by HBQT or HBXBP, and it can mix these in any ways. It's a end-user application (not a library), so such things have no deeper consequences. Although as a rule, HBIDE should stay portable, so f.e. hbwin usage is out of question, and usage of Harbour core functionality is encouraged, even C/C++ code is better to be avoided. There are other shortcuts made which are not terrible problems functionally, but are wrong decisions nevertheless, f.e. HBIDE uses QProcess class, where we have one such class already in Harbour core. It's a waste of energy in several ways to re-implement existing portable core functionality using vendor specific solutions. We also have now .xhp reading functionality in HBIDE, while I made efforts in the past to implement the same thing in hbmk2. Well, instead of testing/fixing hbmk2, we now have a duplicate implementation to maintain and fix. Efficient? Not entirely. [ remaining, even more grave problems can be looked up from mail archives. ] Overall IMO the main problem is that in case of HBQT/HBXBP/HBIDE in the heat of enthusiasm the development path goes into a certain level of featuritis and rush, where we want everything at any future cost and now. IOW quantity is favored instead of quality. IMO we should not have all features, but only the important ones in order of priority, in a stable and working fashion. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Pripal is going a Huge works so same reply can be read also as Please help me in same part when i can'have time or expertise 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. 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. I'm sure there is enough talent around here to help in most of these problems. And I believe there is no problem which we couldn't solve by investing some joint effort into it. 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. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13725] trunk/harbour
Revision: 13725 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13725view=rev Author: vouchcac Date: 2010-01-28 02:47:56 + (Thu, 28 Jan 2010) Log Message: --- 2010-01-27 18:45 UTC-0800 Pritpal Bedi (prit...@vouchcac.com) * contrib/hbide/hbide.prg * contrib/hbide/ideactions.prg * contrib/hbide/idefindreplace.prg * contrib/hbide/resources/findinfiles.ui + Started implementation of Find in Files option. Just to have a glimpse what components it will contain, click on Search button along-side Find buttons. It is not working but it may prompt you which feature I missed to include. Just play. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbide/hbide.prg trunk/harbour/contrib/hbide/ideactions.prg trunk/harbour/contrib/hbide/idefindreplace.prg Added Paths: --- trunk/harbour/contrib/hbide/resources/findinfiles.ui This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13726] trunk/harbour
Revision: 13726 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13726view=rev Author: vszakats Date: 2010-01-28 03:01:28 + (Thu, 28 Jan 2010) Log Message: --- 2010-01-28 04:00 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * contrib/hbct/dummy.c + Indicated that some functions are implemented in core (for C5.3 compatibility). * contrib/hbwin/win_tbmp.prg * Formatting. - contrib/gtqtc + contrib/hbqt/gtqtc * Moved under QT structure. Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/contrib/hbct/dummy.c trunk/harbour/contrib/hbwin/win_tbmp.prg Added Paths: --- trunk/harbour/contrib/hbqt/gtqtc/ Removed Paths: - trunk/harbour/contrib/gtqtc/ This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] SF.net SVN: harbour-project:[13727] trunk/harbour
Revision: 13727 http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13727view=rev Author: vszakats Date: 2010-01-28 03:24:37 + (Thu, 28 Jan 2010) Log Message: --- 2010-01-28 04:23 UTC+0100 Viktor Szakats (harbour.01 syenar.hu) * INSTALL * external/Makefile * contrib/Makefile + Added build option to exclude specific list of contrib/external libraries using syntax: 'HB_CONTRIBLIBS=no lib1 lib2 libn' Modified Paths: -- trunk/harbour/ChangeLog trunk/harbour/INSTALL trunk/harbour/contrib/Makefile trunk/harbour/external/Makefile This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: hbpqtui class
Viktor Szakáts wrote: ...in the heat of enthusiasm the development path goes into a certain level of featuritis and rush, where we want everything at any future cost and now. IOW quantity is favored instead of quality. IMO we should not have all features, but only the important ones in order of priority, in a stable and working fashion. I agree with you. Situations like this, usually drives to a project to split between (allegedly) 'conservative' and 'agressive' developers. IMHO, that is a false dichotomy. The truth is that a development tool must be compact, stable, reliable, rock-solid thing and not a technical playground. Such playground is funny and must exist, but it should be in a different place. Regards, Roberto. ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] Re: hbpqtui class
Hello Viktor Because this is pure technical message so I am here to clarify some points which I think have either been misunderstood or ( by me also, no issues ) interpreted in a wrong way. Viktor Szakáts wrote: Since it's very difficult to make an ultimate decision about the best GUI API as official Harbour, and as it's not very good to tie us exclusively to one vendor (like Nokia in case of QT), we - before beginning - decided to use separate abstraction layers to ease switching components in the future. You are right and we are sticking to the same rule. And in the future too, no two thoughts. Specifically we decided that HBXBP should be a layer which implements Xbase++ compatible GUI classes, with future provision that the underlying GUI engine can be changed, so f.e. we can have HBXBPGTK or HBXBPWX as plugin replacements. This assumes/requires that HBXBP can have _no_ QT, GTK or WX specific parts, simply because if we introduce such things, we break this idea, and reimplementing HBXBP for GTK or WX becomes impossible. (who will implement an emulator for QT UILOADER class...?) Another rule we agreed upon is that HBXBP is pure .prg code. [This is adhered, I have scheduled a detailed reply to HbpQtUI issue, but in brief I would like to suggest that just review the code. QUiLoader() class is just a wrapper to load different components of a dialog from an .xml file, nothing more. It essentally calls other Q* functions to generate the dialog. In Windows you can design a dialog in ant resource toolkit which in turn produces a .rc embeddable in the appln, wheras Qt offers this class to load. If you look into HbpQtUI() class, you will immediately recognize that it reads .ui ( .xml ) format and then the QUiLoader() is called and recognized various window components from .ui read parsing. Also this class adheres to Xbp class modal convensions. If we need to put it along Qt libs, then I have to rewrite this class adhering only Qt calls. Any other engine can achieve the similar job just reading a specifically formated file or even .ui. Even now with some extra effort I can do so purely on class level without calling QUiLoader(). This is not an issue at all. We have already decided on namespace, so this class can be separated from hbXBP any time. For this matter we can think of a separate lib called hbHBP and club all such classes which are based on Xbp there. Xbp remains the placeholder of only those classes which are in Xbase++ distribution. If this is acceptable, it is matter of little time. But because I am not a make expert, so you have to look into the basics. but shortcuts are made by implementing HBXBP specific parts inside HBQT, which is not the best.] I need more explanation what is this. It is not too late to correct if such situation exists. Instead, the proper solution is to implement all QT specific functionality in HBQT, implement all Xbase++ compatible functionality in HBXBP (with possible extensions, which are strictly QT/GTK/etc _independent_). I even propose to separate all such classes which are not Xbp specific but are fully in par with Xbp calling convensions. Qt specif classes which call Qt wrappers are under the domain of Qt only. And you see I have done it exactly like that. Finally we have HBIDE, which can basically use any functionality which is provided by HBQT or HBXBP, and it can mix these in any ways. It's a end-user application (not a library), so such things have no deeper consequences. Although as a rule, HBIDE should stay portable, so f.e. hbwin usage is out of question, and usage of Harbour core functionality is encouraged, even C/C++ code is better to be avoided. This is exactly adhered exept HbpProcess(), below... There are other shortcuts made which are not terrible problems functionally, but are wrong decisions nevertheless, f.e. HBIDE uses QProcess class, where we have one such class already in Harbour core. It's a waste of energy in several ways to re-implement existing portable core functionality using vendor specific solutions. I tried with, and the code stayed for quiet some time, but I could not get rid of console appearing in front of the IDE and hanging ther until the process finished. Also the process output captured at the end. Przemek guided handsomely how other parts could be used but I could not get them working. Moreover Qt's implementation gave me very fine control over very basic points, and may by my lack of time or efforts, I could not achieve with hb_processRun(). I thought you will jump in to fix it. But still it is not too late. If someone can do so please come forward. It should a matter of minutes. We also have now .xhp reading functionality in HBIDE, while I made efforts in the past to implement the same thing in hbmk2. Well, instead of testing/fixing hbmk2, we now have a duplicate
[Harbour] Re: hbpqtui class
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. 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. I'm sure there is enough talent around here to help in most of these problems. And I believe there is no problem which we couldn't solve by investing some joint effort into it. True, but least has come forward... :-(. 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. Regards Pritpal Bedi - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/hbpqtui-class-tp4464679p4471674.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] Re: hbpqtui class
Roberto Lopez wrote: I only say that could be more convenient to establish a first modest goal for a basic, compact, multi-platform GUI bundled with Harbour and working out of the box. I can gather that you have something to srat with this vision. Please come forward and share your code with the group. Viktor, provide Roberto with SVN write access. Regards Pritpal Bedi - enjoy hbIDEing... Pritpal Bedi _a_student_of_software_analysis__design_ -- View this message in context: http://n2.nabble.com/hbpqtui-class-tp4464679p4471695.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
Re: [Harbour] Qt* - A Mission Statement
Pritpal Bedi wrote: So, I think I stand a point to clarify what happened around in the last 21 hours. I'm sorry, it didn't clarify much for me :) I have great respect for anyone who can sacrifice their time the way you have done so. However, I do not understand why a technical discussion has to go in this direction. For me, it is clear that the hierarchical nature of hbqt-xbp means that you should not rule out hbgtk-xbp (or hbwin-xbp etc). They are separate things for good reasons. Surely you can find an abstraction that allows you to proceed without destroying that possibility? BMDBFCDX is still not integrated into the core because it is a poor use of the capabilities of an RDDs to inherit the base methods of another - DBFCDX. In summary, I think Viktor is correct, and you are wrong about this technical detail, and wrong to make it such a big issue outside of technicalities. Regards Alex ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
