On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh wrote:
> On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via Digitalmars-d wrote:
>> Really, what's the case for not supporting this? Am I really a unique snowflake?
>
> Nope, you're just too smart to use a GUI. ;-)
>
> Issues like these were part of what convinced me that the so-called desktop metaphor was bunk and that the current infatuation with GUIs is a case of emperor's clothes, and drove me to embrace the *nix shell.

GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast.

Contrast that with Unix utilities, which are usually designed to do one job and do it well and then interoperate with other such utilities cleanly. Because each one is simple, they work well, and because they're composable, you have a _lot_ more flexibility than you get with a GUI. So, in general, the unix philosophy just ends up working better. But it _does_ require a certain kind of thinking from the user that tends to go well with programmers but not so well with the average joe, and even with that in mind, there _are_ applications that work better as GUIs.

But it's that simplicity and composability that gives us a lot of the power that we have with ranges, and I think that you can see some comparisons between a range-based approach and what you'd typically get in many other languages (particularly when OO is involved), where you often end up with objects that have everything and the kitchen sink in them, which can be quite useful and in some cases, easier to use, but ultimately it's a lot less flexible and harder to maintain.

- Jonathan M Davis

On 9/29/2015 6:51 PM, Jonathan M Davis wrote:
> On Tuesday, 29 September 2015 at 23:50:34 UTC, Walter Bright wrote:
>> Really, what's the case for not supporting this? Am I really a unique snowflake?
>
> No, you're alone, though it's not something that I think about often. I think
> that most of us run into this sort of problem from time to time (e.g. for some
> reason, the VPN client that I use for work won't let you copy-paste the IP
> address that you're connected to, so you have to read it and type it out by hand
> every time that you need to give it to someone, which is just silly). But there
> are aspects of GUIs where I don't think that it's really reasonable to expect to
> be able to copy the text, because it would interfere with how the GUI works
> (e.g. the text on a button). So, I _expect_ there to be times when I can't copy
> a piece text from a GUI.

I should be able to copy the button text by starting the stroke from outside the button and crossing over it.


> However, that being said, I don't think that there's any question that more text
> should be selectable and copyable than is. It looks like KDE made is that you
> can select the text in their about boxes. I have no idea why Microsoft didn't.
> And it's just plain embarrassing that Microsoft wouldn't let you copy error
> messages from error dialogs. But I think that it mostly comes down to the folks
> who put GUIs together not thinking about this sort of thing. It really isn't
> related to the primary functionality of an application, so it's easy to forget.
> And in many cases, I expect that it comes down to exactly what kind of GUI
> widget was used to display the text, and if the toolkit in question wasn't
> designed with this in mind, then everyone using it is going to end up with
> unselectable and uncopyable text in their GUIs - which just goes to show, I
> suppose, that if the GUI toolkit folks get it right, then a lot of programs
> will, and I guess that Win32 or MFC or whatever C# thing Microsoft and many
> other Windows shops use for many of their GUIs don't do it right.

Microsoft should:
1. fix it so it is the default behavior.
2. list it in their guidelines for how dialog boxes should work.

On Wednesday, 30 September 2015 at 01:59:38 UTC, Jonathan M Davis wrote:
> On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh wrote:
>> On Tue, Sep 29, 2015 at 04:50:37PM -0700, Walter Bright via Digitalmars-d wrote:
>>> Really, what's the case for not supporting this? Am I really a unique snowflake?
>>
>> Nope, you're just too smart to use a GUI. ;-)
>>
>> Issues like these were part of what convinced me that the so-called desktop metaphor was bunk and that the current infatuation with GUIs is a case of emperor's clothes, and drove me to embrace the *nix shell.
>
> GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast.
>
> Contrast that with Unix utilities, which are usually designed to do one job and do it well and then interoperate with other such utilities cleanly. Because each one is simple, they work well, and because they're composable, you have a _lot_ more flexibility than you get with a GUI. So, in general, the unix philosophy just ends up working better. But it _does_ require a certain kind of thinking from the user that tends to go well with programmers but not so well with the average joe, and even with that in mind, there _are_ applications that work better as GUIs.


