View mode: basic / threaded / horizontal-split · Log in · Help
May 27, 2005
Native Windows Support
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
Re: Native Windows Support
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
Re: Native Windows Support
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
Re: Native Windows Support
"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
Re: Native Windows Support
>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
Re: Native Windows Support
>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
Re: Native Windows Support
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
Re: Native Windows Support
>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
Re: Native Windows Support
> 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
Re: Native Windows Support
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home