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




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
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.
 


I agree with you - GUI toolkits should behave the same as the 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:
http://www.digitalmars.com/drn-bin/wwwnews?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:
 http://www.digitalmars.com/drn-bin/wwwnews?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.
 


Well, I can tell you that D has already run on at least one mobile 
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.


 Well, I can tell you that D has already run on at least one mobile 
 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




 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


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,

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,

probably being
 used for most of the new stuff.  (Anyone from Microsoft care to jump in here?)
 




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 

 used for most of the new stuff.  (Anyone from Microsoft care to jump 
 in here?)


 


 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,

|>> stuff.  (Anyone from Microsoft care to jump in here?)
|>>
|>


|> 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

 used for most of the new stuff.  (Anyone from Microsoft care to jump
 in here?)




 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,

the plan was to make MSIL the primary compilation target platform



whether that support is filtered through a virtual machine,
emulated, run on an MSIL compatible microprocessor,
interpreted, or whatever.


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:
 


 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.

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.


 



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:



 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.

 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.





 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



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:



 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

 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.





 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


 

 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).


(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:



 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

 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.





 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



 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).


 (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).


 (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



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).


 (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



 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.


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.


(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;


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.


 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.


 (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.



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 

 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 

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 


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*


 System library, making it appear seamless. Venture out into Windows Forms or
 Web Services, and you have to tell the compiler to link to the libraries
 that contain their functionality.


*snip*

 Ok, I can see how you could interpret things that way. But these are
 namespaces from the .NET Base Class Library. They're libraries, just as

 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


 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

so it is entirely concievable that such things have changed somewhat.


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




whereas System.Int32 and System.Boolean (or Bool, I don't remember) are 

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.
 

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.
 

 (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;
 

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
 
 



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...



 whereas System.Int32 and System.Boolean (or Bool, I don't remember) are

 the same. They did that because they thought that would be enought for
 their (initial) lack of generics.


*snip*

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

 -- 
 Carlos Santander Bernal


Again, it has been a while.  Perhaps things have changed.
What I know of it is that Int32 is a structure of the .NET framework, and

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...




..


 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).


(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



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...




 ..


 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).


(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



 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...

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,

probably being
used for most of the new stuff.  (Anyone from Microsoft care to jump in here?)



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.



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...


*snip*

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


*snip*

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

 I will sign up for it!

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


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

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

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

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

TZ



 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,

 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/


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 



 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,

 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/


 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



 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 

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

 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