View mode: basic / threaded / horizontal-split · Log in · Help
May 30, 2005
Re: Native Windows Support
"J C Calvarese" <technocrat7@gmail.com> wrote in message news:d7fmnf$2mt1$1@digitaldaemon.com...
> In article <d7eldn$1iuj$1@digitaldaemon.com>, Lars Ivar Igesund says...
> >
> >TechnoZeus wrote:
> >
> >> "Lars Ivar Igesund" <larsivar@igesund.net> wrote in message
> >> news:d7ej4s$1h0m$1@digitaldaemon.com...
> ..
> >> Even in early beta versions of C#, I was able to write and
> >> compile Windows programs without "me" having to specify ANY
> >> libraries.  Yes, I know the compiler had to call them... but I didn't.
> >
> >Yes, the compiler does the work for you. This has absolutely nothing with
> >the language itself. To have such functionality in the compiler and
> >crossplatform is quite a lot of work, and is the reason for all the extra
> >utils out there (build, etc).
> >
> >I have used stuff in C# where I had to specify extra libraries to link in
> >(it was simple, but it had to be done), so in the case of .Net, it is more
> >of a case of having a very large standard library compared to the rather
> >small phobos.
> >
> >Lars Ivar Igesund
>
> I don't have any experience with C#, so it could be different. With VB.net the
> autmatic library magic only happens within the Visual Studio IDE, but I have to
> specify the .dll's and imports if I use the command-line compiler instead.
> Otherwise I get a bunch of compile-time errors (just like I would in D).
>
> jcc7

Ah, okay.  Now that I didn't know...
but the C# compilers that I used could do it all on the command line,
or from a single context menu click (if you set it up that way) without having to specify
any libraries for such things as controls, forms, containers, console, basic input/output, etc.

TZ
May 30, 2005
Re: Standard GUI Toolkit
"J C Calvarese" <technocrat7@gmail.com> wrote in message news:d7fn1r$2n9h$1@digitaldaemon.com...
> In article <d7ej1d$1gsd$1@digitaldaemon.com>, TechnoZeus says...
> >
> >
> >"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d7ab8i$1379$1@digitaldaemon.com...
> >>
> >> >>The question here is mainly one of whether D is to be considered a
> >> >>fully functional programming language in it's own right,
> >> >>or merely a tool to augment programming in the C language.
> >> >>Of course, the answer may be a matter of opinion, and largely subject to
> >> >>the observer's platform of choice. I personally would like to see it succede
> >> >>as a full featured programming language on all targeted platforms,
> >> >>and then some.
> >> >
> >>
> >> I guess some people won't think a language is legit until microsoft steals it.
> >> :)
> >>
> >> I am very impressed with how much everyone has to say about GUIs here. I think
> >> it surprised me that so many of you guys actually are interested so much in GUI
> >> development. I think we should start working together to come up with a really
> >> solid idea for the standard D GUI toolkit and than use our combined knowledge
> >> and resources to make it a reality.
> >>
> >> D could use it, and we could all use it.
> >>
> >> My initial proposal for this new stanrdard GUI toolkit...
> >>
> >> Basic Controls that end up working out to be the OS's native widgets, not look
> >> alikes. So on mac the scrollbar class will actually abstract a mac scrollbar,
> >> and one windows it will abstract a windows one, not just use a differnt drawing
> >> routine.
> >>
> >> Strong OpenGL support. This ends up being very useful for people who are making
> >> their own GUI's or multimedia apps, but still want direct, and cross platfor,
> >> access to a file open or a menu system.
> >>
> >> Polled events. I for one am not a fan of callbacks being used for every little
> >> thing on earth. I am rewriting Cpw in D right now, and thats the first thing I
> >> am changing. I would love to hear peoples opinions about this...
> >>
> >> I have many more ideas, but thats a start. Ideas?
> >>
> >> Thanks,
> >> Trevor Parscal
> >> www.trevorparscal.com
> >> trevorparscal@hotmail.com
> >
> >Thank you so much...
> >not for the uncalled for and inaccurate insult,
>
> What was the insult there? I've read it 3 times and I don't see it. It seems
> like a call for cooperation and fewer petty arguments. I don't see how that's an
> insult.
>
> >but for your wonderful explanation of what I have been "trying to say" here.
>
> ..
>
> jcc7

Perhaps I misunderstood.  I had thought the line...
"I guess some people won't think a language is legit until microsoft steals it."
was directed at me.  If so... I consider that an insult.
If not... then I apologise for the incorrect assumption,
and I agree that unfortunately yes some people do feel that way.

As for cooperation and fewer petty arguments... I'm all for it.  :)

