www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Native Windows Support

reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
Does anyone know if there are any plans to eventually have native Windows
support in the D language?

By this I mean, not having to import modules from another language (such as C)
to write a Windows program.

There are several reasons why I ask, but before I get into any of them here,
I would just like to know if such a thing is planned at all.

TZ
May 27 2005
next sibling parent reply bobef <bobef_member pathlink.com> writes:
I think the anwer is that D is a programming language not a library for
windows... But it would be cool if windows was better supported... Current win32
headers are more like win16 or at most win95...

In article <d77mve$1vav$1 digitaldaemon.com>, TechnoZeus says...
Does anyone know if there are any plans to eventually have native Windows
support in the D language?

By this I mean, not having to import modules from another language (such as C)
to write a Windows program.

There are several reasons why I ask, but before I get into any of them here,
I would just like to know if such a thing is planned at all.

TZ

May 27 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
bobef wrote:
 I think the anwer is that D is a programming language not a library for
 windows... But it would be cool if windows was better supported... Current
win32
 headers are more like win16 or at most win95...
 
 In article <d77mve$1vav$1 digitaldaemon.com>, TechnoZeus says...
 
Does anyone know if there are any plans to eventually have native Windows
support in the D language?

By this I mean, not having to import modules from another language (such as C)
to write a Windows program.

There are several reasons why I ask, but before I get into any of them here,
I would just like to know if such a thing is planned at all.

TZ


GUI library that was cross-platform. Since we have a whole new language, if you're going to write a GUI style wrapper it may as well be able to run on more than just Windows. I would suggest that either wxWindows or Gtk+ would make good backends for a D UI wrapper. Brad
May 27 2005
next sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
I would hope that a better solution would be to use/invent a D specific 
GUI library that was cross-platform.  Since we have a whole new 
language, if you're going to write a GUI style wrapper it may as well be 
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends 
for a D UI wrapper.

Brad

I have to take issue with this one. Cause if you do make a GUI wrapper, how native the wrapper looks makes a big deal, which than of course limits the wrapper to the lowest denominator of the platforms it supports. So if there is no DatePicker on OSX, than you have to either fake one, or not use it on ANY platform. I also see it from the Gtk+ side, where native style is not such a big deal, and you can theme your own app to be the same everywhere, but for that to be THE gui library of D seems limited too. Why? In graphical user interface design, a HUGE part of making something USABLE is NOT forcing the user to learn something new unless absolutely nessecary. Making the interface different from the native look and feel, even as small of a change as changing an icon in a scroll bar, can make the application less usable on that platform. Than there is the other extreme. The one that I am admitedly taking. Using something like OpenGL to make a next generation gui. This way I am creating a new experience entirely, which causes a learning curve, but is in no way limiting from platform to platform... Blender is an application that proves this design can be successful. www.blender.org The good thing is, you can choose which way you want to go already, and D is in it's early stages. Perhaps D doesn't need a gui toolkit that is in anyway more associated with D than any other. Just my thoughts. Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com
May 27 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Trevor Parscal wrote:
I would hope that a better solution would be to use/invent a D specific 
GUI library that was cross-platform.  Since we have a whole new 
language, if you're going to write a GUI style wrapper it may as well be 
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends 
for a D UI wrapper.

Brad

I have to take issue with this one. Cause if you do make a GUI wrapper, how native the wrapper looks makes a big deal, which than of course limits the wrapper to the lowest denominator of the platforms it supports. So if there is no DatePicker on OSX, than you have to either fake one, or not use it on ANY platform.

that they are run on. Qt manages to do a fair job of cross-platform toolkitting. The point I was making is that if a large scale D GUI project were to be started, I would hope it would be written in a manner that thought about being cross-platform. I feel that market share for non-windows OSes is trending upward, and the benefits of a cross-platform GUI toolkit would be far greater than only a single platform toolkit. As for programming to the lowest common denominator, I think that is a good point. IMHO the solution would be for the toolkit to support each platform to its fullest, and let the application programmer choose the level of platform dependance. Ie, in the toolkit implement DatePicker to only work on Win32 using native calls, if it is a very popular widget, then someone will implement it in a more general way. I realise that what I am saying is HARD - that's why I'm not doing anything about it :) I'm just trying to sway people to be cross-platform aware. Brad
May 27 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
I realise that what I am saying is HARD - that's why I'm not doing 
anything about it :)  I'm just trying to sway people to be 
cross-platform aware.

Brad

I think that cross platform aware is a trend that D is a part of, not against, but sometimes you should also considder limits. For instance, I really wish SDL were capable of handling window management in a more advanced way, but they are so determined to ensure it works on Amiga and some obscure version of Unix, they forgot to make it more powerful for the other 99% on Windows, Mac, and Linux (Well, X) I think we should strive to build a cross platform gui toolkit that is aimed at Modern (still being developed and growing with new technological trends) Desktop operating systems. One might think, the most popular modern operating systems... - Windows XP - Mac OSX - Linux But in reality, you should spend about 7 times more attention to getting solid Window 2000 support before you considder making it work on a Mac. (I base this on the stats I got from google) And windows 2000 doesnt even qualify as a modern OS... 1st. 64.0% Win XP 2nd. 19.7% W2000 3rd. 4.1% Win 98 4th. 3.3% Linux 5th. 2.9% Mac I suppose we should expect OSX to push mac's numbers through the roof, but the problem is, Linux is growing faster, perhaps skewed by the increasing number of chinese computers being shipped with linux for legal reasons, only to later run a pirated copy of windows. I still think we should strive to make a GUI toolkit for the top three though. Just, lets not get caught up on running the apps on a dreamcast. :) If anyone wants to start this new endevor with me, e-mail me, we can get something running and go from there. Just some more thoughts, on my day off... Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com
May 27 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d78245$27ej$1 digitaldaemon.com...
I realise that what I am saying is HARD - that's why I'm not doing
anything about it :)  I'm just trying to sway people to be
cross-platform aware.

Brad

I think that cross platform aware is a trend that D is a part of, not against, but sometimes you should also considder limits. For instance, I really wish SDL were capable of handling window management in a more advanced way, but they are so determined to ensure it works on Amiga and some obscure version of Unix, they forgot to make it more powerful for the other 99% on Windows, Mac, and Linux (Well, X) I think we should strive to build a cross platform gui toolkit that is aimed at Modern (still being developed and growing with new technological trends) Desktop operating systems. One might think, the most popular modern operating systems... - Windows XP - Mac OSX - Linux But in reality, you should spend about 7 times more attention to getting solid Window 2000 support before you considder making it work on a Mac. (I base this on the stats I got from google) And windows 2000 doesnt even qualify as a modern OS... 1st. 64.0% Win XP 2nd. 19.7% W2000 3rd. 4.1% Win 98 4th. 3.3% Linux 5th. 2.9% Mac I suppose we should expect OSX to push mac's numbers through the roof, but the problem is, Linux is growing faster, perhaps skewed by the increasing number of chinese computers being shipped with linux for legal reasons, only to later run a pirated copy of windows. I still think we should strive to make a GUI toolkit for the top three though. Just, lets not get caught up on running the apps on a dreamcast. :) If anyone wants to start this new endevor with me, e-mail me, we can get something running and go from there. Just some more thoughts, on my day off... Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com

Exactly my point. Windows has it's problems, and is quite expensive (especially when compared with any free operating system) but it is popular for more reasons than just the fact that it's backed by a big company. Native support for Windows would be a good step in the right direction in my opinion, especially if a lowest common denominator implementation key Windows style functionality were to be built in as a cross-platform default, and then over-ridden over time in each case where a better solution is found (or made) to be available. This way, rather than leaving out a functionality becuase it's not fully supported on some platform, the functionality would be made available on that platform even if only in a crude form, helping to shape the future in a positive way. Consider the fact that every version of Microsoft Windows older than Windows 95 was entirely a DOS application, running in an environment that had no native GUI support. Consider also that almost 100% of the early Windows programs (and most well written modern ones) could be run without a mouse, because functionality such as the menu system was designed to work in several different ways, and acomodate the user's prefered way of doing things. This concept still works, but has unfortunately not been kept up so much in recent years... but there's no reason D shouldn't be able to have such a concept built in, at least to a reasonable extent. Perhaps in addition to built in assembly language support, there should be built in XML or HTML support, or something similar that would allow a GUI to be built as a native part of the D source code... but there I'm just speculating. Regardless of how it's done, I do feel that any level of native GUI support, and in turn native Windows support based on that native GUI support, would be a huge plus for the future of the D programming language. In short, I would like to write Windows programs "the D way" in D, rather than "the C way" with D parts. TZ TZ
May 28 2005
parent reply Carlos Santander <csantander619 gmail.com> writes:
TechnoZeus escribió:
 
 Exactly my point.  Windows has it's problems, and is quite expensive
(especially
 when compared with any free operating system) but it is popular for more
reasons than
 just the fact that it's backed by a big company.  Native support for Windows
would be a
 good step in the right direction in my opinion, especially if a lowest common
denominator
 implementation key Windows style functionality were to be built in as a
cross-platform default,
 and then over-ridden over time in each case where a better solution is found
(or made) to be
 available.  This way, rather than leaving out a functionality becuase it's not
fully supported on some
 platform, the functionality would be made available on that platform even if
only in a crude form,
 helping to shape the future in a positive way.
 
 Consider the fact that every version of Microsoft Windows older than Windows
95 was entirely
 a DOS application, running in an environment that had no native GUI support. 
Consider also that
 almost 100% of the early Windows programs (and most well written modern ones)
could be run
 without a mouse, because functionality such as the menu system was designed to
work in several
 different ways, and acomodate the user's prefered way of doing things.  This
concept still works,
 but has unfortunately not been kept up so much in recent years... but there's
no reason D shouldn't
 be able to have such a concept built in, at least to a reasonable extent.
 
 Perhaps in addition to built in assembly language support, there should be
built in XML or HTML support,
 or something similar that would allow a GUI to be built as a native part of
the D source code...
 but there I'm just speculating.  Regardless of how it's done, I do feel that
any level of native GUI support, and
 in turn native Windows support based on that native GUI support, would be a
huge plus for
 the future of the D programming language.
 
 In short, I would like to write Windows programs "the D way" in D, rather than
"the C way" with D parts.
 
 TZ
 
 
 TZ
 
 

I really don't understand what you're saying. Can you write native looking Windows applications in C? Yes. Can you do it in D? Yes. How? The same way you do it in C: use a file with the Win32 headers (Core32 in dsource, for example) so you can do "CreateWindow(...)" et al, link with the appropiate libraries (you could need gdi32.lib and/or others) and run it. They have Win2000 look. If you want WinXP theming, you have to use a special resource file, just like you would in C. What's not native there? For other platforms, the process is similar, except that IMHO there's no native look on linux because you can have X, GTK+, KDE, etc. Native on Mac seems to be the same as in Windows, but my experience with it is not that much yet. But you get "native" X, or "native" GTK+, etc. Again, I don't understand what you're saying. I maybe missing something. -- Carlos Santander Bernal
May 28 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:d79t3k$pbv$1 digitaldaemon.com...
 TechnoZeus escribió:
 Exactly my point.  Windows has it's problems, and is quite expensive
(especially
 when compared with any free operating system) but it is popular for more
reasons than
 just the fact that it's backed by a big company.  Native support for Windows
would be a
 good step in the right direction in my opinion, especially if a lowest common
denominator
 implementation key Windows style functionality were to be built in as a
cross-platform default,
 and then over-ridden over time in each case where a better solution is found
(or made) to be
 available.  This way, rather than leaving out a functionality becuase it's not
fully supported on some
 platform, the functionality would be made available on that platform even if
only in a crude form,
 helping to shape the future in a positive way.

 Consider the fact that every version of Microsoft Windows older than Windows
95 was entirely
 a DOS application, running in an environment that had no native GUI support. 
Consider also that
 almost 100% of the early Windows programs (and most well written modern ones)
could be run
 without a mouse, because functionality such as the menu system was designed to
work in several
 different ways, and acomodate the user's prefered way of doing things.  This
concept still works,
 but has unfortunately not been kept up so much in recent years... but there's
no reason D shouldn't
 be able to have such a concept built in, at least to a reasonable extent.

 Perhaps in addition to built in assembly language support, there should be
