www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Favorite GUI library?

reply TheGag96 <thegag96 gmail.com> writes:
Heya guys. For my projects that use a GUI library, I've tried 
both tkd and DlangUI. Both I feel have their drawbacks, and I'd 
like to know if any of you are using anything you find better. In 
my case, my ideal choice would be:

- Nice bindings/API, friendly to idiomatic D
- Cross platform
- Can compile to a standalone binary (no shared libraries or 
extra files)
- Reasonably efficient
- Support for a good amount of well-working widgets

Although quite a cool library, my biggest issue with DlangUI was 
that it was a little mind-bending at times to keep track of 
multiple widgets that view/modify the same data without screwing 
things up. I saw QtE5 recently and have been thinking about 
trying it out.

What do you all recommend? Thanks!
Apr 22 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 23/04/2018 6:12 PM, TheGag96 wrote:

 Heya guys. For my projects that use a GUI library, I've tried both tkd 
 and DlangUI. Both I feel have their drawbacks, and I'd like to know if 
 any of you are using anything you find better. In my case, my ideal 
 choice would be:
 
 - Nice bindings/API, friendly to idiomatic D
 - Cross platform
 - Can compile to a standalone binary (no shared libraries or extra files)
 - Reasonably efficient
 - Support for a good amount of well-working widgets
 
 Although quite a cool library, my biggest issue with DlangUI was that it 
 was a little mind-bending at times to keep track of multiple widgets 
 that view/modify the same data without screwing things up. I saw QtE5 
 recently and have been thinking about trying it out.
 
 What do you all recommend? Thanks!


Just an FYI, when windowing is done properly there will be extra shared 
libraries. You can't get away from it without a lot of duplication of 
code that other libraries have developed (and is standard).
Apr 22 2018
prev sibling next sibling parent Andrea Fontana <nospam example.com> writes:
On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:

 Heya guys. For my projects that use a GUI library, I've tried 
 both tkd and DlangUI. Both I feel have their drawbacks, and I'd 
 like to know if any of you are using anything you find better. 
 In my case, my ideal choice would be:

 - Nice bindings/API, friendly to idiomatic D
 - Cross platform
 - Can compile to a standalone binary (no shared libraries or 
 extra files)
 - Reasonably efficient
 - Support for a good amount of well-working widgets

 Although quite a cool library, my biggest issue with DlangUI 
 was that it was a little mind-bending at times to keep track of 
 multiple widgets that view/modify the same data without 
 screwing things up. I saw QtE5 recently and have been thinking 
 about trying it out.

 What do you all recommend? Thanks!


Did you try dwt or gtkd?

Andrea
Apr 23 2018
prev sibling next sibling parent reply Zoadian <no no.no> writes:
On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:

 Heya guys. For my projects that use a GUI library, I've tried 
 both tkd and DlangUI. Both I feel have their drawbacks, and I'd 
 like to know if any of you are using anything you find better. 
 In my case, my ideal choice would be:

 - Nice bindings/API, friendly to idiomatic D
 - Cross platform
 - Can compile to a standalone binary (no shared libraries or 
 extra files)
 - Reasonably efficient
 - Support for a good amount of well-working widgets

 Although quite a cool library, my biggest issue with DlangUI 
 was that it was a little mind-bending at times to keep track of 
 multiple widgets that view/modify the same data without 
 screwing things up. I saw QtE5 recently and have been thinking 
 about trying it out.

 What do you all recommend? Thanks!


i'm happy with:
vibe.d + CEF + vue.js
Apr 23 2018
parent reply Chris <wendlec tcd.ie> writes:
On Monday, 23 April 2018 at 09:50:21 UTC, Zoadian wrote:


 i'm happy with:
 vibe.d + CEF + vue.js


Good point. I've been thinking about vibe.d + HTML/JS based UIs 
too. I think that's where UIs are increasingly moving towards: 
HTML+CSS + some sort of web-based backends.
Apr 23 2018
parent reply TheGag96 <thegag96 gmail.com> writes:
On Monday, 23 April 2018 at 11:26:30 UTC, Chris wrote:

 On Monday, 23 April 2018 at 09:50:21 UTC, Zoadian wrote:


 i'm happy with:
 vibe.d + CEF + vue.js


 Good point. I've been thinking about vibe.d + HTML/JS based UIs 
 too. I think that's where UIs are increasingly moving towards: 
 HTML+CSS + some sort of web-based backends.


That's definitely what I'm trying to avoid... I feel those kinds 
of interfaces are 99% of the time mega bloated for what they are. 
Discord is the only one that seemed big enough for the britches 
of an entire browser instance. Absolutely not a fan of Electron 
and the like.

I have never tried dwt! I should give that a shot. And I was 
trying gtkd once, and I should probably try again. Back then, I 
had to compile with --build=plain due to some weird linker issues.
Apr 23 2018
next sibling parent reply Zoadian <no no.no> writes:
On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:

 On Monday, 23 April 2018 at 11:26:30 UTC, Chris wrote:

 On Monday, 23 April 2018 at 09:50:21 UTC, Zoadian wrote:


 i'm happy with:
 vibe.d + CEF + vue.js


 Good point. I've been thinking about vibe.d + HTML/JS based 
 UIs too. I think that's where UIs are increasingly moving 
 towards: HTML+CSS + some sort of web-based backends.


 That's definitely what I'm trying to avoid... I feel those 
 kinds of interfaces are 99% of the time mega bloated for what 
 they are. Discord is the only one that seemed big enough for 
 the britches of an entire browser instance. Absolutely not a 
 fan of Electron and the like.


