www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The Current Status of DQt

reply "w0rp" <devw0rp gmail.com> writes:
Hello everyone. From time to time, people ask in the newsgroup 
and also IRC about Qt bindings for D, so I thought it would be a 
good idea to give people an update on where my own bindings 
stand. First, if you want to take a look at my code as it stands, 
you can get it here.

https://github.com/w0rp/dqt

It depends on two other repositories which are also hosted on 
GitHub, and which are mentioned in the readme. Building dqt 
itself isn't that great, as I ran into some issues with DUB, but 
Sönke has since addressed my primary issue, so it may now be 
possible to build the project with the master branch version of 
DUB. Here is what I have done.

1. These bindings use SMOKE, which is a library which can be used 
to generate bindings for C++ libraries. The 'smokeqt' library 
does a Hell of a lot of work already for me. Everything I have is 
written in about 99% D. The "just SMOKE" part I have put in a 
separate repo, and it could potentially be used for wrapping 
other C++ libraries.
2. The majority of classes from Qt are generated as D classes 
which wrap around the C++ classes. This allows for polymorphism, 
at the expense of some additional resource management at times. 
(You can disable garbage collection and let Qt take over.)
3. Calling virtual method overrides from C++ isn't done yet, but 
I pretty much know how to do it, and there is some code in place 
which does about half of the job.
4. You can draw windows and so on with a DQt program. (I drew a 
gridlayout with a few buttons for a calculator successfully)

There are some important things left to do.

1. I have not accounted for multiple inheritance yet, which Qt 
uses. My idea was to nominate one class as the concrete class 
which is inherited (QObject) and then turn other classes into 
interaces which have seperate classes for implementation. 
(QPaintDevice)
2. I have not yet implemented signals and slots. Two options for 
this involve generating QMetaObject instances for classes, 
possibly via template mixins, which do what 'moc' does for C++. A 
second option is to use Qt5 for the library and to force all 
signals and slots behaviour to go through functions, as Qt5 can 
use function pointers as slots. (I prefer option 2.)

So, I am eager to hear what people think about all of this. Does 
anyone like the work that I have done, and will it be useful? 
Have I committed some terrible crime against nature, for which I 
must be punished? Does anyone have any ideas about things that 
could be improved, or where to go next? Please, let me know.

My progress has been somewhat slow in writing all of this, as I 
have been writing it mostly in the evenings, moslty during 
weekdays, after my day job. I've also been running into problems 
for which there are no easy answers, possibly no documentation 
for, and so on. So a great deal of my time has been spent more on 
thinking of what to do next, rather than writing anything. (It 
took me possibly months to come up with the resource management 
scheme that I have now.)
May 03 2014
next sibling parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 03 May 2014 11:00:37 +0000
w0rp via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 So, I am eager to hear what people think about all of this. Does
 anyone like the work that I have done, and will it be useful?
 Have I committed some terrible crime against nature, for which I
 must be punished? Does anyone have any ideas about things that
 could be improved, or where to go next? Please, let me know.


I can't really comment much on your approach or implementation, because I
haven't looked at what you've done, and while I do have some experince with
Qt, I haven't done a lot with it (and I haven't done a lot with GUI
programming in general), so I'm not in a good position to comment on or
review a D wrapper for Qt.

That being said, if I were to write a GUI application in either C++ or D, I
would want to use Qt (preferably Qt5). And given what is on my todo list, I
expect that I'll be looking at writing a GUI application in D within a year
or two. So, having a useable wrapper library for Qt in D is something that
I'm very interested in seeing happen. I wasn't aware of your efforts in that
regard (I was just aware of QtD, though it's not clear to me how actively
developed it is at this point, since it was my understanding that the
original devs dropped it, but I know that some folks have repos of it with
more recent changes), but I'm very glad that someone is taking up this torch,
and I wish you the best of luck with it. I'm just not likely to be of much
help in reviewing or critiquing it at this point. However, there are quite
a few folks around here who are not only much more familiar with GUI
development but who are also very opinionated on the matter, so hopefully
some of them will be able to chime in with useful insights.

