Current state of GUI's

[Chris via Digitalmars-d]

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.