October 12, 2009
Hello Walter,

> BCS wrote:
> 
>> Hello Walter,
>>> Probably not very well. This would work best with getting information
>>> from modules other than the one being edited.
>>>
>> Ouch. There goes about half of what people will want.
>> 
> Right, it's about half. But it's an easy half to get.
> 

Are you thinking of the partially parsed bit or the only in other modules bit? I was looking at the second.


October 12, 2009
language_fan wrote:
> 
> Look, this is what I get on Win32:
> 
> http://johnbokma.com/textpad/select-a-file-dialog.png
> 
> on Linux:
> 
> http://www.matusiak.eu/numerodix/blog/wp-content/uploads/20050710- kdefilechooser.png
> 
> on Java:
> 
> http://www.dil.univ-mrs.fr/~garreta/docJava/tutorial/figures/uiswing/ components/FileChooserOpenMetal.png
> 
> You can probably see something that I have started to call 'consistency'. Almost the same buttons and layouts on every platform. I immediately know how it works. The same design has been there since Windows 95, if I recall correctly. This is what many people have learned to live with.
> 
> Now every time I see a gtk+/swt/dwt application I wonder where the heck that unintuitive terrible piece of cr*p came:
> 
> http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/ graphics/14fig03.gif
> 
> Native? It might very well use native binaries on my platform, but the native feel ends there.

Um.  It's even worse for me.  Yours may not look native, but at least it doesn't look like the sh*t gtk gives me:

http://post-boredom.net/filedialog/lolwut.png



By comparison, my native look and feel (kde4):

http://post-boredom.net/filedialog/muchbetter.png

Qt gets this right.
October 12, 2009
On Mon, Oct 12, 2009 at 1:42 PM, Nick Sabalausky <a@a.a> wrote:
> "Ary Borenszweig" <ary@esperanto.org.ar> wrote in message news:havvl7$1tlv$1@digitalmars.com...
>>
>> Yeah, we made a game in WPF in the company I work for, using bindings (*the* feature of WPF): it was sluggish. From the start I recommended doing it in a lower-level language (I recommended D!) but no one listened to me. It runs pretty slow with an amazing computer. I don't like WPF (nor Siliveright). :-P
>
> Is that related to, or the same as, the win forms library from .NET? Because I've found that to be horribly broken for anyone that uses a light-on-dark color scheme. Certain limitations of it make it impossible to prevent certain things from exhibiting invisible-text-syndrome on such a setup, which inevitably results in an app that's just horribly unprofessional.

WinForms is a managed code wrapper around native win32 widgets.  Kinda
like MFC redone for C#.
WPF doesn't wrap native widgets and uses XML for everything.   But
both are for the CLR.  So if you want to use them with C++ it has to
be managed C++ (aka C++/CLI).  My understanding is that WPF is
supposed to supersede WinForms, but it seems to me like they appeal to
different audiences.  (Like people who want professional
native-looking apps, vs the people who think the Windows Media Player
has a nice  interface).

--bb
October 12, 2009
Nick Sabalausky wrote:
> "language_fan" <foo@bar.com.invalid> wrote in message 
>> "Practical" languages
>> have lots of boiler-plate, and I can easily generate hundreds of lines of
>> code with a couple of key combinations or mouse clicks.
> 
> I disagree very much. For a puritanical anal-retentive language like Java, you *have* to have all that fancy stuff just to make the language even usable. But with a practical language like D, I have mixins, and I've gotten pretty good with regex find and replace, which obviously isn't as good, but it's good enough when dealing with any language that's at least somewhat sensible. With practical languages I never need to generate hundreds of lines of code. If I ever actually needed to do so (and in a way that an IDE could actually help with), I'd take that as a very big red flag that I was using an incredibly shitty language in the first place (like Java).

I think Nick has a point. Java lacks template mixins, and so inserting hundreds of lines of code from an IDE "template" is normal. But with D, doing such would be abnormal.
October 12, 2009
BCS wrote:
> Hello Walter,
> 
>> BCS wrote:
>>
>>> Hello Walter,
>>>> Probably not very well. This would work best with getting information
>>>> from modules other than the one being edited.
>>>>
>>> Ouch. There goes about half of what people will want.
>>>
>> Right, it's about half. But it's an easy half to get.
>>
> 
> Are you thinking of the partially parsed bit or the only in other modules bit? I was looking at the second.
> 
> 

