www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Current state of GUI's

reply "motaito" <noPublic address.com> writes:
Hi,

I haven't used D before and wanted to take a closer look at it. 
However, there are a few things that keep me from doing so. Most 
notably I am somewhat confused about the state of GUI's. I have 
looked at a couple projects and online resources, but the 
resources I found seam to be quite outdated. Sorry in advance, if 
I have missed some update on the topic. I wanted to ask, if there 
is something in the workings (or already done) to provide a 
standard way to create GUI's. Something supported by D, not an 
independent project. Independent projects tend to scare me away, 
as they almost always get abandoned at some point. I am looking 
for a cross platform (Windows, Linux, BSD) solution.

I very much enjoyed working with QT before, especially QML and 
would like to use something, that essentially replaces C++ with D 
for QML. I only found QtD which also seams to be abandoned. Or 
(maybe even preferable) something similar to .NET and WPF as this 
makes it very easy and flexible to create modern GUI's. I would 
like to install a D environment and get working without having to 
build other projects for GUI's.

e.g.
import std.GUI;

void main(string[] args)
{
	auto win = loadGUIFromXML("Path/to/gui.xml");
	win.show();
}

The XML could then have bindings to D-Modules to handle events 
and perform the actual tasks.

e.g.
<dgui>
	<resources>
		<import module="someModule.d" id="sm" />
	</resources>
	<window width="640" height="480">
		<button text="click me" clickEvent="sm:someFunction()" />
		<content path="path/to/other/xml/gui/for/nested/components" />
	</window>
</dgui>

// some component to be loaded into the window above
<dgui>
	<resources>
		<import module="otherModule.d" id="om" />
	</resources>
	<component>
		<button text="click me" clickEvent="om:otherFunction()" 
orientation="LeftToRight">
			<image path="src/to/icon.png" />
			<text content="some text for the button"/>
		</button>
		<label text="some label text" />
	</component>
</dgui>

Does D offer something like this by now? What is the current 
state/standard for GUI creation?
Sep 03 2015
next sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 3 September 2015 at 12:19:25 UTC, motaito wrote:
 Hi,

 I haven't used D before and wanted to take a closer look at it. 
 However, there are a few things that keep me from doing so. 
 Most notably I am somewhat confused about the state of GUI's. I 
 have looked at a couple projects and online resources, but the 
 resources I found seam to be quite outdated. Sorry in advance, 
 if I have missed some update on the topic. I wanted to ask, if 
 there is something in the workings (or already done) to provide 
 a standard way to create GUI's. Something supported by D, not 
 an independent project. Independent projects tend to scare me 
 away, as they almost always get abandoned at some point. I am 
 looking for a cross platform (Windows, Linux, BSD) solution.

 [...]
Not sure of its current state, but you should check out DOtherSide: https://github.com/filcuc/DOtherSide
Sep 03 2015
parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 12:51:18 UTC, CraigDillabaugh 
wrote:
 Not sure of its current state, but you should check out 
 DOtherSide:

 https://github.com/filcuc/DOtherSide
Thanks for the link. I will take a closer look at it. But does this also mean, that there is no "built in" GUI solution for D?
Sep 03 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 04/09/15 1:21 AM, motaito wrote:
 On Thursday, 3 September 2015 at 12:51:18 UTC, CraigDillabaugh wrote:
 Not sure of its current state, but you should check out DOtherSide:

 https://github.com/filcuc/DOtherSide
Thanks for the link. I will take a closer look at it. But does this also mean, that there is no "built in" GUI solution for D?
Short answer: Don't expect anything in Phobos short term. In the mean time you'll probably want a c/c++ library such as QT. Long answer: We're probably about 2 years away before anything useful and even then it will have a huge push back unless e.g. Andrei says we must have a GUI toolkit! We've got money to make it happen. That's if my work gets into Phobos when I am planning it to (unlikely). I know its grim, but keep in mind we need a platform abstraction that supports things like an event loop, window creation independent of what the system actually supports. An image abstraction with common manipulation/formats. Then on top of a platform abstraction some people also need other forms of event handling and the list goes on. But I am actively working on an image library and a window + context creation library for Phobos. It's just a year away. https://github.com/rikkimax/alphaPhobos Not to scare you aware or anything, but you probably don't want a pure Phobos solution anyway.
Sep 03 2015
next sibling parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 14:13:26 UTC, Rikki Cattermole 
wrote:
 Short answer:

 Don't expect anything in Phobos short term.
 In the mean time you'll probably want a c/c++ library such as 
 QT.


 Long answer:

 We're probably about 2 years away before anything useful and 
 even then it will have a huge push back unless e.g. Andrei says 
 we must have a GUI toolkit! We've got money to make it happen.

 That's if my work gets into Phobos when I am planning it to 
 (unlikely).

 I know its grim, but keep in mind we need a platform 
 abstraction that supports things like an event loop, window 
 creation independent of what the system actually supports. An 
 image abstraction with common manipulation/formats.

 Then on top of a platform abstraction some people also need 
 other forms of event handling and the list goes on.

 But I am actively working on an image library and a window + 
 context creation library for Phobos. It's just a year away.
 https://github.com/rikkimax/alphaPhobos

 Not to scare you aware or anything, but you probably don't want 
 a pure Phobos solution anyway.
