>> I remember to implement WAPI_WAITFOR*() functions in hbwin
>> after reading this conversation to help the matter, though
>> we would need some portable core solution for this problem,
>> also.
>>
>
> I mensioned that I made some experiments, though
> not for a longer duration, and could no
Viktor Szakáts wrote:
>
> Thank you. It's good. Pls make sure that this
> class won't contain anything XBP specific, f.e.
> it cannot inherit from xbpWindow. So some slight
> changes will be needed, f.e. to receive a QT
> window object as parameter.
>
For sure not. hbQT does not know anyth
>>
>> So, the clean solution here is either to create a
>> HBXBP specific file format, which implements a portable
>> way of describing UI elements, OR (and this is definitely
>> the easiest) to implement such class in HBQT.
>>
>
> Ok, I do it.
> What be the name : hbqt_qtuiloader.prg ?
Tha
Viktor Szakáts wrote:
>
> I understand that, but .xml is just the container
> format, what really matters is the content and the
> specification which describes this content. In this
> case the content of the .ui file is seemingly a
> QT specific implementation of UI element description,
>
Viktor Szakáts wrote:
>
> You should definitely not neglect other things, since
> we should never forget the fun part and that we do
> Harbour because it gives us something. But it's fully up
> to you how to balance. If it starts to ruin other things,
> just stop. Never anybody called for a
Hi Pritpal,
On 2010 Jan 28, at 07:29, Pritpal Bedi wrote:
>
>
> Viktor Szakáts wrote:
>>
>> If this is the case, there is nothing wrong in asking
>> these things specifically. I very often ask such
>> question on the list (and not always, but sometimes
>> I even get answers), and IMO this s
Pritpal Bedi wrote:
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
Hi Pritpal,
>> 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 H
Wednesday 27 January 2010 17:55:04 je Angel Pais napisal:
> 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.
This is not true
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
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
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
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
> 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 ge
>> 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 wor
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 sup
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 bu
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 i
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 tr
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 :
>
> 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
> w
> 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
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.
w
+1
Please maitain one project
2010/1/27 Angel Pais :
> 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 goo
>
> 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 go
On Wed, Jan 27, 2010 at 5:55 PM, 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.
I'm not saying Harbou
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
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.
___
Ha
On Wed, Jan 27, 2010 at 5:08 PM, Viktor Szakáts 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
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 co
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 un
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 diffe
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 mu
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 undere
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 se
Viktor Szakáts wrote:
>
> "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.
Regards
Pritpal Bedi
-
e
>> 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
Viktor Szakáts wrote:
>
> 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
37 matches
Mail list logo
