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

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

> The question here is mainly one of whether D is to be considered a
> fully functional programming language in it's own right,
> or merely a tool to augment programming in the C language.
> Of course, the answer may be a matter of opinion, and largely subject to
> the observer's platform of choice. I personally would like to see it succede
> as a full featured programming language on all targeted platforms,
> and then some.
> 
> TZ
> 
> 


-- 
Carlos Santander Bernal
May 28, 2005
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
Carlos Santander escribió:
> TechnoZeus escribió:
> 
>>
>> No, that's actually not correct, although the way the API documentation is written I can
>> understand how it may lead people to such a conclusion.
>>
>> Over the years, many languages have been involved in the writing of Windows,
>> and I'm not sure what it's primarily written in now, but I would guess C# is probably being
>> used for most of the new stuff.  (Anyone from Microsoft care to jump in here?)
>>
> 
> C# compiles to MSIL. Windows runs Win32 applications. MSIL applications are not Win32 applications. So C# is as native as Java, for example. I'm sorry, but I disagree with you here.
>

Small correction: Java doesn't use native controls but MSIL does. Still, they both run on a virtual machine, and that makes them not native.

>> The question here is mainly one of whether D is to be considered a
>> fully functional programming language in it's own right,
>> or merely a tool to augment programming in the C language.
>> Of course, the answer may be a matter of opinion, and largely subject to
>> the observer's platform of choice. I personally would like to see it succede
>> as a full featured programming language on all targeted platforms,
>> and then some.
>>
>> TZ
>>
>>
> 
> 


-- 
Carlos Santander Bernal
May 28, 2005
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
In article <d79cpe$dil$1@digitaldaemon.com>, TechnoZeus says...
>
..

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

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

>The question here is mainly one of whether D is to be considered a
>fully functional programming language in it's own right,
>or merely a tool to augment programming in the C language.
>Of course, the answer may be a matter of opinion, and largely subject to
>the observer's platform of choice. I personally would like to see it succede
>as a full featured programming language on all targeted platforms,
>and then some.

What do you want added to D (or changed about D) to achieve this goal? What are you proposing? I think D is already well-suited to be considered "a full featured programming language". The only thing holding back D is the absence of Visual D as part of Microsoft's Visual Studio (don't hold your breath).

jcc7
May 28, 2005
>>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
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).

:)