I agree with this:
"
No user interface windowing classes
GUI styles, philosophies, etc., are not portable from machine to machine. A
GUI Windows app should look like a Windows app when running on a Windows
machine. It should not look and feel like a Mac app unless it is running on
a Mac. Attempts to create a common GUI class library between Windows, Mac,
and other GUI operating systems have all to my knowledge failed.
Java has a successful GUI class library, but does so by creating its own GUI
with its own look and feel. This approach is fine for a web language, but
not for a systems language like D is.
Windowing class libraries should be separate.
"

On the other hand, having a set of portable graphics libraries that used the language would be nice. Mozilla has a cross-platform graphics system built in based on web standards. Therefore, it would probably be helpful if interface bindings for the W3C DOM were defined, etc. Web languages are very good for designing a GUI. That is why Mozilla's UI works so well cross-platform. Yet, I agree it shouldn't be part of the language - just something to keep in mind when developing it.

It would be very very nice if the code for D could be run both as a script,
as long as there aren't any compile time resources that have to be grabbed.
For instance, say I wrote a program using D containing a few import files
and code files that I use for a CGI. It would be nice to be able to run
those without having to compile the script. Most of the time for things like
CGI, its better to leave it in text form. Perl is a nice language for CGI,
but its not very OOP friendly. For Mozilla, XPCOM which defines the back-end
of the browser and the XUL which is the visual front-end contain two
different programming languages. XPCOM uses c++, while XUL uses XML and
javsscript. If D were scriptable along with compilable, javascript could be
replaced with D. This could also occur on web pages on the internet. Is
there any way D could be made into a good scripting language?
Also, there are other libraries that would be nice to have pretty much on
every system, such as CGI libraries, etc. I noticed you had zip listed
there. I believe that this falls into the same category of libraries that
would be nice to have cross-platform. They shouldn't be part of the language
though. It seems with C++, they created the language and then the run-time,
and the run-time libraries were never considered standard. Therefore, its
important that Phobos be considered cross platform. I don't know about the
zip class though. There are many compression methods that are better, such
as bz2 and tgz. I don't know if that really belongs there, it seems out of
place.

I also want to talk about something I like extremely much about perl. It has
many built-in parsing functions that can do a wide variety of things. It
would be great of D had a library of parsing functions also. I realize there
are currently regexp, but parsing functions such as perl has would also be
nice - such as
strip() and chomp(). I noticed you already have many of them in there. Some
are missing though, like chomp() and chop().

"Brian Bober" <netdemonz@yahoo.com> wrote in message news:a3liuk$ruv$1@digitaldaemon.com...

> It would be very very nice if the code for D could be run both as a
script,
> as long as there aren't any compile time resources that have to be
grabbed.
> For instance, say I wrote a program using D containing a few import files and code files that I use for a CGI. It would be nice to be able to run those without having to compile the script. Most of the time for things
like

Well, what's the problem, write an interpreter for D. =)

> Also, there are other libraries that would be nice to have pretty much on every system, such as CGI libraries, etc. I noticed you had zip listed there. I believe that this falls into the same category of libraries that would be nice to have cross-platform. They shouldn't be part of the
language
> though. It seems with C++, they created the language and then the
run-time,
> and the run-time libraries were never considered standard. Therefore, its important that Phobos be considered cross platform. I don't know about the zip class though. There are many compression methods that are better, such as bz2 and tgz. I don't know if that really belongs there, it seems out of place.

Phobos is cross-platform. Some extensions aren't. For now, this is really
a senseless discussion since libraries are not very standartized and
the only D implementation is for Windows.

> I also want to talk about something I like extremely much about perl. It
has
> many built-in parsing functions that can do a wide variety of things. It would be great of D had a library of parsing functions also. I realize
there
> are currently regexp, but parsing functions such as perl has would also be
> nice - such as
> strip() and chomp(). I noticed you already have many of them in there.
Some
> are missing though, like chomp() and chop().

Two lines of code each =)

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3lkra$sof$1@digitaldaemon.com...
> Phobos is cross-platform. Some extensions aren't. For now, this is really
> a senseless discussion since libraries are not very standartized and
> the only D implementation is for Windows.

Phobos will consist of roughly three components:

1) Runtime support for various features of the language, such as constructors, associative arrays, exception stack unwinding, etc. These are internal to the implementation and are not exposed to the programmer.

2) Portable library functions, meant to be available across all normal implementations of D. For example, the string and regexp imports. Subsets will be possible for embedded systems.

3) Platform specific library functions, meant to exploit specific and non-portable features of a particular system. An example is Windows COM support.

If a gui library is done for D, I see it as being a separate library. D should not *specify* a particular way to do gui's; Since gui's evolve and change independently of languages, and since a gui that makes sense on one platform makes no sense on another, such should be an independent platform. Sort of like Gnome vs KDE <g>.

I also wish to avoid the bloat of dragging along a whole gui library even if some is just writing a grep.

"Walter" <walter@digitalmars.com> wrote in message news:a3mo3o$1flk$1@digitaldaemon.com...

> 3) Platform specific library functions, meant to exploit specific and non-portable features of a particular system. An example is Windows COM support.

So, you claim it to be part of Phobos. I see. Anyhow, there is a part that it cross-platform.

> If a gui library is done for D, I see it as being a separate library. D should not *specify* a particular way to do gui's; Since gui's evolve and change independently of languages, and since a gui that makes sense on one platform makes no sense on another, such should be an independent
platform.
> Sort of like Gnome vs KDE <g>.

Well mine uses raw WinAPI.

Walter wrote:

