Jump to page: 1 28  
Page
Thread overview
Native Windows Support
May 27, 2005
TechnoZeus
May 27, 2005
bobef
May 27, 2005
Brad Beveridge
May 27, 2005
Trevor Parscal
May 27, 2005
Brad Beveridge
May 27, 2005
Trevor Parscal
May 28, 2005
TechnoZeus
May 28, 2005
Carlos Santander
May 30, 2005
TechnoZeus
May 30, 2005
Carlos Santander
May 30, 2005
TechnoZeus
May 27, 2005
Andrew Fedoniouk
May 27, 2005
Brad Beveridge
May 27, 2005
Andrew Fedoniouk
May 27, 2005
Kris
May 27, 2005
Andrew Fedoniouk
May 27, 2005
Brad Beveridge
May 28, 2005
Andrew Fedoniouk
May 28, 2005
TechnoZeus
May 28, 2005
Carlos Santander
May 27, 2005
Andrew Fedoniouk
May 28, 2005
Andrew Fedoniouk
May 28, 2005
TechnoZeus
May 28, 2005
Trevor Parscal
May 28, 2005
TechnoZeus
May 28, 2005
TechnoZeus
May 29, 2005
Jim H
wxWidgets (was Re: Native Windows Support)
May 29, 2005
J C Calvarese
May 29, 2005
Jim H
May 27, 2005
TechnoZeus
May 27, 2005
Trevor Parscal
May 28, 2005
TechnoZeus
May 28, 2005
Carlos Santander
May 28, 2005
Carlos Santander
May 28, 2005
Thomas Kühne
May 30, 2005
TechnoZeus
May 30, 2005
Lars Ivar Igesund
May 30, 2005
TechnoZeus
May 30, 2005
Lars Ivar Igesund
May 30, 2005
TechnoZeus
May 30, 2005
Carlos Santander
May 30, 2005
TechnoZeus
May 30, 2005
John C
May 30, 2005
TechnoZeus
May 30, 2005
Carlos Santander
May 31, 2005
TechnoZeus
May 30, 2005
J C Calvarese
May 30, 2005
TechnoZeus
May 28, 2005
J C Calvarese
Standard GUI Toolkit
May 28, 2005
Trevor Parscal
May 30, 2005
TechnoZeus
May 30, 2005
J C Calvarese
May 30, 2005
TechnoZeus
May 30, 2005
Trevor Parscal
May 31, 2005
TechnoZeus
May 29, 2005
John C
May 30, 2005
TechnoZeus
May 30, 2005
John C
May 30, 2005
TechnoZeus
May 27, 2005
Derek Parnell
May 28, 2005
TechnoZeus
May 28, 2005
Shawn Liu
May 28, 2005
TechnoZeus
May 28, 2005
Carlos Santander
May 30, 2005
TechnoZeus
May 28, 2005
J C Calvarese
May 30, 2005
TechnoZeus
May 30, 2005
Lars Ivar Igesund
May 30, 2005
TechnoZeus
Harmonia way. sort of resume
May 28, 2005
Andrew Fedoniouk
May 28, 2005
Trevor Parscal
May 29, 2005
Andrew Fedoniouk
May 29, 2005
pragma
May 29, 2005
Andrew Fedoniouk
May 30, 2005
Dejan Lekic
May 30, 2005
TechnoZeus
May 27, 2005
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
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
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
"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
>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
>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
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
>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
> 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
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 6 7 8