built in XML or HTML support,
 or something similar that would allow a GUI to be built as a native part of
the D source code...
 but there I'm just speculating.  Regardless of how it's done, I do feel that
any level of native GUI support, and
 in turn native Windows support based on that native GUI support, would be a
huge plus for
 the future of the D programming language.

 In short, I would like to write Windows programs "the D way" in D, rather than
"the C way" with D parts.

 TZ


 TZ

I really don't understand what you're saying. Can you write native looking Windows applications in C? Yes. Can you do it in D? Yes. How? The same way you do it in C: use a file with the Win32 headers (Core32 in dsource, for example) so you can do "CreateWindow(...)" et al, link with the appropiate libraries (you could need gdi32.lib and/or others) and run it. They have Win2000 look. If you want WinXP theming, you have to use a special resource file, just like you would in C. What's not native there? For other platforms, the process is similar, except that IMHO there's no native look on linux because you can have X, GTK+, KDE, etc. Native on Mac seems to be the same as in Windows, but my experience with it is not that much yet. But you get "native" X, or "native" GTK+, etc. Again, I don't understand what you're saying. I maybe missing something. -- Carlos Santander Bernal

No, that's not what I mean at all. C has no native support for Windows, and for that matter to my knowledge no native support for development of GUI based applications. Having to use an external header file or library is a good sign that the support is not native to the language, but rather something that was added as an after-thought... probably by someone other than the language's developer. ...and as such, is generally neither universally available to everyone using the language nor included in the language's specification or documentation. TZ
May 30 2005
parent reply Carlos Santander <Carlos_member pathlink.com> writes:
In article <d7eh5d$1ejo$1 digitaldaemon.com>, TechnoZeus says...
No, that's not what I mean at all.

C has no native support for Windows, and for that matter to my knowledge
no native support for development of GUI based applications.

Having to use an external header file or library is a good sign that the
support is not native to the language,
but rather something that was added as an after-thought...
probably by someone other than the language's developer.
...and as such, is generally neither universally available to everyone using
the language
nor included in the language's specification or documentation.

TZ

Please read what Walter thinks about it here: digitalmars.D/24711 -- Carlos Santander Bernal
May 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Carlos Santander" <Carlos_member pathlink.com> wrote in message
news:d7f6b9$25qu$1 digitaldaemon.com...
 In article <d7eh5d$1ejo$1 digitaldaemon.com>, TechnoZeus says...
No, that's not what I mean at all.

C has no native support for Windows, and for that matter to my knowledge
no native support for development of GUI based applications.

Having to use an external header file or library is a good sign that the
support is not native to the language,
but rather something that was added as an after-thought...
probably by someone other than the language's developer.
...and as such, is generally neither universally available to everyone using
the language
nor included in the language's specification or documentation.

TZ

Please read what Walter thinks about it here: digitalmars.D/24711 -- Carlos Santander Bernal

Thanks... good to see where he stands on GUI libraries... but again, I'm not talking about making a GUI library standard. In fact, although I have nothing against that idea if one came along that most D programmers agreed SHOULD be standardized, but short of that happening, I wouldn't want any specific GUI library to be set above the others as a standard. What I'm talking about is adding basic GUI support to the D lanugage itself... the kind of stuff that would make it possible to write a good GUI library in a small fraction of the source code, and would make using a GUI library for a simple cross-platform application completely unnecessary. I've already noticed that Walter isn't too big on GUI's by the fact that when I mentioned my concerns with how D works from a context mene, he told me to open a command prompt and run it from there... but he also does pay attention to what "we" want... meaning, if the D community sees it as important, Walter will most likely also come to see it as important eventually... if he doesn't already. TZ
May 30 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 In graphical user interface design, a HUGE part of making something USABLE 
 is
 NOT forcing the user to learn something new unless absolutely nessecary. 
 Making
 the interface different from the native look and feel, even as small of a 
 change
 as changing an icon in a scroll bar, can make the application less usable 
 on
 that platform.

I would agree, but... There are two different types of UI we are facing these days: 1) "native" and 2) Web UI. If you will count sites or online Web applications with number of native applications in active use now then you will find that Web apps are overwhelming latter in magnitude of times. I am pretty sure that to create really 'native' application - a good citizen of target platform you should use tools and languages of the platform designed for that (E.g. Objective C for Mac and NextStep). There is no compromises here. Dixi. Generally speaking if your application is not an OS extender like e.g. name space extension widget/driver on Windows then you are free to choose your own style. Main requirement - your app should be useful and its UI must follow metaphor of its main function and users will accept it on any platform and in any form. Take a look on Eclipse: even it is using native widgets it is a foreigner on Mac: http://developer.apple.com/tools/images/eclipse_plugin.jpg For example take a look on scrollbars there - to be ergonomic they should be implemented as less invisible as possible in such kind of UI - productive IDEs. Take a look on Microsoft Office - it is *absolutely* non-native Windows UI. http://www.winsupersite.com/images/reviews/office11_10.gif Pay attention on Header of Inbox view ("Arranged by Date") - this is the only one "native" part left from native widget set of Windows on this screen. And it looks as just a UI bug, isn't it? Do you think you need native widget set for something like this?: http://www.activewin.com/reviews/software/utils/v/vscan5d/images/VS5Big.jpg Again, there are applications which *must* look as native as possible. But there are 90% of others which would just win if they will take off the uniform they are wearing now. Another example: Take a look on the app I am participating in creation: http://www.evernote.com/en/products/evernote/ UI is not perfect yet but in any case this application *must not* follow standard native platform look. IMHO, of course. Andrew. "Trevor Parscal" <Trevor_member pathlink.com> wrote in message news:d77uke$24r0$1 digitaldaemon.com...
I would hope that a better solution would be to use/invent a D specific
GUI library that was cross-platform.  Since we have a whole new
language, if you're going to write a GUI style wrapper it may as well be
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends
for a D UI wrapper.

Brad

I have to take issue with this one. Cause if you do make a GUI wrapper, how native the wrapper looks makes a big deal, which than of course limits the wrapper to the lowest denominator of the platforms it supports. So if there is no DatePicker on OSX, than you have to either fake one, or not use it on ANY platform. I also see it from the Gtk+ side, where native style is not such a big deal, and you can theme your own app to be the same everywhere, but for that to be THE gui library of D seems limited too. Why? In graphical user interface design, a HUGE part of making something USABLE is NOT forcing the user to learn something new unless absolutely nessecary. Making the interface different from the native look and feel, even as small of a change as changing an icon in a scroll bar, can make the application less usable on that platform. Than there is the other extreme. The one that I am admitedly taking. Using something like OpenGL to make a next generation gui. This way I am creating a new experience entirely, which causes a learning curve, but is in no way limiting from platform to platform... Blender is an application that proves this design can be successful. www.blender.org The good thing is, you can choose which way you want to go already, and D is in it's early stages. Perhaps D doesn't need a gui toolkit that is in anyway more associated with D than any other. Just my thoughts. Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com

May 27 2005
next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
Andrew Fedoniouk wrote:
<snip>

Andrew - if you don't mind me summarising - you are saying that:
As long as your app does useful work, and the UI is intuitive - and 
let's face it most UI's are more or less the same - then it doesn't 
matter that it does or doesn't look like the native platform?

That is a very interesting view - I will have to take note of how many 
apps I run that use "non standard" UI elements.  I hadn't thought about 
it before, but I thinkt that you are completly correct.  Even Apple, who 
are usually very strict on UI, have now got multiple different looks to 
their application.

I which case, Harmonia would be a good UI to choose :)
BTW, are you planning on allowing Harmonia to have multiple windows at 
some point in the future?

Brad
May 27 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Brad Beveridge"wrote:
 Andrew Fedoniouk wrote:
 <snip>

 Andrew - if you don't mind me summarising - you are saying that:
 As long as your app does useful work, and the UI is intuitive - and let's 
 face it most UI's are more or less the same - then it doesn't matter that 
 it does or doesn't look like the native platform?

Exactly! Moreover: pretty frequently "nativeness" of look-n-feel is just a stopper. E.g. application: http://www.evernote.com/en/images/EN-screenshot-8-full.gif *must* look different. It uses idiom of endless tape with notes (HTML and free hand) which you cannot describe in terms of OS widgets. I will say also: it is using HWNDs on Windows and this is... I'd better stay silent here.
 That is a very interesting view - I will have to take note of how many 
 apps I run that use "non standard" UI elements.  I hadn't thought about it 
 before, but I thinkt that you are completly correct.  Even Apple, who are 
 usually very strict on UI, have now got multiple different looks to their 
 application.

:) Microsoft Office, WinAmp/MediaPlayer, MSN Messenger, Netscape/Opera browsers. FireFox is pretending to be native but it does not and this is bad (small details missed, heavvy, slow, etc.). It would be much more better if its UI will be implemented natively on Win32 or just completely different. All Adobe products, All Symantec/McAfee consumer products. KlipFolio (http://www.serence.com/images/content/screens/kf-2.jpg) And only one really native Win32 application I am using I wrote by myself: http://blocknote.net/images/screenshot.jpg :)))))))
 I which case, Harmonia would be a good UI to choose :)

Oh, yeh! And the best one if D will run on mobile platforms.
 BTW, are you planning on allowing Harmonia to have multiple windows at 
 some point in the future?

What do you mean under "multiple windows"? You can create as much OS windows as you want now.... Or you mean MDI? MDI is a usability disaster (imo) - you can show multiple documents in many and more convenient ways to the user in Harmonia. Andrew.
 Brad 

May 27 2005
next sibling parent reply "Kris" <fu bar.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com>
 Exactly! Moreover: pretty frequently "nativeness" of look-n-feel
 is just a stopper. E.g. application:
 http://www.evernote.com/en/images/EN-screenshot-8-full.gif
 *must* look different. It uses idiom of endless tape with notes
 (HTML and free hand) which you cannot describe in terms of
 OS widgets.

EverNote looks like a great product! Is this something you're involved with, Andrew?
May 27 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Kris" <fu bar.com> wrote in message news:d7877i$2b97$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com>
 Exactly! Moreover: pretty frequently "nativeness" of look-n-feel
 is just a stopper. E.g. application:
 http://www.evernote.com/en/images/EN-screenshot-8-full.gif
 *must* look different. It uses idiom of endless tape with notes
 (HTML and free hand) which you cannot describe in terms of
 OS widgets.

EverNote looks like a great product! Is this something you're involved with, Andrew?

Thanks. Concept is just perfect. UI implementation.... we are working on that :)) ....I guess TerraInformatica should be in "Help/About..."... yes, it is there. I wish D working on mobiles.... :( Andrew.
May 27 2005
prev sibling next sibling parent reply Brad Beveridge <brad somewhere.net> writes:
 Oh, yeh! And the best one if D will run on mobile platforms.
 

platform. The last place I worked was a linux house specialising in ARM based systems. We cross compiled GDC to run on ARM linux, and build a small test app to make sure D and Phobos were behaving. I guess that strictly speaking, the board wasn't mobile - it didn't actually have a battery on the prototype units we had :) If only getting tool chains to work with PocketPC were so easy ;) Brad
May 27 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Oh, yeh! And the best one if D will run on mobile platforms.

platform. The last place I worked was a linux house specialising in ARM based systems. We cross compiled GDC to run on ARM linux, and build a small test app to make sure D and Phobos were behaving. I guess that strictly speaking, the board wasn't mobile - it didn't actually have a battery on the prototype units we had :)

Wow, I think that it will run on Sharp Zaurus then.
 If only getting tool chains to work with PocketPC were so easy ;)

Sigh. I know at least two corporations who will pay for such toolset. Compiler/linker would be enough. As far I can see it is possible to create native layer for Harmonia emulating PocketPC environment on Win32. So main design could be made on PC.
May 27 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d786bg$2af6$1 digitaldaemon.com...
 "Brad Beveridge"wrote:
 <snip>

 I which case, Harmonia would be a good UI to choose :)

Oh, yeh! And the best one if D will run on mobile platforms.
 BTW, are you planning on allowing Harmonia to have multiple windows at
 some point in the future?

 Brad

What do you mean under "multiple windows"? You can create as much OS windows as you want now.... Or you mean MDI? MDI is a usability disaster (imo) - you can show multiple documents in many and more convenient ways to the user in Harmonia. Andrew.