- Jonathan M Davis
May 03 2014
prev sibling next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sat, 2014-05-03 at 11:00 +0000, w0rp via Digitalmars-d wrote:
[…]

 2. I have not yet implemented signals and slots. Two options for 
 this involve generating QMetaObject instances for classes, 
 possibly via template mixins, which do what 'moc' does for C++. A 
 second option is to use Qt5 for the library and to force all 
 signals and slots behaviour to go through functions, as Qt5 can 
 use function pointers as slots. (I prefer option 2.)


It's Qt, signals and slots are necessary!


From a personal perspective I only care about Qt5 and in particular QML.



 So, I am eager to hear what people think about all of this. Does 
 anyone like the work that I have done, and will it be useful? 
 Have I committed some terrible crime against nature, for which I 
 must be punished? Does anyone have any ideas about things that 
 could be improved, or where to go next? Please, let me know.


Whilst GtkD works and I am using it for a small GNOME-based project, Qt
is a better choice for systems that are to work on GNOME, OSX, KDE,
Android, and even Windows. QtD appears to have died, though Michael
Crompton has been trying to get it going again:
https://bitbucket.org/michaelc37/qtd-experimental


 My progress has been somewhat slow in writing all of this, as I 
 have been writing it mostly in the evenings, moslty during 
 weekdays, after my day job. I've also been running into problems 
 for which there are no easy answers, possibly no documentation 
 for, and so on. So a great deal of my time has been spent more on 
 thinking of what to do next, rather than writing anything. (It 
 took me possibly months to come up with the resource management 
 scheme that I have now.)


I suspect there is a "chicken and egg" situation here: D doesn't have a
strong Qt offering, so people do not use D for Qt work, and no-one is
using Qt and D so there is no resource to ensure a strong Qt offering
for D.

This cycle got broken for Go when Gustavo Niemeyer decided his group in
Canonical would use Go and QML and so he created the Go support for QML
on company time. He has focussed entirely on support for QML, and not
worried about providing a complete Go binding to Qt. Much of it is
there, but only with a view to supporting the QML aspects of things.
This has meant that Go+QML is really rather good.

I wonder if instead of trying to create a D binding to Qt, DQt (or QtD),
following Gustavo's approach with Go and just providing a D binding to
QML would get further faster.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 03 2014
parent reply "FrankLike" <1150015857 qq.com> writes:
  I think Get experience from QML to create  a D binding to Qt, 
that is better than binding to QML. the Go's The programming 
thinking is not same to the C++,and D.

DQt is Working hard more, but has significant effect for D.

DQt is very clear.
May 03 2014
parent "FrankLike" <1150015857 qq.com> writes:
I'm intersting for DQt is better than QML.
May 03 2014
prev sibling next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
A "meta" question, not related to your specific implementation:

While Qt is certainly the most powerful and comprehensive 
portable GUI framework, it also contains lots of code that's not 
related to user interfaces: strings, multi-threading support, 
file abstractions, containers, databases interfaces, etc. In 
short: Things which properly should be part of the standard 
library, but aren't (widely) available, or not working well 
enough in C++.

Now, Qt depends on those, and if you want to interact with it, 
you need to use them in your own code. Doesn't that cause a lot 
of friction? Just as a random example, QListView can take its 
elements from a data source ("model"). But in D, that data source 
might be idiomatically implemented as a range, so it has to be 
adapted first. Or, a more frequent thing: char[] vs. QString.

Could it be a better strategy to only re-use low-level 
functionality of Qt internally, but provide more idiomatic public 
D interfaces for it?
May 04 2014
next sibling parent reply "w0rp" <devw0rp gmail.com> writes:
On Sunday, 4 May 2014 at 09:21:30 UTC, Marc Schütz wrote:

 A "meta" question, not related to your specific implementation:

 While Qt is certainly the most powerful and comprehensive 
 portable GUI framework, it also contains lots of code that's 
 not related to user interfaces: strings, multi-threading 
 support, file abstractions, containers, databases interfaces, 
 etc. In short: Things which properly should be part of the 
 standard library, but aren't (widely) available, or not working 
 well enough in C++.

 Now, Qt depends on those, and if you want to interact with it, 
 you need to use them in your own code. Doesn't that cause a lot 
 of friction? Just as a random example, QListView can take its 
 elements from a data source ("model"). But in D, that data 
 source might be idiomatically implemented as a range, so it has 
 to be adapted first. Or, a more frequent thing: char[] vs. 
 QString.

 Could it be a better strategy to only re-use low-level 
 functionality of Qt internally, but provide more idiomatic 
 public D interfaces for it?