Right, the second.
October 12, 2009
Walter Bright wrote:
> In my discussions with companies about adopting D, the major barrier that comes up over and over isn't Tango vs Phobos, dmd being GPL, debugger support, libraries, bugs, etc., although those are important.
> 
> It's the IDE.
> 
> They say that the productivity gains of D's improvements are overbalanced by the loss of productivity by moving away from an IDE. And what is it about an IDE that is so productive? Intellisense (Microsoft's word for autocompletion).
> 
> So, while I'm not going to be writing an IDE, I figure that dmd can help. dmd already puts out .doc and .di files. How about putting out an xml file giving all the information needed for an IDE to implement autocompletion? There'd be one .xml file generated per .d source file.
> 
> The nice thing about an xml file is while D is relatively easy to parse, xml is trivial. Furthermore, an xml format would be fairly robust in the face of changes to D syntax.
> 
> What do you think?

Next question: what about conditional compilation?
October 12, 2009
BCS wrote:
> template Foo (T) { T map(T[]) { ... } }
> 
> class Bar { mixin Foo!(int); }
> 
> void main()
> {
>   Bar bar;
>   bar. /// will the IDE have to do anything special to see 'map' or will it just be listed as another function?
> }

Probably it would just work.

On the other hand, if you had this:

T manipulate(T)(T value) { ... }
MyObject foo;
manipulate(foo). // IDE dies here

The compiler wouldn't have completion on the line of code you're currently editing, since it's a syntax error. The IDE won't know anything about D and so can't determine what the return type of manipulate() is.
October 12, 2009
On 12/10/2009 23:00, Walter Bright wrote:
> Bill Baxter wrote:
>> But it doesn't sound to me like it will be that much use to serious IDEs.
>
> Possibly not, but for lightweight IDEs I think it would be of much use.
> It would also make things very accessible to Emacs and Vim, two very
> widely used programmers' editors.
>
> (One thing I like about Vim is I can run it remotely via putty. A
> graphical gui IDE is impractical to use remotely, and yes, I've tried
> remote desktops. Unusable.)

I agree with Bill's post. I can't see any benefir for IDEs but a better documentation tool based on this would be great.

regarding working on a remote machine:
you can mount a remote file system through ssh and work localy on that remoted filesystem.

eclipse provides a similar concept with a plugin (search for RSE or TM for eclipse)
in addition eclipse provides better integration with the remote machine: executing remote commands straight from the GUI, remote debugging integration, etc..

in the latest version the CDT integration was improved a lot. it still isn't perfect (the C++ indexer needs more work) but I think by the next release they'll fix the remaining issues.
October 12, 2009
"Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote in message news:hb05lr$2bv5$2@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> Never touched FF3.5, I tried FF3 and it was such a worthless POS I went back to FF2, which is still a total POS, or course, but at least this way I have separate back/forward dropdowns, winestripe actually works, and I have no awfulbar *without* needing an anti-awfulbar addon (mozilla's standard strategy: force idiotic ill-conceived changes on everyone and rely on third-party add-on hacks for anyone who wants it fixed).
>
>
> Um, so why are you still using FF at all? :)
>

Very good question actually. In short: As badly as FF sucks, everything else sucks even more.

The main reason: For me, the web would be completely unusable without AdBlock Plus, NoScript and BetterPrivacy (For the record, I don't have a problem with ads on web pages, as long as they're 100% static, zero animation, zero sound, zero DHTML, zero of those ads-that-look-like-links-embedded-into-the-actual-text-content, and don't take up half the page.) Repagination, Linkification, DownloadHelper, DownThemAll, BugMeNot and TabMix Plus are...not strictly essential...but still things I'd rather not have to go without. This stuff rules out IE (very limited in customization and available add-ons), Opera (the alleged add-on system is a pathetic joke), and Safari (Customization in an Apple app? Ah ha ha ha ha ha!).

Plus there's a *lot* of other details on how I like to have things set up that nothing but FF allows me to do (even though it often requires an addon, such as TabMix Plus). This rules out all the ones aboves, plus Chrome. So for all practical purposes, that only leaves FF.

Secondary reason: I *HATE* apps that force a skin down my throat, even more than I hate GTK apps (at least GTK makes a small token effort to look vaguely like my system is supposed to look). This provides further strikes against Chrome and Safari.

Chrome also forces an extra always-resident process onto my system whether I want it or not. (I don't. And I don't give a crap what feature it may provide.)

And Safari, of course, has even more strikes against it, but Safari's such a joke anyway its not even worth mentioning any further.


October 12, 2009
On Mon, Oct 12, 2009 at 3:20 PM, Yigal Chripun <yigal100@gmail.com> wrote:
> On 12/10/2009 23:00, Walter Bright wrote:
>>
>> Bill Baxter wrote:
>>>
>>> But it doesn't sound to me like it will be that much use to serious IDEs.
>>
>> Possibly not, but for lightweight IDEs I think it would be of much use. It would also make things very accessible to Emacs and Vim, two very widely used programmers' editors.

That could be true, but you said the thing that prompted this idea was enterprise-y customers looking for an enterprise-y IDE.  Vim ain't on that roster.

--bb