If we are talking binary size: then yes, I agree.
But it is a lot easier to maintain & write than QT-Widgets/GTK 
based code.
Apr 23 2018
parent reply Nerve <nervecenter7 gmail.com> writes:
On Monday, 23 April 2018 at 14:56:37 UTC, Zoadian wrote:

 If we are talking binary size: then yes, I agree.
 But it is a lot easier to maintain & write than QT-Widgets/GTK 
 based code.


Users don't care how easy it is for you to maintain your code. If 
the user experience sucks, they'll never come back.

When code readability, size, and maintenance gains all coincide 
with performance, it's a rare thing indeed, but in most cases 
developers have to make a tradeoff. I agree with TheGag96 that 
Discord is probably the only application with a feature set that 
justifies the tradeoffs.

Mailboxes, taskers, and text editors consuming 150 Mb of RAM, 
multiple processes, spare CPU cycles, and battery life rendering 
a blinking cursor is an instant uninstall. The user DOES NOT CARE 
how easy it is for you to maintain your codebase.
Apr 23 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/23/2018 11:46 PM, Nerve wrote:

 The user DOES NOT CARE how easy it is 
 for you to maintain your codebase.


That needs to be painted on every wall, and etched into every computer, 
and tattooed onto every forehead, at every developer workspace in the world.
Apr 24 2018
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:


 That's definitely what I'm trying to avoid... I feel those 
 kinds of interfaces are 99% of the time mega bloated for what 
 they are. Discord is the only one that seemed big enough for 
 the britches of an entire browser instance. Absolutely not a 
 fan of Electron and the like.

 I have never tried dwt! I should give that a shot. And I was 
 trying gtkd once, and I should probably try again. Back then, I 
 had to compile with --build=plain due to some weird linker 
 issues.


The advantage of using web technologies for UI:

- high re-usability: use the same or similar layout+functionality 
for desktop, Android/iPhone apps and web based UIs.
- freedom as to layout and theming with CSS (highly customizable 
for users too)
- cross platform: no need to deploy libs (e.g. Gtk on Mac and 
Windows)
- maintenance: older JS code / CSS will still be ok in _most_ 
cases, whereas Gtk and other frameworks introduce depractaions 
and breaking changes so that you have to a) rewrite parts of your 
code and b) maintain older (outdated) versions of the program 
until you can be sure that the older libs are no longer used / 
distributed
- distribution: While users don't care about your maintenance 
costs, they do care about having an app available on their smart 
phones/desktops/online. So multiply various versions of say a Gtk 
app by platform (_at least_ you have to maintain 2Gtk*3Platform = 
6 apps). Users hate being told that it only works on Linux 
desktop. Thus, web technologies can be a real gain.
- progress: web technologies have made huge progress JS and CSS 
are much better now. Layout and js engines are much smarter as 
well. So you benefit from this and get it more or less for free 
on every platform.
Apr 24 2018
next sibling parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

 On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:


 That's definitely what I'm trying to avoid... I feel those 
 kinds of interfaces are 99% of the time mega bloated for what 
 they are. Discord is the only one that seemed big enough for 
 the britches of an entire browser instance. Absolutely not a 
 fan of Electron and the like.

 I have never tried dwt! I should give that a shot. And I was 
 trying gtkd once, and I should probably try again. Back then, 
 I had to compile with --build=plain due to some weird linker 
 issues.


 The advantage of using web technologies for UI:

 - high re-usability: use the same or similar 
 layout+functionality for desktop, Android/iPhone apps and web 
 based UIs.
 - freedom as to layout and theming with CSS (highly 
 customizable for users too)
 - cross platform: no need to deploy libs (e.g. Gtk on Mac and 
 Windows)
 - maintenance: older JS code / CSS will still be ok in _most_ 
 cases, whereas Gtk and other frameworks introduce depractaions 
 and breaking changes so that you have to a) rewrite parts of 
 your code and b) maintain older (outdated) versions of the 
 program until you can be sure that the older libs are no longer 
 used / distributed
 - distribution: While users don't care about your maintenance 
 costs, they do care about having an app available on their 
 smart phones/desktops/online. So multiply various versions of 
 say a Gtk app by platform (_at least_ you have to maintain 
 2Gtk*3Platform = 6 apps). Users hate being told that it only 
 works on Linux desktop. Thus, web technologies can be a real 
 gain.
 - progress: web technologies have made huge progress JS and CSS 
 are much better now. Layout and js engines are much smarter as 
 well. So you benefit from this and get it more or less for free 
 on every platform.


