Perfectly fine. The technical side seems about alright.
In hbmk2 parlance:
--- xhgtk.hbp
libs=xhgtkmain xhgtkcairo xhgtkglib xhgtkgdk xhgtkgtk xhgtkpango
xhgtkclasses
{linux}ldflags="`pkg-config --libs gtk+-2.0 libglade-2.0`"
---
Brgds,
Viktor
On Wed, Mar 18, 2009 at 9:47 AM, Lorenzo Fiorini
wrot
On Wed, Mar 18, 2009 at 9:41 AM, Viktor Szakáts wrote:
> Yes, after all this isn't the end of the world. With
> consistently naming the related libs, it can be just as good.
> Even the dependencies are easier to handle with the
> approach.
This is what I use now in hb-func.sh:
...
if [ "\${HB_XH
>
> > Sorry, I don't understand you.
> > xhgtk uses several subdirs to store different part of the interface,
> > and these subdirs generate one unified library. This doesn't seem
> > possible with our current GNU-make system.
>
> I have integrated xhgtk in the contrib using "standard" makefiles an
On Wed, Mar 18, 2009 at 12:03 AM, Viktor Szakáts
> Sorry, I don't understand you.
> xhgtk uses several subdirs to store different part of the interface,
> and these subdirs generate one unified library. This doesn't seem
> possible with our current GNU-make system.
I have integrated xhgtk in the
On Tue, Mar 17, 2009 at 11:51 PM, Massimo Belgrano wrote:
> I want only rember Przemek proposal of xhgtk
Sorry, I don't understand you.
xhgtk uses several subdirs to store different part of the interface,
and these subdirs generate one unified library. This doesn't seem
possible with our curren
I want only rember Przemek proposal of xhgtk
2009/3/17 Viktor Szakáts :
> ? In one mail you're talking about hbqt, now you're talking about
> xhgtk, while Przemek and Phil has been talking about xbgtk.
> Sorry I cannot follow.
> IMO after looking at both projects, they are better fitted standalone
? In one mail you're talking about hbqt, now you're talking about xhgtk,
while Przemek and Phil has been talking about xbgtk.
Sorry I cannot follow.
IMO after looking at both projects, they are better fitted standalone
than inside our contrib tree.
As for hbqt, I'd vote to see some code first, t
xhgtk if i remember right Przemyslaw post
2009/3/17 Viktor Szakáts
>
> Yes, we can put it into contrib. But do we have anything to put there already?
--
Massimo Belgrano
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.
Or even:---
#include
#include "hbapi.h"
HB_FUNC( QT_QDIALOG )
{
hb_retptr( new QDialog( ( QWidget * ) hb_parptr( 1 ),
( Qt::WindowFlags ) hb_parni( 2 ) ) );
}
---
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-proj
Yes, we can put it into contrib. But do we have anything to put there
already?
I'd suggest a few minor cleanups:
---
#include
#include "hbapi.h"
HB_FUNC( QT_QDIALOG )
{
QWidget * parent = ( QWidget * ) hb_parptr( 1 );
hb_retptr( new QDialog( parent, ( Qt::WindowFlags ) hb_parni( 2 ) ) );
}
Hi Marcos
Marcos Gambeta wrote:
>
> The work is done manually. See the example:
>
> -
> File: qdialog.cpp
> -
>
> #include
> #include "hbapi.h"
>
> /*
> QDialog ( QWidget * parent = 0, Qt::WindowFlags f = 0 )
> */
> HB_FUNC( QT_QDIALOG )
> {
>QDialog* di
I vote for hbqt in contrib +1
2009/3/12 Marcos Gambeta
> I am following the same "Class Inheritance Hierarchy" of the Qt.
>
> The project was started few days ago. If Harbour developers agree, i can
> continue in the Harbour contrib dir. Vailton Renato is ready to help me in
> the development.
Hi,
On Fri, Mar 13, 2009 at 6:55 PM, Przemyslaw Czerpak wrote:
> I have a patch for Harbour builds and some small cleanups to
> the version in CVS.
> Can I sent it to you?
Yes of course, probably the xbgtk mailing list is a better place,
AFAIR you were subscribed to it, but you can send the patc
On Thu, 12 Mar 2009, Phil Krylov wrote:
Hi,
> I plan to evolve xbgtk as needed. It's currently just enough for a
> couple of my projects. However, I always welcome any fixes and
> additions. Well it's really cool when you feed a .spec from new GTK+
> version to the code generator, and it builds 8
On Thu, Mar 12, 2009 at 4:13 PM, Przemyslaw Czerpak wrote:
> On Thu, 12 Mar 2009, Ernad Husremovic wrote:
>
> Hi,
>
>> Is it implemented similar to the qtRuby, qtPython ?
>> They are generating bindings automatically all the classes from the
>> framework with some tools (cpp2xml, kalyptus, qtsmok
On Thu, 12 Mar 2009, Ernad Husremovic wrote:
Hi,
> Is it implemented similar to the qtRuby, qtPython ?
> They are generating bindings automatically all the classes from the framework
> with some tools (cpp2xml, kalyptus, qtsmoke ..) ?
> Maybe you have wrote that on your blog, but I don't unders
Ernad Husremovic escreveu:
Great news !
Is it implemented similar to the qtRuby, qtPython ?
They are generating bindings automatically all the classes from the framework
with some tools (cpp2xml, kalyptus, qtsmoke ..) ?
Maybe you have wrote that on your blog, but I don't understand spanish la
Great! I wanted to mention QT as the other great contender for portable GUI,
a wish apparently come true.
Brgds,
Viktor
On Thu, Mar 12, 2009 at 1:22 PM, Marcos Gambeta wrote:
> Massimo Belgrano escreveu:
>
>> In this area also QT seem interesting but is not present any wrapper
>> library afaik
>
Great news !
Is it implemented similar to the qtRuby, qtPython ?
They are generating bindings automatically all the classes from the framework
with some tools (cpp2xml, kalyptus, qtsmoke ..) ?
Maybe you have wrote that on your blog, but I don't understand spanish language
:).
Great effort, th
>
> Hi agree for xhgtk in contrib
> I Hope that HBGTK follow t WvgParts class modal (GTWVG) compatible
> with Xbase++XbpParts and implement also a GT
> If Following the same class structure the make the code portable.
> New()|Init() / Create() / Configure() / Destroy().
>
> In this area also QT s
Massimo Belgrano escreveu:
In this area also QT seem interesting but is not present any wrapper
library afaik
Massimo,
See the link:
http://www.magsoftinfo.com.br/blog/?cat=9
HbQt is LGPL. Wait few days to see the code.
Regards,
Marcos Gambeta
_
Hi agree for xhgtk in contrib
I Hope that HBGTK follow t WvgParts class modal (GTWVG) compatible
with Xbase++XbpParts and implement also a GT
If Following the same class structure the make the code portable.
New()|Init() / Create() / Configure() / Destroy().
In this area also QT seem interesting
FWIW, IMO it would also be very nice to see xhgtk integrated under the
Harbour contrib tree.
For sure this is much more a decision from the xhgtk authors,
than us, but it would be nice, and probably the best choice
towards portable GUI.
xhgtk has a big bunch of 3rd party dependencies, but probabl
On Sun, 07 Dec 2008, Bill Smith wrote:
Hi Bill,
> Right now, a ? "hello, world" program build from "hbmk hello" at best
> yields a blank screen in a terminal window on both SuSE Linux and
> Windows XP.
I have not idea how you crate such effect. I cannot replicate it.
Clean Harbour builds work c
On Sun, Dec 7, 2008 at 10:15 PM, Bill Smith <[EMAIL PROTECTED]> wrote:
> Thank You Lorenzo, you are absolutely correct, simplicity == elegance
> is critical.
Bill, thanks for your support.
Harbour was created by former Cl*pper programmers with the main goal
to be 100% compatible to it so many th
Thank You Lorenzo, you are absolutely correct, simplicity == elegance
is critical. This is not only the case for today, but down the road
when changes and incompatibilities could make tracking what library and
what combination of instructions or options or commented instructions in
source might be
On Sun, Dec 7, 2008 at 9:43 PM, Rodrigo Miguel <[EMAIL PROTECTED]> wrote:
> We need keep in mind that we have xharbour users as well, so, we need
> try to keep both configurations if possible.
I know, for this I think it would be better to have a different trees.
The xhgtk developers are free to
Hi Lorenzo,
> 1 - rewrite Makefiles using harbour standards ( and rename all the
> files lowercase ).
> This will create one lib for every dir but it seems more "gtk like"
> and since the link will be managed by hb* the user will not see the
> difference
We need keep in mind that we have xharbour
On Sun, Dec 7, 2008 at 4:54 PM, Przemyslaw Czerpak <[EMAIL PROTECTED]> wrote:
> BTW do you want to integrate XHGTK with Harbour contrib?
> Don't you think it will be better to keep it as separate
> project and only add some integration tools.
You're right but as we've seen lately it's not easy fo
On Sat, 06 Dec 2008, Lorenzo Fiorini wrote:
Hi Lorenzo,
> xhgtk's Makefile uses hbcc and hbcmp so xhgtk can't be included in
> contrib ( or better it is possible but only after the first install ).
It's an optional build for which uses Makefile.scr and allows to compiled
XHGTK without setting an
xhgtk's Makefile uses hbcc and hbcmp so xhgtk can't be included in
contrib ( or better it is possible but only after the first install ).
I see two possibilities:
1 - rewrite Makefiles using harbour standards ( and rename all the
files lowercase ).
This will create one lib for every dir but it se
31 matches
Mail list logo
