Re^2: Questions about Tk::ACH distribution

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]

Comment on Re^2: Questions about Tk::ACH distribution Select or Download Code

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...	[reply]
Re^4: Questions about Tk::ACH distribution by Anonymous Monk on Nov 29, 2013 at 10:12 UTC
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]
Re^4: Questions about Tk::ACH distribution by capfan (Sexton) on Dec 12, 2013 at 19:27 UTC
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]
Re^5: Questions about Tk::ACH distribution by Anonymous Monk on Dec 13, 2013 at 02:53 UTC
Read more... (355 Bytes) 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 :)	[reply]
Re^4: Questions about Tk::ACH distribution by Anonymous Monk on Dec 13, 2013 at 16:23 UTC
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]
Re^5: Questions about Tk::ACH distribution by Anonymous Monk on Dec 13, 2013 at 23:08 UTC
see Re^5: Questions about Tk::ACH distribution	[reply]


The stupid question is the question not asked
	PerlMonks