I'm only interested in getting the GUI parts of Qt to work. A lot 
of the features of Qt exist I think because there wasn't a 
reasonable portable alternative in C++ at the time. I think with 
D, there are or will be better alternatives than what Qt offers 
for certain things. (Like a threading implementation, for 
instance.) So my interest in supporting Qt classes only extends 
as far as getting GUI building to work. So I want to use native D 
types like 'string' and 'int[]' as much as possible, rather than 
Qt's types.

I believe that some wrapping can be avoided. I haven't attempted 
it yet, but I believe that it should be possible to recreate 
value types from Qt in D, and pass them over such that the data 
matches up to what C++ expects. Then basic things like what to do 
with a bunch of QPoint values can be dealt with in idiomatic D 
ways.
May 04 2014
parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 2014-05-04 at 13:15 +0000, w0rp via Digitalmars-d wrote:
[…]

 I'm only interested in getting the GUI parts of Qt to work. A lot 
 of the features of Qt exist I think because there wasn't a 
 reasonable portable alternative in C++ at the time. I think with 
 D, there are or will be better alternatives than what Qt offers 
 for certain things. (Like a threading implementation, for 
 instance.) So my interest in supporting Qt classes only extends 
 as far as getting GUI building to work. So I want to use native D 
 types like 'string' and 'int[]' as much as possible, rather than 
 Qt's types.


I guess a dark corner is going to be GUI network applications (which I
have as one of my pet projects). Qt supports GUI and network on the same
event loop, which is both good and terrible. For PyQt5 with a single
thread (and a GIL) it is great. For languages such as D and C++ which
can manage multiple kernel threads on multicore machines I would think
separate even loops would be better (but I don't yet have any data, I am
just beginning to try this idea out – it is likely that many people have
already trodden this route…) For this latter case the D architecture I
have in mind is vibe.d for network and GtkD or QtD^H^H^HDQt for GUI. I
suspect to do this sensibly needs signals for Qt.
[…]
-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 04 2014
prev sibling parent reply Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 04/05/2014 11:21, "Marc Schütz" <schuetzm gmx.net>" a écrit :

 A "meta" question, not related to your specific implementation:

 While Qt is certainly the most powerful and comprehensive portable GUI
 framework, it also contains lots of code that's not related to user
 interfaces: strings, multi-threading support, file abstractions,
 containers, databases interfaces, etc. In short: Things which properly
 should be part of the standard library, but aren't (widely) available,
 or not working well enough in C++.

 Now, Qt depends on those, and if you want to interact with it, you need
 to use them in your own code. Doesn't that cause a lot of friction? Just
 as a random example, QListView can take its elements from a data source
 ("model"). But in D, that data source might be idiomatically implemented
 as a range, so it has to be adapted first. Or, a more frequent thing:
 char[] vs. QString.

 Could it be a better strategy to only re-use low-level functionality of
 Qt internally, but provide more idiomatic public D interfaces for it?


With a friend we created the DQuick project cause of our major interest 
of the QtQuick (also called QML) part of Qt framework and also for the 
reason you invoke. For us phobos already aim to implement same things 
than QtCore, and wrapping primitive types of Qt seems hard and will 
introduce design constraint and poor performances. It's certainly bad 
for a longterm vision.

IMO DQt will be interesting for those looking for a stable GUI library 
based on widget essentially.
DQuick have no chance to be usable in production before years if we 
continue to develop it.
We are back after a long break, it's really hard to stay motivated cause 
we have some difficulties with points aren't fixed in D, mainly GC 
issues, signals,... My friend just find get the property binding working 
in D code, but he doesn't like his code :-).

