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


in reply to Questions about Tk::ACH

Does this module have to live in this namespace forever?

A module is a namespace associated with a file, and no, it dosn't have to live in the Tk-ACH distribution, but it currently does

I did this for Tk::FileEntry to make it work

Well, you didn't need to do that, it already works, changing the directory structure isnt needed

So, do I have to adjust my patch to this kind of directory structure of Tk::ACH (which would mean, that I won't provide a patch because I don't like it)?

What does your patch do?

Why don't you start with 

ptar -Czxvf Tk-ACH-0.04.tar.gz
rename Tk-ACH-0.04 Tk-ACH-0.04-old
ptar -Czxvf Tk-ACH-0.04.tar.gz
rename Tk-ACH-0.04 Tk-ACH-0.04-new

[download]

Then edit Tk-ACH-0.04-new to fix whatever you're fixing,

then run diff -ruN Tk-ACH-0.04-old Tk-ACH-0.04-new > Tk-ACH-0.04-new.patch and send that to the maintainer

Usually developers don't like to change directory layout that already works, and has worked since 1998 (and before), just to accept a fix for some bug not related to directory layout

Replies are listed 'Best First'.
Re^2: Questions about Tk::ACH distribution
by capfan (Sexton) on Nov 28, 2013 at 18:53 UTC

    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

    [download]
[reply]
[d/l]
[select]

      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...

[reply]
        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.

[reply]

        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

[reply]
        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?

[reply]

In Section Seekers of Perl Wisdom