These are nice points, but the fact remains that running a web 
browser torun something as simple as a text editor is extremely 
inefficient. I personally don't use atom, VS-code or anything 
else, because they are all very slow. I tried VC-code once. It 
was nice in terms of UI, but was borderline unusable because it 
would take almost half a second to register keys, and the laptop 
fans would always spin up.
Using it on a laptop means:
- You will be using far more memory. This means its harder to 
open multiple tabs or programs (profiler + editor or docs in 
Firefox)
- Mobile device battery life takes a hit. This is non negligible. 
Battery life on my old mac using just vim (with a few plugins) is 
6 hrs. With vs-code it was 2-3 hrs
- Way more on disk memory. With disk space becoming cheap, this 
is less of a concern for most modern devices, but why be 
wasteful? Besides, in developing countries, its still pretty hard 
to get lots of storage, which means users are forced to decide 
which apps are more important.
- If the mobile device's CPU is under less load, in general it 
will remain cooler and thus less likely to throttle. Putting 
pressure on the thermal cap by running CPU intensive programs 
like a browser, when it can be done more efficiently is bad

We should be getting more efficient with time, especially 
considering Moore's law is on its last legs, not less efficient
Apr 24 2018
parent reply Uknown <sireeshkodali1 gmail.com> writes:
On Tuesday, 24 April 2018 at 11:15:43 UTC, Uknown wrote:

 On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

 On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:


 That's definitely what I'm trying to avoid... I feel those 
 kinds of interfaces are 99% of the time mega bloated for what 
 they are. Discord is the only one that seemed big enough for 
 the britches of an entire browser instance. Absolutely not a 
 fan of Electron and the like.

 I have never tried dwt! I should give that a shot. And I was 
 trying gtkd once, and I should probably try again. Back then, 
 I had to compile with --build=plain due to some weird linker 
 issues.


 The advantage of using web technologies for UI:

 - high re-usability: use the same or similar 
 layout+functionality for desktop, Android/iPhone apps and web 
 based UIs.
 - freedom as to layout and theming with CSS (highly 
 customizable for users too)
 - cross platform: no need to deploy libs (e.g. Gtk on Mac and 
 Windows)
 - maintenance: older JS code / CSS will still be ok in _most_ 
 cases, whereas Gtk and other frameworks introduce depractaions 
 and breaking changes so that you have to a) rewrite parts of 
 your code and b) maintain older (outdated) versions of the 
 program until you can be sure that the older libs are no 
 longer used / distributed
 - distribution: While users don't care about your maintenance 
 costs, they do care about having an app available on their 
 smart phones/desktops/online. So multiply various versions of 
 say a Gtk app by platform (_at least_ you have to maintain 
 2Gtk*3Platform = 6 apps). Users hate being told that it only 
 works on Linux desktop. Thus, web technologies can be a real 
 gain.
 - progress: web technologies have made huge progress JS and 
 CSS are much better now. Layout and js engines are much 
 smarter as well. So you benefit from this and get it more or 
 less for free on every platform.


 These are nice points, but the fact remains that running a web 
 browser torun something as simple as a text editor is extremely 
 inefficient. I personally don't use atom, VS-code or anything 
 else, because they are all very slow. I tried VC-code once. It 
 was nice in terms of UI, but was borderline unusable because it 
 would take almost half a second to register keys, and the 
 laptop fans would always spin up.
 Using it on a laptop means:
 - You will be using far more memory. This means its harder to 
 open multiple tabs or programs (profiler + editor or docs in 
 Firefox)
 - Mobile device battery life takes a hit. This is non 
 negligible. Battery life on my old mac using just vim (with a 
 few plugins) is 6 hrs. With vs-code it was 2-3 hrs
 - Way more on disk memory. With disk space becoming cheap, this 
 is less of a concern for most modern devices, but why be 
 wasteful? Besides, in developing countries, its still pretty 
 hard to get lots of storage, which means users are forced to 
 decide which apps are more important.
 - If the mobile device's CPU is under less load, in general it 
 will remain cooler and thus less likely to throttle. Putting 
 pressure on the thermal cap by running CPU intensive programs 
 like a browser, when it can be done more efficiently is bad

 We should be getting more efficient with time, especially 
 considering Moore's law is on its last legs, not less efficient


I forgot to mention consistency. This is the biggest reason I 
don't use non native apps. I'm not talking about your app being 
consistent across operating systems. I'm referring to being 
consistent with programs on the current system. E.g a native 
macOS app has a certain way it looks and behaves. I can expect 
cmd+w to close a window, cmd+q to quit and the the "traffic 
lights" to be on the top left. Non native apps mess things up, 
making them harder to use. Keyboard shortcuts _generally_ work, 
but when they don't they are a pain. Even messing with buttons, 
making them smaller, or placing them weirdly, or using custom 
tabs and menus makes it harder to work with a program.
For e.g. look at the divide between "modern" and "native" apps on 
Windows. Even on linux, back in the day, GTK apps looked out of 
place on QT systems and vice versa.
Apr 24 2018
next sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 24 April 2018 at 12:44:59 UTC, Uknown wrote:


 I forgot to mention consistency. This is the biggest reason I 
 don't use non native apps. I'm not talking about your app being 
 consistent across operating systems. I'm referring to being 
 consistent with programs on the current system. E.g a native 
 macOS app has a certain way it looks and behaves. I can expect 
 cmd+w to close a window, cmd+q to quit and the the "traffic 
 lights" to be on the top left. Non native apps mess things up, 
 making them harder to use. Keyboard shortcuts _generally_ work, 
 but when they don't they are a pain. Even messing with buttons, 
 making them smaller, or placing them weirdly, or using custom 
 tabs and menus makes it harder to work with a program.
 For e.g. look at the divide between "modern" and "native" apps 
 on Windows. Even on linux, back in the day, GTK apps looked out 
 of place on QT systems and vice versa.


