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

 as long as there aren't any compile time resources that have to be

 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

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

 though. It seems with C++, they created the language and then the

 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

 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

 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.

 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

 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

 graphics library that is cross-language (only C and Java now, Perl and

 soon, others later) and VERY cross-platform (Win32, X11, SDL, Java AWT,

 and Amiga now, with more soon).  It does only one thing, and it does that

 thing very well:  It moves an integer array (in your favorite language) to

 screen (in your favorite GUI).  It is fast enough to do dynamic animation

 the fly, even in Java (it is much faster than the Swing set for pixel

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


 change independently of languages, and since a gui that makes sense on


 platform makes no sense on another, such should be an independent


 Sort of like Gnome vs KDE <g>.

 I also wish to avoid the bloat of dragging along a whole gui library


 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

 It should need only one or two hundred bytes of compiled code to

 Take a look at TinyPTC (http://www.gaffer.org/tinyptc/).  It is an

 graphics library that is cross-language (only C and Java now, Perl and

 soon, others later) and VERY cross-platform (Win32, X11, SDL, Java AWT,

 and Amiga now, with more soon).  It does only one thing, and it does that

 thing very well:  It moves an integer array (in your favorite language) to

 screen (in your favorite GUI).  It is fast enough to do dynamic animation

 the fly, even in Java (it is much faster than the Swing set for pixel

 Such low-level graphics support could make it trivial to write Netscape

 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

 PDAs and embedded systems (to supply all the graphics power a small system

 need).  If it were part of the D language "environment", it could go a

 to giving D apps a high degree of implicit platform independence. And it

 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

 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


 great.

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

 done!

 I suspect he codes faster than I can read.  I'm just happy I was able to

 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

 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