I am still looking forward to seeing Harmonia. I am also curious whether or not it is something that could be incorporated into D as an integral part, and if so, would you be willing to let it be, if Walter / Digital Mars were willing to incorporate it at that level? In other words, is it possible that (if other people were willing) we may some day be able to download a D compiler, and write GUI applications in entirely in D that would use Harmonia as a GUI backbone, without having to separately download, install, and configure Harmonia to work the the D compiler? (I'm guessing the answer to this is no, so don't worry about disappointing me, but I had to ask.) As for multi-document interface, it's not a disaster if done right. In fact, it's a great way to be able to handle many documents in one program at the same time. Take a look at Sysedit (if you don't already know it, which you probably do) for one example. You probably already have it, if you have Windows. Another good example is Crimson Editor http://www.crimsoneditor.com/ which has a tab-bar just below it's tool-bar, listing the open documents... which can be tiled or cascaded from the Window menu, or can be displayed one at a time by maximizing the foreground document window. In effect, the MDI allows the application to act as a desktop on a desktop... which is an apt matephore since the GUI was originally modeled to represent a metaphore for physical desktops such as those that many desktop computers occupy space on. TZ
May 28 2005
parent Carlos Santander <csantander619 gmail.com> writes:
TechnoZeus escribió:
 
 As for multi-document interface, it's not a disaster if done right.  In fact,
 it's a great way to be able to handle many documents in one program at the
same time.
 Take a look at Sysedit (if you don't already know it, which you probably do)
for one example.
 You probably already have it, if you have Windows.
 Another good example is Crimson Editor http://www.crimsoneditor.com/ which has
a
 tab-bar just below it's tool-bar, listing the open documents... which can be
tiled or cascaded from the
 Window menu, or can be displayed one at a time by maximizing the foreground
document window.
 In effect, the MDI allows the application to act as a desktop on a desktop...
 which is an apt matephore since the GUI was originally modeled to represent
 a metaphore for physical desktops such as those that
 many desktop computers occupy space on.
 
 TZ
 
 

I agree. It's also the trend with browsers: even IE7 will have tabbed browsing. -- Carlos Santander Bernal
May 28 2005
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I disagree.  I hate programs that try to have their own look, and avoid 
using them unless they are the only thing that opens PDFs, DOCs, etc... 
like most of the examples you gave.

I tried Eclipse, and it doesn't feel native.  It's not the look, it's 
the feel.

-[Unknown]


In graphical user interface design, a HUGE part of making something USABLE 
is
NOT forcing the user to learn something new unless absolutely nessecary. 
Making
the interface different from the native look and feel, even as small of a 
change
as changing an icon in a scroll bar, can make the application less usable 
on
that platform.

I would agree, but... There are two different types of UI we are facing these days: 1) "native" and 2) Web UI. If you will count sites or online Web applications with number of native applications in active use now then you will find that Web apps are overwhelming latter in magnitude of times. I am pretty sure that to create really 'native' application - a good citizen of target platform you should use tools and languages of the platform designed for that (E.g. Objective C for Mac and NextStep). There is no compromises here. Dixi. Generally speaking if your application is not an OS extender like e.g. name space extension widget/driver on Windows then you are free to choose your own style. Main requirement - your app should be useful and its UI must follow metaphor of its main function and users will accept it on any platform and in any form. Take a look on Eclipse: even it is using native widgets it is a foreigner on Mac: http://developer.apple.com/tools/images/eclipse_plugin.jpg For example take a look on scrollbars there - to be ergonomic they should be implemented as less invisible as possible in such kind of UI - productive IDEs. Take a look on Microsoft Office - it is *absolutely* non-native Windows UI. http://www.winsupersite.com/images/reviews/office11_10.gif Pay attention on Header of Inbox view ("Arranged by Date") - this is the only one "native" part left from native widget set of Windows on this screen. And it looks as just a UI bug, isn't it? Do you think you need native widget set for something like this?: http://www.activewin.com/reviews/software/utils/v/vscan5d/images/VS5Big.jpg Again, there are applications which *must* look as native as possible. But there are 90% of others which would just win if they will take off the uniform they are wearing now. Another example: Take a look on the app I am participating in creation: http://www.evernote.com/en/products/evernote/ UI is not perfect yet but in any case this application *must not* follow standard native platform look. IMHO, of course. Andrew. "Trevor Parscal" <Trevor_member pathlink.com> wrote in message news:d77uke$24r0$1 digitaldaemon.com...
I would hope that a better solution would be to use/invent a D specific
GUI library that was cross-platform.  Since we have a whole new
language, if you're going to write a GUI style wrapper it may as well be
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends
for a D UI wrapper.

Brad

I have to take issue with this one. Cause if you do make a GUI wrapper, how native the wrapper looks makes a big deal, which than of course limits the wrapper to the lowest denominator of the platforms it supports. So if there is no DatePicker on OSX, than you have to either fake one, or not use it on ANY platform. I also see it from the Gtk+ side, where native style is not such a big deal, and you can theme your own app to be the same everywhere, but for that to be THE gui library of D seems limited too. Why? In graphical user interface design, a HUGE part of making something USABLE is NOT forcing the user to learn something new unless absolutely nessecary. Making the interface different from the native look and feel, even as small of a change as changing an icon in a scroll bar, can make the application less usable on that platform. Than there is the other extreme. The one that I am admitedly taking. Using something like OpenGL to make a next generation gui. This way I am creating a new experience entirely, which causes a learning curve, but is in no way limiting from platform to platform... Blender is an application that proves this design can be successful. www.blender.org The good thing is, you can choose which way you want to go already, and D is in it's early stages. Perhaps D doesn't need a gui toolkit that is in anyway more associated with D than any other. Just my thoughts. Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com


May 27 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 I hate programs that try to have their own look, and avoid using them ...

WinAmp, now playing, Status Quo: "Oh-oo-oh you're in the army, in the army now". :))) (WinAmp. sic!) Russian anekdote: Drill-sergeant: "If you, civil, think that you are so wise then why aren't you marching in the order?" I am not sure about my translation but it should be close. To be serious: Name applications you are using which you consider as good from your point? No offence implied, honestly. As many people as many opionions. That is true and good. Andrew. "Unknown W. Brackets" <unknown simplemachines.org> wrote in message news:d7892e$2coi$1 digitaldaemon.com...
I disagree.  I hate programs that try to have their own look, and avoid 
using them unless they are the only thing that opens PDFs, DOCs, etc... 
like most of the examples you gave.

 I tried Eclipse, and it doesn't feel native.  It's not the look, it's the 
 feel.

 -[Unknown]


In graphical user interface design, a HUGE part of making something 
USABLE is
NOT forcing the user to learn something new unless absolutely nessecary. 
Making
the interface different from the native look and feel, even as small of a 
change
as changing an icon in a scroll bar, can make the application less usable 
on
that platform.

I would agree, but... There are two different types of UI we are facing these days: 1) "native" and 2) Web UI. If you will count sites or online Web applications with number of native applications in active use now then you will find that Web apps are overwhelming latter in magnitude of times. I am pretty sure that to create really 'native' application - a good citizen of target platform you should use tools and languages of the platform designed for that (E.g. Objective C for Mac and NextStep). There is no compromises here. Dixi. Generally speaking if your application is not an OS extender like e.g. name space extension widget/driver on Windows then you are free to choose your own style. Main requirement - your app should be useful and its UI must follow metaphor of its main function and users will accept it on any platform and in any form. Take a look on Eclipse: even it is using native widgets it is a foreigner on Mac: http://developer.apple.com/tools/images/eclipse_plugin.jpg For example take a look on scrollbars there - to be ergonomic they should be implemented as less invisible as possible in such kind of UI - productive IDEs. Take a look on Microsoft Office - it is *absolutely* non-native Windows UI. http://www.winsupersite.com/images/reviews/office11_10.gif Pay attention on Header of Inbox view ("Arranged by Date") - this is the only one "native" part left from native widget set of Windows on this screen. And it looks as just a UI bug, isn't it? Do you think you need native widget set for something like this?: http://www.activewin.com/reviews/software/utils/v/vscan5d/images/VS5Big.jpg Again, there are applications which *must* look as native as possible. But there are 90% of others which would just win if they will take off the uniform they are wearing now. Another example: Take a look on the app I am participating in creation: http://www.evernote.com/en/products/evernote/ UI is not perfect yet but in any case this application *must not* follow standard native platform look. IMHO, of course. Andrew. "Trevor Parscal" <Trevor_member pathlink.com> wrote in message news:d77uke$24r0$1 digitaldaemon.com...
I would hope that a better solution would be to use/invent a D specific
GUI library that was cross-platform.  Since we have a whole new
language, if you're going to write a GUI style wrapper it may as well be
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends
for a D UI wrapper.

Brad

I have to take issue with this one. Cause if you do make a GUI wrapper, how native the wrapper looks makes a big deal, which than of course limits the wrapper to the lowest denominator of the platforms it supports. So if there is no DatePicker on OSX, than you have to either fake one, or not use it on ANY platform. I also see it from the Gtk+ side, where native style is not such a big deal, and you can theme your own app to be the same everywhere, but for that to be THE gui library of D seems limited too. Why? In graphical user interface design, a HUGE part of making something USABLE is NOT forcing the user to learn something new unless absolutely nessecary. Making the interface different from the native look and feel, even as small of a change as changing an icon in a scroll bar, can make the application less usable on that platform. Than there is the other extreme. The one that I am admitedly taking. Using something like OpenGL to make a next generation gui. This way I am creating a new experience entirely, which causes a learning curve, but is in no way limiting from platform to platform... Blender is an application that proves this design can be successful. www.blender.org The good thing is, you can choose which way you want to go already, and D is in it's early stages. Perhaps D doesn't need a gui toolkit that is in anyway more associated with D than any other. Just my thoughts. Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com



May 27 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Visual Studio .NET - while it has many Office style widgets, it by and 
large uses the general look and feel of Windows.

VMware.

Firefox, Thunderbird (imho, native-ness on multiple plaforms is their 
clear strong point, whatever you say.)

Symantec Antivirus (corporate version, uses native UI.)

SmartFTP (not a perfect example.)

Ahead Nero (not a perfect example.)

TUGZip, WinZip, whatever you prefer.

MySQL and its applications.

These all look good, work well, and are easy to use.  They feel right, 
they respect my Windows preferences.

A good example of a bad one: Cisco's VPN client.  Ugh, the feel of that 
program.  TortoiseCVS too (which uses native widgets, but badly imho), 
althought I only use it for the icons in Explorer.

And although you asserted otherwise, Adobe Photoshop (which I also use) 
uses a lot of native widgets which is a good thing.  It uses a lot of 
custom ones, but that's a neccessity - I never said that shouldn't be done.

-[Unknown]


 Name applications you are using which you consider as good from your
 point?
 
 No offence implied, honestly.
 As many people as many opionions. That is true and good.
 
 Andrew.

May 27 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 Visual Studio .NET - while it has many Office style widgets, it by and 
 large uses the general look and feel of Windows.

Visual Studio.Net uses old set of Office UI widgets (a.k.a flat controls) All controls in this foundation are custom made and has non Windows look-n-feel e.g. massive use of mouse-over effects. If you are in XP then try to switch from XP theme to Classic. Visual Studio.Net just ignores your preferences. Seems like I don't understand your "general look and feel of Windows". Or you mean just color schema? Or window layout (which is pretty much IBMs CUI )?
 VMware.

Ah this beauty of Windows dialogs: http://www.vmware.com/products/desktop/img/ws5_large7.gif :)
 Firefox, Thunderbird (imho, native-ness on multiple plaforms is their 
 clear strong point, whatever you say.)

Not point but intention. As point cannot be reached so straightforward. Small detail: Standard tabs in Windows http://www.mozilla-firefox.com/images/tab-menu.png were not designed for use in windows-frames. They are for dialogs only. It would be way better if Firefox use different look for them.
 Symantec Antivirus (corporate version, uses native UI.)

I'll trust you, never seen it. This one: http://www.softpedia.com/screenshots//Norton-AntiVirus-Virus-Definitions_1.png I know.
 SmartFTP (not a perfect example.)

 Ahead Nero (not a perfect example.)

 TUGZip, WinZip, whatever you prefer.