Well, this is only an issue if you want to provide an OS specific 
LAF for users who expect it and want it this way (Mac users, 
Windows users). So if you design an image or text editor for 
desktop, you would probably want to go native. However, loads of 
apps these days are meant for tablets, phones and the web. If, 
for example, I were to develop an app for language learning, I'd 
definitely not go native, but base the UI on HTML+CSS+JS. In that 
way, you can re-use it for smart phones and the login section of 
the user account. It'd be madness not to. A lot of apps have 
their own unique look these days (just as websites do), and users 
know (and even expect) that. If for some reason you have to 
interact with the OS's services on say an iPhone, you can always 
write a thin native wrapper in Objective-C or Swift. But I 
wouldn't base the logic on and around the native framework.

As for the rest, it's all about trade-offs and use cases. I don't 
use web-based programming editors nor would I write one, for the 
reasons you mentioned and because it has a well defined use case, 
i.e. hours of programming on your lap or desktop. For a language 
learning app, a weather app, a converter etc., going native is in 
most cases a bit OTT.
Apr 24 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/24/2018 08:44 AM, Uknown wrote:

 Even on linux, back in the day, GTK apps looked out of place on 
 QT systems and vice versa.


That's still true even now, albeit maybe not to the same extent (that 
is, until you try to save/open a file...).

We REALLY need a lib that provides the GTK API/ABI and converts to Qt. 
(Might be a nightmare to maintain though, the way GTK loves 
changing/removing things on a whim...)
Apr 24 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

 - cross platform: no need to deploy libs (e.g. Gtk on Mac and 
 Windows)


Well... that depends. If you can just use the browser already 
installed, yeah, but then you have to deal with cross-browser 
(which is still a thing, like I did a wysiwyg editor for work 
that is a redistributable server exe they run locally, but the ui 
is in a browser. You get better results on firefox than chrome 
due to a bunch of little things.)

Same with deprecation. Web stuff breaks somewhat frequently, and 
new features requiring bleeding edge won't always be there.
Apr 24 2018
next sibling parent Chris <wendlec tcd.ie> writes:
On Tuesday, 24 April 2018 at 12:29:04 UTC, Adam D. Ruppe wrote:

 On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

 - cross platform: no need to deploy libs (e.g. Gtk on Mac and 
 Windows)


 Well... that depends. If you can just use the browser already 
 installed, yeah, but then you have to deal with cross-browser 
 (which is still a thing, like I did a wysiwyg editor for work 
 that is a redistributable server exe they run locally, but the 
 ui is in a browser. You get better results on firefox than 
 chrome due to a bunch of little things.)


True, true. I've had my share of that. But often it can be fixed 
easily or the next version of the browser can already cope with 
it.


 Same with deprecation. Web stuff breaks somewhat frequently, 
 and new features requiring bleeding edge won't always be there.


In my experience, if you stick to plain JS+CSS+HTML things don't 
break that often. On the network side things can change. Then 
again, if you stick to robust bog standard protocols and the 
like, you're not really in danger of having to re-write 
everything.
Apr 24 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/24/2018 08:29 AM, Adam D. Ruppe wrote:

 like I did a wysiwyg editor for work that is a redistributable 
 server exe they run locally, but the ui is in a browser. You get better 
 results on firefox than chrome due to a bunch of little things.)


Yea, Chrome is kind of notorious for random breakages compared to other 
browsers. Google seems to still be a fan of that "move fast to break 
everything" fad that (unsurprisingly) has been biting Facebook in the ass.


 Same with deprecation. Web stuff breaks somewhat frequently, and new 
 features requiring bleeding edge won't always be there.


Honestly, I find that if my web sites exhibit browser-compatibility 
issues, it means I've over-engineered something. Even in Chrome, the 
HTML/CSS basics are pretty stable. It's only when you start getting into 
the "newer is better" bleeding edge "this week's version of webdev best 
practices" stuff, and toolkits and the like, that things start falling 
apart.
Apr 24 2018
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 25 April 2018 at 03:00:13 UTC, Nick Sabalausky 
(Abscissa) wrote:


 Yea, Chrome is kind of notorious for random breakages compared 
 to other browsers. Google seems to still be a fan of that "move 
 fast to break everything" fad that (unsurprisingly) has been 
 biting Facebook in the ass.



 Honestly, I find that if my web sites exhibit 
 browser-compatibility issues, it means I've over-engineered 
 something. Even in Chrome, the HTML/CSS basics are pretty 
 stable. It's only when you start getting into the "newer is 
 better" bleeding edge "this week's version of webdev best 
 practices" stuff, and toolkits and the like, that things start 
 falling apart.


I recently had this issue with Chrome [1] and it is honestly 
annoying. I found out that it had been reported several times and 
what do Chrome devs say? Issue closed, it's an effin feature. To 
me it looks like they were over-intellectualizing the issue and 
came up with a "feature" that is counter-intuitive.

