Re: The Current Status of DQt
On Fri, 09 May 2014 09:56:09 + 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: http://dlang.org/phobos/std_datetime.html#.Date.toISOString 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
Re: The Current Status of DQt
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: http://dlang.org/phobos/std_datetime.html#.Date.toISOString
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@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
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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
Re: The Current Status of DQt
On Thu, 2014-05-08 at 20:09 +, 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.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
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@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?
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@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
Re: The Current Status of DQt
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.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
Re: The Current Status of DQt
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?
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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 );
Re: The Current Status of DQt
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
Re: The Current Status of DQt
https://github.com/SeijiFujita/dfl-examples-d2
Re: The Current Status of DQt
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?
Re: The Current Status of DQt
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
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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
Re: The Current Status of DQt
On 2014-05-05 7:00 PM, FrankLike wrote: http://forum.dlang.org/thread/wdddgiowaidcojbrk...@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!
Re: The Current Status of DQt
http://forum.dlang.org/thread/wdddgiowaidcojbrk...@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
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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?
Re: The Current Status of DQt
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 :-)
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
On Sun, 2014-05-04 at 13:15 +, 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.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
Re: The Current Status of DQt
Le 04/05/2014 11:21, Marc Schütz schue...@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.
Re: The Current Status of DQt
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.
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@forum.dlang.org
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@forum.dlang.org I just read your announcement and this is very good.
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@forum.dlang.org Worth a reddit announcement tomorrow morning? -- Andrei
Re: The Current Status of DQt
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/wdddgiowaidcojbrk...@forum.dlang.org It's a great news.
Re: The Current Status of DQt
On Sat, 03 May 2014 11:00:37 + 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
Re: The Current Status of DQt
On Sat, 2014-05-03 at 11:00 +, 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.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
Re: The Current Status of DQt
I'm intersting for DQt is better than QML.
Re: The Current Status of DQt
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.