TZ
May 30, 2005
Re: Native Windows Support
"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d7f7h2$26ut$1@digitaldaemon.com...
>
> TZ, I am affraid it is (naturally) impossible, because Windows API is C -
> so, whether You like it or not, some C stuff MUST be imported... Same is
> with all other operating systems...
>
> -- 
> ...........
> Dejan Lekic
>   http://dejan.lekic.org
>

What I'm asking for is NOT impossible.

A big challange, perhaps... but by no means impossible.

TZ
May 30, 2005
Re: Native Windows Support
> Okay, it's been a while but here's how I remember it...
>
> Functionality was placed into namespaces.
> For example, int was an alias for System.Int32 and bool was an alias for 
> System.boolean
> but it was possible to specify a namespace with the using statement so 
> functionality
> in that namespace could be used without full qualification.
> In other words, you could specify something like...
> using System;
> using System.Reflection;
> and then anything in the System namespace or the System.Reflection 
> namespace
> could be used with that part of it's fully qualified name stripped off.
>
> For console applications, you had to specify that you were using the 
> System.Console namespace
> if you wanted to avoid having to type things like...
> System.Console.WriteLine("hello");
> and instead be able to simply type...
> WriteLine("hello");
> and likewise, if you wanted Windows style forms, you had to either specify
> a namespace with the using statement, such as in...
> using System.WinForms;
> to keep from having to fully qualify something like...
> System.Winforms.TextBox textbox1;
> and instead be able to qualify a text box names textbox1 as simply...
> TextBox textbox1;
>
> I don't recall ever having to specify a library to use for such things.
> Perhaps the namespaces automatically told the compiler what libraries to 
> use, but
> if so, the process was transparent to me as a programmer.
>
> In that sense, console applications were no more native to C# than Windows 
> applications.
>
> True, it could be said that neither was fully native, but only one short 
> line of text was needed to make
> one or the other "seem" native to the language... and no further mention 
> of it was needed anywhere, at any time.
>
> Now... looking at the C# language specification
> (which I haven't looked at in years until just now)...
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/CSharpSpecStart.asp
>
> under Introduction -> Getting Started...
> the following example program is given...
>
> using System;
> class Hello
> {
>   static void Main() {
>      Console.WriteLine("hello, world");
>   }
> }
>
> and to compile it, you would use a command like....
> csc hello.cs
>
> No need to separately link it to anything.

That's not true. C# by default just links certain libraries, such as the 
System library, making it appear seamless. Venture out into Windows Forms or 
Web Services, and you have to tell the compiler to link to the libraries 
that contain their functionality.

>
> The line...
> Console.WriteLine("hello, world");
> could just as easily be replaced with...
> Credits.Display();
> and again, no linking needs to be specified to compile it into a working 
> program.
>
> In fact, one could just as easily specify...
>
> using System;
> using System.Web;
> using System.Web.UI;
>
> and then go on to write an application as if HTML support was native to 
> the C# language,
> again, without any need to specify anything more than those three lines... 
> anywhere, at any time.
>
> When I think about it, yeah... you're probably right.
> Libraries were most likely being used... but a thin disguise over that 
> fact meant that I never had to think about it.
> Likewise, I would guess that libraries are likely being used in Visual 
> Basic when a control or container is dropped into an application...
> but the programmer never has to think about that to use the control or 
> container.

Ok, I can see how you could interpret things that way. But these are 
namespaces from the .NET Base Class Library. They're libraries, just as 
Phobos and Mango and DWT are all libraries. C# automatically imports a few 
for you (System, for example), but for others (such as System.Drawing and 
System.Windows.Forms) you'd still need to reference them manually. If you 
use Visual Studio, it has templates that automate this process, so perhaps 
that's why it appeared as though all the work was done for you. The 
namespaces are not part of the language, there's nothing native to C# in 
those namespaces. The C# language is aware of some of the libraries, and 
indeed relies on them for its basic types, as you mention; but D relies on 
some Phobos functionality. I don't see much difference in that respect.

>
> That's what I'm trying to encourage here... to have the D language allow 
> programmers to concentrate on programming...
> rather than on putting together the pieces that support the program. 
> That's the whole idea behind higher level languages.
> Otherwise, we might as well be writing everything in assembly code.
>
> TZ
>
>
May 30, 2005
Re: Standard GUI Toolkit
>"I guess some people won't think a language is legit until microsoft steals it."

was ONLY directed at being a JOKE.. I would never insult TechnoZeus. Unless he
punched me or something, cause than he would have it comming :) (< Also a joke)

My point is that many people thought Java was not ligitmate for a very long time
for instance, and it FINNALY proved itself after years and years of refinment
and proof of concept in the faithful developer's work.

Microsoft comes out with C#, within 6 months it's just as respected.