I see DQt/gtkD and DQuick as complementary projects. I hope we will 
capable to provide good enough GUI libraries to D community shortly.
May 04 2014
parent reply "w0rp" <devw0rp gmail.com> writes:
On Sunday, 4 May 2014 at 13:32:13 UTC, Xavier Bigand wrote:

 With a friend we created the DQuick project cause of our major 
 interest of the QtQuick (also called QML) part of Qt framework 
 and also for the reason you invoke. For us phobos already aim 
 to implement same things than QtCore, and wrapping primitive 
 types of Qt seems hard and will introduce design constraint and 
 poor performances. It's certainly bad for a longterm vision.

 IMO DQt will be interesting for those looking for a stable GUI 
 library based on widget essentially.
 DQuick have no chance to be usable in production before years 
 if we continue to develop it.
 We are back after a long break, it's really hard to stay 
 motivated cause we have some difficulties with points aren't 
 fixed in D, mainly GC issues, signals,... My friend just find 
 get the property binding working in D code, but he doesn't like 
 his code :-).

 I see DQt/gtkD and DQuick as complementary projects. I hope we 
 will capable to provide good enough GUI libraries to D 
 community shortly.


Best of luck to you guys. I encourage as many people as possible 
to give writing D GUI libraries a go, and perhaps we can all 
learn from each other.
May 04 2014
parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as 
 possible to give writing D GUI libraries a go, and perhaps we 
 can all learn from each other.


Done ;)

http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org
May 04 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/4/14, 9:19 AM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as possible to
 give writing D GUI libraries a go, and perhaps we can all learn from
 each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


Worth a reddit announcement tomorrow morning? -- Andrei
May 04 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


 Worth a reddit announcement tomorrow morning? -- Andrei


TkD is nice,but the exe's Memory usage is 6.8~7M,but DFL's only 
2.8~3M,and only a single file on windows 7.

https://github.com/Rayerd/dfl,
https://github.com/FrankLIKE/dfl
May 05 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-05 7:00 PM, FrankLike wrote:

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


 Worth a reddit announcement tomorrow morning? -- Andrei


 TkD is nice,but the exe's Memory usage is 6.8~7M,but DFL's only
 2.8~3M,and only a single file on windows 7.

 https://github.com/Rayerd/dfl,
 https://github.com/FrankLIKE/dfl


I've just started using tkd and the memory usage is 3.4MB on windows for 
a Hello World.

It requires a lot of tcl/tk source files (900 files) and 2 dlls, but I 
think a workaround can be found for them to be packed in an in-place 
unpacker app by compiling on top of it (I'm looking into this right 
now). It would be good to have an application that know what to trim out 
too. The zipped size of a tkd application is 3 MB.

It's very simple to use, it implements a lot of the D idioms and, most 
of all, it's stable. I appreciate the effort very much!
May 06 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 07/05/14 01:05, Etienne wrote:


 I've just started using tkd and the memory usage is 3.4MB on windows for
 a Hello World.

 It requires a lot of tcl/tk source files (900 files) and 2 dlls, but I
 think a workaround can be found for them to be packed in an in-place
 unpacker app by compiling on top of it (I'm looking into this right
 now). It would be good to have an application that know what to trim out
 too. The zipped size of a tkd application is 3 MB.

 It's very simple to use, it implements a lot of the D idioms and, most
 of all, it's stable. I appreciate the effort very much!


Have you tried DWT [1]? It has no dependencies except for the system 
libraries. Although, it will generate quite large binaries. But I don't 
think they'll grow that much when adding new functionality.

[1] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg
May 06 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-07 2:40 AM, Jacob Carlborg wrote:

 On 07/05/14 01:05, Etienne wrote:


 I've just started using tkd and the memory usage is 3.4MB on windows for
 a Hello World.

 It requires a lot of tcl/tk source files (900 files) and 2 dlls, but I
 think a workaround can be found for them to be packed in an in-place
 unpacker app by compiling on top of it (I'm looking into this right
 now). It would be good to have an application that know what to trim out
 too. The zipped size of a tkd application is 3 MB.

 It's very simple to use, it implements a lot of the D idioms and, most
 of all, it's stable. I appreciate the effort very much!


 Have you tried DWT [1]? It has no dependencies except for the system
 libraries. Although, it will generate quite large binaries. But I don't
 think they'll grow that much when adding new functionality.

 [1] https://github.com/d-widget-toolkit/dwt


Sweet, as I see it works and there's plenty of documentation about swt. 
Not much can beat a 2.6MB standalone application with a 2mb footprint!

It could use a dub.json file though, and the Color object gives me a 
memory error when I close the window.
May 07 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-05-07 20:18, Etienne wrote:


 Sweet, as I see it works and there's plenty of documentation about swt.
 Not much can beat a 2.6MB standalone application with a 2mb footprint!

 It could use a dub.json file though


