September 02, 2013
On Mon, Sep 02, 2013 at 01:34:04PM -0700, Walter Bright wrote:
> On 9/2/2013 7:15 AM, Manu wrote:
> >On 2 September 2013 23:50, Andrej Mitrovic <andrej.mitrovich@gmail.com <mailto:andrej.mitrovich@gmail.com>> wrote:
> >
> >    On 9/2/13, Manu <turkeyman@gmail.com <mailto:turkeyman@gmail.com>> wrote:
> >     > But I still barely see this as an inconvenience when compared
> >     > to not being able to read a class definition.
> >
> >    How about not being able to read the include paths in VS? I'm
> >    talking about this:
> >
> >    http://i.stack.imgur.com/0cTZG.png
> >
> >    You can view 2 lines at a time. After almost 20 years they still
> >    haven't fixed this. Where is their core dev team that should make
> >    the IDE experience great?
> >
> >
> >Classic.
> 
> It is classic. Scott Meyers did a presentation on that, calling it the "keyhole" interface, because it shows the view as if you looked at the data through a keyhole.
> 
> Sometimes I defeat the keyhole by doing a "select all" in it, and then pasting it into notepad. I do the reverse, too: if the text entry box is only an inch square (some companies do this), I'll compose the message in notepad then cut&paste it into the keyhole.

It's things like this "keyhole interface", that caused me to be convinced that the GUI emperor has no clothes, and to turn to CLI-only development.


T

-- 
The problem with the world is that everybody else is stupid.
September 02, 2013
On 9/1/2013 9:27 PM, Manu wrote:
> Yeah, but you've gotta know what to type, and it's hardly google-quality in
> terms of it's relevence detection.

You can also search by keyword.

http://d.puremagic.com/issues/describekeywords.cgi
September 02, 2013
On 9/2/2013 1:41 PM, Walter Bright wrote:
> On 9/1/2013 9:27 PM, Manu wrote:
>> Yeah, but you've gotta know what to type, and it's hardly google-quality in
>> terms of it's relevence detection.
>
> You can also search by keyword.
>
> http://d.puremagic.com/issues/describekeywords.cgi

For Manu, searching on the "industry" keyword:

http://d.puremagic.com/issues/buglist.cgi?keywords=industry

Note that keywords are curated manually, so if they are applied incorrectly, fix 'em!
September 02, 2013
On Monday, September 02, 2013 07:13:20 Iain Buclaw wrote:
> On 2 September 2013 07:03, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
> > On Monday, September 02, 2013 06:59:00 Iain Buclaw wrote:
> >> Guess it also depends on what version of gdb you use too I guess, as iirc
> >> D
> >> support I described came in at around 7.4 release.
> > 
> > I recall it being 7.2, but it's been a while since I tried D with gdb, so
> > I
> > don't know. And it may have improved quite a bit since the last time I
> > tried (it's probably been well over a year now since I tried it with
> > anything other than tracking down a segfault). Part of my problem is that
> > I'm so used to using printf debugging now that I don't even think about
> > using a proper debugger even when I should. I usually only end up using a
> > debugger when I have no other choice (which is not the best of habits).
> 
> Yep, that's probably the one...  I think the main problem around that time was that dmd still emitted D arrays as longs.   So of course you won't get any useful information from gdb.  Giving 2.064 development a whirl, I see that it has now switched to emitting D arrays as structs so it strings (and other types of D arrays) should show up with no problem when debugging code generated by dmd.

That would be a huge improvement.