> ...
> If a gui library is done for D, I see it as being a separate library. D
> should not *specify* a particular way to do gui's; Since gui's evolve and
> change independently of languages, and since a gui that makes sense on one
> platform makes no sense on another, such should be an independent platform.
> Sort of like Gnome vs KDE <g>.
>
> I also wish to avoid the bloat of dragging along a whole gui library even if some is just writing a grep.

I'd advocate making an extremely simple, cross-platform graphics library available as "part" of D.  And I mean simple as in bare-to-the-bones minimal. It should need only one or two hundred bytes of compiled code to implement.

Take a look at TinyPTC (http://www.gaffer.org/tinyptc/).  It is an itty-bitty
graphics library that is cross-language (only C and Java now, Perl and Python
soon, others later) and VERY cross-platform (Win32, X11, SDL, Java AWT, DOS,
and Amiga now, with more soon).  It does only one thing, and it does that one
thing very well:  It moves an integer array (in your favorite language) to the
screen (in your favorite GUI).  It is fast enough to do dynamic animation on
the fly, even in Java (it is much faster than the Swing set for pixel drawing).

Such low-level graphics support could make it trivial to write Netscape plugins in D, or even entire GUIs (simple, small, slow GUIs, that is).  And though TinyPTC may be convenient and handy to have on large PC-like systems (the graphical equivalent of printf to stdout), it would be invaluable to have on PDAs and embedded systems (to supply all the graphics power a small system may need).  If it were part of the D language "environment", it could go a long way to giving D apps a high degree of implicit platform independence. And it would help push D closer to the hardware (in a high-level kind of way).

When D is ported to a new platform, a very basic graphics lib can go with it.

Check it out.  There are several excellent examples on Gaffer's site.


-BobC

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C5F6549.A38A1EE2@yahoo.com...

> Take a look at TinyPTC (http://www.gaffer.org/tinyptc/).  It is an
itty-bitty
> graphics library that is cross-language (only C and Java now, Perl and
Python
> soon, others later) and VERY cross-platform (Win32, X11, SDL, Java AWT,
DOS,
> and Amiga now, with more soon).  It does only one thing, and it does that
one
> thing very well:  It moves an integer array (in your favorite language) to
the
> screen (in your favorite GUI).  It is fast enough to do dynamic animation
on
> the fly, even in Java (it is much faster than the Swing set for pixel
drawing).

I'm also aware about it. Most likely, you'll see a wrapper soon, and then I'll rewrite it in D.

Ok, do you want to lead the charge porting it to D? It sounds like it'd be great.

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C5F6549.A38A1EE2@yahoo.com...
> Walter wrote:
>
> > ...
> > If a gui library is done for D, I see it as being a separate library. D
> > should not *specify* a particular way to do gui's; Since gui's evolve
and
> > change independently of languages, and since a gui that makes sense on
one
> > platform makes no sense on another, such should be an independent
platform.
> > Sort of like Gnome vs KDE <g>.
> >
> > I also wish to avoid the bloat of dragging along a whole gui library
even if
> > some is just writing a grep.
>
> I'd advocate making an extremely simple, cross-platform graphics library available as "part" of D.  And I mean simple as in bare-to-the-bones
minimal.
> It should need only one or two hundred bytes of compiled code to
implement.
>
> Take a look at TinyPTC (http://www.gaffer.org/tinyptc/).  It is an
itty-bitty
> graphics library that is cross-language (only C and Java now, Perl and
Python
> soon, others later) and VERY cross-platform (Win32, X11, SDL, Java AWT,
DOS,
> and Amiga now, with more soon).  It does only one thing, and it does that
one
> thing very well:  It moves an integer array (in your favorite language) to
the
> screen (in your favorite GUI).  It is fast enough to do dynamic animation
on
> the fly, even in Java (it is much faster than the Swing set for pixel
drawing).
>
> Such low-level graphics support could make it trivial to write Netscape
plugins
> in D, or even entire GUIs (simple, small, slow GUIs, that is).  And though TinyPTC may be convenient and handy to have on large PC-like systems (the graphical equivalent of printf to stdout), it would be invaluable to have
on
> PDAs and embedded systems (to supply all the graphics power a small system
may
> need).  If it were part of the D language "environment", it could go a
long way
> to giving D apps a high degree of implicit platform independence. And it
would
> help push D closer to the hardware (in a high-level kind of way).
>
> When D is ported to a new platform, a very basic graphics lib can go with
it.
>
> Check it out.  There are several excellent examples on Gaffer's site.
>
>
> -BobC
>
>

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C5F6549.A38A1EE2@yahoo.com...

> Check it out.  There are several excellent examples on Gaffer's site.

Now I've got pixel format converter and GDI version ported to D in about an hour. DirectDraw will be a bit trickier since some parts of ddraw.h must be ported as well...

Walter wrote:

> Ok, do you want to lead the charge porting it to D? It sounds like it'd be great.

What, a slow old burn-out case of a guy like me?  Pavel already has half of it done!

I suspect he codes faster than I can read.  I'm just happy I was able to feed him an idea he hadn't already though of!

No, these days I'm more of an architecture and R&D guy.  I try to design systems and strategies that can easily and reliably be implemented by below-average coders such as myself.


-BobC

"Robert W. Cunningham" <rwc_2001@yahoo.com> wrote in message news:3C60AB78.4BC81910@yahoo.com...
> Walter wrote:
>
> > Ok, do you want to lead the charge porting it to D? It sounds like it'd
be
> > great.
>
> What, a slow old burn-out case of a guy like me?  Pavel already has half
of it
> done!
>
> I suspect he codes faster than I can read.  I'm just happy I was able to
feed
> him an idea he hadn't already though of!
>
> No, these days I'm more of an architecture and R&D guy.  I try to design systems and strategies that can easily and reliably be implemented by below-average coders such as myself.
>
>
> -BobC
>

ROTFL!!

:)


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail