Re: [MacPerl] Porting an Inside Mac QuickDraw example routine

[ilir topalli <ilir@gis.net>]

>>sort of detracts from what makes perl attractive to start: the ability
>>  to whip out code that does what you want without swetting the small
>>  stuff.

>  Sure, but I still don't see them as not Perl-like.  They are just more
>  complex.  It seems we just have different views of what "Perl-like" is.  So
>  we will just drop that phrase and move on.  :)



 Your right, I agree the term is vague and we should definitely drop it.  Sorry
 to use such a vague term.

 It seems however that we also are a bit vague on the term "different".
 I don't mean to be facetious here (email can often come off as a bit unfriendly

 since there are so few subtelties of conversation) I'm just trying understand
 your  position from your perspective.  I'm sure that there is much that I would

 agree with.

 What I am hearing is that the perl toolbox is different in that it is
implemented in Perl and perl handles them in its own way (such as the way it
handles constants and functions).  I am also hearing is that the toolbox modules

are very similar to the apple toolbox routines. I can agree with that.

 Is what your saying that the toolbox modules are implemented as similarly to
the Inside Mac Specifications as possible and that still jives with the way
people
 like to do things in perl and what attracts people to Perl?



 If so I can't really agree. (If not I don't mean to put words in your mouth).
 And maybe we don't need to agree on this, but if so,

 1)  Surely more people would use the toolbox than do.
 Maybe some people with a programming background that is heavy in the toolbox
department are used to handling things this way.


 2) The toolbox routines were created by Apple which did not have any
consideration of Perl in mind when they designed.  As they say in the movie
business,any similarities are purely coincidental.

 It seems that this would be why so many people stick to standard Perl and avoid

using them.  (That, and the time investment in learning the toolbox and learning

the toolbox really is like learning another language).

 I think the programming culture of Perlers is often Very different from the
programming culture that developed the toolbox (I may be wrong here).

At  the very least, Inside Macintosh is not about "more than one
 way to do it"  it is about "there is only one way to do it".  At present there
really is only one way to implement the toolbox.

 Although useful and sometimes necessary I and many many experienced Perl
programmers tell me that they have had some difficulty and
 most perlers seem to avoid using the Toolbox whenever possible.
 I was amazed at how easy it was to get up and running in Perl.  The Apple
specific stuff however is a different story.
 Perhaps that is due to the huge number of resources dedicated to Perl
programming compared to Perl-Toolbox
 As well many use Perl for form parsing/handling, something that Perl makes
easy.

 It's a shame too.  I think the first thing MacPerlers should be experimenting
with is the GUI and events.  The toolbox and the Mac:Whatever modules is what
makes MacPerl special.

 It would be nice if making a complicated window was as simple as making a
complex form or database, especially since we approach an age where graphical
interfaces are becoming as common than forms.

 I think Perl could evolve into a tremendous general purpose development tool if
it
could handle GUI or other graphics as simply and powerfully as it does text.
I guess parsing HTML is a step in this direction, but controling a second
language has its obvious problems

 Of course everyone is different.  I'm sure  the
 present state of the toolbox apeals to many.

_______
 Rather than keep harping on(and as I read what I wrote I am harping :s )
 what we don't agree on how about  (which I think isn't much) I'll talk
 about what we do agree on. Perhaps this should even be a new thread.

 Clearly Perl is a growing and evolving language.  As Perl continues to grow and

advance, would it be nice if there were more that one way to do toolbox
routines?
 I think so.  Apple Events::Simple is one step in this direction.  It would be
nice if there was something similar to Windows,controls, events and Quickdraw.

 Do others agree or disagree?  Does anybody have anything on their wishlist that

would simplify these functions? That would add something to them? what kind of
assumptions
would be part of/excluded from such a module?

 Anything people post would be helpful I think.  Only out of discussion will
these things actually come to be created. One of the nice things about an open
source language is the ability of the community to discuss ideas before
implementation. Or to decide implementation would be a bad idea.
(perhaps I should be posting on the toolbox forum)

I'll throw out a (tiny) bone:  I think color managment in sort of obscure.  I
have
seen a lot of postings for instance that use (I think from MPPE)


  RGBForeColor(new_color(16384, 16384, 16384));
  sub new_color {bless(\pack('SSS', @_[0..2]), 'RGBColor');}

I think the "bless(\pack($,#,#,#)) " is pretty obscure.  Like I said before, I'm
not
looking to get rid of anything here.  Obviously even this subroutine could be
simplified
from it's function within a function form.


 I guess porting of Tk would be a good step in that direction.  I
have very little experience with it though. Does Tk also use Controls etc?   All
I
know is that a lot of people seem to really dislike using it (at least Mac
users).


 Is that because the Tk concepts are so different from the Mac GUI concepts?
 Or is it that the Mac way of doing it has many advantages over Tk that make
 people avoid it?

>  The reason I say I don't think it would work, that the API is too
>  different, is because I have done GUIs with the Tk and Mac OS APIs, and I
>  once had thoughts of adapting the Tk API to sit on top of the Mac OS API,
>  and after doing some Tk, I realized the concepts just didn't map well
>  enough to make it seem worth the effort of doing it or even using it.

It seems like it would be a herculean task. Considering entire volumes are
written just about using Tk. You are a brave man.







# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org