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 

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>. 

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 

 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