Thanks for the details! I was afraid, of something like this. To me D doesn't seam very competitive without a complete toolset :( Given that D has been around for a while now I am somewhat surprised it's not further along. I know it's a lot of work and not easy to do but clearly there has been a need for this for many years now. The resources I found were several years old (not including that they must have been working on it for a while before abandoning the project). It will be hard to compete with something like QT. I was hoping for a cross platform solution that would deliver good performance without the complexity of c/c++. But if there is no built in solution QT seams a better option. I wanted to avoid QT because of the added complexity and the QT-windows tend to lag on a windows platform. This may go away with updates and bugfixes though. Anyway, I hope you will be successful with alphaPhobos. I think D needs it, so don't abandon it! I will keep an eye out and check again in about a year or so. But for now I have to rethink whether to use D or not. Out of curiosity, why do you think that I wouldn't want a Phobos solution? Wouldn't an integrated solution be better? I would not have to maintain a build of an external third party project, that may or may not be abandoned in the future, not knowing whether there will be updates, bugfixes or missing features to be added. It seams like quite a bit extra management for my project if I have to keep a third party project up to date and may need to adjust my code due to an update in an external project.
Sep 03 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 04/09/15 3:15 AM, motaito wrote:
 Anyway, I hope you will be successful with alphaPhobos. I think D needs
 it, so don't abandon it! I will keep an eye out and check again in about
 a year or so. But for now I have to rethink whether to use D or not.
Thanks, this is a long term thing. I've been planning this for ~2 years. Previous was Devisualization (Github org of mine). So a bunch of code has actually originated here. Before that DOOGLE. Even some of that came from OOGL (ported it from c++ to D as D_OOGL).
 Out of curiosity, why do you think that I wouldn't want a Phobos
 solution? Wouldn't an integrated solution be better? I would not have to
 maintain a build of an external third party project, that may or may not
 be abandoned in the future, not knowing whether there will be updates,
 bugfixes or missing features to be added. It seams like quite a bit
 extra management for my project if I have to keep a third party project
 up to date and may need to adjust my code due to an update in an
 external project.
Because, at best case the graphics could be very ugly and lacking of features in a GUI toolkit. We're just too far away from it. We need to focus on getting the core problems solved. So that people can flourish with building e.g. GUI toolkits unimpeded by what we support. Also helps interop between them. After we have a decent one, then we can consider it for Phobos. I know the current situation is unfortunate. We've had some pretty major changes in the last few years and that is ok. I hope we do get to a point where it is easy to get started in almost any problem domain :)
Sep 03 2015
parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 15:26:45 UTC, Rikki Cattermole 
wrote:
 On 04/09/15 3:15 AM, motaito wrote:
 Anyway, I hope you will be successful with alphaPhobos. I 
 think D needs
 it, so don't abandon it! I will keep an eye out and check 
 again in about
 a year or so. But for now I have to rethink whether to use D 
 or not.
Thanks, this is a long term thing. I've been planning this for ~2 years. Previous was Devisualization (Github org of mine). So a bunch of code has actually originated here. Before that DOOGLE. Even some of that came from OOGL (ported it from c++ to D as D_OOGL).
 Out of curiosity, why do you think that I wouldn't want a 
 Phobos
 solution? Wouldn't an integrated solution be better? I would 
 not have to
 maintain a build of an external third party project, that may 
 or may not
 be abandoned in the future, not knowing whether there will be 
 updates,
 bugfixes or missing features to be added. It seams like quite 
 a bit
 extra management for my project if I have to keep a third 
 party project
 up to date and may need to adjust my code due to an update in 
 an
 external project.
Because, at best case the graphics could be very ugly and lacking of features in a GUI toolkit. We're just too far away from it. We need to focus on getting the core problems solved. So that people can flourish with building e.g. GUI toolkits unimpeded by what we support. Also helps interop between them. After we have a decent one, then we can consider it for Phobos. I know the current situation is unfortunate. We've had some pretty major changes in the last few years and that is ok. I hope we do get to a point where it is easy to get started in almost any problem domain :)
Again Thanks for the details. It's very much appreciated. From a usability stand point for alphaPhobos. Are you more going into the direction of WPF or QML, using a declaration file or more along the lines of a QWidget, building the GUI through instantiating objects inside a D-module?
Sep 03 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 04/09/15 3:37 AM, motaito wrote:
 On Thursday, 3 September 2015 at 15:26:45 UTC, Rikki Cattermole wrote:
 On 04/09/15 3:15 AM, motaito wrote:
 Anyway, I hope you will be successful with alphaPhobos. I think D needs
 it, so don't abandon it! I will keep an eye out and check again in about
 a year or so. But for now I have to rethink whether to use D or not.
Thanks, this is a long term thing. I've been planning this for ~2 years. Previous was Devisualization (Github org of mine). So a bunch of code has actually originated here. Before that DOOGLE. Even some of that came from OOGL (ported it from c++ to D as D_OOGL).
 Out of curiosity, why do you think that I wouldn't want a Phobos
 solution? Wouldn't an integrated solution be better? I would not have to
 maintain a build of an external third party project, that may or may not
 be abandoned in the future, not knowing whether there will be updates,
 bugfixes or missing features to be added. It seams like quite a bit
 extra management for my project if I have to keep a third party project
 up to date and may need to adjust my code due to an update in an
 external project.