Excellent unfolding of this point, and one I have been pondering for my own use case.  I would like to be able to explore data interactively using various building blocks written in D that I can strap together quickly.  User interfaces matter so much for things you do everyday, yet often people are more concerned with making it shiny for the marketing guys than productive for serious users - especially so for relative monopolies.

It's interesting to see how different applications tackle this problem.  It doesn't necessarily need to be either GUI or command line.  For example, the Bloomberg terminal is kind of a combination (more old-school GUI than not, and the GUI bit is the one I like least).  The ipython/Jupyter notebook is another kind - that's great for writing intermediate size chunks of code but not so much for use as a shell.  So another possibility is the qtconsole style.  (Maybe R and Julia, but I am less familiar with those).  I think in both Jupyter and qtconsole you can have graphical widgets (certainly in Jupyter).

Adam Ruppe's terminal is quite an interesting approach.  as you can display images inline within the terminal window, and not hard to make them interactive.  Possibly a shell with graphics and some kind of light scripting language like Lua can be the best of both worlds, in particular in relation to the composability aspect.

In Bloomberg if I want to see which bonds are deliverable for the front month gilt future, I can type "G A[F9]DLV[ENTER]" and see an editable analysis window pop up - not quite a commandline, but shortcuts on steroids.  It's easy to replicate this kind of shortcut in a terminal (including prompts/helptext etc) whilst still having the ability to do more powerful things using the commandline without context switching.

for example findticker --macro --confidence/consumer GBP | less
(not something that will go quickly in Bloomberg because GUI).

or findticker -- macro --confidence/consumer OECD | chart -s 2009 -f monthly
(find all OECD consumer confidence numbers and plot them since 2009)



Laeeth.

On Wed, Sep 30, 2015 at 01:59:36AM +0000, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, 30 September 2015 at 00:20:46 UTC, H. S. Teoh wrote:
[...]
> >Issues like these were part of what convinced me that the so-called desktop metaphor was bunk and that the current infatuation with GUIs is a case of emperor's clothes, and drove me to embrace the *nix shell.
> 
> GUIs work quite well for certain types of applications - especially those that are very visual (e.g. Photoshop). And in general, if they're done correctly, they allow you to do a certain set of operations efficiently and easily, but by their very nature, they don't tend to be very flexible, and when you do try and make them flexible, they tend to get very complicated, very fast.

Oh, I agree that certain tasks are better suited for GUIs. For example, highly visual tasks like freehand drawing, photo-editing (Photoshop), etc., are clearly better suited to a graphical interface.  Many things aren't, though, in spite of people trying to shoehorn them into GUIs because GUIs are k00l and therefore we must do GUI or we're not in the in-crowd.


> Contrast that with Unix utilities, which are usually designed to do one job and do it well and then interoperate with other such utilities cleanly.  Because each one is simple, they work well, and because they're composable, you have a _lot_ more flexibility than you get with a GUI. So, in general, the unix philosophy just ends up working better. But it _does_ require a certain kind of thinking from the user that tends to go well with programmers but not so well with the average joe, and even with that in mind, there _are_ applications that work better as GUIs.

I know the commandline scares away your average joe. That's the kind of audience GUIs are catered to, which is understandable. What gets annoying is when you're *forced* to use GUI even if you're not the average joe. Many tasks in Windows simply cannot be done without clicking through the GUI. You have no choice in the matter. Where it get ugly is when the GUIs in question have issues, like non-resizeability or non-copyability where there's no *technical* reason why it cannot be done. That's when I start wishing it was Linux where I can just fire up a text editor and edit system config files directly instead of getting an aneurysm from clicking the rodent trying to coax it to do what I want.


> But it's that simplicity and composability that gives us a lot of the power that we have with ranges, and I think that you can see some comparisons between a range-based approach and what you'd typically get in many other languages (particularly when OO is involved), where you often end up with objects that have everything and the kitchen sink in them, which can be quite useful and in some cases, easier to use, but ultimately it's a lot less flexible and harder to maintain.
[...]

The infamous god-object? I thought that was an antipattern...