Just seems to me that people cling to them for whatever reason. But, I do NOT
assume such about anyone who is working with D at such an early stage... I mean,
how much faith do we all show in D to spend so much time? And microsoft is FAR
from owning it..

And yes, the call for more cooperation, and less argument of petty issues. Can
we turn that into a project?

I will sign up for it!

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com
May 30, 2005
Re: Native Windows Support
"John C" <johnch_atms@hotmail.com> wrote in message news:d7fsok$2sms$1@digitaldaemon.com...
*snip*
> That's not true. C# by default just links certain libraries, such as the
> System library, making it appear seamless. Venture out into Windows Forms or
> Web Services, and you have to tell the compiler to link to the libraries
> that contain their functionality.
>
*snip*
>
> Ok, I can see how you could interpret things that way. But these are
> namespaces from the .NET Base Class Library. They're libraries, just as
> Phobos and Mango and DWT are all libraries. C# automatically imports a few
> for you (System, for example), but for others (such as System.Drawing and
> System.Windows.Forms) you'd still need to reference them manually. If you
> use Visual Studio, it has templates that automate this process, so perhaps
> that's why it appeared as though all the work was done for you. The
> namespaces are not part of the language, there's nothing native to C# in
> those namespaces. The C# language is aware of some of the libraries, and
> indeed relies on them for its basic types, as you mention; but D relies on
> some Phobos functionality. I don't see much difference in that respect.
>
>
>

Okay, as I've said.. it's been a while.  I haven't used a "release version" of C#,
so it is entirely concievable that such things have changed somewhat.