WinZip is a bad example too. The best from UI/usability perspective is MS builtin zip support - it shows ZIP files transparently - as a Shell Namespace Extension. But not enough functionality. Good example in fact - native look and feel but not enough features and completely "not cute" :)
 MySQL and its applications.

??? Command line interface ??? Where is GUI there?
 These all look good, work well, and are easy to use.  They feel right, 
 they respect my Windows preferences.

At least Visual Studio .NET does not respect your Windows preferences. In fact Microsoft is a biggest abuser of their own UI design recomendations. No one major product suite is not using them. MS Money, VS, MSN, Office - all of them has their own and distinct GUI style.
 A good example of a bad one: Cisco's VPN client.  Ugh, the feel of that 
 program.  TortoiseCVS too (which uses native widgets, but badly imho), 
 althought I only use it for the icons in Explorer.

I lost you here completely. http://www.tortoisecvs.org/screenshot1.png Tortoise clients made as Namespace Extensions. This is 120% native look-n-feel. What do you mean? Andrew.
May 27 2005
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
 Seems like I don't understand your "general look and feel of Windows".
 Or you mean just color schema? Or window layout (which is pretty
 much IBMs CUI )?

Microsoft designed the GUI, so they can keep it with the same feel. The look isn't as important, and Visual Studio .NET does adjust somewhat to the theme I choose; much better than some of the programs you've mentioned.
 Not point but intention. As point cannot be reached so straightforward.

Language barriers.....
 Small detail: Standard tabs in Windows...

I very strongly disagree, but this is only a matter of opinion.
MySQL and its applications.

??? Command line interface ??? Where is GUI there?

MySQL and its applications. You may have to look at it and no rely on memory from '99.
 I lost you here completely.
 http://www.tortoisecvs.org/screenshot1.png
 Tortoise clients made as Namespace Extensions.
 This is 120% native look-n-feel.

Look and feel are not the same thing. And that's just the shell integration you're looking at, that's not the part that "feels" wrong. -[Unknown]
May 27 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
news:d78lid$2od8$1 digitaldaemon.com...
 Seems like I don't understand your "general look and feel of Windows".
 Or you mean just color schema? Or window layout (which is pretty
 much IBMs CUI )?

Microsoft designed the GUI, so they can keep it with the same feel. The look isn't as important, and Visual Studio .NET does adjust somewhat to the theme I choose; much better than some of the programs you've mentioned.
 Not point but intention. As point cannot be reached so straightforward.

Language barriers.....
 Small detail: Standard tabs in Windows...

I very strongly disagree, but this is only a matter of opinion.
MySQL and its applications.

??? Command line interface ??? Where is GUI there?

MySQL and its applications. You may have to look at it and no rely on memory from '99.
 I lost you here completely.
 http://www.tortoisecvs.org/screenshot1.png
 Tortoise clients made as Namespace Extensions.
 This is 120% native look-n-feel.

Look and feel are not the same thing. And that's just the shell integration you're looking at, that's not the part that "feels" wrong. -[Unknown]

Correct me if I'm mistaken, but I think a good "non-visual" example of what you are talking about can be found in the keyboard shortcuts for cut, copy, and paste. Originally, Windows used cut = shift-delete, copy = ctrl-insert, paste = shift-insert, while Macintosh used cut = option-x, copy = option-c, paste = option v, and applications written for each platform usually conformed to those standards. Over time, people who learned on Macs in high-school and college, and felt uncomfortable with the Windows keyboard shortcuts or wanted cross-platform consistancy wrote into their Windows applications... cut = ctrl-x, copy = ctrl-c, paste = ctrl-v, but Windows still supported it's own "built-in" keyboard shortcuts too. Now, newer versions of Windows no longer have any consistant keyboard shortcuts for those three functions, and shift-delete has even been adapted in Windows Explorer as a keyboard shortcut for "permanent delete" making a serious risk for someone who is used to thinking of shift-delete as a way of deleting something from it's current location but being able to paste it into a new location from the clipboard. The "feel" is no longer consistant... even within the operating system, in this case. TZ
May 28 2005
prev sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
Unless it's a really useful app, with a very powerful purpose, like 3D Studio
Max for instance, than being as close to the native style as possible is usually
a good thing.

Little utilities, I feel, are best made native looking. I use Nero, not one of
those "themed" cd burners, cause I can't take them seriously.

Media players and instant messaging like www.trillian.cc are themable, and often
times people chose themes that aren't native, but there always seems to be a
native theme, so at least there is an option for the user.

All in all, usability is not something that most software developers pay any
attention to at all. I know, I am a usability consultant. Even big companies
with huge teams have a hard time making software usable, so they hire
specialists, (outsourcing or in house) to help make things better.

All in all, I think that neither Windows, Linux, or Mac (in order of popularity
on the desktop) have a perfect UI look and feel, but if a user accustoms
themselves to it, forcing them to learn your "new" way of doing things is like
making a Mac user use Windows; they will be out of their element for a while.

Like I said though, a big program, like one you can take a class for... It
doesnt matter as long as it's usefull, cause quite frankly you are going to have
to learn so much, and there is simply not enough controls in a basic gui kit on
any platform to make a REAL program from.

My 2 cents.. plus some.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 27 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d78df2$2gn8$1 digitaldaemon.com...
 Unless it's a really useful app, with a very powerful purpose, like 3D Studio
 Max for instance, than being as close to the native style as possible is
usually
 a good thing.

 Little utilities, I feel, are best made native looking. I use Nero, not one of
 those "themed" cd burners, cause I can't take them seriously.

 Media players and instant messaging like www.trillian.cc are themable, and
often
 times people chose themes that aren't native, but there always seems to be a
 native theme, so at least there is an option for the user.

 All in all, usability is not something that most software developers pay any
 attention to at all. I know, I am a usability consultant. Even big companies
 with huge teams have a hard time making software usable, so they hire
 specialists, (outsourcing or in house) to help make things better.

 All in all, I think that neither Windows, Linux, or Mac (in order of popularity
 on the desktop) have a perfect UI look and feel, but if a user accustoms
 themselves to it, forcing them to learn your "new" way of doing things is like
 making a Mac user use Windows; they will be out of their element for a while.

 Like I said though, a big program, like one you can take a class for... It
 doesnt matter as long as it's usefull, cause quite frankly you are going to
have
 to learn so much, and there is simply not enough controls in a basic gui kit on
 any platform to make a REAL program from.

 My 2 cents.. plus some.

 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com

I agree with most, but not all of what you just said. The part I disagree with is the idea that if a program is already large and complex enough to be expected to take a lot of training to use, then the extent to which such a program is designed to allow existing knowledge to be apploed doesn't matter. The way I see it... It matters a lot! Yes, there are always going to be new elements in a sufficiently complex program that need to be learned from the ground up, but overwhelming people with a barage of new little things to "re-learn" is usually not necessary. It may be easier for the programmers to design the software that way, but that's exactly why I'm asking about native Windows support and more importantly, native GUI and modern platform support in the D language... so that D programs could be "more easily" written not to require such a steep learning curve. In other words, I would like to see usability addressed at the programming language development level... while there's still a chance of that happening. TZ
May 28 2005
prev sibling parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d77uke$24r0$1 digitaldaemon.com...
I would hope that a better solution would be to use/invent a D specific
GUI library that was cross-platform.  Since we have a whole new
language, if you're going to write a GUI style wrapper it may as well be
able to run on more than just Windows.
I would suggest that either wxWindows or Gtk+ would make good backends
for a D UI wrapper.

Brad


 native the wrapper looks makes a big deal, which than of course limits the
 wrapper to the lowest denominator of the platforms it supports. So if there is
 no DatePicker on OSX, than you have to either fake one, or not use it on ANY
 platform.

 I also see it from the Gtk+ side, where native style is not such a big deal,
and
 you can theme your own app to be the same everywhere, but for that to be THE
gui
 library of D seems limited too. Why?

 In graphical user interface design, a HUGE part of making something USABLE is
 NOT forcing the user to learn something new unless absolutely nessecary. Making
 the interface different from the native look and feel, even as small of a
change
 as changing an icon in a scroll bar, can make the application less usable on
 that platform.

 Than there is the other extreme. The one that I am admitedly taking. Using
 something like OpenGL to make a next generation gui. This way I am creating a
 new experience entirely, which causes a learning curve, but is in no way
 limiting from platform to platform... Blender is an application that proves
this
 design can be successful. www.blender.org

 The good thing is, you can choose which way you want to go already, and D is in
 it's early stages. Perhaps D doesn't need a gui toolkit that is in anyway more
 associated with D than any other.

 Just my thoughts.

 Thanks,
 Trevor Parscal
 www.trevorparscal.com
 trevorparscal hotmail.com

I agree. It is important that to what ever extent possible, what works on one platform will also work on another. Take the "printf" statement for example (which is a C function that is used a lot in D) and consider the fact that it works fine in a program with a console window, or in a console or terminal style application, but fails to give any output in a GUI application with no console window. This is nowhere near ideal. It would be better to have an output function that outputs to the main background surface of an application by default, or one that outputs to the active forground surface of an application by default, or one that sends it's output to the most recently active surface of the application that is text capable... or SOME consistant behavior, but defined as a language standard rather than as an external function that may or may not output to anything at all when it's told to. Implementation of such basic things as menus, text output, text input, directional input (such as a joystick, arrow keys, etc.) and so on, can and should be native to the programming language if possible, and established as standards with certain predictable functionality. The exact implementation of that functionality can then be drawn from the resources available on the target platform. For example, a menu object can contain information on menu titles, descriptions, hot-keys, and so on. but the menu displayed by such an object, and the times or places it is displayed can vary from one platform to another. A console or terminal application may display the menu in textual form at key times when menu input is expected, while a GUI application may display it at all times in the main menu bar of the application's main window on one platform, or as a subset of the main OS menu when that application is in the foreground on another platform. Any functional default would be sufficient to allow the object to be used, and can be improved on in future implementations, and/or over-ridden by advanced programmers who are not satisfied with the defaults. The date picker is a good example. It's not hard to implement a text based default for such a thing, which could be used in non-GUI environments, or in environments that lack one or that have one which is not yet supported... as a temporary substitute, if necessary. The important thing is, in my opinion, to recognize that such functionality is necessary in today's applications and build at least "some" native support into the programming language, if at all possible. This native support shouldn't go so far as to preclude choices that the programmer would otherwise have, but should give consistant default behaviors within a given environment when no such choice has been made... again, to the extent possible... which is hugely a function of time and intent. It's the intent that I am questioning. After all... time is something that all of us here are investing, so we should have no trouble being patient if we feel confident that the future is bright. (no pun intended.) TZ
May 28 2005
prev sibling parent reply "Jim H" <jhewesNOSPAM ix.netcom.com> writes:
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d77ots$20ms$1 digitaldaemon.com...
 I would suggest that either wxWindows or Gtk+ would make good backends for 
 a D UI wrapper.

Speaking of wxWidgets (wxWindows), as soon as I discovered D, I thought how great it would be to use D together with wxWidgets. Unfortunately, wxWidgets is written in C++. I was wondering if it would be possible to build a translator to port the C++ code to D. I don't even think you would have to port it to "D style". Instead use non-GC memory allocation, C-style declaration where possible, etc. But I guess that is not practical based on was was said in the thread titled "inner classes". :-( Jim
May 28 2005
parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d7bc31$1pj7$1 digitaldaemon.com>, Jim H says...
"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d77ots$20ms$1 digitaldaemon.com...
 I would suggest that either wxWindows or Gtk+ would make good backends for 
 a D UI wrapper.

Speaking of wxWidgets (wxWindows), as soon as I discovered D, I thought how great it would be to use D together with wxWidgets. Unfortunately, wxWidgets is written in C++.

I don't know how they did it, but there's a project called wxD that attempts to bridge wxWidgets and D: http://wxd.sourceforge.net/ This might also be interesting to you: http://www.prowiki.org/wiki4d/wiki.cgi?wxD jcc7
May 28 2005
parent "Jim H" <jhewesNOSPAM ix.netcom.com> writes:
"J C Calvarese" <technocrat7 gmail.com> wrote in message 
news:d7bcuq$1q63$1 digitaldaemon.com...
 In article <d7bc31$1pj7$1 digitaldaemon.com>, Jim H says...

 I don't know how they did it, but there's a project called wxD that 
 attempts to
 bridge wxWidgets and D: http://wxd.sourceforge.net/

 This might also be interesting to you:
 http://www.prowiki.org/wiki4d/wiki.cgi?wxD

 jcc7