Yeah, that's on my todo list.


 and the Color object gives me a memory error when I close the window.


It does? Do you have a test case?

-- 
/Jacob Carlborg
May 07 2014
parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-07 3:30 PM, Jacob Carlborg wrote:

 On 2014-05-07 20:18, Etienne wrote:


 Sweet, as I see it works and there's plenty of documentation about swt.
 Not much can beat a 2.6MB standalone application with a 2mb footprint!

 It could use a dub.json file though


 Yeah, that's on my todo list.


 and the Color object gives me a memory error when I close the window.


 It does? Do you have a test case?


Yes :

  Label label3 =
new
Label(shell, SWT.NONE);
label3.setSize(100,20);
label3.setLocation(30,150);
label3.setBackground(
new
Color(display,200,111,50));
label3.setText(
"Speak no evil"
);
May 07 2014
next sibling parent reply Etienne <etcimon gmail.com> writes:
On 2014-05-07 6:22 PM, Etienne wrote:

 On 2014-05-07 3:30 PM, Jacob Carlborg wrote:

 On 2014-05-07 20:18, Etienne wrote:


 Sweet, as I see it works and there's plenty of documentation about swt.
 Not much can beat a 2.6MB standalone application with a 2mb footprint!

 It could use a dub.json file though


 Yeah, that's on my todo list.


 and the Color object gives me a memory error when I close the window.


 It does? Do you have a test case?


 Yes :

   Label label3 =
 new
 Label(shell, SWT.NONE);
 label3.setSize(100,20);
 label3.setLocation(30,150);
 label3.setBackground(
 new
 Color(display,200,111,50));
 label3.setText(
 "Speak no evil"
 );


I was looking at a quick tutorial here:
http://www.cs.umanitoba.ca/~eclipse/2-Basic.pdf

It works great without the setBackground
May 07 2014
next sibling parent reply "FrankLike" <1150015857 qq.com> writes:
 Sweet, as I see it works and there's plenty of documentation 
 about swt.
 Not much can beat a 2.6MB standalone application with a 2mb 
 footprint!








I test  on  windows 7,it's size is 2829k,with a  2836k footprint.
But DFL's  is 778k with a  2724k.

example:github.com/SeijiFujita/dfl-examples-d2

Frank
May 07 2014
parent reply Etienne Cimon <etcimon gmail.com> writes:
On 2014-05-07 23:04, FrankLike wrote:

 Sweet, as I see it works and there's plenty of documentation about
 swt.
 Not much can beat a 2.6MB standalone application with a 2mb footprint!








 I test  on  windows 7,it's size is 2829k,with a  2836k footprint.
 But DFL's  is 778k with a  2724k.

 example:github.com/SeijiFujita/dfl-examples-d2

 Frank


I'm not sure if dfl would have layouts? Can you make the elements 
stretch along with the window resize action without writing custom 
algorithms?
May 07 2014
parent "FrankLike" <1150015857 qq.com> writes:
 I'm not sure if dfl would have layouts? Can you make the 
 elements stretch along with the window resize action without 
 writing custom algorithms?


DFL  is  so good,someone will do it.

Frank
May 07 2014
prev sibling parent reply "FrankLike" <1150015857 qq.com> writes:
https://github.com/SeijiFujita/dfl-examples-d2
May 07 2014
parent reply "John" <john.joyus gmail.com> writes:
On Thursday, 8 May 2014 at 03:06:48 UTC, FrankLike wrote:

 https://github.com/SeijiFujita/dfl-examples-d2


Do you have any screenshots? Thanks.
May 07 2014
parent "FrankLike" <1150015857 qq.com> writes:
On Thursday, 8 May 2014 at 05:17:09 UTC, 
Johhttps://github.com/FrankLikeps://github.com/FrankLike/dflrote:

 On Thursday, 8 May 2014 at 03:06:48 UTC, FrankLike wrote:

 https://github.com/SeijiFujita/dfl-examples-d2


 Do you have any screenshots? Thanks.


get the DFL by https://github.com/FrankLike/dfl

You can get make the dfl.lib  by  the bat file.

Then make  the exsmples by bat file.