Because, at best case the graphics could be very ugly and lacking of features in a GUI toolkit. We're just too far away from it. We need to focus on getting the core problems solved. So that people can flourish with building e.g. GUI toolkits unimpeded by what we support. Also helps interop between them. After we have a decent one, then we can consider it for Phobos. I know the current situation is unfortunate. We've had some pretty major changes in the last few years and that is ok. I hope we do get to a point where it is easy to get started in almost any problem domain :)
Again Thanks for the details. It's very much appreciated. From a usability stand point for alphaPhobos. Are you more going into the direction of WPF or QML, using a declaration file or more along the lines of a QWidget, building the GUI through instantiating objects inside a D-module?
Neither, I'm not touching GUI's itself. Only the creation of a window and a context. GUI's are far too controversial and for good reason. They are next to impossible to do properly. But that is not a popular opinion :p Here is more or less what I'm planning on supporting: https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/ui/window/defs.d There is a bunch of optional features you will notice in other files. Such as a menu, notifications and even screenshots.
Sep 03 2015
parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 15:41:34 UTC, Rikki Cattermole 
wrote:
 Neither, I'm not touching GUI's itself. Only the creation of a 
 window and a context.

 GUI's are far too controversial and for good reason. They are 
 next to impossible to do properly. But that is not a popular 
 opinion :p

 Here is more or less what I'm planning on supporting: 
 https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/ui/window/defs.d
 There is a bunch of optional features you will notice in other 
 files. Such as a menu, notifications and even screenshots.
I see, more like a unified groundwork for someone to build a GUI on top. Looks like an interesting project. Good luck with alphaPhobos! It will be interesting to see it move forward.
Sep 03 2015
parent reply "Zekereth" <viserion.thrall gmail.com> writes:
On Thursday, 3 September 2015 at 16:18:34 UTC, motaito wrote:
 On Thursday, 3 September 2015 at 15:41:34 UTC, Rikki Cattermole 
 wrote:
 Neither, I'm not touching GUI's itself. Only the creation of a 
 window and a context.

 GUI's are far too controversial and for good reason. They are 
 next to impossible to do properly. But that is not a popular 
 opinion :p

 Here is more or less what I'm planning on supporting: 
 https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/ui/window/defs.d
 There is a bunch of optional features you will notice in other 
 files. Such as a menu, notifications and even screenshots.
I see, more like a unified groundwork for someone to build a GUI on top. Looks like an interesting project. Good luck with alphaPhobos! It will be interesting to see it move forward.
https://github.com/buggins/dlangui is fairly complete and contains DML - DlangUI Markup Language - similar to QML.
Sep 03 2015
parent reply "thedeemon" <dlang thedeemon.com> writes:
On Thursday, 3 September 2015 at 16:31:33 UTC, Zekereth wrote:
 https://github.com/buggins/dlangui is fairly complete and 
 contains DML - DlangUI Markup Language - similar to QML.
+1, came here to mention dlangui. It already works and contains a lot of good stuff, including layout engine and markup language.
Sep 03 2015
parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 16:36:31 UTC, thedeemon wrote:
 On Thursday, 3 September 2015 at 16:31:33 UTC, Zekereth wrote:
 https://github.com/buggins/dlangui is fairly complete and 
 contains DML - DlangUI Markup Language - similar to QML.
+1, came here to mention dlangui. It already works and contains a lot of good stuff, including layout engine and markup language.
Zekereth and thedeemon I guess I will stick to QT for my current project, but I will build some smaller learning projects in D, to try out various GUI libraries. DlangUI seams promising. I probably will either use DlangUI or GtkD.
Sep 03 2015
parent reply "bachmeier" <no spam.com> writes:
On Thursday, 3 September 2015 at 17:58:21 UTC, motaito wrote:
  Zekereth and  thedeemon
 I guess I will stick to QT for my current project, but I will 
 build some smaller learning projects in D, to try out various 
 GUI libraries. DlangUI seams promising. I probably will either 
 use DlangUI or GtkD.
Hopefully you will help by creating documentation (writing a blog post about your adventure would be a valuable exercise) and filing bug reports/feature requests. Even if you can't use any of them now you can push the process along.
Sep 03 2015
parent "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 19:59:24 UTC, bachmeier wrote:
 On Thursday, 3 September 2015 at 17:58:21 UTC, motaito wrote:
  Zekereth and  thedeemon
 I guess I will stick to QT for my current project, but I will 
 build some smaller learning projects in D, to try out various 
 GUI libraries. DlangUI seams promising. I probably will either 
 use DlangUI or GtkD.