I had seen that. But I'm not sure the status or whether it will be actively maintained. I assume it's not a full, manual port of the library since it says it is "wxWidgets bindings for D language". I'm not sure exactly what that involves. I wonder if it makes sense to talk about a common way to link different languages. Of course this was the point of COM on Windows, and it works. But it's pretty complicated. You need to read a book in order to really understand how to make a COM component. Then there is .NET which is a simpler way for different languages to link. But now you need to compile to bytecode and run on a virtual machine. Performance suffers. So is there any way it makes sense to have a way for different languages to link together, which is as simple to use as .NET, but also allows the speed of native compilation and no VM? Or does this not make sense? Jim
May 29 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"bobef" <bobef_member pathlink.com> wrote in message
news:d77n8d$1vir$1 digitaldaemon.com...
 I think the anwer is that D is a programming language not a library for
 windows... But it would be cool if windows was better supported... Current
win32
 headers are more like win16 or at most win95...

 In article <d77mve$1vav$1 digitaldaemon.com>, TechnoZeus says...
Does anyone know if there are any plans to eventually have native Windows
support in the D language?

By this I mean, not having to import modules from another language (such as C)
to write a Windows program.

There are several reasons why I ask, but before I get into any of them here,
I would just like to know if such a thing is planned at all.

TZ


Being a language doesn't preclude native support for anything, at any level. It's a matter of choice. I was just wondering if anyone knew of any plans for such support, mainly. As it stands now, I know of no way to write even the simplest Windows program without having to fall back on the use of some other "language" to do it. That's not to say that it cant't be done... just that I don't know of a way. I have been trying for some time now to write a simple file utinity for GenePool4 entirely in the D language, but I can't even figure out how to do something simple like open a file dialog to get a filename. TZ
May 27 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
As it stands now, I know of no way to write even the simplest Windows program
without
having to fall back on the use of some other "language" to do it.  That's not
to say that it cant't be done...
just that I don't know of a way.

Windows was written in C, so anything you do with native windows is going to have to interface with C code. Correct me if I am wrong...
I have been trying for some time now to write a simple file utinity for
GenePool4 entirely in the D language,
but I can't even figure out how to do something simple like open a file dialog
to get a filename.

Native controls like that require the use of the native C headers, like windows.h and winuser.h. Luckily we have people who made windows bindings in D. Check out Core32 on dsource.org Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com
May 27 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d77ute$24uf$1 digitaldaemon.com...
As it stands now, I know of no way to write even the simplest Windows program
without
having to fall back on the use of some other "language" to do it.  That's not
to say that it cant't be done...
just that I don't know of a way.

Windows was written in C, so anything you do with native windows is going to have to interface with C code. Correct me if I am wrong...
I have been trying for some time now to write a simple file utinity for
GenePool4 entirely in the D language,
but I can't even figure out how to do something simple like open a file dialog
to get a filename.

Native controls like that require the use of the native C headers, like windows.h and winuser.h. Luckily we have people who made windows bindings in D. Check out Core32 on dsource.org Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com

No, that's actually not correct, although the way the API documentation is written I can understand how it may lead people to such a conclusion. Over the years, many languages have been involved in the writing of Windows, and I'm not sure what it's primarily written in now, but I would guess C# is probably being used for most of the new stuff. (Anyone from Microsoft care to jump in here?) 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. TZ
May 28 2005
next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
TechnoZeus escribió:
 
 No, that's actually not correct, although the way the API documentation is
written I can
 understand how it may lead people to such a conclusion.
 
 Over the years, many languages have been involved in the writing of Windows,
 and I'm not sure what it's primarily written in now, but I would guess C# is
probably being
 used for most of the new stuff.  (Anyone from Microsoft care to jump in here?)
 

C# compiles to MSIL. Windows runs Win32 applications. MSIL applications are not Win32 applications. So C# is as native as Java, for example. I'm sorry, but I disagree with you here.
 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.
 
 TZ
 
 

-- Carlos Santander Bernal
May 28 2005
parent reply Carlos Santander <csantander619 gmail.com> writes:
Carlos Santander escribió:
 TechnoZeus escribió:
 
 No, that's actually not correct, although the way the API 
 documentation is written I can
 understand how it may lead people to such a conclusion.

 Over the years, many languages have been involved in the writing of 
 Windows,
 and I'm not sure what it's primarily written in now, but I would guess 
 C# is probably being
 used for most of the new stuff.  (Anyone from Microsoft care to jump 
 in here?)

C# compiles to MSIL. Windows runs Win32 applications. MSIL applications are not Win32 applications. So C# is as native as Java, for example. I'm sorry, but I disagree with you here.

Small correction: Java doesn't use native controls but MSIL does. Still, they both run on a virtual machine, and that makes them not native.
 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.

 TZ


-- Carlos Santander Bernal
May 28 2005
next sibling parent =?ISO-8859-1?Q?Thomas_K=FChne?= <thomas-dloop kuehne.THISISSPAM.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carlos Santander wrote:

| Carlos Santander escribió:
|
|> TechnoZeus escribió:
|>
|>>
|>> No, that's actually not correct, although the way the API
|>> documentation is written I can understand how it may lead people
|>> to such a conclusion.
|>>
|>> Over the years, many languages have been involved in the writing
|>> of Windows, and I'm not sure what it's primarily written in now,
|>> but I would guess C# is probably being used for most of the new
|>> stuff.  (Anyone from Microsoft care to jump in here?)
|>>
|>
|> C# compiles to MSIL. Windows runs Win32 applications. MSIL
|> applications are not Win32 applications. So C# is as native as
|> Java, for example. I'm sorry, but I disagree with you here.
|>
|
| Small correction: Java doesn't use native controls but MSIL does.
| Still, they both run on a virtual machine, and that makes them not
| native.

That is a strict definition of "native".

Lax definition form a user's point of view:
The UI element is native, if all accessibility tools, input methods,
dictionary-lookup tools etc. are working properly.

Thomas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFCmNsd3w+/yD4P9tIRAsVAAKCNcpQG7zE87k6SaREszBgL175j/QCeO+bm
ur5IZRYpNzeslQnA78/oFs4=
=ay2x
-----END PGP SIGNATURE-----
May 28 2005
prev sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:d7a2qb$tc7$1 digitaldaemon.com...
 Carlos Santander escribió:
 TechnoZeus escribió:

 No, that's actually not correct, although the way the API
 documentation is written I can
 understand how it may lead people to such a conclusion.

 Over the years, many languages have been involved in the writing of
 Windows,
 and I'm not sure what it's primarily written in now, but I would guess
 C# is probably being
 used for most of the new stuff.  (Anyone from Microsoft care to jump
 in here?)

C# compiles to MSIL. Windows runs Win32 applications. MSIL applications are not Win32 applications. So C# is as native as Java, for example. I'm sorry, but I disagree with you here.

Small correction: Java doesn't use native controls but MSIL does. Still, they both run on a virtual machine, and that makes them not native.
 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.

 TZ


-- Carlos Santander Bernal

Perhaps this has changed since I last looked at it, but durring the early C# betas, as I understood it, the plan was to make MSIL the primary compilation target platform for the C# language (and other .net languages), but not the "only" one. One way or the other though, support for windows is native to C#, regardless of whether that support is filtered through a virtual machine, emulated, run on an MSIL compatible microprocessor, interpreted, or whatever. The C# "language" supports Windows program development. I would like to see the D language do so also... or at least natively support development of GUI based applications, even if only in a generic sense. In fact, I would actually preffer it to be somewhat generic, because it is easier that way to write cross-platform GUI based applications and then compile them for each target platform. TZ
May 30 2005
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
TechnoZeus wrote:
 
 One way or the other though, support for windows is native to C#,
 regardless of whether that support is filtered through a virtual machine,
 emulated, run on an MSIL compatible microprocessor,
 interpreted, or whatever.

No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
 
 The C# "language" supports Windows program development.

Yes, through it's libraries.
 I would like to see the D language do so also... or at least natively
 support development of GUI based applications, even if only in a generic
 sense. In fact, I would actually preffer it to be somewhat generic,
 because it is easier that way to write cross-platform GUI based
 applications and then compile them for each target platform.

All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos. Lars Ivar Igesund
May 30 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d7ej4s$1h0m$1 digitaldaemon.com...
 TechnoZeus wrote:

 One way or the other though, support for windows is native to C#,
 regardless of whether that support is filtered through a virtual machine,
 emulated, run on an MSIL compatible microprocessor,
 interpreted, or whatever.

No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
 The C# "language" supports Windows program development.

Yes, through it's libraries.
 I would like to see the D language do so also... or at least natively
 support development of GUI based applications, even if only in a generic
 sense. In fact, I would actually preffer it to be somewhat generic,
 because it is easier that way to write cross-platform GUI based
 applications and then compile them for each target platform.

All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos. Lars Ivar Igesund

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. The same goes for Visual Basic, for that matter, and if I'm not mistaken, also for Delphi. I'm sure more could be added to that list, but my point is... I would like D to be in the list. TZ
May 30 2005
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
TechnoZeus wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:d7ej4s$1h0m$1 digitaldaemon.com...
 TechnoZeus wrote:

 One way or the other though, support for windows is native to C#,
 regardless of whether that support is filtered through a virtual
 machine, emulated, run on an MSIL compatible microprocessor,
 interpreted, or whatever.

No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
 The C# "language" supports Windows program development.

Yes, through it's libraries.
 I would like to see the D language do so also... or at least natively
 support development of GUI based applications, even if only in a
 generic sense. In fact, I would actually preffer it to be somewhat
 generic, because it is easier that way to write cross-platform GUI
 based applications and then compile them for each target platform.

All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos. Lars Ivar Igesund

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
May 30 2005
next sibling parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d7eldn$1iuj$1 digitaldaemon.com...
 TechnoZeus wrote:

 "Lars Ivar Igesund" <larsivar igesund.net> wrote in message
 news:d7ej4s$1h0m$1 digitaldaemon.com...
 TechnoZeus wrote:

 One way or the other though, support for windows is native to C#,
 regardless of whether that support is filtered through a virtual
 machine, emulated, run on an MSIL compatible microprocessor,
 interpreted, or whatever.

No, support for windows is provided through the Forms-library and siblings. This library has a C#-interface, just as it could have a D interface. Recent criticisms of the Forms-library says that it mostly is wrapper around the C functions of Windows, which are mostly available for D through import-files and wrappers.
 The C# "language" supports Windows program development.

Yes, through it's libraries.
 I would like to see the D language do so also... or at least natively
 support development of GUI based applications, even if only in a
 generic sense. In fact, I would actually preffer it to be somewhat
 generic, because it is easier that way to write cross-platform GUI
 based applications and then compile them for each target platform.

All this boils down to the discussion about having a standard-GUI-library in Phobos, or not. IMO, not, just because a GUI-library will be many times larger than the rest of phobos. Lars Ivar Igesund

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

It has everything to do with the language if it's in the language specification. The C language doesn't include support for GUI based applications, so in C it has nothing to do with the language and everything to do with workarounds and extensions... but that's "the C way". TZ
May 30 2005
parent reply Carlos Santander <Carlos_member pathlink.com> writes:
In article <d7em2q$1kc9$1 digitaldaemon.com>, TechnoZeus says...
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d7eldn$1iuj$1 digitaldaemon.com...
 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

It has everything to do with the language if it's in the language specification. The C language doesn't include support for GUI based applications, so in C it has nothing to do with the language and everything to do with workarounds and extensions... but that's "the C way". TZ

I don't think it's true: the C# specification doesn't mention Forms: http://www.jaggersoft.com/csharp_standard/toc.htm. Also see http://en.wikipedia.org/wiki/C_Sharp_programming_language and notice how in "Language features" there's no mention of Forms. -- Carlos Santander Bernal
May 30 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Carlos Santander" <Carlos_member pathlink.com> wrote in message
news:d7f6v1$26hg$1 digitaldaemon.com...
 In article <d7em2q$1kc9$1 digitaldaemon.com>, TechnoZeus says...
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d7eldn$1iuj$1 digitaldaemon.com...
 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