Frank
May 07 2014
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 08/05/14 00:22, Etienne wrote:


 Yes :

   Label label3 =
 new
 Label(shell, SWT.NONE);
 label3.setSize(100,20);
 label3.setLocation(30,150);
 label3.setBackground(
 new
 Color(display,200,111,50));
 label3.setText(
 "Speak no evil"
 );


Thanks, I'll have a look. Could you please report an issue here as well 
(I assume you're using Windows) :

https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86

-- 
/Jacob Carlborg
May 07 2014
parent Etienne Cimon <etcimon gmail.com> writes:
On 2014-05-08 02:09, Jacob Carlborg wrote:

 On 08/05/14 00:22, Etienne wrote:


 Yes :

   Label label3 =
 new
 Label(shell, SWT.NONE);
 label3.setSize(100,20);
 label3.setLocation(30,150);
 label3.setBackground(
 new
 Color(display,200,111,50));
 label3.setText(
 "Speak no evil"
 );


 Thanks, I'll have a look. Could you please report an issue here as well
 (I assume you're using Windows) :

 https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86


Yes, I also added a pull request here: 
https://github.com/d-widget-toolkit/dwt/pull/13
May 08 2014
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Tuesday, 6 May 2014 at 23:05:40 UTC, Etienne wrote:

 It requires a lot of tcl/tk source files (900 files) and 2 
 dlls, but I think a workaround can be found for them to be 
 packed in an in-place unpacker app by compiling on top of it 
 (I'm looking into this right now). It would be good to have an 
 application that know what to trim out too. The zipped size of 
 a tkd application is 3 MB.


Nah, it doesn't need that much. You can have Tcl/Tk installed on 
the machine which for posix is no trouble as it's shipped with 
the OS. For Windows you can just copy the DLL's and library 
folder to the exe directory. It's all explained in the readme. 
https://github.com/nomad-software/tkd/blob/master/README.md


 It's very simple to use, it implements a lot of the D idioms 
 and, most of all, it's stable. I appreciate the effort very 
 much!


Thanks.
May 07 2014
prev sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Sunday, 4 May 2014 at 17:51:50 UTC, Andrei Alexandrescu wrote:

 On 5/4/14, 9:19 AM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as 
 possible to
 give writing D GUI libraries a go, and perhaps we can all 
 learn from
 each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


 Worth a reddit announcement tomorrow morning? -- Andrei


Just seen this. Yeah an announcement would be great, what time do 
you think is best for maximum impact? Do you want to do it?
May 07 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/14, 12:29 PM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 17:51:50 UTC, Andrei Alexandrescu wrote:

 On 5/4/14, 9:19 AM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as possible to
 give writing D GUI libraries a go, and perhaps we can all learn from
 each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


 Worth a reddit announcement tomorrow morning? -- Andrei


 Just seen this. Yeah an announcement would be great, what time do you
 think is best for maximum impact? Do you want to do it?


9 AM PST. Will do tomorrow. -- Andrei
May 07 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-05-07 at 12:53 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]

 9 AM PST. Will do tomorrow. -- Andrei


So what is that in ISO 8601 time. Get with the programme…

;-)

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 07 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/14, 1:02 PM, Russel Winder via Digitalmars-d wrote:

 On Wed, 2014-05-07 at 12:53 -0700, Andrei Alexandrescu via Digitalmars-d
 wrote:
 […]

 9 AM PST. Will do tomorrow. -- Andrei


 So what is that in ISO 8601 time. Get with the programme…


Where's that units library when you need it?
May 07 2014
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 7 May 2014 at 20:02:20 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Wed, 2014-05-07 at 12:53 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 […]

 9 AM PST. Will do tomorrow. -- Andrei


 So what is that in ISO 8601 time. Get with the programme…

 ;-)


Pacific Standard Time, UTC−8:00
Pakistan Standard Time, UTC+5:00
Philippine Standard Time, UTC+8:00
May 08 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Thu, 2014-05-08 at 20:09 +0000, Kagamin via Digitalmars-d wrote:

 On Wednesday, 7 May 2014 at 20:02:20 UTC, Russel Winder via 
 Digitalmars-d wrote:

 On Wed, 2014-05-07 at 12:53 -0700, Andrei Alexandrescu via 
 Digitalmars-d
 wrote:
 […]

 9 AM PST. Will do tomorrow. -- Andrei


 So what is that in ISO 8601 time. Get with the programme…

 ;-)


 
 Pacific Standard Time, UTC−8:00
 Pakistan Standard Time, UTC+5:00
 Philippine Standard Time, UTC+8:00