As is the static singleton class, which is so widespread in Java because their fixation on OO doctrine prohibits free functions as a matter of orthodoxy, even though many things are really better off as free functions than class members.

To me, such shenanigans are a code smell symptomic of an underlying design / conceptual flaw, just as the sometimes ridiculous shenanigans you have to go through in order to make something work as a GUI when clearly a different kind of interface would be much better suited. But such suggestions are usually shot down by various standard fallacies ("non-GUI == not user-friendly", "nobody uses CLI anymore", "GUI == k00l, CLI == not k00l", etc.) and never seriously considered, even though they really should be.


T

-- 
It only takes one twig to burn down a forest.

On 9/25/2015 9:06 AM, Dicebot wrote:
> What causes conflict? Is it just optilink? Maybe it would be more reasonable to
> simply rename it to something less generic? DMD doesn't look like something that
> inherently requires isolation.

We're in the process of switching the Win32 dmd toolchain to use "optlink.exe" rather than "link.exe". Should have done that a long time ago.

On 30-Sep-2015 02:50, Walter Bright wrote:
> On 9/29/2015 1:58 AM, Jonathan M Davis wrote:
>> There have certainly been times where I've wanted to copy text that
>> was not
>> selectable for some reason (or selectable but not copyable), but it
>> sounds like
>> you have a much higher expectation of text selectability than I do.
>
> Cases that frustrate me:
>
> 1. In filing a bug report, I need to input the version number. For
> Internet Explorer, I bring up the "About Internet Explorer" dialog box.
> The version is (I kid you not) a 55 character string of random digits
> and letters. I want to cut&paste this. Not possible.
>
> 2. I get a dialog box popping up with an error message in it. I want to
> google the error message. Have to retype it.
>
> 3. Thunderbird Mail lets me import/export the address book. But not
> account settings. So I want to select and copy the account settings
> dialog box. Nope.
>
> Really, what's the case for not supporting this? Am I really a unique
> snowflake?
>

When that happens to me I use Abbyy FineReader to OCR the screenshot, there is even a special screenshot reader app. Sometimes it's a lifesaver.

-- 
Dmitry Olshansky

On 2015-09-30 01:50, Walter Bright wrote:

> Cases that frustrate me:
>
> 1. In filing a bug report, I need to input the version number. For
> Internet Explorer, I bring up the "About Internet Explorer" dialog box.
> The version is (I kid you not) a 55 character string of random digits
> and letters. I want to cut&paste this. Not possible.
>
> 2. I get a dialog box popping up with an error message in it. I want to
> google the error message. Have to retype it.

You clearly are not using the right operating system ;). On OS X I can copy text from all native dialogs.

> 3. Thunderbird Mail lets me import/export the address book. But not
> account settings. So I want to select and copy the account settings
> dialog box. Nope.

Can't you copy the editable text fields? Or do you want to copy the labels as well?

Can't you copy the whole profile directory?

> Really, what's the case for not supporting this? Am I really a unique
> snowflake?

No, not at all.

-- 
/Jacob Carlborg

On Wednesday, 30 September 2015 at 04:48:35 UTC, H. S. Teoh wrote:
> On Wed, Sep 30, 2015 at 01:59:36AM +0000, Jonathan M Davis via Digitalmars-d wrote:
> I know the commandline scares away your average joe. That's the kind of audience GUIs are catered to, which is understandable. What gets annoying is when you're *forced* to use GUI even if you're not the average joe. Many tasks in Windows simply cannot be done without clicking through the GUI. You have no choice in the matter. Where it get ugly is when the GUIs in question have issues, like non-resizeability or non-copyability where there's no *technical* reason why it cannot be done. That's when I start wishing it was Linux where I can just fire up a text editor and edit system config files directly instead of getting an aneurysm from clicking the rodent trying to coax it to do what I want.