It has everything to do with the language if it's in the language specification. The C language doesn't include support for GUI based applications, so in C it has nothing to do with the language and everything to do with workarounds and extensions... but that's "the C way". TZ

I don't think it's true: the C# specification doesn't mention Forms: http://www.jaggersoft.com/csharp_standard/toc.htm. Also see http://en.wikipedia.org/wiki/C_Sharp_programming_language and notice how in "Language features" there's no mention of Forms. -- Carlos Santander Bernal

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. 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. 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
next sibling parent reply "John C" <johnch_atms hotmail.com> writes:
 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
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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.

 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
prev sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
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 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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.

 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
prev sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
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
May 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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
prev sibling next sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d79cpe$dil$1 digitaldaemon.com>, TechnoZeus says...

No, that's actually not correct, although the way the API documentation is
written I can
understand how it may lead people to such a conclusion.

Over the years, many languages have been involved in the writing of Windows,
and I'm not sure what it's primarily written in now, but I would guess C# is
probably being
used for most of the new stuff.  (Anyone from Microsoft care to jump in here?)

I'm sure C and C++ have been used to write Windows. If C# has been used (and I'm not sure that it has), it's only been very recently. What else has been used? Do HTML, CSS, and RTF count? It doesn't seem likely that Microsoft used Java. Perhaps they used a little VB. I'm sure they used some assembler, but it was probably inline in a C program.
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.

What do you want added to D (or changed about D) to achieve this goal? What are you proposing? I think D is already well-suited to be considered "a full featured programming language". The only thing holding back D is the absence of Visual D as part of Microsoft's Visual Studio (don't hold your breath). jcc7
May 28 2005
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
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
May 28 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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, but for your wonderful explanation of what I have been "trying to say" here. That is exactly what I'm talking about... except to hopefully become an integral part of the D language, rather than an optional add-on. Sure, you can "compute" without GUI controls, but that's obviously not the full extent of what programs are expected (by most people) to do these days. I would just like to see the Dlanguage specification have built in support for the "concept" of GUI based appications, with the idea being that a D compiler for a specific platform would be able to compile a simple working GUI based application in a single step, without the need for anything other than... the operating system and computer to run the compiler on, a D source file written by the application developer, and the files that came in the compiler's installation package. TZ
May 30 2005
parent reply J C Calvarese<technocrat7 gmail.com> writes:
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
May 30 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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
parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
"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
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message
news:d7fuvj$2uo2$1 digitaldaemon.com...

 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)

 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
May 31 2005
prev sibling parent reply "John C" <johnch_atms hotmail.com> writes:
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d79cpe$dil$1 digitaldaemon.com...
 "Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
 news:d77ute$24uf$1 digitaldaemon.com...
As it stands now, I know of no way to write even the simplest Windows 
program without
having to fall back on the use of some other "language" to do it. 
That's not to say that it cant't be done...
just that I don't know of a way.

Windows was written in C, so anything you do with native windows is going to have to interface with C code. Correct me if I am wrong...
I have been trying for some time now to write a simple file utinity for 
GenePool4 entirely in the D language,
but I can't even figure out how to do something simple like open a file 
dialog to get a filename.

Native controls like that require the use of the native C headers, like windows.h and winuser.h. Luckily we have people who made windows bindings in D. Check out Core32 on dsource.org Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com

No, that's actually not correct, although the way the API documentation is written I can understand how it may lead people to such a conclusion. Over the years, many languages have been involved in the writing of Windows, and I'm not sure what it's primarily written in now, but I would guess C# is probably being used for most of the new stuff. (Anyone from Microsoft care to jump in here?)

Surely it doesn't matter what language Windows is written in, only what language the public API is. And that's C. Even those parts of Windows not written in C (COM/ActiveX, GDI+) have a C API. Microsoft's Raymond Chen blogs frequently about the internals of Windows http://blogs.msdn.com/oldnewthing/ C# is only relevant when programming for the Common Language Runtime (CLR). None of the Win32 API accesses CLR bits. Microsoft's forthcoming Avalon and Indigo are only relevant in a CLR environment. Perhaps this is what you meant by "the new stuff". The next version of Windows, for example, will not be primarily written in C# (or any other CLR-targeting language).
 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.

Any language that needs to access operating system functionality has to interface with a public API. For Windows, that's generally C, as I've said above. It makes no difference if that language is C++, D, Delphi, Visual Basic or Eiffel. You're going to need to call down to C.
 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.

 TZ

 

May 29 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:d7ckge$2m20$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
 news:d79cpe$dil$1 digitaldaemon.com...
 "Trevor Parscal" <Trevor_member pathlink.com> wrote in message
 news:d77ute$24uf$1 digitaldaemon.com...
As it stands now, I know of no way to write even the simplest Windows
program without
having to fall back on the use of some other "language" to do it.
That's not to say that it cant't be done...
just that I don't know of a way.

Windows was written in C, so anything you do with native windows is going to have to interface with C code. Correct me if I am wrong...
I have been trying for some time now to write a simple file utinity for
GenePool4 entirely in the D language,
but I can't even figure out how to do something simple like open a file
dialog to get a filename.

Native controls like that require the use of the native C headers, like windows.h and winuser.h. Luckily we have people who made windows bindings in D. Check out Core32 on dsource.org Thanks, Trevor Parscal www.trevorparscal.com trevorparscal hotmail.com

No, that's actually not correct, although the way the API documentation is written I can understand how it may lead people to such a conclusion. Over the years, many languages have been involved in the writing of Windows, and I'm not sure what it's primarily written in now, but I would guess C# is probably being used for most of the new stuff. (Anyone from Microsoft care to jump in here?)

Surely it doesn't matter what language Windows is written in, only what language the public API is. And that's C. Even those parts of Windows not written in C (COM/ActiveX, GDI+) have a C API. Microsoft's Raymond Chen blogs frequently about the internals of Windows http://blogs.msdn.com/oldnewthing/ C# is only relevant when programming for the Common Language Runtime (CLR). None of the Win32 API accesses CLR bits. Microsoft's forthcoming Avalon and Indigo are only relevant in a CLR environment. Perhaps this is what you meant by "the new stuff". The next version of Windows, for example, will not be primarily written in C# (or any other CLR-targeting language).
 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.

Any language that needs to access operating system functionality has to interface with a public API. For Windows, that's generally C, as I've said above. It makes no difference if that language is C++, D, Delphi, Visual Basic or Eiffel. You're going to need to call down to C.
 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.

 TZ


True, a compiled Windows application needs to communicate with the Windows API, but that does not mean the application's source code needs to be written any differently for Windows than for any other GUI to get basic GUI functionality, and it definately doesn't mean that the application developer should have to specify in the source code or in any compiler command that any C files or header files or library files or DLLs have to be used to make the application work. That's what I mean by "native support" is to be able to simply write for the targer platform and compile... and get a working application. Not an assortment of error messages due to a failure to import or link-in some foreign item. TZ
May 30 2005
parent reply "John C" <johnch_atms hotmail.com> writes:
 True, a compiled Windows application needs to communicate with the Windows 
 API,
 but that does not mean the application's source code needs to be written 
 any differently
 for Windows than for any other GUI to get basic GUI functionality, and it 
 definately doesn't mean
 that the application developer should have to specify in the source code 
 or in any compiler command
 that any C files or header files or library files or DLLs have to be used 
 to make the application work.

 That's what I mean by "native support" is to be able to simply write for 
 the targer platform and compile...
 and get a working application.  Not an assortment of error messages due to 
 a
 failure to import or link-in some foreign item.

I think I understand now. D does this to remain compatible with C, which is one of the language's main aims. Some other languages don't link directly with OS APIs, they accomplish such calls at runtime at a cost to performance. In the case of C#, it's called "platform invoke" which is nowhere near as efficient (and you still need to specifiy which DLL you're importing a function from). It has its own problems, too: it's blown up in my face many times.
 TZ 

May 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"John C" <johnch_atms hotmail.com> wrote in message
news:d7emor$1l3a$1 digitaldaemon.com...
 True, a compiled Windows application needs to communicate with the Windows
 API,
 but that does not mean the application's source code needs to be written
 any differently
 for Windows than for any other GUI to get basic GUI functionality, and it
 definately doesn't mean
 that the application developer should have to specify in the source code
 or in any compiler command
 that any C files or header files or library files or DLLs have to be used
 to make the application work.

 That's what I mean by "native support" is to be able to simply write for
 the targer platform and compile...
 and get a working application.  Not an assortment of error messages due to
 a
 failure to import or link-in some foreign item.

I think I understand now. D does this to remain compatible with C, which is one of the language's main aims. Some other languages don't link directly with OS APIs, they accomplish such calls at runtime at a cost to performance. In the case of C#, it's called "platform invoke" which is nowhere near as efficient (and you still need to specifiy which DLL you're importing a function from). It has its own problems, too: it's blown up in my face many times.
 TZ


Well, perhaps I'm asking too much... but I hope not. All I really am asking for is what I consider basic functionality. Okay, so different people consider different functionality to be basic. There was a time when floating point operations "always" required special routines. Such times are, fortunately, behind us now. I see the ability to open a common dialog box to browse for a file as basic functionality in today's world. I also see the ability to specify items on a menu and have their activation trigger an event as basic functionality in today's world. I see detecting a mouse click to be as basic as detecting a keystroke, in today's world. Customized controls, I don't yet see as basic functionality... but I do see them as things that should be easy to assemble from basic GUI or SGML functionality. TZ
May 30 2005
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Fri, 27 May 2005 12:51:53 -0500, TechnoZeus wrote:

 Does anyone know if there are any plans to eventually have native Windows
support in the D language?

Yes. I have plans to port my Windows development library to D. It only supports the Windows 32 API and is not cross platform. And it provides high level interface to the API while still allowing direct API calls in your application. -- Derek Parnell Melbourne, Australia 28/05/2005 8:04:13 AM
May 27 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message
news:zk6rrzdisf4x.bi4cd4ec35md.dlg 40tude.net...
 On Fri, 27 May 2005 12:51:53 -0500, TechnoZeus wrote:

 Does anyone know if there are any plans to eventually have native Windows
support in the D language?

Yes. I have plans to port my Windows development library to D. It only supports the Windows 32 API and is not cross platform. And it provides high level interface to the API while still allowing direct API calls in your application. -- Derek Parnell Melbourne, Australia 28/05/2005 8:04:13 AM

Looking for any help with testing? Can't spare a lot of time, but if it's going to be in pure D... I would be willing to try it and give some feedback. TZ
May 28 2005
prev sibling next sibling parent reply "Shawn Liu" <liuxuhong.cn gmail.com> writes:
I think there may be misunderstandings of "native" and "look-n-feel". 
Actually, they are not in the same category.

On windows platform, "native" means there is a HWND underground the widget 
or control. It is created by "CreateWindow" or "CreateWindowEx" and it has a 
"Windowproc" callback function to guide its behaviors.

In contrast to "native", the way is "emulation". There is a top-level native 
window as container, and any other or partial widgets are emulated by 
"drawing".

The extreme instance of "emulation" is java SWING. Except the top-level 
window, everything is emulated. Andrew Fedoniouk's "Harmonia", obviously, is 
emulated too.
http://www.terrainformatica.com/wiki/pmwiki.php?pagename=Harmonia.Harmonia
The SWT, "Standard Widget Toolkit", a sub-project of Eclipse, although 
written in java, is native.
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/main.html


Let's talk about "look-n-feel". "look-n-feel" is just the appearance and 
behaviors of an application. appearance" involves in border, color and etc. 
"behaviors" involves cursor in, cursor out and etc.

SWING can emulates several "look-n-feel"s included Metal, Windows, and etc. 
JGoodies has a even more vivid implementation.
http://www.jgoodies.com/freeware/skeleton-pro/images/skeleton-pro.png
But, it is non-native.

Native implementation is not fully equal to "native controls" or "native 
widgets". SWT uses any widgets as possible. If a widget does not exist in 
some platform, SWT emulates it. But in a native way of this emulation. (By 
"CreateWindow" but not by "drawing" like SWING).

Another example,the Fox-Toolkit, a cross-platform toolkit.
http://www.fox-toolkit.org/
All widgets are emulated in a native way, include button, combo, tree, 
notebook, grid, openfile dialog and etc. None of the controls in 
"commctl32.dll" is used. This make it's "look-n-feel"s are identical in any 
platforms. Though FOX's look-n-feel is more like win95 style. It is native!

