Standard library for perl6? (graphical primitives)
Markus Laire
other areas where standard library would be of use.)
If I want to write a crossplatform text-mode application, I could write
it in perl, and know that it will be usable in wide variety of
platforms, as long as I use only "standard" commands and not any
platform-specific modules etc..
But if I want to write graphics-mode application, I really don't know
what to do. Even if I were to write a simple one, which just draws lines
or puts pixels on screen, I do not know of any good solution.
Java has graphical primitives, but is encumbered by bad licenses.
C doesn't have graphical primitives in standard library, AFAIK.
Perl does have CPAN, but the problem is that there are no standard
modules, and so there can be several modules doing the same thing. perl5
has some standard commands, listed in "perlfunc", but that doesn't
include any graphical primitives.
Could it be possible to create a "Standard library" for perl6, which
would also include graphical primitives (putpixel, getpixel,
getcolordepth, putimage, getimage, copyrectangle)?
Just a basic example:
use 6;
use Stdlib::GraphicalPrimitives;
// check for availability of graphics mode
if (!GraphModeAvailable())) {
print "No graphics available, sorry\n";
exit 1;
}
// initialize graph-mode, ask for a 100x100 pixel area
// with 24bit colors to work on
if (!InitGraphics(100, 100, 24)) {
print "Couldn't get 100x100x24 graphics area\n";
exit 2;
}
// do something
DrawLine(0, 0, 99, 99);
// ...
--
Markus Laire
Luke Palmer
> Perl does have CPAN, but the problem is that there are no standard
> modules, and so there can be several modules doing the same thing.
And what is the problem with that?
For example, some of the modules for graphics you get to choose from
are wxPerl, Tk, SDL. Each of these has its strengths and weaknesses,
so you may have one project where Tk is the right thing (perhaps a
graphical debugger), and another where SDL is the right thing (a game
of some sort), etc. A standard library has to be able to do
everything, which usually means that it won't be good at anything.
That is, unless we put as much effort into designing it as we have
into Perl 6, which is not going to happen. Plus, people have already
done that, and put the results into modules like wxPerl, Tk and SDL.
> Could it be possible to create a "Standard library" for perl6, which
> would also include graphical primitives (putpixel, getpixel,
> getcolordepth, putimage, getimage, copyrectangle)?
With what underlying library? There are many ways to access the
screen. If we stick to one way, we'll be as portable as QBasic.
But more importantly, we're trying to stay away from that word
"standard". When you wish for a standard library, you're wishing that
something get done. In open source projects, the best way to ensure
that something get done is to do it. So go write a graphics library,
and then we'll see about making it standard.
The other thing we've learned about "standard", is that we're making
an early commitment, which is probably a crappy commitment. If you
provide nothing, that is forcing the CPAN community to come up with
one (probably more than one). And all of those will probably be
better than one that we come up with: I don't see too many graphics
efficianados around p6l.
The other other thing we've learned about "standard" is that if there
is a decent standard library, then vendors don't care about installing
any modules. So the plan for perl 6 is to provide little or no
standard library so that vendors will be forced to install a decent
set of modules (maybe Bundle::Standard... oops, there's that word
again).
Luke
Bryan Burgers
> On 10/14/05, Markus Laire <mar...@laire.info> wrote:
> > Perl does have CPAN, but the problem is that there are no standard
> > modules, and so there can be several modules doing the same thing.
>
> And what is the problem with that?
The problem may be that it doesn't work everywhere. What I find
exciting about parrot is that (it sounds like to me) you'll be able to
run a perl6 file anywhere that has parrot, much like Java. I think
what Markus is getting at is for there to be a way to display graphics
through parrot everywhere parrot runs as well. Yes, different modules
are extremely important, because the programmer deserves a choice, but
some modules run someplaces, others run other places - it'd be a good
thing to have the absolute bare essentials run everywhere.
Bryan
Chromatic
> What I find exciting about parrot is that (it sounds like to me)
> you'll be able to run a perl6 file anywhere that has parrot, much like
> Java. I think what Markus is getting at is for there to be a way to
> display graphics through parrot everywhere parrot runs as well. Yes,
> different modules are extremely important, because the programmer
> deserves a choice, but some modules run someplaces, others run other
> places - it'd be a good thing to have the absolute bare essentials run
> everywhere.
I agree, but it's not an easy question: which bare essentials are those?
How big is the screen on every device where Parrot runs? Is there
hardware acceleration? Is there a text-mode console? Is there a
framebuffer? How many colors? Is there a back buffer? What types of
input devices are available? Does the platform have POSIX support?
Does it have a MMU? Can it run a compiler from the program? Is there
an existing graphics library on every platform we can use or will we
have to write and maintain a superset of all graphics primitives we want
to provide on every platform? Does the platform support tiling or
overlapping windows? Does it manage resources automatically or leave
that up to the programmer?
-- c
Nathan Gray
> Could it be possible to create a "Standard library" for perl6, which
> would also include graphical primitives (putpixel, getpixel,
> getcolordepth, putimage, getimage, copyrectangle)?
I'm interested in creating a perl6 binding to cairo
(http://cairographics.org), but haven't gotten anywhere close to
starting that project.
-kolibrie
Dave Whipp
> I'm not completely sure if it would be worth the trouble to support only
> most primitive graphical commands "in core", (no windows, etc..), and
> leave the rest to the modules (or to the programmer).
To a large extent, I'd want to leave most details to modules, etc. But
what would be nice (tm) would be to establish a framework within
graphics libraries can the created. Sort of like DBI/DBD: A core set of
capabilities ala DBI, implemented in multiple ways via drivers (DBD).
The only problem is ... it's hard.
But things like "create window" are the sort of interfaces that you
would want to become defacto standards. Drawing pixels/lines is much
less interesting (except as exposed by a "canvas" widget)
The thing that makes it feasable is perhaps that most look-and-feel
stuff is already externalized from specific applications. So it is
reasonable to have a generic "open window" that "just works". Perhaps
the equivalent of DBI is semantically the same as the interface to web
browsers (client side) -- thats probably the closest we have a broadly
accepted standard.