The thing about (Google) Chrome is this: unlike IE, it used to 
comply with web standards. No surprises, no stupid work arounds 
required, no two sets of code. IE went down, Chrome went up, and 
justly so. But now Chrome is becoming the new old IE (Mind you, 
even MS copped it that they had to comply with the standards!). 
And not to mention the built-in data "leakage". But like IE back 
in the day, everybody uses Chrome by default.

Imo, HTML+CSS are still good ways to build interfaces fast. I 
think there should be more UI frameworks (native or not) that 
provide this option instead of each framework cooking its own 
stew.

As for JS, I agree with TheGag96, you simply cannot write 
beautiful code in JS. There are two scenarios. 1. You can use JS 
for the mere basics and have it communicate with the server, say 
vibe.d, and the real cool stuff happens on the server in D. 2. 
You need to keep things flexible on the client side and process a 
lot of stuff (e.g. data you get back from the server) with JS, so 
you don't need to change-and-recompile vibe.d and others can 
change things according to their needs. It will get a bit messy, 
it's JS after all. To keep things simple follow these rules, if 
you have to use JS:

1. Don't try to be smart, don't try to write flashy or beautiful 
code. JS will thwart you.
2. Use the same dumb routines all over the place, it's easier to 
copy-and-paste and it will prevent breakage.
3. Stay away from the latest features that seem to work but are 
officially not "implemented yet"
4. Wait. JS engines are getting better and better.

Having said this, _vibe.d can also as a GUI client_. Cf. D Web 
Development, Kai Nacke.

[1] 
https://stackoverflow.com/questions/20367046/onclick-event-firing-in-firefox-and-ie-but-not-in-chrome
Apr 25 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/25/2018 05:49 AM, Chris wrote:

 
 I recently had this issue with Chrome [1] and it is honestly annoying. I 
 found out that it had been reported several times and what do Chrome 
 devs say? Issue closed, it's an effin feature. To me it looks like they 
 were over-intellectualizing the issue and came up with a "feature" that 
 is counter-intuitive.
 
 The thing about (Google) Chrome is this: unlike IE, it used to comply 
 with web standards. No surprises, no stupid work arounds required, no 
 two sets of code. IE went down, Chrome went up, and justly so. But now 
 Chrome is becoming the new old IE (Mind you, even MS copped it that they 
 had to comply with the standards!). And not to mention the built-in data 
 "leakage". 


Yea. Google's pretty much decided they own the web and related 
standards. (If silicon valley has its way, in a few years time we won't 
even have an internet, we'll just have Facebook and Google. Heck, we're 
lucky that hasn't already happened...although...in some ways it arguably 
has...)

Funny thing is, and I'm no MS apologist, but back when MS was the one 
trying to decide how the web should operate, at least they actually made 
some vastly BETTER design choices than the W3C did. Ex, IE's old box 
model and its JS API for handling separate mouse buttons were actually 
SANE compared to the ridiculous equivalents from the W3C (can't help 
wondering if the W3C went contrary to MS on those designs just to spite 
MS (not that I can completely blame them), though I don't know how the 
timeline went and who's designs came first).

But fast-forward to now when it's now Google instead of MS saying "We'll 
be the ones designing the web standards, thank you very much, W3C.", 
they don't even have the benefit of making BETTER designs like MS did, 
they're just making random contradictory decisions. Quirk's Mode 
<https://www.quirksmode.org/blog/> is constantly finding new Google 
Chrome "interpretations" that are just...well, at best, they're not an 
improvement over W3C.


 But like IE back in the day, everybody uses Chrome by default.


Well yea, all the hipster nerds say Google is God and Chrome is what you 
should be using, so it must be so. ;)

At the very least, I just wish there was a good choice. Mozilla used to 
be the Burger King of browsers ("Your way, right away."), but they've 
spent the last decade hopping on silicon valley's "Our developers matter 
more than our users" bandwagon, too. (The "Soup Nazis" of software.)
Apr 25 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/25/2018 10:31 PM, Nick Sabalausky (Abscissa) wrote:

 
 Yea. Google's [complain, gripe, blah, blah, blah...]


I found this to be a very interesting, and not particularly surprising, 
peek at the way things work^H^H^H^Hoperate inside Google-ville:

https://mtlynch.io/why-i-quit-google/

I guess it indirectly explains many things. Like why my Android device 
can't even handle basic WiFi things like...oh...not loosing my wireless 
password every-single-time. Or...connecting to another machine *on the 
same freaking network* without using a Google-hosted service (erm, 
sorry, I mean "cloud") as a go-between. Well, no matter, just like my 
laptop, I'll just ditch the pack-in OS in favor of Linux...oh wait...crap.
Apr 25 2018
parent reply Johannes Pfau <nospam example.com> writes:
Am Wed, 25 Apr 2018 22:45:59 -0400 schrieb Nick Sabalausky (Abscissa):


 On 04/25/2018 10:31 PM, Nick Sabalausky (Abscissa) wrote:

 
 Yea. Google's [complain, gripe, blah, blah, blah...]


 I found this to be a very interesting, and not particularly surprising,
 peek at the way things work^H^H^H^Hoperate inside Google-ville:
 
 https://mtlynch.io/why-i-quit-google/
 
 I guess it indirectly explains many things. Like why my Android device
 can't even handle basic WiFi things like...oh...not loosing my wireless
 password every-single-time. Or...connecting to another machine *on the
 same freaking network* without using a Google-hosted service (erm,
 sorry, I mean "cloud") as a go-between. Well, no matter, just like my
 laptop, I'll just ditch the pack-in OS in favor of Linux...oh
 wait...crap.