My point was not to discuss C# anyway.  My point was to suggest that
the D language be stepped up a notch to provide basic functionality at it's core
that the C language does not.  Functionality that has been standardized to the
point that it could be included in the D language without making any part of the language
platform spoecific (as the "built-in assembler does, at this point).

I'm not asking for much... in my opinion.

I'm also not seeing people say that they would dislike having such basic functionality included in the D language...
but rather that people are not "used to it" at this point.

So, I'll start a new thread (for the sake of those who don't follow old threads, and ask straight out...

if it were POSSIBLE, would anyone besides me like to see basic GUI functionality built into the D language?
(please answer in the new thread, "Basic GUI functionality in the D language")

TZ
May 30, 2005
Re: Native Windows Support
TechnoZeus escribió:
> 
> Okay, it's been a while but here's how I remember it...
> 
> Functionality was placed into namespaces.
> For example, int was an alias for System.Int32 and bool was an alias for System.boolean

This isn't a C# ng, but still...
I don't think that's true. AFAIUI, int and bool are C# native types, 
whereas System.Int32 and System.Boolean (or Bool, I don't remember) are 
classes. What C# is automatic boxing/unboxing so it seems like they're 
the same. They did that because they thought that would be enought for 
their (initial) lack of generics.

> but it was possible to specify a namespace with the using statement so functionality
> in that namespace could be used without full qualification.
> In other words, you could specify something like...
> using System;
> using System.Reflection;
> and then anything in the System namespace or the System.Reflection namespace
> could be used with that part of it's fully qualified name stripped off.
> 
> For console applications, you had to specify that you were using the System.Console namespace
> if you wanted to avoid having to type things like...
> System.Console.WriteLine("hello");
> and instead be able to simply type...
> WriteLine("hello");
> and likewise, if you wanted Windows style forms, you had to either specify
> a namespace with the using statement, such as in...
> using System.WinForms;
> to keep from having to fully qualify something like...
> System.Winforms.TextBox textbox1;
> and instead be able to qualify a text box names textbox1 as simply...
> TextBox textbox1;
> 
> I don't recall ever having to specify a library to use for such things.
> Perhaps the namespaces automatically told the compiler what libraries to use, but
> if so, the process was transparent to me as a programmer.
> 
> In that sense, console applications were no more native to C# than Windows applications.
> 
> True, it could be said that neither was fully native, but only one short line of text was needed to make
> one or the other "seem" native to the language... and no further mention of it was needed anywhere, at any time.
> 
> Now... looking at the C# language specification
> (which I haven't looked at in years until just now)...
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/CSharpSpecStart.asp
> 
> under Introduction -> Getting Started...
> the following example program is given...
> 
> using System;
> class Hello
> {
>    static void Main() {
>       Console.WriteLine("hello, world");
>    }
> }
> 
> and to compile it, you would use a command like....
> csc hello.cs
> 
> No need to separately link it to anything.
> 
> The line...
> Console.WriteLine("hello, world");
> could just as easily be replaced with...
> Credits.Display();
> and again, no linking needs to be specified to compile it into a working program.
> 
> In fact, one could just as easily specify...
> 
> using System;
> using System.Web;
> using System.Web.UI;
> 
> and then go on to write an application as if HTML support was native to the C# language,
> again, without any need to specify anything more than those three lines... anywhere, at any time.
> 
> When I think about it, yeah... you're probably right.
> Libraries were most likely being used... but a thin disguise over that fact meant that I never had to think about it.
> Likewise, I would guess that libraries are likely being used in Visual Basic when a control or container is dropped into an application...
> but the programmer never has to think about that to use the control or container.
> 

What Justin said about VB.Net applies just the same to C#.

> That's what I'm trying to encourage here... to have the D language allow programmers to concentrate on programming...
> rather than on putting together the pieces that support the program.  That's the whole idea behind higher level languages.
> Otherwise, we might as well be writing everything in assembly code.
> 
> TZ
> 
> 


I could be reading too much, but from what you've said so far, it is to 
my impression that you think that D doesn't have real support for GUI 
based applications, but it has support for console based. If that's not 
correct, then my following argument is pointless, but if it's true then 
I think you're wrong: either D has support for both console and GUI 
applications or has no support for either. We've already told you how to 
do GUI applications: interfacing with C libraries. But have you thought 
how D does console output? Either with printf/putc/puts/etc which are C 
functions or with writef, which in turn calls putc.

-- 
Carlos Santander Bernal
May 31, 2005
Re: Native Windows Support
"Carlos Santander" <csantander619@gmail.com> wrote in message news:d7g5hh$38u$1@digitaldaemon.com...
>
> This isn't a C# ng, but still...
> I don't think that's true. AFAIUI, int and bool are C# native types,
> whereas System.Int32 and System.Boolean (or Bool, I don't remember) are
> classes. What C# is automatic boxing/unboxing so it seems like they're
> the same. They did that because they thought that would be enought for
> their (initial) lack of generics.
>
*snip*
>
> I could be reading too much, but from what you've said so far, it is to
> my impression that you think that D doesn't have real support for GUI
> based applications, but it has support for console based. If that's not
> correct, then my following argument is pointless, but if it's true then
> I think you're wrong: either D has support for both console and GUI
> applications or has no support for either. We've already told you how to
> do GUI applications: interfacing with C libraries. But have you thought
> how D does console output? Either with printf/putc/puts/etc which are C
> functions or with writef, which in turn calls putc.
>
> -- 
> Carlos Santander Bernal

Again, it has been a while.  Perhaps things have changed.
What I know of it is that Int32 is a structure of the .NET framework, and
the C# language derives it's int type from that structure.  I know for a fact that
at one point in time this was done by means of making int and alias for Int32,
but I don't know whether or not it is currently derived in the same way.

Anyway, it's unimportant.... and getting off-subject.

As for your impression, I would have to say that it is off, but not way off.
I am not saying that D lacks "real support" for either console or GUI applications.
What I am saying is that to my knowledge it lacks "any native" support for GUI based applications.
Native support for console based or "text based" applications is sparse, but does exist,
and Phobos augments them nicely... but GUI application development is litterally foreign to D at this point,
with the GUI portions of such applications having to rely on sparsely available and
for the most part questionably functional external libraries most of which neither written in nor for the D language.

Know of a good exception to this?  If so, I would love to see it...
but either way the fact still remains, that the D language could benefit from some core support for such things as
menus and controls, which are so commonly used in GUI based applications.

Of, and by the way... printf was buggy when used in D, last I checked,
so I generally use writef instead... which isn't a C function at all.  (Correct me if I'm wrong here, Walter.)

TZ
May 31, 2005
Re: Standard GUI Toolkit
"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d7fuvj$2uo2$1@digitaldaemon.com...
>
*snip*
>
> was ONLY directed at being a JOKE.. I would never insult TechnoZeus. Unless he
> punched me or something, cause than he would have it comming :) (< Also a joke)
>
*snip*
>
> And yes, the call for more cooperation, and less argument of petty issues. Can
> we turn that into a project?
>
> I will sign up for it!
>
> Thanks,
> Trevor Parscal
> www.trevorparscal.com
> trevorparscal@hotmail.com
>

Okay... sorry for taking your joke seriously.
No tone of voice in text, tends to lead to such misunderstandings occasionally.
That's why emoticons are so nice.  :)

My apologies for the misinterpretation of your jest.
As we both know, the issue it addressed is a very serious one... but yes, there is humor in it also.

I've often wondered why a sense of humor isn't considered one of our major senses.
After all, without one a person tends to miss out on most of the world.

Yep... sounds like a project I've been signed up for most of my life now.
Not sure who's got the list, but I'm sure I'm on it somewhere.  :)

TZ
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home