Hopefully you will help by creating documentation (writing a blog post about your adventure would be a valuable exercise) and filing bug reports/feature requests. Even if you can't use any of them now you can push the process along.
I can't make any promises. It will depend on how busy I will be. But I keep it in mind. If I write something, you could find it on www.motaito.com. I have only a few things there (installing arch and gentoo for beginners). I could make an additional post in this forum (provide a link), if I find the time to do so. Right now I would say it's somewhat unlikely, but if the interest is there, I can try to find the time.
Sep 03 2015
prev sibling next sibling parent reply "Shannon" <refaQtor gmail.com> writes:
On Thursday, 3 September 2015 at 15:15:47 UTC, motaito wrote:

 Thanks for the details! I was afraid, of something like this. 
 To me D doesn't seam very competitive without a complete 
 toolset :( Given that D has been around for a while now I am 
 somewhat surprised it's not further along. I know it's a lot of 
 work and not easy to do but clearly there has been a need for 
 this for many years now. The resources I found were several 
 years old (not including that they must have been working on it 
 for a while before abandoning the project). It will be hard to 
 compete with something like QT.

 I was hoping for a cross platform solution that would deliver 
 good performance without the complexity of c/c++. But if there 
 is no built in solution QT seams a better option. I wanted to 
 avoid QT because of the added complexity and the QT-windows 
 tend to lag on a windows platform. This may go away with 
 updates and bugfixes though.
With D's relatively easy ability to link C libs, gtkD is the way I would've gone, IF I wasn't such a satisfied and long time user of Qt across BeOS-OS/2-BSD-Windows-OSX-Android-iOS-embedded Linux (did I miss any?). The monumental amount of continual work involved in keeping a consistent professional interface blended into the "major" operating systems and adjusted to make the native user feel at home seems folly to attempt - though I do keep my fingers crossed for dlangui for a gui lib done the "D" way. Anyway, though I have so enjoyed the huge part of Qt that is non-gui, and especially their model/view components where I can do all my model manipulation behind the scenes and practically hot-swap or connect multiple views to a model. I've spent much of the last year building commandline applications with D running on the desktop and behind production web applications on aws servers. And I've found a novel way to relatively easily hook up thin Qt graphical interfaces on top of the commandline app that interacts with JSON via stdin/stdout as it does on servers. In the Qt graphical interface I put, for example, a QTableView which I connect to a thin class that inherits QAbstractTableModel and implements four methods, three of which are 1 liners. The other method simply connects to stdin and converts the JSON that it receives, from the D commandline app, into data for each (row,column) that the View calls for. I actually embed the D executable into the Qt application, then extract and run it when the Qt app starts up. I'm always amazed how un-noticably fast that is. So, best of both worlds. The D implementation is generally easier/more enjoyable for the actual guts of the tool, and I get a perfectly slick Qt user interface. sorry, this is already too long. I mean to open up and example repo/wiki with that pattern. RSN (Real Soon Now) good luck.
Sep 03 2015
next sibling parent "Shannon" <refaQtor gmail.com> writes:
On Friday, 4 September 2015 at 03:36:37 UTC, Shannon wrote:
 On Thursday, 3 September 2015 at 15:15:47 UTC, motaito wrote:
oh, DOtherSide was mentioned. the first time I looked at it. it implements QAbstractListModel .. very familiar. I should study that some more.
Sep 03 2015
prev sibling parent "motaito" <noPublic address.com> writes:
On Friday, 4 September 2015 at 03:36:37 UTC, Shannon wrote:
 Anyway, though I have so enjoyed the huge part of Qt that is 
 non-gui, and especially their model/view components where I can 
 do all my model manipulation behind the scenes and practically 
 hot-swap or connect multiple views to a model.
I have rarely a need for non-gui apps myself. Maybe I have been looking at D with wrong expectations to begin with. QT has some nifty tools :) I have to admit that I became lazi with gui modeling, after having spent lots of time using c#. With WPF you practically get sorting and filtering of tables for free. I have come to really like the MVVM pattern with WPF. It is very convenient.
 And I've found a novel way to relatively easily hook up thin Qt 
 graphical interfaces on top of the commandline app that 
 interacts with JSON via stdin/stdout as it does on servers.
That sound very interesting!
 So, best of both worlds.  The D implementation is generally 
 easier/more enjoyable for the actual guts of the tool, and I 
 get a perfectly slick Qt user interface.
That's exactly was I was hoping for with D. Maybe I should try to give your approach a try.
 sorry, this is already too long.  I mean to open up and example 
 repo/wiki with that pattern. RSN (Real Soon Now)
