Re: qtD
On Wednesday, 14 August 2013 at 07:20:14 UTC, Benjamin Thaut
wrote:
Am 01.08.2013 16:36, schrieb michaelc37:
I compiled against Qt4, I want to try it on Qt5 soon but there
is
another annoying issue I discovered when trying to update and
compile
all of the qtd exmples: All slot functions must now be
declared public..
I'm guessing something changed in traits recently.
Yes since dmd 2.061 typeof no longer works on members you don't
have access to. But it is possible to bypass this using the
tupleof property. See typeOfFieldImpl in
https://github.com/Ingrater/druntime/blob/master/src/core/traits.d
Kind Regards
Benjamin Thaut
Thanks, i just tried this but it didnt work as i expected or
maybe i misunderstood.
e.g.
class Test
{
private void aa(){};
private int bb;
public void cc(){};
}
writeln(Test.tupleof.length); //prints 1
writeln(Test.tupleof[0].stringof); //prints (Test).bb
it didnt see aa(), or cc()
Re: qtD
I'd love to see good working Qt bindings in D. I have considered resurrecting the QtD project before, but I've been far too busy and/or lazy to really do anything.
Re: qtD
On Wednesday, 14 August 2013 at 15:16:27 UTC, David Nadlinger wrote: On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote: I don't think I got that far as I got a "Can't find the D compiler problem. It seems the build rebuilds the build in some way but fails. :-(( The cmake/FindD.cmake script searched for 'ldc' only, not 'ldc2'. Am on the way home right now, but I just pushed a commit (yay for git-hg) that should fix that issue (but only that issue). David I'm not sure that enough, the output of the "ldc2 --version" compiler seems to have changed. Also i found that in CMakeLists.txt ldc2 needs "D_FLAGS -d-version=QtdCppShared" for the D_IS_LLVM condition. Here is what i did. https://bitbucket.org/michaelc37/qtd-experimental/commits/bfd137549ab266cc0c2131be18d8ad955e78a501 I managed to get it to compile with ldc2, after hacking up a fix for Atomic.d , i did commit that change as i am not familiar with llvm at all.. But if anyone wants to try it, it is attached to https://bitbucket.org/michaelc37/qtd-experimental/issue/1/cannot-compile-with-ldc2
Re: qtD
On Tuesday, 13 August 2013 at 11:03:33 UTC, Russel Winder wrote: I don't think I got that far as I got a "Can't find the D compiler problem. It seems the build rebuilds the build in some way but fails. :-(( The cmake/FindD.cmake script searched for 'ldc' only, not 'ldc2'. Am on the way home right now, but I just pushed a commit (yay for git-hg) that should fix that issue (but only that issue). David
Re: qtD
Am 01.08.2013 16:36, schrieb michaelc37: I compiled against Qt4, I want to try it on Qt5 soon but there is another annoying issue I discovered when trying to update and compile all of the qtd exmples: All slot functions must now be declared public.. I'm guessing something changed in traits recently. Yes since dmd 2.061 typeof no longer works on members you don't have access to. But it is possible to bypass this using the tupleof property. See typeOfFieldImpl in https://github.com/Ingrater/druntime/blob/master/src/core/traits.d Kind Regards Benjamin Thaut
Re: qtD
On Tue, 2013-08-13 at 05:11 +0200, michaelc37 wrote: […] > patched the make file for ldc2, but ran into a problem during > compile with Atomic.d. Your changes are better than mine so I ditched mine. > I think the llvm_memory_barrier function no longer exists. I > found and tried to apply fixes from a patch made to tango's > Atomic.d > http://www.dsource.org/projects/tango/attachment/ticket/2101/llvm3.atomic.patch), > > ended up with a compile error that made no sense to me "Error: > Integer constant expression expected instead of ordering" > > AtomicOrdering ordering = getOrdering(ms == msync.rel ? msync.seq > : ms); > ... > ... > llvm_atomic_store!(T)(cast(T)newval, cast(shared T*)&val, > ordering); I don't think I got that far as I got a "Can't find the D compiler problem. It seems the build rebuilds the build in some way but fails. :-(( Classes in typesystem: 538 Generated: - d.: 529 (529) - cpp-impl..: 506 (506) - cpp-h.: 399 (399) - meta-info.: 28 (28) - pri...: 7 (7) Done, 344 warnings (577 known issues) [100%] Built target dgen Scanning dependencies of target main -- The CXX compiler identification is GNU 4.8.1 -- The C compiler identification is GNU 4.8.1 -- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++ -- Check for working CXX compiler: /home/users/russel/bin.Linux.x86_64/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc -- Check for working C compiler: /home/users/russel/bin.Linux.x86_64/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done CMake Error at cmake/FindD.cmake:41 (message): D compiler is not found Call Stack (most recent call first): CMakeLists.txt:180 (FIND_PACKAGE) -- Configuring incomplete, errors occurred! make[2]: *** [main] Error 1 make[1]: *** [CMakeFiles/main.dir/all] Error 2 make: *** [all] Error 2 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: qtD
On Monday, 12 August 2013 at 19:08:14 UTC, David Nadlinger wrote: On Monday, 12 August 2013 at 15:28:34 UTC, Russel Winder wrote: https://code.google.com/p/qtd/ (which has a Subversion repository) clearly points to http://www.dsource.org/projects/qtd – which I guess has a checkoutable (Subversion) repository. It's a Mercurial repository. QtD moved to BitBucket because of DSource stability problems impairing development. I suggested Eldar to nuke the DSource one to avoid confusion – i.e. either disable it, or replace it with a singe "repo has moved" text file in the root directory, or something like that –, but somehow this never happened (I don't recall whether there was actually disagreement about this or if we just never got around to do the change). But then there is https://bitbucket.org/qtd/repo As far as I am aware, this is the "current" repository, i.e. the last that Eldar, Max, Alexey and I actually committed to. However, I don't think any of us are actually working on QtD right now, and even simple patches/pull requests take inexcusably long to merge. and https://github.com/qtd-developers/qtd This seems to be an attempt to revive QtD, possibly by Michael Crompton, who contributed a few patches on BitBucket before. The URL is unnecessarily long, though – I just reserve github.com/qtd, if somebody wants admin rights for the organization, just drop me a line. That was actually me. I started working on it, and I got a few patches in when I got really busy with work. Unfortunately, that was just about the same time I started understanding the build system... It is unfortunately long, but I borrowed the naming scheme from ldc... Also, if anyone wants admin rights, drop me a line. I probably shouldn't be in charge of it since I only really have a passing interest (I just wanted to fix the PKGBUILD for Arch Linux..., also, if someone else can actually fix it, let me know). Before any activity gets going on QtD might it be an idea to decide with which VCS and support tools? Yep. I can't speak for Eldar and Max, who are really the ones who "own" QtD (I only contributed a few smaller fixes), but I'd say, if somebody wants to genuinely pick up QtD development, they should go ahead and choose whatever they feel most comfortable with. Git/GitHub certainly would be a good fit for the D ecosystem. Perhaps more should be done on http://www.dsource.org/projects/qtd to make it clear where action is to happen? I just tried to; the person behind the GitHub repository (Michael?) is welcome to amend that page. Note that the actual installation guides linked from that page all referred to the proper repository before as well. David I unfortunately don't have a dsource account, and I'm not sure how to get one. Please, let me know how I can help out. I'm 100% ok with handing over the qtd-developers org (if that's what we want to use).
Re: qtD
On Monday, 12 August 2013 at 19:28:41 UTC, michaelc37 wrote: On Monday, 12 August 2013 at 15:47:02 UTC, Russel Winder wrote: On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: I have cloned you qtd-experimental to try a build with ldc2. However it seems cmake/FindD.cmake needs amending to cope with ldc2 in a user defined place :-( I haven't tried ldc2/gdc yet, I'll have a look a bit later. patched the make file for ldc2, but ran into a problem during compile with Atomic.d. I think the llvm_memory_barrier function no longer exists. I found and tried to apply fixes from a patch made to tango's Atomic.d http://www.dsource.org/projects/tango/attachment/ticket/2101/llvm3.atomic.patch), ended up with a compile error that made no sense to me "Error: Integer constant expression expected instead of ordering" AtomicOrdering ordering = getOrdering(ms == msync.rel ? msync.seq : ms); ... ... llvm_atomic_store!(T)(cast(T)newval, cast(shared T*)&val, ordering);
Re: qtD
On Monday, 12 August 2013 at 19:08:14 UTC, David Nadlinger wrote: On Monday, 12 August 2013 at 15:28:34 UTC, Russel Winder wrote: https://code.google.com/p/qtd/ (which has a Subversion repository) clearly points to http://www.dsource.org/projects/qtd – which I guess has a checkoutable (Subversion) repository. It's a Mercurial repository. QtD moved to BitBucket because of DSource stability problems impairing development. I suggested Eldar to nuke the DSource one to avoid confusion – i.e. either disable it, or replace it with a singe "repo has moved" text file in the root directory, or something like that –, but somehow this never happened (I don't recall whether there was actually disagreement about this or if we just never got around to do the change). But then there is https://bitbucket.org/qtd/repo As far as I am aware, this is the "current" repository, i.e. the last that Eldar, Max, Alexey and I actually committed to. However, I don't think any of us are actually working on QtD right now, and even simple patches/pull requests take inexcusably long to merge. and https://github.com/qtd-developers/qtd This seems to be an attempt to revive QtD, possibly by Michael Crompton, who contributed a few patches on BitBucket before. The URL is unnecessarily long, though – I just reserve github.com/qtd, if somebody wants admin rights for the organization, just drop me a line. Before any activity gets going on QtD might it be an idea to decide with which VCS and support tools? Yep. I can't speak for Eldar and Max, who are really the ones who "own" QtD (I only contributed a few smaller fixes), but I'd say, if somebody wants to genuinely pick up QtD development, they should go ahead and choose whatever they feel most comfortable with. Git/GitHub certainly would be a good fit for the D ecosystem. Perhaps more should be done on http://www.dsource.org/projects/qtd to make it clear where action is to happen? I just tried to; the person behind the GitHub repository (Michael?) is welcome to amend that page. Note that the actual installation guides linked from that page all referred to the proper repository before as well. David That github repo is not mine, and I assumed the current repo was still on bitbucket. However, I agree moving to github would be ideal.
Re: qtD
On Monday, 12 August 2013 at 15:47:02 UTC, Russel Winder wrote: On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: I have cloned you qtd-experimental to try a build with ldc2. However it seems cmake/FindD.cmake needs amending to cope with ldc2 in a user defined place :-( I haven't tried ldc2/gdc yet, I'll have a look a bit later.
Re: qtD
On Monday, 12 August 2013 at 15:28:34 UTC, Russel Winder wrote: https://code.google.com/p/qtd/ (which has a Subversion repository) clearly points to http://www.dsource.org/projects/qtd – which I guess has a checkoutable (Subversion) repository. It's a Mercurial repository. QtD moved to BitBucket because of DSource stability problems impairing development. I suggested Eldar to nuke the DSource one to avoid confusion – i.e. either disable it, or replace it with a singe "repo has moved" text file in the root directory, or something like that –, but somehow this never happened (I don't recall whether there was actually disagreement about this or if we just never got around to do the change). But then there is https://bitbucket.org/qtd/repo As far as I am aware, this is the "current" repository, i.e. the last that Eldar, Max, Alexey and I actually committed to. However, I don't think any of us are actually working on QtD right now, and even simple patches/pull requests take inexcusably long to merge. and https://github.com/qtd-developers/qtd This seems to be an attempt to revive QtD, possibly by Michael Crompton, who contributed a few patches on BitBucket before. The URL is unnecessarily long, though – I just reserve github.com/qtd, if somebody wants admin rights for the organization, just drop me a line. Before any activity gets going on QtD might it be an idea to decide with which VCS and support tools? Yep. I can't speak for Eldar and Max, who are really the ones who "own" QtD (I only contributed a few smaller fixes), but I'd say, if somebody wants to genuinely pick up QtD development, they should go ahead and choose whatever they feel most comfortable with. Git/GitHub certainly would be a good fit for the D ecosystem. Perhaps more should be done on http://www.dsource.org/projects/qtd to make it clear where action is to happen? I just tried to; the person behind the GitHub repository (Michael?) is welcome to amend that page. Note that the actual installation guides linked from that page all referred to the proper repository before as well. David
Re: qtD
On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: I have cloned you qtd-experimental to try a build with ldc2. However it seems cmake/FindD.cmake needs amending to cope with ldc2 in a user defined place :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: qtD
On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: > for anyone still interested. > > after some itch scratching i finally got this to compile with dmd > 2.063.2 on ubuntu 64bit - > https://bitbucket.org/michaelc37/qtd-experimental Hummm… https://code.google.com/p/qtd/ (which has a Subversion repository) clearly points to http://www.dsource.org/projects/qtd – which I guess has a checkoutable (Subversion) repository. But then there is https://bitbucket.org/qtd/repo and https://github.com/qtd-developers/qtd Before any activity gets going on QtD might it be an idea to decide with which VCS and support tools? Given Git is the DMD VCS, it would sort of make sense to work with Git and GitHub, though I am happy to work with Mercurial and BitBucket (or even Git and BitBucket!) Perhaps more should be done on http://www.dsource.org/projects/qtd to make it clear where action is to happen? Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: qtD
On Thursday, 1 August 2013 at 07:57:30 UTC, Russel Winder wrote: On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: for anyone still interested. We're here :-) after some itch scratching i finally got this to compile with dmd 2.063.2 on ubuntu 64bit - https://bitbucket.org/michaelc37/qtd-experimental here is what i did. 1) had to create auto_ref template for passing rvalues q: i remember some discussion on this, has a solution been finalized? 2) modify generator so that it adds the "override" keyword where necessary 3) modify generator so that structs are passed to cpp exported functions as pointers. q: i think that some d structs are objects in cpp (QRect?), and when cpp read the data the alignment seem to be off(e.g. height variable data, ended up in the x variable). Can somone explain this? Are you compiling against Qt4 or Qt5? I don't have Ubuntu but do have Debian Unstable and Fedora 18 (will move to 19 when it is released). I'd be happy to be a test builder if that would be helpful. I have a PySide (Qt4) application that I would like to try reimplementing in a native code language — I have to do some work on this anyway to switch back to PyQt since PyQt5 is about and PySide is stuck on Qt4). Options are C++, Go, D. Or possibly all of them. Now that Qt5 is out and about I am hesitant to do anything with Qt4, particularly now there is a SCons tool for Qt5. Thanks. I compiled against Qt4, I want to try it on Qt5 soon but there is another annoying issue I discovered when trying to update and compile all of the qtd exmples: All slot functions must now be declared public.. I'm guessing something changed in traits recently. I'll keep trying, but I'm not sure how much further I can go with this, as i don't have a solid c++ or qt background.
Re: qtD
On 31/07/13 16:26, Joseph Rushton Wakeling wrote: > On 07/31/2013 02:59 PM, michaelc37 wrote: >> for anyone still interested. > > Very happy to hear that QtD is getting some attention. GUI programming is > quite > a long way from what I usually do, but I think having good and up-to-date Qt > bindings is likely to be very important for D. > +1 -- Jordi Sayol
Re: qtD
On Wednesday, 31 July 2013 at 17:55:50 UTC, Kagamin wrote: Does it look as if the c++ side expects an extra field in the beginning of the object? Yes, I think that's what it looked like. I'll try to re-run post some data results this weekend.
Re: qtD
On Wed, 2013-07-31 at 14:59 +0200, michaelc37 wrote: > for anyone still interested. We're here :-) > after some itch scratching i finally got this to compile with dmd > 2.063.2 on ubuntu 64bit - > https://bitbucket.org/michaelc37/qtd-experimental > > here is what i did. > > 1) had to create auto_ref template for passing rvalues > q: i remember some discussion on this, has a solution been > finalized? > 2) modify generator so that it adds the "override" keyword where > necessary > 3) modify generator so that structs are passed to cpp exported > functions as pointers. > q: i think that some d structs are objects in cpp (QRect?), > and when cpp read the data the alignment seem to be off(e.g. > height variable data, ended up in the x variable). Can somone > explain this? Are you compiling against Qt4 or Qt5? I don't have Ubuntu but do have Debian Unstable and Fedora 18 (will move to 19 when it is released). I'd be happy to be a test builder if that would be helpful. I have a PySide (Qt4) application that I would like to try reimplementing in a native code language — I have to do some work on this anyway to switch back to PyQt since PyQt5 is about and PySide is stuck on Qt4). Options are C++, Go, D. Or possibly all of them. Now that Qt5 is out and about I am hesitant to do anything with Qt4, particularly now there is a SCons tool for Qt5. Thanks. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: qtD
Does it look as if the c++ side expects an extra field in the beginning of the object?
Re: qtD
On Monday, 1 October 2012 at 17:31:11 UTC, Habibutsu wrote: Anybody knows, project qtd (http://www.dsource.org/projects/qtd/) is alive or died? Last changes was one year ago. Tracking system contains critical bugs and nobody fixes. There may be other working bindings for Qt?
Re: qtD
On Wednesday, 31 July 2013 at 13:58:10 UTC, Kagamin wrote: QRect doesn't have a field for height: http://qt.gitorious.org/qt/qtbase/blobs/stable/src/corelib/tools/qrect.h#line262 sorry i think i meant y2 (i was writting that post in a hurry)
Re: qtD
On 07/31/2013 02:59 PM, michaelc37 wrote: > for anyone still interested. Very happy to hear that QtD is getting some attention. GUI programming is quite a long way from what I usually do, but I think having good and up-to-date Qt bindings is likely to be very important for D.
Re: qtD
On 7/31/13, michaelc37 wrote: > 3) modify generator so that structs are passed to cpp exported > functions as pointers. > q: i think that some d structs are objects in cpp (QRect?), > and when cpp read the data the alignment seem to be off(e.g. > height variable data, ended up in the x variable). Can somone > explain this? Sounds like http://d.puremagic.com/issues/show_bug.cgi?id=5570 ?
Re: qtD
QRect doesn't have a field for height: http://qt.gitorious.org/qt/qtbase/blobs/stable/src/corelib/tools/qrect.h#line262
Re: qtD
for anyone still interested. after some itch scratching i finally got this to compile with dmd 2.063.2 on ubuntu 64bit - https://bitbucket.org/michaelc37/qtd-experimental here is what i did. 1) had to create auto_ref template for passing rvalues q: i remember some discussion on this, has a solution been finalized? 2) modify generator so that it adds the "override" keyword where necessary 3) modify generator so that structs are passed to cpp exported functions as pointers. q: i think that some d structs are objects in cpp (QRect?), and when cpp read the data the alignment seem to be off(e.g. height variable data, ended up in the x variable). Can somone explain this?
Re: QtD fails to build on Arch Linux
I am very interested in seeing some updated bindings for Qt in D. I would even like to contribute to a revival project in some fashion. (Even though thinking about how bindings for Qt's classes and macros work makes my head spin.) My best experience in producing a GUI application thus far has been with Python and PySide. I think strong and up-to-date bindings for Qt in D could make GUI application programming even nicer than GUI programming in Python. This would be very good for D's PR.
Re: QtD fails to build on Arch Linux
Hrm, now I'm getting something else: /home/otto/aur/qtd/src/qtd/d2/qt/core/QSize.d(62): Error: function qt.core.QSize.QSize.scale (int w, int h, AspectRatioMode mode) is not callable using argument types (QSize,AspectRatioMode) /home/otto/aur/qtd/src/qtd/d2/qt/core/QSize.d(62): Error: function qt.core.QSize.QSize.scale (int w, int h, AspectRatioMode mode) is not callable using argument types (QSize,AspectRatioMode) /home/otto/aur/qtd/src/qtd/d2/qt/core/QSize.d(62): Error: (QSize __ctmp1680 = 0; , __ctmp1680).this(w, h) is not an lvalue /home/otto/aur/qtd/src/qtd/d2/qtd/MOC.d(181): Deprecation: variable modified in foreach body requires ref storage class This doesn't seem as easy to work around. I'll have to dig into the code. Running: * gcc 4.8 * qt 4.8.4 Still looking into it.
Re: QtD fails to build on Arch Linux
This project very interest for me. But current QtD is supports only 4.8 Qt version. If anybody wants to revive this project and know something about Qt binding specific (this is not simple c++ binding, as I know. How bind QT_OBJECT macros?), I can to help him. Anyway, if someone tell me about QtD develop ideas, I'll be very grateful:) I'd like to get this working with Qt5, but I don't even know where to begin. If I get time, I'll start diving into the code to see if I can figure something out. Concerning that, would you find it advantageous to support both Qt4 and Qt5? Also, what about dynamic vs static bindings? [1] About this build trouble: add -fpermissive to CXXFLAGS and all will be builded and work correctly (to the best of my memory) Thanks, that works, but it saddens me to do this. Since I'm new to the project, I don't know if that's a binding issue or if it's a Qt one. I've adopted the package on the AUR and I'll be updating the PKGBUILD with the flag. [1] http://www.gamedev.net/page/resources/_/technical/game-programming/binding-d-to-c-r3122
Re: QtD fails to build on Arch Linux
On Saturday, 18 May 2013 at 17:24:21 UTC, Tyler Jameson Little wrote: I'm on 64-bit, so I've used the 64-bit patch [1] on bitbucket to get the compile started. I get a lot of these errors: [ 3%] Building CXX object CMakeFiles/cpp_core.dir/cpp/qt_core/QAbstractItemModel_shell.cpp.o /home/otto/sandbox/qtd/build_dir/build/cpp/qt_core/QAbstractItemModel_shell.cpp: In member function ‘virtual QModelIndex QAbstractItemModel_QtDShell::buddy(const QModelIndex&) const’: /home/otto/sandbox/qtd/build_dir/build/cpp/qt_core/QAbstractItemModel_shell.cpp:83:141: error: taking address of temporary [-fpermissive] qtd_QAbstractItemModel_buddy_QModelIndex_const_dispatch(QObjectLink::getLink(this)->dId, &__d_return_value, &qtd_from_QModelIndex(index0)); I'm using gcc 4.8 if that makes a difference. I've noticed that the original developers have more or less abandoned it (a patch for finding 64-bit dmd sits in the issue tracker gathering dust), but it seems to be the only Qt binding out there. I've noticed on the D forums that the developers have possibly lost interest [2]. So, has anyone else had problems building QtD recently? Is there any community interest in maintaining it? If people need it, I'd consider looking into fixing the current build status, but I can't commit to maintaining it long-term since I don't have any active projects that need it. I may in the future, hence the tentative offer to help. [1] https://bitbucket.org/qtd/repo/issue/4/cmake-finding-dmd#comment-4087437 [2] http://forum.dlang.org/thread/mailman.461.1349112690.5162.digitalmar...@puremagic.com This project very interest for me. But current QtD is supports only 4.8 Qt version. If anybody wants to revive this project and know something about Qt binding specific (this is not simple c++ binding, as I know. How bind QT_OBJECT macros?), I can to help him. Anyway, if someone tell me about QtD develop ideas, I'll be very grateful:) About this build trouble: add -fpermissive to CXXFLAGS and all will be builded and work correctly (to the best of my memory)
Re: qtD
On Wednesday, 3 October 2012 at 08:13:59 UTC, Russel Winder wrote: Presumably the Qt5 release could be an impetus to restart active evolution of QtD? QtQuick doesn't really do it for me given QtDesigner, but… This all depends on enough people feeling the need to scratch their related itch – my own little projects using QtD are finished, and I don't have too much time to spend on D right now, so I'm trying to concentrate on core language and LDC work… David
Re: qtD
On Tue, 2012-10-02 at 23:52 +0200, Eldar Insafutdinov wrote: > On Monday, 1 October 2012 at 17:31:11 UTC, Habibutsu wrote: > > Anybody knows, project qtd > > (http://www.dsource.org/projects/qtd/) is alive or died? Last > > changes was one year ago. Tracking system contains critical > > bugs and nobody fixes. There may be other working bindings for > > Qt? > > Hey, yes I haven't been working on QtD for quite some time now, > and unfortunately no one else has picked up on it. I don't know > of any other efforts made, and due to the big undertaking it > would be wiser to build on what's there already... Presumably the Qt5 release could be an impetus to restart active evolution of QtD? QtQuick doesn't really do it for me given QtDesigner, but… I work in a biased sample set, but very few people I know would write Qt applications in C++, it's all PyQt4 and PySide with connection to C, C++ and Fortran to make use of computational frameworks. cf. SciPy. Also it has to be noted that for all it's C++ horrible API, wxWidgets has a large mind share in the cross-platform GUIs arena, especially given wxPython and wxGlade. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: qtD
On Monday, 1 October 2012 at 17:31:11 UTC, Habibutsu wrote: Anybody knows, project qtd (http://www.dsource.org/projects/qtd/) is alive or died? Last changes was one year ago. Tracking system contains critical bugs and nobody fixes. There may be other working bindings for Qt? Hey, yes I haven't been working on QtD for quite some time now, and unfortunately no one else has picked up on it. I don't know of any other efforts made, and due to the big undertaking it would be wiser to build on what's there already...
Re: QtD lisence
On Fri, 2012-08-17 at 13:06 +0100, Joseph Rushton Wakeling wrote: > On 17/08/12 08:55, Russel Winder wrote: > > Can I suggest a re-phasing "proprietary code needs to dynamically link > > to Qt to comply with the LGPL". To avoid the LGPL with Qt you need to > > buy a commercial Qt licence. > > I think this is over-stating the licence requirements. The legally safest > option is certainly to dynamically link against the LGPL-licensed code, but > it's > not an explicitly-stated _requirement_ of the licence. This is true. About a decade ago I took legal advice regarding GPL, LGPL and various scenarios. The problem was that there was very little case law to give solidity to any interpretation of the licences and the law surrounding them. Taking a defensive view is thus the safest way forward. > The requirements are that the recipient of the program must be able to link > it > to a newer version of the LGPL-licensed part. That could be achieved through > dynamic linking, or it could be achieved through distributing object files > along > with the program. (You could also distribute source code, but since this is > what's trying to be avoided here it's not a solution.) We also thought about this interpretation of compliance, but it leads to dangerous doubts for end user products. OK for software tools where the end user is themselves in the software business. > Qt recommends dynamic linking because it can't be guaranteed that some legal > jurisdictions wouldn't interpret a statically-linked program as a "derivative > work" of the LGPL-licensed code, thus falling under its copyleft provisions. > However, such an interpretation is almost certainly not in line with the > licence's intentions. The core problem here is no case law and no international agreements. So "derivative work", "linking", "dynamic" and "static" are all legally undefined in this contexts in many jurisdictions. Worse I bet there are very few computer literate folk working in jurisprudence. > It might be worth contacting the Software Freedom Law Center for advice on > these > points: https://www.softwarefreedom.org/ But the problem is that they are USA centric. Or are they taking on more people internationally now? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: QtD lisence
On 17/08/12 08:55, Russel Winder wrote: Can I suggest a re-phasing "proprietary code needs to dynamically link to Qt to comply with the LGPL". To avoid the LGPL with Qt you need to buy a commercial Qt licence. I think this is over-stating the licence requirements. The legally safest option is certainly to dynamically link against the LGPL-licensed code, but it's not an explicitly-stated _requirement_ of the licence. The requirements are that the recipient of the program must be able to link it to a newer version of the LGPL-licensed part. That could be achieved through dynamic linking, or it could be achieved through distributing object files along with the program. (You could also distribute source code, but since this is what's trying to be avoided here it's not a solution.) Qt recommends dynamic linking because it can't be guaranteed that some legal jurisdictions wouldn't interpret a statically-linked program as a "derivative work" of the LGPL-licensed code, thus falling under its copyleft provisions. However, such an interpretation is almost certainly not in line with the licence's intentions. It might be worth contacting the Software Freedom Law Center for advice on these points: https://www.softwarefreedom.org/
Re: QtD lisence
On Fri, 2012-08-17 at 11:37 +0200, Jacob Carlborg wrote: […] > What I meant was to avoid being forced to license your code under LGPL. > It's not just for proprietary code, there are also other open source > licenses which are not compatible with GPL. Indeed. Sadly though, licences such as ASL 2.0, MIT, BSD, etc. allow the unscrupulous to use and make proprietary versions of codebases and continue to make use of updates provided for free by unpaid volunteers, whilst making money from their proprietary version. The permissive licences are fine for established codebases, e.g. Groovy, where there is no realistic opportunity for successful bad behaviour. For smaller, less well established codebases, it is possible and known to have happened. The strategy seems then to use LGPL as a FOSS start up and then relicence to a more permissive licence once you have a reasonable sized user base that protects against bas behaviour. None of this applies to systems that are necessarily distributed as source, for that case a whole different set of factors applies. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: QtD lisence
On 2012-08-17 09:55, Russel Winder wrote: Can I suggest a re-phasing "proprietary code needs to dynamically link to Qt to comply with the LGPL". To avoid the LGPL with Qt you need to buy a commercial Qt licence. Applications that are themselves LGPL or GPL can dynamically or statically link to LGPL libraries. What I meant was to avoid being forced to license your code under LGPL. It's not just for proprietary code, there are also other open source licenses which are not compatible with GPL. -- /Jacob Carlborg
Re: QtD lisence
On Thu, 2012-08-16 at 23:04 +0200, Jacob Carlborg wrote: > On 2012-08-16 22:32, ShestakoffVS wrote: > > > David, i read about LGPL and other nokia stupid ideas and now want to > > know can i staticly link my programm with qtd. > > As far as I know you need to link dynamically to Qt to avoid the LGPL > license. Can I suggest a re-phasing "proprietary code needs to dynamically link to Qt to comply with the LGPL". To avoid the LGPL with Qt you need to buy a commercial Qt licence. Applications that are themselves LGPL or GPL can dynamically or statically link to LGPL libraries. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: QtD lisence
On Thu, 2012-08-16 at 22:32 +0200, ShestakoffVS wrote: […] > David, i read about LGPL and other nokia stupid ideas and now > want to know can i staticly link my programm with qtd. LGPL is not a Nokia idea and not a stupid idea either. Using LGPL libraries you can write proprietary code and dynamically link to the version of the LGPL code the end user installs. If you want to statically link proprietary code to Qt then buy a commercial licence for Qt. The price of the Qt licence just becomes part of your BoM. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: QtD lisence
On Thu, 16 Aug 2012 23:15:14 +0200 Andrej Mitrovic wrote: > On 8/16/12, ShestakoffVS wrote: > > David, i read about LGPL and other nokia stupid ideas and now > > want to know can i staticly link my programm with qtd. > > Laws aren't stupid ideas. Just stupidly implemented ;)
Re: QtD lisence
On 8/16/12, ShestakoffVS wrote: > David, i read about LGPL and other nokia stupid ideas and now > want to know can i staticly link my programm with qtd. Laws aren't stupid ideas. If you want to make a commercial app, regardless of any libraries, you better have a lawyer.
Re: QtD lisence
On 2012-08-16 22:32, ShestakoffVS wrote: David, i read about LGPL and other nokia stupid ideas and now want to know can i staticly link my programm with qtd. As far as I know you need to link dynamically to Qt to avoid the LGPL license. -- /Jacob Carlborg
Re: QtD lisence
On Thursday, 16 August 2012 at 19:11:51 UTC, David Nadlinger wrote: On Thursday, 16 August 2012 at 19:07:20 UTC, ShestakoffVS wrote: But i didn't understand how i can use qtd for commercial project if i must use qt sources (that i cant use in commercial project) when i'm building qtd. You can use Qt under the LGPL: http://qt.nokia.com/products/licensing. David David, i read about LGPL and other nokia stupid ideas and now want to know can i staticly link my programm with qtd.
Re: QtD lisence
On Thursday, 16 August 2012 at 19:07:20 UTC, ShestakoffVS wrote: But i didn't understand how i can use qtd for commercial project if i must use qt sources (that i cant use in commercial project) when i'm building qtd. You can use Qt under the LGPL: http://qt.nokia.com/products/licensing. David
Re: QtD lisence
On Thursday, 16 August 2012 at 18:24:51 UTC, David Nadlinger wrote: On Thursday, 16 August 2012 at 16:35:19 UTC, ShestakoffVS wrote: Could you explicitly explain me can i use QtD bindings for commercial project? I am not a lawyer, but: Yes, you can, under the restriction your Qt license mandates. The QtD libraries itself are Boost-licensed, it's just the generator executable (and the samples) which are GPL due to code carried over from QtJambi. David Thanks for your reply, David. But i didn't understand how i can use qtd for commercial project if i must use qt sources (that i cant use in commercial project) when i'm building qtd. I think i can use without payment only qtd binding tehnology not qt sourses. Sorry about my pedantry. I want to explain why i need this information. I'm working with opengl within python and C, and now i need some more performance and i want move to D, but i need good GUI library. With python i used PySide it's under LGPL license.
Re: QtD lisence
On Thursday, 16 August 2012 at 16:35:19 UTC, ShestakoffVS wrote: Could you explicitly explain me can i use QtD bindings for commercial project? I am not a lawyer, but: Yes, you can, under the restriction your Qt license mandates. The QtD libraries itself are Boost-licensed, it's just the generator executable (and the samples) which are GPL due to code carried over from QtJambi. David
Re: QtD on Windows 7?
"Benjamin Thaut" wrote in message news:is554g$k8f$1...@digitalmars.com... >I just tried to get QtD to run on windows 7 64 bit. (compiling QtD and my >app in 32 bit though) Unfortunatly it crashes the second I move my mouse >over a button. I'm using the first of the provided examples, and even that >crashes. > I searched the QtD forums and tickets, and this issue has been reported > serveral times, but there is no statement or solution on it yet. > Did any one of you manage to get QtD running on Windows 7 64 bit? > If so what Qt version did you use? Which dmd version? I'm using Qt 4.7.4. > > If QtD is not usable, what gui library do you use in D 2.0? I've never really used any GUI libs in D yet, so I can't help with your QtD problem. But if you need an alternate GUI lib, DWT (based off SWT) is supposed to be good, and it's recently added D2 support. I've heard good things about DFL, too, but AIUI, that's Windows-only.
