http://qs1969.pair.com?node_id=1064862


in reply to Re: Questions about Tk::ACH distribution
in thread Questions about Tk::ACH

Hi!

Thank you for the answer. It's good to hear another opinion regarding the directory structure.

It look that I mixed things up. Tk::FileEntry does work. But it doesn't look good and it has a not-so-good documentation. That's what I improved: adding POD and switching to getOpenFile for file selection. And I made the bindings work that were commented in the test file.

I found Tk-ACH on github (https://github.com/gitpan/Tk-ACH), so I created a pull request. I hope it is usable, it's my first one.

Testing was tricky though. prove -l didn't work because there was no lib folder with expected directory structure. This is what I actually used instead of prove:

dmake TEST_FILES=t/fileentry.t TEST_VERBOSE=1 test

Replies are listed 'Best First'.
Re^3: Questions about Tk::ACH distribution
by Anonymous Monk on Nov 29, 2013 at 10:11 UTC

    Hi:)

    ...gitpan ...

    gitpan was built by automatic software years ago (cpan on github), it isn't updated anymore, and IIRC no mail gets forwarded to the original cpan authors, so there is nobody watching for your pull request

    OTOH, the current Tk-ACH maintainer YEWENBIN has github account of his own (wenbinye) and is active on there ... so he'd be the person to contact

    and switching to getOpenFile for file selection.

    That seems very odd, as it seems to destroy the purpose behind the module , which is to avoid getOpenFile by implementing a different look/feel...

      gitpan ... so there is nobody watching for your pull request

      ha, and I see that I missed the username on the gitpan as wenbinye , so the notification went through

      :) must be too much turkey

      and switching to getOpenFile for file selection.

      That seems very odd, as it seems to destroy the purpose behind the module , which is to avoid getOpenFile by implementing a different look/feel...

      Uhm, I'm not sure I I'd miss something here. Where do you get the information that Tk::FileEntry uses the far ugliest file selector on purpose?

      I thought it's used because at the time when the module was written, there was no getOpenFile implementation for all OS'.

      So, if this is not the case and Tk::FileEntry will be stuck with this scarecrow dialog, then my patch (which did not get any attention) was absolutely obsolete and I will have to do it myself anyway.

      What do you think of Tk::FilePicker?

        on second thought I think I may have confused the Tk::FileEntry author as writing Tk::FileSelect ... so I wrote all that wrong "destroying of purpose" stuff ... was reading too much into it :/

        What do you think of Tk::FilePicker?

        Never heard of it :)

        Do you mean as your own replacement for Tk::FileSelect? Not bad name :)

        You might consider allowing a user to chooose what kind of dialog to popup, Tk::FileSelect, Tk::JFileDialog, Tk::FBox, whatever :)

      That seems very odd, as it seems to destroy the purpose behind the module , which is to avoid getOpenFile by implementing a different look/feel...

      When reading this, I got the impression that you might have mixed up Tk::FileEntry with Tk::PathEntry.