The simplest way to check whether an application is native or not, is to use 
Microsoft SPY tool. A native widget must have a HWND, and SPY can find its 
class name, rectangle and style. Only the top-level container can be found 
by SPY in an emulated-by-drawing application.

Some application can not work with the emulation-by-drawing program. For 
example, and on screen dictionary application. When mouse cursor moves on a 
native window, it catches the DrawText() call by system hooks and translates 
the text. But it can't work with "emulation-by-drawing" app since there is 
not a HWND to catch.



- Shawn Liu 
May 28 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Shawn Liu" <liuxuhong.cn gmail.com> wrote in message
news:d797jn$6tb$1 digitaldaemon.com...
 I think there may be misunderstandings of "native" and "look-n-feel".
 Actually, they are not in the same category.

 On windows platform, "native" means there is a HWND underground the widget
 or control. It is created by "CreateWindow" or "CreateWindowEx" and it has a
 "Windowproc" callback function to guide its behaviors.

 In contrast to "native", the way is "emulation". There is a top-level native
 window as container, and any other or partial widgets are emulated by
 "drawing".

 The extreme instance of "emulation" is java SWING. Except the top-level
 window, everything is emulated. Andrew Fedoniouk's "Harmonia", obviously, is
 emulated too.
 http://www.terrainformatica.com/wiki/pmwiki.php?pagename=Harmonia.Harmonia
 The SWT, "Standard Widget Toolkit", a sub-project of Eclipse, although
 written in java, is native.
 http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-swt-home/main.html


 Let's talk about "look-n-feel". "look-n-feel" is just the appearance and
 behaviors of an application. appearance" involves in border, color and etc.
 "behaviors" involves cursor in, cursor out and etc.

 SWING can emulates several "look-n-feel"s included Metal, Windows, and etc.
 JGoodies has a even more vivid implementation.
 http://www.jgoodies.com/freeware/skeleton-pro/images/skeleton-pro.png
 But, it is non-native.

 Native implementation is not fully equal to "native controls" or "native
 widgets". SWT uses any widgets as possible. If a widget does not exist in
 some platform, SWT emulates it. But in a native way of this emulation. (By
 "CreateWindow" but not by "drawing" like SWING).

 Another example,the Fox-Toolkit, a cross-platform toolkit.
 http://www.fox-toolkit.org/
 All widgets are emulated in a native way, include button, combo, tree,
 notebook, grid, openfile dialog and etc. None of the controls in
 "commctl32.dll" is used. This make it's "look-n-feel"s are identical in any
 platforms. Though FOX's look-n-feel is more like win95 style. It is native!

 The simplest way to check whether an application is native or not, is to use
 Microsoft SPY tool. A native widget must have a HWND, and SPY can find its
 class name, rectangle and style. Only the top-level container can be found
 by SPY in an emulated-by-drawing application.

 Some application can not work with the emulation-by-drawing program. For
 example, and on screen dictionary application. When mouse cursor moves on a
 native window, it catches the DrawText() call by system hooks and translates
 the text. But it can't work with "emulation-by-drawing" app since there is
 not a HWND to catch.


 - Shawn Liu

Sorry, I should have stated my question more clearly. I had meant support that was native to the D language. Whether or not that support ties into Windows in a way that is native to Windows isn't something that I'm concerned about at this time, as long as it's functional and allows programming in native D source code without the need to link to libraries or DLLs which were written in some other language and which are not a part of the operating system. Years back, I suggested to Microsoft that they make certain parts of such programs as Internet Explorer and Word a part of the operating system, both to allow those programs to have a smaller footprint within the system, and to allow many of their features and much of their functionality to be easily integrated into other applications. They listened... and as a result, much of that functionality is now a part of Windows and can be accessed through API calls without having to first separately install one of those programs. I don't care where that functionality came from, or for that matter how it's integrated into the system, so much as that it's there and I would like to see D support it natively... to at least a reasonable extent. For example, if a person writes a line of D code to display a piece of text, it should do so... and if a person writes a line of D code to allow a choice to be made by the user from a list of possibilities, that should work also. Eliminating the console window in a Windows application should not disable such functionality... At worst, it should simply divert it. At best, it should be possible to treat text based environments as if they have GUI support, and let the GUI elements be emulated in text much the same as the Microsoft Narrator in Windows XP (or other similar OS level text-to-speech programs) emulates them in speech. Then a window, menu, or common dialog box wouldn't have to be treated as if it's a foreign element that needs a translator from another language. TZ
May 28 2005
next sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
TechnoZeus escribió:
 
 Sorry, I should have stated my question more clearly.
 I had meant support that was native to the D language.
 Whether or not that support ties into Windows in a way that is
 native to Windows isn't something that I'm concerned about at
 this time, as long as it's functional and allows programming in
 native D source code without the need to link to libraries or DLLs
 which were written in some other language and which are not
 a part of the operating system.
 
 Years back, I suggested to Microsoft that they make certain parts of
 such programs as Internet Explorer and Word a part of the operating system,
 both to allow those programs to have a smaller footprint within the system, and
 to allow many of their features and much of their functionality to be easily
integrated
 into other applications.  They listened... and as a result, much of that
functionality is now
 a part of Windows and can be accessed through API calls without having to
first separately
 install one of those programs.  I don't care where that functionality came
from, or for that matter
 how it's integrated into the system, so much as that it's there and I would
like to see D support it natively...
 to at least a reasonable extent.
 
 For example, if a person writes a line of D code to display a piece of text,
it should do so...
 and if a person writes a line of D code to allow a choice to be made by the
user from a list of possibilities, that should work also.
 Eliminating the console window in a Windows application should not disable
such functionality... At worst, it should simply divert it.
 At best, it should be possible to treat text based environments as if they
have GUI support, and let the GUI elements be emulated in text
 much the same as the Microsoft Narrator in Windows XP (or other similar OS
level text-to-speech programs) emulates them in speech.
 Then a window, menu, or common dialog box wouldn't have to be treated as if
it's a foreign element that needs a translator from another language.
 
 TZ
 
 

That's the point: Windows has those things in its core: kernel32.dll, user32.dll, gdi32.dll, etc. So we use them. For that, we need two things: an import library (created with implib) which has no code, only stubs, and a header (a complete set of headers is the core32 library in dsource, another is Y. Tomino's. The link can be found in the wiki). The headers are needed so the compiler won't complain, and the library are there so the linker won't complain. If you want to use Narrator or any other thing, just find the corresponding dll, create an import library, create the headers, and use it. It's the way things are done. -- Carlos Santander Bernal
May 28 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Carlos Santander" <csantander619 gmail.com> wrote in message
news:d79t3v$pbv$4 digitaldaemon.com...
 TechnoZeus escribió:
 Sorry, I should have stated my question more clearly.
 I had meant support that was native to the D language.
 Whether or not that support ties into Windows in a way that is
 native to Windows isn't something that I'm concerned about at
 this time, as long as it's functional and allows programming in
 native D source code without the need to link to libraries or DLLs
 which were written in some other language and which are not
 a part of the operating system.

 Years back, I suggested to Microsoft that they make certain parts of
 such programs as Internet Explorer and Word a part of the operating system,
 both to allow those programs to have a smaller footprint within the system, and
 to allow many of their features and much of their functionality to be easily
integrated
 into other applications.  They listened... and as a result, much of that
functionality is now
 a part of Windows and can be accessed through API calls without having to
first separately
 install one of those programs.  I don't care where that functionality came
from, or for that matter
 how it's integrated into the system, so much as that it's there and I would
like to see D support it natively...
 to at least a reasonable extent.

 For example, if a person writes a line of D code to display a piece of text,
it should do so...
 and if a person writes a line of D code to allow a choice to be made by the
user from a list of possibilities, that should work also.
 Eliminating the console window in a Windows application should not disable
such functionality... At worst, it should simply divert it.
 At best, it should be possible to treat text based environments as if they
have GUI support, and let the GUI elements be emulated in text
 much the same as the Microsoft Narrator in Windows XP (or other similar OS
level text-to-speech programs) emulates them in speech.
 Then a window, menu, or common dialog box wouldn't have to be treated as if
it's a foreign element that needs a translator from another language.

 TZ

That's the point: Windows has those things in its core: kernel32.dll, user32.dll, gdi32.dll, etc. So we use them. For that, we need two things: an import library (created with implib) which has no code, only stubs, and a header (a complete set of headers is the core32 library in dsource, another is Y. Tomino's. The link can be found in the wiki). The headers are needed so the compiler won't complain, and the library are there so the linker won't complain. If you want to use Narrator or any other thing, just find the corresponding dll, create an import library, create the headers, and use it. It's the way things are done. -- Carlos Santander Bernal

You not only missed my point completely, but also stated a point of view as if it were a fact. No, just because things are done a certain way in C does not mean that there is no other way. I'm sure I've mentioned it here before... I don't even like C. It's something that I put up with when I have no choice. TZ
May 30 2005
prev sibling parent reply J C Calvarese<technocrat7 gmail.com> writes:
In article <d79lf7$jvk$1 digitaldaemon.com>, TechnoZeus says...

Years back, I suggested to Microsoft that they make certain parts of
such programs as Internet Explorer and Word a part of the operating system,
both to allow those programs to have a smaller footprint within the system, and
to allow many of their features and much of their functionality to be easily
integrated
into other applications.  They listened... and as a result, much of that
functionality is now
a part of Windows and can be accessed through API calls without having to first
separately
install one of those programs.  I don't care where that functionality came
from, or for that matter
how it's integrated into the system, so much as that it's there and I would
like to see D support it natively...
to at least a reasonable extent.

I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input. As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions. If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.) jcc7
May 28 2005
parent reply "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"J C Calvarese" <technocrat7 gmail.com> wrote in message
news:d7a4o1$uuc$1 digitaldaemon.com...
 In article <d79lf7$jvk$1 digitaldaemon.com>, TechnoZeus says...

Years back, I suggested to Microsoft that they make certain parts of
such programs as Internet Explorer and Word a part of the operating system,
both to allow those programs to have a smaller footprint within the system, and
to allow many of their features and much of their functionality to be easily
integrated
into other applications.  They listened... and as a result, much of that
functionality is now
a part of Windows and can be accessed through API calls without having to first
separately
install one of those programs.  I don't care where that functionality came
from, or for that matter
how it's integrated into the system, so much as that it's there and I would
like to see D support it natively...
to at least a reasonable extent.

I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input. As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions. If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.) jcc7

Actually, when I recommended it, I also specifically stated that all such components should be documented so that anyone could use them. I unfortunately, am not (nor was I at that time) a Microsoft employee... so making suggestions was the best I could do. Much like I am now making suggestions for the D language, but am powerless to have any more direct effect on how the D language turns out. I'm not suggesting that we do away with all the libraries. What I am suggesting is that basic GUI functionality should be supported by the language itself so that the application developer has no need to specify any library to do simple things like create a window and put some simple working controls on it, or open a common dialog box. TZ
May 30 2005
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
TechnoZeus wrote:

 "J C Calvarese" <technocrat7 gmail.com> wrote in message
 news:d7a4o1$uuc$1 digitaldaemon.com...
 In article <d79lf7$jvk$1 digitaldaemon.com>, TechnoZeus says...

Years back, I suggested to Microsoft that they make certain parts of
such programs as Internet Explorer and Word a part of the operating
system, both to allow those programs to have a smaller footprint within
the system, and to allow many of their features and much of their
functionality to be easily integrated
into other applications.  They listened... and as a result, much of that
functionality is now a part of Windows and can be accessed through API
calls without having to first separately
install one of those programs.  I don't care where that functionality
came from, or for that matter how it's integrated into the system, so
much as that it's there and I would like to see D support it natively...
to at least a reasonable extent.

I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input. As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions. If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.) jcc7

Actually, when I recommended it, I also specifically stated that all such components should be documented so that anyone could use them. I unfortunately, am not (nor was I at that time) a Microsoft employee... so making suggestions was the best I could do. Much like I am now making suggestions for the D language, but am powerless to have any more direct effect on how the D language turns out. I'm not suggesting that we do away with all the libraries. What I am suggesting is that basic GUI functionality should be supported by the language itself so that the application developer has no need to specify any library to do simple things like create a window and put some simple working controls on it, or open a common dialog box. TZ