:-)

I think we can infer that Andrei meant to say 09:00-08:00. Unless there
is some shenanigans with moving the clocks forward an hour.


Please see this public service announcement:  http://xkcd.com/1179/

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
May 08 2014
parent reply "Kagamin" <spam here.lot> writes:
On Friday, 9 May 2014 at 05:00:48 UTC, Russel Winder via 
Digitalmars-d wrote:

 Pacific Standard Time, UTC−8:00
 Pakistan Standard Time, UTC+5:00
 Philippine Standard Time, UTC+8:00


 :-)

 I think we can infer that Andrei meant to say 09:00-08:00. 
 Unless there
 is some shenanigans with moving the clocks forward an hour.


He probably refers to some study of reddit activity, results of 
that study might not match his time zone. Also you detected it as 
UTC-7.


 Please see this public service announcement:  
 http://xkcd.com/1179/


Though it lists 20130227 as discouraged format, but it's a valid 
ISO 8601 format, and phobos Date.toISOString generates string in 
that format:
May 09 2014
parent Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Fri, 09 May 2014 09:56:09 +0000
Kagamin via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 Please see this public service announcement:
 http://xkcd.com/1179/


 Though it lists 20130227 as discouraged format, but it's a valid
 ISO 8601 format, and phobos Date.toISOString generates string in
 that format:



Yes, it's supported, because it's standard, but it's preferred that
toISOExtString be used precisely because the non-extended format is not only
discouraged, but it's harder to read (which is probably why it's discouraged).

- Jonathan M Davis
May 12 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 5/7/14, 12:53 PM, Andrei Alexandrescu wrote:

 On 5/7/14, 12:29 PM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 17:51:50 UTC, Andrei Alexandrescu wrote:

 On 5/4/14, 9:19 AM, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as possible to
 give writing D GUI libraries a go, and perhaps we can all learn from
 each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


 Worth a reddit announcement tomorrow morning? -- Andrei


 Just seen this. Yeah an announcement would be great, what time do you
 think is best for maximum impact? Do you want to do it?


 9 AM PST. Will do tomorrow. -- Andrei


http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/

https://twitter.com/D_Programming/status/464434846849179648

https://www.facebook.com/dlang.org/posts/843295265684156

https://hn.algolia.com/#!/story/forever/0/Tkd


Andrei
May 08 2014
next sibling parent "FrankLike" <1150015857 qq.com> writes:
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/

 https://twitter.com/D_Programming/status/464434846849179648

 https://www.facebook.com/dlang.org/posts/843295265684156

 https://hn.algolia.com/#!/story/forever/0/Tkd


 Andrei


Hello,
TKD is very nice, and it's easy to use,but how to build it to 
small? Such as the size is below to 1M, not must have the lib 
,and Memory usage is below to 3M.

Thank you.

Frank.
May 08 2014
prev sibling parent "FrankLike" <1150015857 qq.com> writes:
http://www.reddit.com/r/programming/comments/251s5i/tkd_cross_platform_gui_toolkit_for_d_based_on/

 https://twitter.com/D_Programming/status/464434846849179648

 https://www.facebook.com/dlang.org/posts/843295265684156

 https://hn.algolia.com/#!/story/forever/0/Tkd


 Andrei


Hello,
TKD is very nice, and it's easy to use,but how to build it to
small? Such as the size is below to 1M, not must have the lib
,and Memory usage is below to 3M.

Thank you.

Frank.
May 08 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Sunday, 4 May 2014 at 16:19:32 UTC, Gary Willoughby wrote:

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as 
 possible to give writing D GUI libraries a go, and perhaps we 
 can all learn from each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


I just read your announcement and this is very good.
May 04 2014
prev sibling parent Xavier Bigand <flamaros.xavier gmail.com> writes:
Le 04/05/2014 18:19, Gary Willoughby a écrit :

 On Sunday, 4 May 2014 at 14:09:38 UTC, w0rp wrote:

 Best of luck to you guys. I encourage as many people as possible to
 give writing D GUI libraries a go, and perhaps we can all learn from
 each other.


 Done ;)

 http://forum.dlang.org/thread/wdddgiowaidcojbrklsg forum.dlang.org