> >> If you are a gdc 4.8 user of course, you would have gdb 7.5 at least (as
> >> it
> >> doesn't work with earlier gdb versions).  And current development would
> >> recommend gdb 7.6
> >> 
> >> Have you given cgdb a try?  It's a curses front end to gdb, I added D syntax highlighting support a while ago for.  :)
> > 
> > I recall running into cgdb in the Arch repo and thinking of checking it out, but I don't recall if I did anything beyond install it. I'll have to make sure that I check it out some time soon.
> 
> I'd recommending checking out the latest development on github, as it includes some minor fixes to properly highlighting binary numbers, numbers with optional exponent, wysiwyg string literals r"...", hex strings x"...", and string postfixes that were added after the 0.6.7 release.

Then I'll have to check it out sometime soon.

- Jonathan M Davis
September 02, 2013
On Monday, September 02, 2013 14:13:10 Jacob Carlborg wrote:
> On 2013-09-02 07:51, Jonathan M Davis wrote:
> > However, my experience with gdb and C++ is also that gdb sucks at it, as
> > it
> > can't even handle basic stuff like operator overloading. So, I've come to
> > the conclusion that the only thing that gdb can handle correctly is
> > actual C code, and that if you want to do anything else, you have to
> > fight it. But maybe I just suck at using gdb.
> 
> Perhaps you should try LLDB with C++.

I don't think that I've ever heard of lldb. I'll have to check it out. Thanks for the info.

- Jonathan M Davis
September 02, 2013
On 9/2/2013 1:36 PM, H. S. Teoh wrote:
> It's things like this "keyhole interface", that caused me to be
> convinced that the GUI emperor has no clothes, and to turn to CLI-only
> development.

One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.

On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses.

With VS, or any GUI, if there's not a button to do it, I'm reduced to:

move mouse
click
move mouse
click
move mouse
type
move mouse
click
type

to get something done. And if I want to do it again, I have to repeat that process. After the 10th time, it's gaaaaahhh I hate it and go back to the CLI.

I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's:

right shift click on the picture
select open with
select photoeditor
select edit
select rotate
select autorotate
select apply
select save
select exit

Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool:

write a script that does it to one picture, name it cc.bat

do:
   dir/b *.jpg >doit.bat

open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes

execute the script

Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!

September 02, 2013
On Monday, 2 September 2013 at 21:04:24 UTC, Walter Bright wrote:
> On 9/2/2013 1:36 PM, H. S. Teoh wrote:
>> It's things like this "keyhole interface", that caused me to be
>> convinced that the GUI emperor has no clothes, and to turn to CLI-only
>> development.
>
> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
>
> On the CLI, I constantly use the history list, and I constantly write throwaway scripts to automate what I'm doing at the moment. It makes everything I do, no matter how obscure, only 2 or 3 keypresses.
>
> With VS, or any GUI, if there's not a button to do it, I'm reduced to:
>
> move mouse
> click
> move mouse
> click
> move mouse
> type
> move mouse
> click
> type
>
> to get something done. And if I want to do it again, I have to repeat that process. After the 10th time, it's gaaaaahhh I hate it and go back to the CLI.
>
> I scan a lot of photos. I have a GUI photo editor. A common thing I do is straighten the photos, because they never go through the scanner straight. So it's:
>
> right shift click on the picture
> select open with
> select photoeditor
> select edit
> select rotate
> select autorotate
> select apply
> select save
> select exit
>
> Sounds easy, right? It is easy. Now do it to 1000 photos. With a command line tool:
>
> write a script that does it to one picture, name it cc.bat
>
> do:
>    dir/b *.jpg >doit.bat
>
> open the file and use the macro feature to prepend "cc " to each file name, maybe 10 keystrokes
>
> execute the script
>
> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!

I'm not that big fan of "full" Guis either and try to stick to slick ones.

But for fairness sake: Better Gui Programms (read: way too few) have Macro facilities.

(My major reason to go GUI for programming is the auto* /configure/m4/makefile mess. Having that handled by some build in magic is cool. Which, if I'm not mistaken is less of an issue with D (dub, etc?))

A+ -R
September 02, 2013
On 2 September 2013 11:01, Robert Schadek <realburner@gmx.de> wrote:
> On 09/02/2013 11:55 AM, deadalnix wrote:
>>
>> I don't think that githubing everything is a wise move.
> ok, why do you think that?

1. Hosting the source for the pages on github is going just fine. 2. Github's bug tracker is too simplistic, and really is a downgrade from bugzilla. eg: How do you bring up a graph of all new bugs, regressions and closed bugs between 28th May 2013 and today using github?


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
September 02, 2013
On Monday, 2 September 2013 at 21:04:24 UTC, Walter Bright wrote:
> One of the giant failures of the GUI interface, and that VS suffers from, too, is when you need to do repetitive operations.
>
> ...

I agree most GUI's could be better in that respect.

The solution: use the GUI most of the time and CLI when that's the better tool. No need to throw out the baby with the bathwater.
September 02, 2013
On 9/2/13, Walter Bright <newshound2@digitalmars.com> wrote:
> Done! And CLI Clint goes and surfs the n.g. while GUI Gus has just gotten to picture 4, only 996 more to go!

Some GUI apps have macro features, or batch processing. Take a look at IrfanView for image batch conversion:

http://i.imgur.com/JrQqdi0.png

Now imagine if this was a CLI program. You'd have to use hundreds of switches, and it wouldn't be obvious what each switch does at a glance. It even has keyboard shortcuts, you press 'b' and you get the batch dialog, click, click, done.

Don't get me started on CLI programs where you have to use the damn space bar to go through all the --help options because it comes on multiple pages, or where switches have really funky syntax, and let's not forget escaping rules and paths or names with spaces.

It's just as bad as a poorly designed GUI app.