If you have the time, please to so!
Sep 03 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Thursday, 3 September 2015 at 15:15:47 UTC, motaito wrote:
 Thanks for the details! I was afraid, of something like this. 
 To me D doesn't seam very competitive without a complete 
 toolset :( Given that D has been around for a while now I am 
 somewhat surprised it's not further along. I know it's a lot of 
 work and not easy to do but clearly there has been a need for 
 this for many years now. The resources I found were several 
 years old (not including that they must have been working on it 
 for a while before abandoning the project). It will be hard to 
 compete with something like QT.

 I was hoping for a cross platform solution that would deliver 
 good performance without the complexity of c/c++. But if there 
 is no built in solution QT seams a better option. I wanted to 
 avoid QT because of the added complexity and the QT-windows 
 tend to lag on a windows platform. This may go away with 
 updates and bugfixes though.

 Anyway, I hope you will be successful with alphaPhobos. I think 
 D needs it, so don't abandon it! I will keep an eye out and 
 check again in about a year or so. But for now I have to 
 rethink whether to use D or not.

 Out of curiosity, why do you think that I wouldn't want a 
 Phobos solution? Wouldn't an integrated solution be better? I 
 would not have to maintain a build of an external third party 
 project, that may or may not be abandoned in the future, not 
 knowing whether there will be updates, bugfixes or missing 
 features to be added. It seams like quite a bit extra 
 management for my project if I have to keep a third party 
 project up to date and may need to adjust my code due to an 
 update in an external project.
Don't give up yet. I've learned that a D GUI is not so important. There is a plethora of platforms and devices (mobile phones, tablets, PCs etc etc), so it's better not to get married to one particular UI. Keep your program GUI-agnostic and then you can connect it to any GUI you want. And D is easy to connect to: C(++), Lua (LuaD) and Python (PyD). With D you can concentrate on the program, the GUI could be anything. E.g. look at how the DCD/Dscanner plug-in works with Textadept and other editors. https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support
Sep 04 2015
parent reply "motaito" <noPublic address.com> writes:
On Friday, 4 September 2015 at 09:12:23 UTC, Chris wrote:
 Don't give up yet. I've learned that a D GUI is not so 
 important. There is a plethora of platforms and devices (mobile 
 phones, tablets, PCs etc etc), so it's better not to get 
 married to one particular UI. Keep your program GUI-agnostic 
 and then you can connect it to any GUI you want. And D is easy 
 to connect to: C(++), Lua (LuaD) and Python (PyD).

 With D you can concentrate on the program, the GUI could be 
 anything. E.g. look at how the DCD/Dscanner plug-in works with 
 Textadept and other editors.

 https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support
At first I thought, yes your right. But on second thought that kind of brings me back to the initial question. I would prefer an integrated solution, so I don't have the hustle with dependencies. With your approach, I also have to maintain a dependency. E.g. if I choose PyD I also need to distribute it to the end user. I am not even sure, if I would also need to have python as separate dependency or if it's included in PyD. Either way while python may be common on Linux, it is not a standard on Windows. I have the same problem with something like GtkD. The Gtk Framework is common on Linux but not on windows. I don't have such issues with QT. There I have all in one package. All I have to do is include the required dll's. QT is also very common in many Linux distributions. So, I can just compile and give it to anyone who is interested without the hustle of more dependencies. BSD is certainly the most difficult to find a solution. Such a great OS so little support. But they too have QT. I was hoping to basically use QT with D instead of C++. Shannon made a post with an interesting approach. I think I will look more into that first. But thanks for the tip!
Sep 04 2015
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-04 15:23, motaito wrote:

 BSD is certainly the most difficult to find a solution.
I tried compiling DWT on PC-BSD and it compile just if I remove one check for Linux. Although it doesn't link because I haven't managed to install the necessary libraries yet. -- /Jacob Carlborg
Sep 04 2015
parent reply "motaito" <noPublic address.com> writes:
On Friday, 4 September 2015 at 14:47:47 UTC, Jacob Carlborg wrote:
 On 2015-09-04 15:23, motaito wrote:

 BSD is certainly the most difficult to find a solution.
I tried compiling DWT on PC-BSD and it compile just if I remove one check for Linux. Although it doesn't link because I haven't managed to install the necessary libraries yet.
Glad to see someone giving an effort for BSD. It would be awesome to have more developers keeping it in mind.
Sep 05 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-05 13:41, motaito wrote:

 Glad to see someone giving an effort for BSD. It would be awesome to
 have more developers keeping it in mind.
It links now when I manged to install all the dependencies, but it doesn't run :(. Segfaults for some reason, I haven't looked in to it. -- /Jacob Carlborg
Sep 05 2015
parent reply "motaito" <noPublic address.com> writes:
On Saturday, 5 September 2015 at 19:13:12 UTC, Jacob Carlborg 
wrote:
 It links now when I manged to install all the dependencies, but 
 it doesn't run :(. Segfaults for some reason, I haven't looked 
 in to it.
Bummer... However, I appreciate that you are giving it a shot! But you see my point. An out of the box solution like QT would be worth gold. That's the one thing Microsoft got right. They have awesome developer tools. Or in the words of Steve Ballmer: "Developers! Developers! Developers!" :) Instead of loosing time you could just focus on building some software. Imagine D would have a kick ass IDE like visual studio but cross platform like QT. Productivity, efficiency and performance in one. Too bad D doesn't have the option for paid developers to create something like this. It's just too much work for your spare time. So, it's unlikely to happen any time soon :( Still, I very much appreciate people like Rikki Cattermole who builds a base to work of for others. The problem is for a few individuals that just takes a long time to complete.
Sep 05 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 06/09/15 11:43 AM, motaito wrote:
 On Saturday, 5 September 2015 at 19:13:12 UTC, Jacob Carlborg wrote:
 It links now when I manged to install all the dependencies, but it
 doesn't run :(. Segfaults for some reason, I haven't looked in to it.
Bummer... However, I appreciate that you are giving it a shot! But you see my point. An out of the box solution like QT would be worth gold. That's the one thing Microsoft got right. They have awesome developer tools. Or in the words of Steve Ballmer: "Developers! Developers! Developers!" :) Instead of loosing time you could just focus on building some software. Imagine D would have a kick ass IDE like visual studio but cross platform like QT. Productivity, efficiency and performance in one. Too bad D doesn't have the option for paid developers to create something like this. It's just too much work for your spare time. So, it's unlikely to happen any time soon :( Still, I very much appreciate people like Rikki Cattermole who builds a base to work of for others. The problem is for a few individuals that just takes a long time to complete.
I would very much appreciate people helping out. E.g. Contributing manipulation functions, image loader / exporter. Most importantly unittests. Fix bugs. I'll most likely do the PNG test case infrastructure, but it would make things go a few months faster if somebody took ownership of testing in general. I'll also be creating a TODO list for what needs to happen with Phobos. E.g. nogc version of std.string:indexOf. So plenty of places anybody can jump in and help :)
Sep 05 2015
parent "motaito" <noPublic address.com> writes:
On Sunday, 6 September 2015 at 02:27:42 UTC, Rikki Cattermole 
wrote:
 I would very much appreciate people helping out.
 E.g. Contributing manipulation functions, image loader / 
 exporter.

 Most importantly unittests. Fix bugs.
 I'll most likely do the PNG test case infrastructure, but it 
 would make things go a few months faster if somebody took 
 ownership of testing in general.

 I'll also be creating a TODO list for what needs to happen with 
 Phobos. E.g.  nogc version of std.string:indexOf. So plenty of 
 places anybody can jump in and help :)
I can imagine that you could need help. With work and private projects I am pretty much max out already for the foreseeable future. That's also why I was hoping that D already has the tool, to speed up the process. I hope you find someone though!
Sep 06 2015
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-09-06 01:43, motaito wrote:

 Bummer... However, I appreciate that you are giving it a shot!

 But you see my point. An out of the box solution like QT would be worth
 gold. That's the one thing Microsoft got right. They have awesome
 developer tools. Or in the words of Steve Ballmer: "Developers!
 Developers! Developers!" :)

 Instead of loosing time you could just focus on building some software.
 Imagine D would have a kick ass IDE like visual studio but cross
 platform like QT. Productivity, efficiency and performance in one. Too
 bad D doesn't have the option for paid developers to create something
 like this. It's just too much work for your spare time. So, it's
 unlikely to happen any time soon :(
Yeah, I completely agree.
 Still, I very much appreciate people like Rikki Cattermole who builds a
 base to work of for others. The problem is for a few individuals that
 just takes a long time to complete.
That's also why I work on DWT and not a custom library. It's a port of SWT to D. -- /Jacob Carlborg
Sep 06 2015
prev sibling parent reply "Chris" <wendlec tcd.ie> writes:
On Friday, 4 September 2015 at 13:23:47 UTC, motaito wrote:
 On Friday, 4 September 2015 at 09:12:23 UTC, Chris wrote:
 Don't give up yet. I've learned that a D GUI is not so 
 important. There is a plethora of platforms and devices 
 (mobile phones, tablets, PCs etc etc), so it's better not to 
 get married to one particular UI. Keep your program 
 GUI-agnostic and then you can connect it to any GUI you want. 
 And D is easy to connect to: C(++), Lua (LuaD) and Python 
 (PyD).

 With D you can concentrate on the program, the GUI could be 
 anything. E.g. look at how the DCD/Dscanner plug-in works with 
 Textadept and other editors.

 https://github.com/Hackerpilot/DCD/wiki/IDEs-and-Editors-with-DCD-support
At first I thought, yes your right. But on second thought that kind of brings me back to the initial question. I would prefer an integrated solution, so I don't have the hustle with dependencies. With your approach, I also have to maintain a dependency. E.g. if I choose PyD I also need to distribute it to the end user. I am not even sure, if I would also need to have python as separate dependency or if it's included in PyD. Either way while python may be common on Linux, it is not a standard on Windows. I have the same problem with something like GtkD. The Gtk Framework is common on Linux but not on windows. I don't have such issues with QT. There I have all in one package. All I have to do is include the required dll's. QT is also very common in many Linux distributions. So, I can just compile and give it to anyone who is interested without the hustle of more dependencies. BSD is certainly the most difficult to find a solution. Such a great OS so little support. But they too have QT. I was hoping to basically use QT with D instead of C++. Shannon made a post with an interesting approach. I think I will look more into that first. But thanks for the tip!
I see what you mean. As far as I know, the libraries (PyD, LuaD etc.) would be in the static build of the executable, so you wouldn't have to "distribute" them, only Python or Lua. But that's no problem either, just include lua5.x.so/dll. Please guys, correct me, if I'm wrong here, I don't wanna give motaito any wrong information. This said, the GUI should only be a very very thin layer on top of your actual program, regardless. What if your users say that they want a different GUI (Mac users for example, they don't accept anything that is a bit different), or the D-GUI doesn't work on a given OS for some reason, or a new GUI is introduced with a new OS. That's why I said that your program should never get married to a specific GUI.
Sep 04 2015
parent "motaito" <noPublic address.com> writes:
On Friday, 4 September 2015 at 15:03:59 UTC, Chris wrote:
 I see what you mean. As far as I know, the libraries (PyD, LuaD 
 etc.) would be in the static build of the executable, so you 
 wouldn't have to "distribute" them, only Python or Lua. But 
 that's no problem either, just include lua5.x.so/dll. Please 
 guys, correct me, if I'm wrong here, I don't wanna give motaito 
 any wrong information.
I'll just try it and see if it works. If I can simply include the .so/dll I guess it would work well enough. It's more of a hustle if e.g. python has to be installed by the user.
Sep 05 2015
prev sibling parent "jmh530" <john.michael.hall gmail.com> writes:
On Thursday, 3 September 2015 at 14:13:26 UTC, Rikki Cattermole 
wrote:
 Short answer:

 Don't expect anything in Phobos short term.
 In the mean time you'll probably want a c/c++ library such as 
 QT.
I really don't know much about GUI programming. I was looking at some basic info about GTK+, which led me to GObject, which led me to the Vala language. My understanding is that Vala is basically an OO version of C (i.e. it works well with GObject without a lot of the complexity of writing GObject code). People seem to be using it with GNOME. Maybe to your point about not having a pure D solution, it might be useful to investigate this as well.
Sep 03 2015
prev sibling parent reply "CraigDillabaugh" <craig.dillabaugh gmail.com> writes:
On Thursday, 3 September 2015 at 13:21:45 UTC, motaito wrote:
 On Thursday, 3 September 2015 at 12:51:18 UTC, CraigDillabaugh 
 wrote:
 Not sure of its current state, but you should check out 
 DOtherSide:

 https://github.com/filcuc/DOtherSide
Thanks for the link. I will take a closer look at it. But does this also mean, that there is no "built in" GUI solution for D?
No there is no standard D GUI. There are lots of efforts by different community members like DWT (https://github.com/d-widget-toolkit/dwt). I pointed you to DOtherSide because of all the GUI's I've heard of it seemed the closest to what you are looking for. I think DWT is the most complete of the D GUI libraries available though. I think part of the issues is that there is no strong consensus in the community as to what form a D GUI would take, through there is certainly a lot of discussion.
Sep 03 2015
parent "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 14:16:19 UTC, CraigDillabaugh 
wrote:
 No there is no standard D GUI.  There are lots of efforts by 
 different
 community members like DWT 
 (https://github.com/d-widget-toolkit/dwt). I
 pointed you to DOtherSide because of all the GUI's I've heard 
 of it
 seemed the closest to what you are looking for.  I think DWT is 
 the
 most complete of the D GUI libraries available though.

 I think part of the issues is that there is no strong consensus
 in the community as to what form a D GUI would take, through 
 there
 is certainly a lot of discussion.
Thanks for the input! I was hoping for a standard D Gui though. I guess I have to give it a shot, before making a final decision.
Sep 03 2015
prev sibling next sibling parent reply "Mike James" <foo bar.com> writes:
On Thursday, 3 September 2015 at 12:19:25 UTC, motaito wrote:
 Hi,

 I haven't used D before and wanted to take a closer look at it. 
 However, there are a few things that keep me from doing so. 
 Most notably I am somewhat confused about the state of GUI's. I 
 have looked at a couple projects and online resources, but the 
 resources I found seam to be quite outdated. Sorry in advance, 
 if I have missed some update on the topic. I wanted to ask, if 
 there is something in the workings (or already done) to provide 
 a standard way to create GUI's. Something supported by D, not 
 an independent project. Independent projects tend to scare me 
 away, as they almost always get abandoned at some point. I am 
 looking for a cross platform (Windows, Linux, BSD) solution.

 [...]
Have a look at GtkD and DWT - they are the most complete. I've written small apps using both and they work :-) With GtkD you can use the Glade Builder to simplify design of the GUI elements.
Sep 03 2015
parent "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 14:24:29 UTC, Mike James wrote:
 Have a look at GtkD and DWT - they are the most complete. I've 
 written small apps using both and they work :-)
 With GtkD you can use the Glade Builder to simplify design of 
 the GUI elements.
Thanks for the reply. A graphical tool to build the GUI might come in handy :) I will remember it, in case I decide to use D. Right now I am on the fence... (I pointed this already out in an other reply to rikki, but I will like wait before using D).
Sep 03 2015
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-03 14:19, motaito wrote:

 I am looking for a cross platform (Windows, Linux, BSD) solution.
Others have already mentioned DWT. It officially only support Windows and Linux. It might be easy to get it to work on BSD since the platform is similar to Linux, assuming GTK is used. -- /Jacob Carlborg
Sep 03 2015
parent "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 14:35:44 UTC, Jacob Carlborg 
wrote:
 On 2015-09-03 14:19, motaito wrote:

 I am looking for a cross platform (Windows, Linux, BSD) 
 solution.
Others have already mentioned DWT. It officially only support Windows and Linux. It might be easy to get it to work on BSD since the platform is similar to Linux, assuming GTK is used.
Thanks for the tip. It's always hard to find out of the box support for BSD. That request was probably a bit of a stretch :)
Sep 03 2015
prev sibling next sibling parent reply Jim Hewes <jimhewes gmail.com> writes:
On 9/3/2015 5:19 AM, motaito wrote:
 Hi,

 I haven't used D before and wanted to take a closer look at it. However,
 there are a few things that keep me from doing so.
I'm in a similar place as you are. While D is better than C++, right now C++ plus JUCE is better for me overall than D plus <whatever GUI lib>. C# plus WPF seems attractive too except that WPF isn't cross platform. Anyway, I still always keep an eye on D.
Sep 03 2015
parent reply "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 16:40:56 UTC, Jim Hewes wrote:
 I'm in a similar place as you are. While D is better than C++, 
 right now C++ plus JUCE is better for me overall than D plus 
 <whatever GUI lib>. C# plus WPF seems attractive too except 
 that WPF isn't cross platform. Anyway, I still always keep an 
 eye on D.
Yeah, it's a shame that the mono framework does not support WPF. I think WPF and MEF are the two most powerful features from .NET (for me anyway, that may be subjective). And working in visual studio is really nice too. I wish there was a cross platform IDE like that. I don't quite like the text editor from eclipse, but I haven't used it in a while. Maybe I need to give it another try.
Sep 03 2015
next sibling parent reply Jim Hewes <jimhewes gmail.com> writes:
On 9/3/2015 10:51 AM, motaito wrote:
 And working in visual studio is really nice
 too. I wish there was a cross platform IDE like that. I don't quite like
 the text editor from eclipse, but I haven't used it in a while. Maybe I
 need to give it another try.
Just in case you hadn't seen it, there is now Visual Studio Code: https://code.visualstudio.com/ Although I haven't really looked at it myself. I don't think it can accept plug-ins (yet) such as VisualD so that may rule it out.
Sep 03 2015
parent "motaito" <noPublic address.com> writes:
On Thursday, 3 September 2015 at 18:12:38 UTC, Jim Hewes wrote:
 On 9/3/2015 10:51 AM, motaito wrote:
 And working in visual studio is really nice
 too. I wish there was a cross platform IDE like that. I don't 
 quite like
 the text editor from eclipse, but I haven't used it in a 
 while. Maybe I
 need to give it another try.
Just in case you hadn't seen it, there is now Visual Studio Code: https://code.visualstudio.com/ Although I haven't really looked at it myself. I don't think it can accept plug-ins (yet) such as VisualD so that may rule it out.
I forgot about visual studio code. Right now I am trying to move away from windows products and only support the windows platform for cross platform reasons. It's a shame though, I used visual studio for years and it's my favorite IDE. However, I have a moral issue with the data collection philosophy that windows is currently trying to enforce. Just like visual studio code, among the first things you have to agree to is the terms and privacy policy, which will try to collect as much data as they can. I think something like visual studio code is their way to get data from other platforms as well... Otherwise it would look interesting and I would certainly give it a shot but I try to support this behavior as little as possible. Thanks for the tip though!
Sep 03 2015
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 09/03/2015 01:51 PM, motaito wrote:
 Yeah, it's a shame that the mono framework does not support WPF. I think
 WPF and MEF are the two most powerful features from .NET (for me anyway,
 that may be subjective). And working in visual studio is really nice
 too. I wish there was a cross platform IDE like that. I don't quite like
 the text editor from eclipse, but I haven't used it in a while. Maybe I
 need to give it another try.
I thought Mono did support that. Like in GitExtentions which runs fine on Linux (well, aside from frequent crashing). Or is WPF different from "win forms"?
Sep 03 2015
next sibling parent "motaito" <noPublic address.com> writes:
On Friday, 4 September 2015 at 00:11:02 UTC, Nick Sabalausky 
wrote:
 On 09/03/2015 01:51 PM, motaito wrote:
 Yeah, it's a shame that the mono framework does not support 
 WPF. I think
 WPF and MEF are the two most powerful features from .NET (for 
 me anyway,
 that may be subjective). And working in visual studio is 
 really nice
 too. I wish there was a cross platform IDE like that. I don't 
 quite like
 the text editor from eclipse, but I haven't used it in a 
 while. Maybe I
 need to give it another try.
I thought Mono did support that. Like in GitExtentions which runs fine on Linux (well, aside from frequent crashing). Or is WPF different from "win forms"?
Afaik, WPF is not supported nor are there any plans to do so. http://www.mono-project.com/docs/gui/wpf/ MEF may be supported, I haven't found any info. It's possible that it will be supported with with the .NET 5 framework coming up.
Sep 03 2015
prev sibling parent "thedeemon" <dlang thedeemon.com> writes:
On Friday, 4 September 2015 at 00:11:02 UTC, Nick Sabalausky 
wrote:
 On 09/03/2015 01:51 PM, motaito wrote:
 Yeah, it's a shame that the mono framework does not support 
 WPF.
 I thought Mono did support that. Like in GitExtentions which 
 runs fine on Linux (well, aside from frequent crashing). Or is 
 WPF different from "win forms"?
Yes, it's totally different. WinForms is based on good old WinAPI with classical windows, dialogs, controls and GDI for drawing. WPF is based on a new engine over DirectX with lots of vector graphics, transformations and effects, everything GPU-accelerated. They remade everything - windows, controls and layouts are described declaratively in XAML format (XML-based), then everything is rendered with that new engine, even text is drawn differently (and in first versions looked differently). Mono never had and probably will never have WPF because this DirectX-based rendering engine is too hard to port.
Sep 03 2015
prev sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Thursday, 3 September 2015 at 12:19:25 UTC, motaito wrote:
 ...
Please see: http://wiki.dlang.org/GUI_Libraries
Sep 03 2015