Maybe this will help:
https://puri.sm/shop/librem-5/

Hope is the last thing to die ;-)

-- 
Johannes
Apr 26 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/26/2018 03:20 PM, Johannes Pfau wrote:

 
 Maybe this will help:
 https://puri.sm/shop/librem-5/
 
 Hope is the last thing to die ;-)
 


Thanks for the link, looks interesting. Don't quite understand how that 
distributed telephony is supposed to work though, while still 
(hopefully) interoperating with the standard telephone network.

Fingers crossed for that device or something like it, but not holding my 
breath (and as much as I hate Google/Android, anything without a 
built-in point-tipped stylus is useless to me and has basically zero 
chance of replacing my Galaxy Note - unfortunately).

Thing is, there's been so many attempts at iOS/Android alternatives 
already, and by much bigger organizations too. Even MS couldn't hold on, 
and that's the same company that was able to force their way into the 
notoriously tough-to-crack game console market by sheer financial force 
alone (by weathering a loss that even dwarfed the Dreamcast). So I fear 
that "hope" is ALL there is at this point. But I hope I'm wrong ;)

(And even if it does pan out, it's not like many people could just 
install it on an existing device: Those stupid things are locked down 
far tighter than any modern PC BIOS.)

I'll definitely keep an eye on that though.
Apr 26 2018
prev sibling parent reply Chris <wendlec tcd.ie> writes:
On Thursday, 26 April 2018 at 02:31:07 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 04/25/2018 05:49 AM, Chris wrote:

 Well yea, all the hipster nerds say Google is God and Chrome is 
 what you should be using, so it must be so. ;)

 At the very least, I just wish there was a good choice. Mozilla 
 used to be the Burger King of browsers ("Your way, right 
 away."), but they've spent the last decade hopping on silicon 
 valley's "Our developers matter more than our users" bandwagon, 
 too. (The "Soup Nazis" of software.)


Technology, science etc. are no exception to (natural) human 
behavior: do as everybody else does, sure it's good. The problem 
is that pragmatism ("I have to write in JS, if I want to write a 
web app") turns into an ideology/relgion ("It's the best thing we 
have, if it wasn't, we'd be using something else, wouldn't we?"). 
Rationalizing irrational bs and irrationalizing the rational is a 
defense mechanism of humans. Groupthink and tribalism (hippsters) 
are part of our DNA, sometimes it makes sense, sometimes it's an 
obstacle.

I remember that Walter once wrote that whenever he saw some work 
of engineering he would have the feeling that he could do it 
better. That's why we have D and that's why we are here on this 
forum. The "sure there must be a better way" kind of thinking 
(with the benefit of hindsight) is what keeps technology 
evolving, but there will always be groupthink, tribalism, 
concentration (and abuse) of power that slows down progress...You 
could write a book about it. It's been like this, since we 
learned how to light a fire. Fire...wheel, think about how long 
it took us to get there :)
Apr 27 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/27/2018 06:29 AM, Chris wrote:

 On Thursday, 26 April 2018 at 02:31:07 UTC, Nick Sabalausky (Abscissa) 
 wrote:

 On 04/25/2018 05:49 AM, Chris wrote:

 Well yea, all the hipster nerds say Google is God and Chrome is what 
 you should be using, so it must be so. ;)

 At the very least, I just wish there was a good choice. Mozilla used 
 to be the Burger King of browsers ("Your way, right away."), but 
 they've spent the last decade hopping on silicon valley's "Our 
 developers matter more than our users" bandwagon, too. (The "Soup 
 Nazis" of software.)


 
 Technology, science etc. are no exception to (natural) human behavior: 
 do as everybody else does, sure it's good. The problem is that 
 pragmatism ("I have to write in JS, if I want to write a web app") turns 
 into an ideology/relgion ("It's the best thing we have, if it wasn't, 
 we'd be using something else, wouldn't we?"). Rationalizing irrational 
 bs and irrationalizing the rational is a defense mechanism of humans. 
 Groupthink and tribalism (hippsters) are part of our DNA, sometimes it 
 makes sense, sometimes it's an obstacle.
 


That may be so, but a big part of being a participant in civilized 
society, and far more than that, being a professional, means having the 
basic will, ability and responsibility to utilize our higher-level 
cognitive functions (which we've also evolved and are baked into our 
genetics) to selectively override the baser instincts, and to discern 
when and where it's appropriate to do so.

It's a basic responsibility of being human, and it's a fundamental 
qualification of being a professional in a technical field.
Apr 27 2018
parent Chris <wendlec tcd.ie> writes:
On Saturday, 28 April 2018 at 00:17:29 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 04/27/2018 06:29 AM, Chris wrote:

 On Thursday, 26 April 2018 at 02:31:07 UTC, Nick Sabalausky 
 (Abscissa) wrote:

 [...]


 
 Technology, science etc. are no exception to (natural) human 
 behavior: do as everybody else does, sure it's good. The 
 problem is that pragmatism ("I have to write in JS, if I want 
 to write a web app") turns into an ideology/relgion ("It's the 
 best thing we have, if it wasn't, we'd be using something 
 else, wouldn't we?"). Rationalizing irrational bs and 
 irrationalizing the rational is a defense mechanism of humans. 
 Groupthink and tribalism (hippsters) are part of our DNA, 
 sometimes it makes sense, sometimes it's an obstacle.
 


 That may be so, but a big part of being a participant in 
 civilized society, and far more than that, being a 
 professional, means having the basic will, ability and 
 responsibility to utilize our higher-level cognitive functions 
 (which we've also evolved and are baked into our genetics) to 
 selectively override the baser instincts, and to discern when 
 and where it's appropriate to do so.

 It's a basic responsibility of being human, and it's a 
 fundamental qualification of being a professional in a 
 technical field.


I understand perfectly well what you mean. In theory, yes. But 
reality is different. It takes a lot of time and effort to bring 
about changes once something has been established. Just think of 
how much harder it gets to decide where to go for a drink the 
more people are involved. And usually you end up in a place 
nobody is really happy with.
Apr 28 2018
prev sibling next sibling parent reply Thomas Brix Larsen <brix brix-verden.dk> writes:
On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:

 Heya guys. For my projects that use a GUI library, I've tried 
 both tkd and DlangUI. Both I feel have their drawbacks, and I'd 
 like to know if any of you are using anything you find better. 
 In my case, my ideal choice would be:

 - Nice bindings/API, friendly to idiomatic D
 - Cross platform
 - Can compile to a standalone binary (no shared libraries or 
 extra files)
 - Reasonably efficient
 - Support for a good amount of well-working widgets

 Although quite a cool library, my biggest issue with DlangUI 
 was that it was a little mind-bending at times to keep track of 
 multiple widgets that view/modify the same data without 
 screwing things up. I saw QtE5 recently and have been thinking 
 about trying it out.

 What do you all recommend? Thanks!


I'd recommend dqml[1] or full Qt using Calypso[2] instead of 
QtE5. I'm currently using dqml in a project and it is working out 
great.

[1]: https://github.com/filcuc/dqml
[2]: https://github.com/Syniurge/Calypso
Apr 24 2018
next sibling parent reply TheGag96 <thegag96 gmail.com> writes:
On Tuesday, 24 April 2018 at 14:30:07 UTC, Thomas Brix Larsen 
wrote:

 I'd recommend dqml[1] or full Qt using Calypso[2] instead of 
 QtE5. I'm currently using dqml in a project and it is working 
 out great.


Awesome, thank you! I'll keep that in mind!

On Tuesday, 24 April 2018 at 13:08:24 UTC, Chris wrote:

 In my experience, if you stick to plain JS+CSS+HTML things 
 don't break that often.


...If you can get things written in the first place. Over the 
summer I interned at a place where they taught me how to write a 
web app, and I very quickly learned that unless you're using 
TypeScript or something, it's nearly impossible to write clean, 
well-structured JavaScript code, just by the nature of language 
itself. And even then it's still kinda gross.

My whole point with what I said earlier was that there's no 
reason to be greedy about resources for your app unless it's 
specifically needed. If you're trying to deploy on every 
imaginable platform, I could absolutely see the benefit of being 
able to develop one app for all of them at once through the web - 
but that's even assuming there's no major quirks/concerns between 
all browsers.

Uknown's point about Moore's Law, I think, is the one we should 
be paying attention to. A while back, I saw a talk by Jonathan 
Blow called "Making Game Programming Less Terrible"[1], and 
lately it's been on my mind a ton. I've begun to think that by 
going straight to web/Node stuff is just contributing to the 
degeneration of software/computing. Things are so much slower 
than they should be nowadays because programmers either A) didn't 
know any better how to write software that's as snappy as it 
should be, or B) wanted to make things easier/cheaper for 
themselves.

A bit off-topic I suppose lol, but I hope this kind of outlines 
why I follow D so much in the first place and why I want 
something lightweight but workable if I can find it.

[1] https://www.youtube.com/watch?v=gWv_vUgbmug
Apr 24 2018
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Apr 24, 2018 at 06:13:46PM +0000, TheGag96 via Digitalmars-d wrote:
[...]

 Uknown's point about Moore's Law, I think, is the one we should be
 paying attention to. A while back, I saw a talk by Jonathan Blow
 called "Making Game Programming Less Terrible"[1], and lately it's
 been on my mind a ton.  I've begun to think that by going straight to
 web/Node stuff is just contributing to the degeneration of
 software/computing. Things are so much slower than they should be
 nowadays because programmers either A) didn't know any better how to
 write software that's as snappy as it should be, or B) wanted to make
 things easier/cheaper for themselves.


This reminds me of Nick Sabalausky's rant once that back in the 80's we
used to run programs on 64KB RAM and 8kHz CPUs, and lived with the slow
performance, and nowadays we have GB's of RAM and multicore GHz CPUs,
and we are finally able to write web apps that do basically the same
things with about the same slow performance as in the 80's (but with
many orders of magnitude greater resource consumption).  Software has
come a long ways indeed.</sarcasm> :-D


T

-- 
MASM = Mana Ada Sistem, Man!
Apr 24 2018
next sibling parent Arjan <arjan ask.me.to> writes:
On Tuesday, 24 April 2018 at 18:43:54 UTC, H. S. Teoh wrote:


 This reminds me of Nick Sabalausky's rant once that back in the 
 80's we used to run programs on 64KB RAM and 8kHz CPUs, and 
 lived with the slow performance, and nowadays we have GB's of 
 RAM and multicore GHz CPUs, and we are finally able to write 
 web apps that do basically the same things with about the same 
 slow performance as in the 80's (but with many orders of 
 magnitude greater resource consumption).  Software has come a 
 long ways indeed.</sarcasm> :-D


 T


https://www.artima.com/cppsource/how_to_go_slow.html
Apr 24 2018
prev sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/24/2018 02:43 PM, H. S. Teoh wrote:

 
 This reminds me of Nick Sabalausky's rant once that back in the 80's we
 used to run programs on 64KB RAM and 8kHz CPUs, and lived with the slow
 performance, and nowadays we have GB's of RAM and multicore GHz CPUs,
 and we are finally able to write web apps that do basically the same
 things with about the same slow performance as in the 80's (but with
 many orders of magnitude greater resource consumption).  Software has
 come a long ways indeed.</sarcasm> :-D


Except that I don't think I ever once experienced the degree of 
text-entry delay or random stutters on my Apple II that I regularly 
experience on my "modern" PC which is more than capable of, ex., far 
surpassing Myst-level imagery in real-time, among other supercomputer feats.

Now that we have ARM, GPU computing, Gates is retired and MS isn't the 
big dog it used to be, I think we need to bring back and update the old 
"What Andy giveth, Bill taketh away" saying ;)
Apr 24 2018
prev sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 04/24/2018 10:30 AM, Thomas Brix Larsen wrote:

 
 I'd recommend dqml[1] or full Qt using Calypso[2] instead of QtE5. I'm 
 currently using dqml in a project and it is working out great.


Why not QtE5? I've been meaning to give it a try.
Apr 24 2018
parent Thomas Brix Larsen <brix brix-verden.dk> writes:
On Wednesday, 25 April 2018 at 03:05:52 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 04/24/2018 10:30 AM, Thomas Brix Larsen wrote:

 
 I'd recommend dqml[1] or full Qt using Calypso[2] instead of 
 QtE5. I'm currently using dqml in a project and it is working 
 out great.


 Why not QtE5? I've been meaning to give it a try.


It is just the parts of Qt needed by the author. Only minor parts 
of QtCore, QtGui, QtScript, QtWebEngine, and QtWidgets seems to 
be wrapped. While modern Qt user interfaces are mostly made with 
QML (QtDeclarative and QtQuickControls2).

https://github.com/MGWL/QtE5/tree/master/source
Apr 25 2018
prev sibling next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 23 April 2018 at 06:12:33 UTC, TheGag96 wrote:

 Heya guys. For my projects that use a GUI library, I've tried 
 both tkd and DlangUI. Both I feel have their drawbacks, and I'd 
 like to know if any of you are using anything you find better. 
 In my case, my ideal choice would be:

 - Nice bindings/API, friendly to idiomatic D
 - Cross platform
 - Can compile to a standalone binary (no shared libraries or 
 extra files)
 - Reasonably efficient
 - Support for a good amount of well-working widgets


I can't say I've seen a library which meets your ideal but I 
still find DWT my favorite; not that I'm well verse in GUI 
libraries.

I think this is a fair statement about SWT (what DWT is based 
on). SWT provides the basics for graphical interfaces it doesn't 
try to do things for you. The JFace library is intended to 
provide a little more help, but I don't think it has made it over 
to D yet.
Apr 24 2018
prev sibling parent reply User <user tmp.com> writes:
I write lot of small utilities on Windows and prefer to have a 
gui.

Gtkd is nice. Glade is awsome. but the runtime dlls are about 
20mb, too much for a 1mb tool. For some reason the theming on 
Windows didnt work well for me.

Dwt is nice, but no glade like gui editor.  when using dwt, I 
build gui manually.

Html css looks too different from native app. Opening and saving 
files is painful, nok.

Most of the time java, swing, netbeans works very well. Startup 
time sucks, so i just added an intrresting splash screen and 
people seemed to like it.

I have high hopes for dlangui, but it's still beta and has some 
bugs that's blocking me.

In conclusion, if startup time is important i use dwt. Otherwise 
java with netbeans.
Apr 28 2018
parent Jacob Carlborg <doob me.com> writes:
On 2018-04-28 19:39, User wrote:


 Dwt is nice, but no glade like gui editor.  when using dwt, I build gui 
 manually.


You might be able to use WindowBuilder [1] and port the Java code to D.

[1] https://www.eclipse.org/windowbuilder/

-- 
/Jacob Carlborg
Apr 29 2018