It's a great news.
May 04 2014
prev sibling parent reply Joseph Rushton Wakeling via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 03/05/14 13:00, w0rp via Digitalmars-d wrote:

 Hello everyone. From time to time, people ask in the newsgroup and also IRC
 about Qt bindings for D, so I thought it would be a good idea to give people an
 update on where my own bindings stand. First, if you want to take a look at my
 code as it stands, you can get it here.

 https://github.com/w0rp/dqt


First of all, it's fantastic that you're working on this.  Many thanks!

I won't comment on the details of the code; it's outside my area of experience, 
but I do think that Qt support is something that will be very important for 
adoption of D.


 So, I am eager to hear what people think about all of this. Does anyone like
the
 work that I have done, and will it be useful? Have I committed some terrible
 crime against nature, for which I must be punished? Does anyone have any ideas
 about things that could be improved, or where to go next? Please, let me know.


A remark about your README: it lists as dependencies "A recent Qt 4 version, 
like Qt 4.8".

I think you should be far more explicit, far earlier in the README, about 
exactly which Qt versions are supported.  Pretty much the first question I had 
on my mind, clicking on the link to your project, was, "Is this going to
support 
Qt 5.x ... ?"

I also think that a focus on 4.x rather than 5.x is likely to be 
counter-productive.  5.2+ seems to be where all the interest is these days.


 My progress has been somewhat slow in writing all of this, as I have been
 writing it mostly in the evenings, moslty during weekdays, after my day job.
 I've also been running into problems for which there are no easy answers,
 possibly no documentation for, and so on. So a great deal of my time has been
 spent more on thinking of what to do next, rather than writing anything. (It
 took me possibly months to come up with the resource management scheme that I
 have now.)


I can sympathize with your predicament as I often find myself in the same 
position.  The good side is that the time spent thinking in this way is usually 
very productive when one comes to finally sit down and write :-)
May 04 2014
parent reply "w0rp" <devw0rp gmail.com> writes:
On Sunday, 4 May 2014 at 13:08:38 UTC, Joseph Rushton Wakeling via

 A remark about your README: it lists as dependencies "A recent 
 Qt 4 version, like Qt 4.8".

 I think you should be far more explicit, far earlier in the 
 README, about exactly which Qt versions are supported.  Pretty 
 much the first question I had on my mind, clicking on the link 
 to your project, was, "Is this going to support Qt 5.x ... ?"

 I also think that a focus on 4.x rather than 5.x is likely to 
 be counter-productive.  5.2+ seems to be where all the interest 
 is these days.


Qt 4.8 support comes largely from what is possible easily now. 
DQt uses SMOKE to wrap Qt. In particular smokeqt, which produces 
the SMOKE Qt bindings. You can get smokeqt for Qt 4 straight from 
most package managers (Arch Linux, Debian, Gentoo, ...) and it's 
also the current master version of the project on git. Someone 
has very recently been working on a Qt5 branch for smokeqt, so I 
expect Qt 5 support to come soon. Qt5 support for smokeqt will 
directly influcence Qt 5 support in DQt, and I might jump on it 
early for binding functions as slots. (A Qt 5 feature.)

Qt 4 support basically arises from what is easy to do right now. 
Supporting Qt 5 doesn't seem that far off. I went with Qt 4 for 
now because it's easier, and at this stage it's more important to 
work with something that can actually work and learn from that, 
than to try and work with something which might not actually work 
at all.
May 04 2014
parent Etienne Cimon <etcimon gmail.com> writes:
On 2014-05-04 09:26, w0rp wrote:

 Qt 4 support basically arises from what is easy to do right now.
 Supporting Qt 5 doesn't seem that far off. I went with Qt 4 for now
 because it's easier, and at this stage it's more important to work with
 something that can actually work and learn from that, than to try and
 work with something which might not actually work at all.


Nice work, I think Qt 4 is a very nice start and can help bring a lot 
more interest in D from the C++ crowd if it's successfully implemented, 
I think these people worry mostly about using the same data types and 
interface in a new programming language.
May 05 2014