www.digitalmars.com         C & C++   DMDScript  

D - GUI, scripting, main and zip

reply "Brian Bober" <netdemonz yahoo.com> writes:
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().
Feb 04 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"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 =)
Feb 04 2002
parent reply "Walter" <walter digitalmars.com> writes:
"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.
Feb 04 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
Feb 04 2002
prev sibling next sibling parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
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
Feb 04 2002
next sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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.
Feb 04 2002
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
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
Feb 05 2002
parent reply "Robert W. Cunningham" <rwc_2001 yahoo.com> writes:
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
Feb 05 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"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
Feb 07 2002
prev sibling parent "Pavel Minayev" <evilone omen.ru> writes:
"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...
Feb 05 2002
prev sibling parent "Robert M. Münch" <robert.muench robertmuench.de> writes:
"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:a3mo3o$1flk$1 digitaldaemon.com...


 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>.


Hi, concerning a GUI library I want to mention the OpenAmulet project I
coordinated for about 2 years. Have a look at http://www.openip.org
Unfortunately I don't have any time to continue the project but the concept
of OpenAmulet (constrained solvers used to link GUI elements, prototyping of
GUI elements etc.) is still good. Maybe someone can have a look at it. A
port to D would really be cool ;-)) and yes OpenAmulet is portable and uses
only very basic GDI functions.


--
Robert M. Münch
IT & Management Freelancer
Mobile: +49 (0)177 2452 802
Fax   : +49 (0)721 8408 9112
Web   : http://www.robertmuench.de
Feb 11 2002