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