I would make a release from my Perl package browser, but it took me two hours just to commit it to SourceForge. (I am making slow progress on doing anything useful on these public computers).
Instructions for anonymous CVS
But, you can just grab the script file from the veiwcvs stuff. The SourceForge CVS browser is very slow to update, so wait for the stuff with today's (or close ) date.
Things you need: Lots of Tk:: and Module:: stuff.
Don't get too hung up on the yucky code. It is just version 1, and I wrote this over two weeks when I had about an hour of free time at the end of the day. Consistency was a luxury.
Any comments are welcome. Anyone who can help me extract the right info from the packages to display in the various panes will be rewarded with beer, shamelessy.
Re:See also: Perl Oasis
brian_d_foy on 2004-01-08T08:57:26
Hey, that looks pretty cool. Thanks. I download the source and I will have to look at it tonight.
Do not feel bad about it being Windows only though---I would really like to make a Mac only version just so its faster and integrates well with everything else (e.g. cut and paste, AppleEvents, and what not).
;) It's a cool perl script that could become one of the often used programming tools <wink>.
Just one thing I didn't get... The breaking apart of the modules into the right panes. What are you planning to do? A pane with a summary, another pane with examples, etc??
It's a great script and runs without any problems (even after repeated pounding of the module tree view) on a Ti PowerBook 1GHz/1GB 15" running Panther 10.3.2/Perl 5.8.2.
/oliver/
Btw. The tar ball on sourceforge just explodes an empty directory without any files.
Re:like it a whole lot...
brian_d_foy on 2004-01-08T09:05:39
Ah, fudge.
I did not have a MANIFEST file in the frickin' directory. I am so discombobulated trying to set up a development environment. That's not an excuse, just a bit of venting.
As for the right panes, you mean the tabbed thingys? I just want to make all of the stuff (docs, code, etc) easily available without creating a bunch of windows. That's the big design problem in my opinion---how to keep from creating windows all over the place. I often jump between the docs and code, so I like to keep those things close to each other. The other stuff has been useful sometimes for me too.
Eventually, I would like to make those panes configurable so you can pick and choose the ones that you want, the one that is on top initially, and so on, but that is a way down the road.
Re:Bitchy Tk
brian_d_foy on 2004-01-08T18:29:46
I do not know much about which versions it should work with, even which exact version I have.
This reminds me---how do you test Tk things?Re:Bitchy Tk
ethan on 2004-01-08T21:26:13
This reminds me---how do you test Tk things?
That was what I asked me as well when I saw the Tk tests fly by. NI-S has obviously found a way.
Those tests are maybe a little flaky. I have my window manager configured so that I place any newly created window on my desktop with a mouse-click. That made some of the tests, that apparently expected to create a new window right away, fail.Re:Bitchy Tk
brian_d_foy on 2004-01-09T18:15:40
I know I can test that things like window creation happens, but how can I test that when I press this key this menu gets updated, and other GUI events like that? Chris Nandor has some stuff like that for one of his Mac distros, but it also relies on the user doing the thing that the test tells him to do (and doing it correctly).
I suppose that a Test::Tk could delve into the main window data structure and look at things, or could simulate some events somehow. Someone with more skill than I have would need to figure all that out.