Yeah. A big problem with mobile platforms, Windows, and Mac OS X is that they all tend to target the average joe and don't necessarily give the power users good tools (I suspect that Mac OS X does the best out of those given its BSD underpinnings, but I haven't used it, so I don't know). Linux and the BSDs do a _far_ better job - probably because they're pretty much written by geeks for geeks. They're not trying to dumb everything down. I hate dealing with mobile precisely because they're trying to hide the fact that it's a computer and are trying to dumb the whole thing down for the average joe. Windows isn't as bad, but even when it does a fairly good job, it's still catering to folks who are scared of the command line. And some of the changes that they've made over time have the same problems as the mobile OSes where they're basically trying to hide a lot of stuff from the user - especially stuff related to the filesystem.

>> But it's that simplicity and composability that gives us a lot of the power that we have with ranges, and I think that you can see some comparisons between a range-based approach and what you'd typically get in many other languages (particularly when OO is involved), where you often end up with objects that have everything and the kitchen sink in them, which can be quite useful and in some cases, easier to use, but ultimately it's a lot less flexible and harder to maintain.
> [...]
>
> The infamous god-object? I thought that was an antipattern...

It doesn't usually go _that_ far, but when using OO, it's still pretty common to put everything on the class, and very little is generic. So, if functionality gets added, it gets added to the class that the programmer wants to use it with at the time. It actually tends to make it easier to find functionality, because it's grouped with what it's used with and documented with it, but it really isn't reusable. So, even if a class isn't so complicated that it's a god-object, it can still have way more functionality on it than necessarily makes sense, especially if you start thinking about generic programming and being able to reuse functionality.

Another example would be frameworks vs libraries / components. With a framework, the programmer that wrote it provides most of the functionality, and you override and/or fill-in pieces of it for your particular application. It saves you a lot of time and effort, because you don't have to code it all up yourself, and often, you don't even have to understand that much about how any of it works, because it's doing so much for you. However, a framework generally isn't very flexible (or if it is, it gets _very_ complicated, very quickly), and its code isn't particularly reusable, because it's only usable within the framework. So, from the perspective of a beginner or someone trying to get something done that doesn't require much flexibility, a framework might be a great solution. But as soon as you need to do anything that the framework folks didn't think of or which doesn't fit in well with how the framework is designed, you're pretty much screwed and forced to ditch the framework entirely. Contrast that with a library built entirely of reusable components that can be used to build functionality similar to that of the framework. It's probably going to be harder to use for some cases, because it's generally not doing as much for you out-of-the-box, but you can build what the framework does using the components it gives you, and you can build completely different stuff using those same components. You get a lot more flexibility and power out of it - but less hand-holding.

Good GUIs solve the common case well but don't generally do well for uncommon cases, and unlike command-line tools, they can't be used to build something else that isn't as common.

> But such suggestions are usually shot down by various standard fallacies ("non-GUI == not user-friendly", "nobody uses CLI anymore", "GUI == k00l, CLI == not k00l", etc.) and never seriously considered, even though they really should be.

To be fair, for most people, CLI _isn't_ user-friendly - e.g. I sure wouldn't want to require that my mother use the command line. She has enough trouble with GUIs. As you mentioned, the problem is when everything is targeting the average joe and power users aren't given good tools. Having stuff that caters to the average joe is fine. It's when that's all they're doing that we have a problem.

- Jonathan M Davis

On Wednesday, 30 September 2015 at 04:48:35 UTC, H. S. Teoh wrote:
> I know the commandline scares away your average joe. That's the kind of audience GUIs are catered to, which is understandable. What gets annoying is when you're *forced* to use GUI even if you're not the average joe. Many tasks in Windows simply cannot be done without clicking through the GUI. You have no choice in the matter. Where it get ugly is when the GUIs in question have issues, like non-resizeability or non-copyability where there's no *technical* reason why it cannot be done. That's when I start wishing it was Linux where I can just fire up a text editor and edit system config files directly instead of getting an aneurysm from clicking the rodent trying to coax it to do what I want.

Well, any interface may or may not provide desired features. It being config files, CLI or API, every feature still must be implemented, and if it's not the user is out of luck.

On 9/29/2015 11:03 PM, Dmitry Olshansky wrote:
> When that happens to me I use Abbyy FineReader to OCR the screenshot, there is
> even a special screenshot reader app. Sometimes it's a lifesaver.

I use a flamethrower to light cigarettes, too!