You are more arguing for a larger phobos where a GUI-toolkit is included. Thus you still have it in a library, but it is easier (effortless, really) to link in. Lars Ivar Igesund
May 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d7elke$1iuj$2 digitaldaemon.com...
 TechnoZeus wrote:

 "J C Calvarese" <technocrat7 gmail.com> wrote in message
 news:d7a4o1$uuc$1 digitaldaemon.com...
 In article <d79lf7$jvk$1 digitaldaemon.com>, TechnoZeus says...

Years back, I suggested to Microsoft that they make certain parts of
such programs as Internet Explorer and Word a part of the operating
system, both to allow those programs to have a smaller footprint within
the system, and to allow many of their features and much of their
functionality to be easily integrated
into other applications.  They listened... and as a result, much of that
functionality is now a part of Windows and can be accessed through API
calls without having to first separately
install one of those programs.  I don't care where that functionality
came from, or for that matter how it's integrated into the system, so
much as that it's there and I would like to see D support it natively...
to at least a reasonable extent.

I think general consensus among the programmer community (with some agreement from the court system) was that Microsoft added parts of IE and Office to the operating system to stymie their competitors (such as Netscape, WordPerfect, and Lotus). Since you recommended this practice, I'm sure they appreciated your input. As far as I know, the only thing prevent us from using these API functions is the same thing that thwarted Netscape et al.: some of them are undocumented by Microsoft. Other than that the only roadblock would be to port the part of a C header file that contains the required definitions. If you haven't actually tried one of D's GUI libraries, I'd recommend that you do so. There's a full list here: http://www.prowiki.org/wiki4d/wiki.cgi?AvailableGuiLibraries I'd suggest you start with either DFL or MinWin since both projects work on Windows. (And they both have a dsource forum that allows for convenient conversations with the author.) jcc7

Actually, when I recommended it, I also specifically stated that all such components should be documented so that anyone could use them. I unfortunately, am not (nor was I at that time) a Microsoft employee... so making suggestions was the best I could do. Much like I am now making suggestions for the D language, but am powerless to have any more direct effect on how the D language turns out. I'm not suggesting that we do away with all the libraries. What I am suggesting is that basic GUI functionality should be supported by the language itself so that the application developer has no need to specify any library to do simple things like create a window and put some simple working controls on it, or open a common dialog box. TZ

You are more arguing for a larger phobos where a GUI-toolkit is included. Thus you still have it in a library, but it is easier (effortless, really) to link in. Lars Ivar Igesund

No, I would be quite happy with that, but that is not what I'm suggesting. TZ
May 30 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
1) Harmonia supports transparency of child components
    (up to alpha blending). E.g. Windows does not.

2) Harmonia uses "modern" and flexible event propagation
    schema reducing event handling code in times for your
    application. This also allows you to build more modular
    and reusable components and code.

3) Harmonia uses HTML as a layout manager (and GUI resource
    definitions).  No one GUI OS provides you 'natively' such
    facilities so far.

4) It is possible to reproduce look-n-feel of any current GUI OS.
    You just need to create SystemTheme module which is using
    OS Widget drawing primitives (e.g. on XP it is uxthemes.dll calls).

5) It is *always* possible to reproduce exactly the same behavior
    of native OS widgets. In fact basic OS widgets like editbox,
    combobox, etc. are not a "rocket science" at all.

6) In principle: nothing stops you to use native OS widgets. E.g.
    you may host child IE window on Harmonia window. Yes,
    this is not a crossplatform solution but life is life.
    Native package is there and it is open. (E.g. in Java/SWING it
    is closed)

7) In Harmonia you can write application which will look like
    and behave *exactly* in the same way on any supported platform.
    At the same time you can create application which will
    look and behave natively on any target platform - D by
    itself provides various static and dynamic facilities for that.
    E.g. on Mac OSX menu is not a part of the window
    ( but if your task demands you can use in-window menu
      even there using Harmonia )

8) By its design Harmonia is agnostic to OS and is a good
    investment. E.g. if you have application which is now running
   successfuly on Win32 then it will run on Avalon in 2006
   with redesign of only thin layer talking with OS.

9) Harmonia/D applications are native by definition. They
    are compiled into native code and can use *all* facilities
    of underlying OS.

And please remember that:

1)  It is almost impossible
to write GUI code which will be 100% the same
on different platforms.  No one toolkit guaranties
this. Question is just about how big portion of it
you can reuse in different versions of your
application.

2) I think that Harmonia way is a harmonized
balance between isolation of platform specifics
and effectivenes of UI. This is the goal
that SWING and WinForms failed to reach, IMHO.

And finally:

Harmonia as a good woman follows the modern
fashion/vogue principle.
"Hide everything which must be hidden but make
this in the way I can see it" ((c) mine).

:)
May 28 2005
next sibling parent reply Trevor Parscal <Trevor_member pathlink.com> writes:
I thought you weren't willing to five harmonia up to being in the standard D
library?

Weren't we trying to come up with soemthing for that?

However, harmonia sounds awesome and I am really enthousaiastic about it's
development, as it will provide D programers with a solid option.

I don't know, maybe D should NEVER have a GUI toolkit that is more assocated
with the core language than any other. Maybe doing so would be disasterous, just
as Glut became a dinosour as soon as OpenGL leveled off. Now with OpenGL
flourishing again Glut seems like a bad joke.

And yes, I have used Glut before, thats how I know. As well as Native Win32,
SDL, FLTK, GLFW, and Cpw. None of which satisfy me, so I am writing me own.

If you want  something done right you have to do it youself.. Usually.

Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal hotmail.com
May 28 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Trevor Parscal" <Trevor_member pathlink.com> wrote in message 
news:d7alnm$1ain$1 digitaldaemon.com...
I thought you weren't willing to five harmonia up to being in the standard 
D
 library?

 Weren't we trying to come up with soemthing for that?

D as a platform should support/have following: * Harmonia (as a type) - universal toolkit for those cases when you need what is described in my statement in previous message. * WinGUI - Windows GUI toolkit using native widgets. * MacGUI - Mac GUI toolkit using native widgets. * LinuxGUI - (GTK?) toolkit. Idealy all of them should share basic primitives e.g. something similar to harmonia.gx.* package and use similar vocabularies: Application, Window, Widget. In this case developers can share most of the code of custom widgets. Platform specific packages must be designed to be as close as possible to existing technologies of UI design on target platform to reduce learning curves, be able to produce as compact as possible applications, etc. For example on Windows (WinGUI) should be made as a thin layer similar to WTL. And no global and universal abstractions please - just pure wrappers around existing HWND set. On Linux - it just follows GTK as close as possible, etc.
 However, harmonia sounds awesome and I am really enthousaiastic about it's
 development, as it will provide D programers with a solid option.

Yes it is. And we are doing couple of projects were Harmonia approach is exactly what we need thus highly probable that we will not sing the song "Sic transit gloria mundi..." in the nearest future.
 I don't know, maybe D should NEVER have a GUI toolkit that is more 
 assocated
 with the core language than any other. Maybe doing so would be 
 disasterous, just
 as Glut became a dinosour as soon as OpenGL leveled off. Now with OpenGL
 flourishing again Glut seems like a bad joke.

I agree, language is language - not more not less. But something named as D platform should have some foundation. For GUI part see my four IMHOs above.
 And yes, I have used Glut before, thats how I know. As well as Native 
 Win32,
 SDL, FLTK, GLFW, and Cpw. None of which satisfy me, so I am writing me 
 own.

I am familiar with pretty much all from the list: http://www.geocities.com/SiliconValley/Vista/7184/guitool.html (know architecture, etc.)
 If you want  something done right you have to do it youself.. Usually.

Usually you just have no time for that. Sigh. Andrew.
May 28 2005
prev sibling parent reply pragma <pragma_member pathlink.com> writes:
Andrew,
I just checked out Harmonia today and so far it looks very interesting.  I'm
intrigued by the idea of using HTML for the make-work GUI building that seems to
plague other API's.   I have some questions, but I was unable to find your
proper email address any place.  If you want to reply offline that's okay by me,
but I figured that folks here might have similar questions.

I spent over an hour pouring over the code and I was stumped as how to bind data
to a control declared in HTML.  Ideally, I would expect to be able to ask the
Doc or HtmlView what Widget named 'x' was and then ask the returned Widget what
it's 'value' property was.  

Also, I sort of get what the event plumbing is trying to do, but I'm not sure
how to get any useful information from events.  How does one translate an event
to a Widget?  Where should I add my custom event handlers to the application
(extend Application, or View, or something else?)

- EricAnderton at yahoo
May 28 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"pragma" <pragma_member pathlink.com> wrote in message 
news:d7b4im$1k5m$1 digitaldaemon.com...
 Andrew,
 I just checked out Harmonia today and so far it looks very interesting. 
 I'm
 intrigued by the idea of using HTML for the make-work GUI building that 
 seems to
 plague other API's.   I have some questions, but I was unable to find your
 proper email address any place.  If you want to reply offline that's okay 
 by me,
 but I figured that folks here might have similar questions.

Eric, news terrainformatica.com is valid email address. You may write there. For the reasons we all know too well I am not publishing other addresses.
 I spent over an hour pouring over the code and I was stumped as how to 
 bind data
 to a control declared in HTML.  Ideally, I would expect to be able to ask 
 the
 Doc or HtmlView what Widget named 'x' was and then ask the returned Widget 
 what
 it's 'value' property was.

Thanks for the question. I am dup'ing it in Q&A in Harmonia Wiki. Idea is simple: HtmlPanel is a template taking one parameter: HtmlPanel(W) where W is any type derived from Widgets - container of ... Widgets. Thus in Harmonia HTML is not an external entity. Being applied to the container it behaves as its layout manager capable to layout referred widgets (<input>) and render HTML. Consider it as drawable layout manager. Example: HtmlPanel!(Widgets) myhtmlpanel = new HtmlPanel!(Widgets); When you will load in it some html having <input>'s like: myhtmlpanel.html = "<html><input type=mytype /></html>"; then while parsing it will call method: Widget HtmlPanel(W).createWidget(char[] widgetType) where widgetType in this case will be string "mytype". Default implementation (createWidget per se) create widgets of known HTML types ('text', 'radio', 'checkbox') and does this ~= w; // ~= defined in Widgets class adding newly created widget to the container. Thus all HTML widgets will be just children of your container and to retrieve all of them use: foreach( Widget w; myhtmlpanel. forward ) // ascending Z order or foreach( Widget w; myhtmlpanel. backward ) // descending Z order or Widget w = myhtmlpanel[n]; There is also helper method - Widgets.values: NamedBoxes values(Widgets container) It allows you to gather all control values from any container in one shot. NamedBoxes is declared as alias box[wchar[]] NamedBoxes; // module harmonia.ui.widgets; This is useful if your form's html is coming e.g. from DB and you would like to store values in DB also. Just declare in html <input>'s with proper names and types. I've found that DataBinding is almost unusable. In most cases pair of 'values' getter/setter is just enough.
 Also, I sort of get what the event plumbing is trying to do, but I'm not 
 sure
 how to get any useful information from events.  How does one translate an 
 event
 to a Widget?  Where should I add my custom event handlers to the 
 application
 (extend Application, or View, or something else?)

What do you mean by 'translate an event' - to send an event? If you mean just some command (EventCommand) then use: Window.sendCommand(Command cmd, Widget target, bool doIt = true /* otherwise - poll */) It will send (traverse the event) using sinking/bubbling mechanism: http://catcode.com/domcontent/events/capture.html First EventCommand will arrive to the window with SINKING flag set then it will walk through chain parent-child until it will reach the target. Then without SINKING flag it will 'bubble' from the target up to the window and Application. Any widget in the chain can stop event propagation by returning 'true' from its bool Widget.on(EventCommand) { ... } So at any time Application and any container of your widget know that event is routing to your widget. Any container in the parent/child chain can handle non-processed events. Thus if you need to create a compound control consisting of multiple exisiting widgets/components you will be able to handle *any* event routed to its children without any modifications of existing components. Cool, eh? :) Andrew.
May 29 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
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
  
May 30 2005
parent "TechnoZeus" <TechnoZeus PeoplePC.com> writes:
"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