View mode: basic / threaded / horizontal-split · Log in · Help
May 28, 2005
Re: Native Windows Support
> 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 28, 2005
Re: Native Windows Support
>
>> 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 28, 2005
Re: Native Windows Support
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
Re: Native Windows Support
"Trevor Parscal" <Trevor_member@pathlink.com> wrote in message news:d77ute$24uf$1@digitaldaemon.com...
>
> >As it stands now, I know of no way to write even the simplest Windows program without
> >having to fall back on the use of some other "language" to do it.  That's not to say that it cant't be done...
> >just that I don't know of a way.
> >
>
> Windows was written in C, so anything you do with native windows is going to
> have to interface with C code. Correct me if I am wrong...
>
> >I have been trying for some time now to write a simple file utinity for GenePool4 entirely in the D language,
> >but I can't even figure out how to do something simple like open a file dialog to get a filename.
> >
>
> Native controls like that require the use of the native C headers, like
> windows.h and winuser.h. Luckily we have people who made windows bindings in D.
>
> Check out Core32 on dsource.org
>
> Thanks,
> Trevor Parscal
> www.trevorparscal.com
> trevorparscal@hotmail.com

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

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

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

TZ
May 28, 2005
Re: Native Windows Support
"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
Re: Native Windows Support
"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
Re: Native Windows Support
"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
Re: Native Windows Support
"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
Re: Native Windows Support
"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
Re: Native Windows Support
"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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home