Well, I'm trying but not getting too far. I tried the code as suggested by
Milan but got errors. I then tried to mimic what I say in the Messagebox
code in the Tk package. This is what I have so far:
function GetOpenFile2(; filetypes::Array=[], initialdir::String="",
initialfile::String="", multiple::Bool=[], title::
String="")
args = Dict()
if length(filetypes) > 0 args["filetypes"] = filetypes end
if length(initialdir) > 0 args["initialdir"] = initialdir end
if length(initialfile) > 0 arg["initialfile"] = initialfile end
if length(multiple) > 0 args["multiple"] = multiple end
if length(title) > 0 args["title"] = title end
tcl("tk_getOpenFile"; args)
end
I coded this in Juno but got an error message that keyword args needs a
default value. Not sure why since it doesn't have one in Messagebox. Not
sure how to proceed.
Eric
On Friday, February 27, 2015 at 4:44:13 PM UTC-6, Eric S wrote:
>
> A correction, the newest suggestion for filetypes does indeed work on my
> Mac, I just needed to find a folder with a proper file ending in ",txt"!
>
> Eric
>
> On Friday, February 27, 2015 at 4:40:53 PM UTC-6, Eric S wrote:
>
> Milan,
>
> I'm just learning Julia so some of what you wrote isn't familiar to me
> yet. For instance I'm not familiar with this construct: "Text files" =>
> ".txt". In any case, I still can't get the filetypes keyword to work on my
> Mac. Even with your latest suggestion, all the files end up grayed out. It
> may be that the Mac dialogs don't support the use of filetypes in this
> context. I'm supposing there must be some function for determining the
> computer type in case we need to make some keywords conditional on platform.
>
> Thanks,
>
> Eric
>
> On Friday, February 27, 2015 at 3:20:51 PM UTC-6, Milan Bouchet-Valat
> wrote:
>
> Le vendredi 27 février 2015 à 12:16 -0800, Eric S a écrit :
> > Milan,
> >
> >
> > Thanks for the hint. When I try the following call on my computer (OS
> > X 10.10.2) it invokes the open file dialog (native too), but all the
> > files are grayed out and not selectable.
> >
> >
> > julia> z=tcl("tk_getOpenFile", filetypes=["Text files {.txt}"])
> Sorry, I didn't pay attention to the actual result. This actually needs
> to be "{Text files} {.txt}". Probably another argument in favor of
> writing it as "Text files" => ".txt".
>
> > If I leave out the filetypes, I can select any files. As for the
> > implementation, you can pass in as few or as many keyword arguments in
> > a Dict. I think just allowing the user to set up the Dict is easier
> > than exposing each of the keywords separately in the function call
> > just because there are so many of them. The following works for
> > instance:
> >
> >
> > julia> kwarg = Dict();
> >
> >
> > julia> kwarg["title"]="Pick a file";
> >
> >
> > julia> kwarg["multiple"]=true;
> >
> >
> > julia> z=tcl("tk_getOpenFile", kwarg)
> No, I don't think forcing the user to explicitly create a dict is a good
> idea. Keyword arguments are precisely here to avoid this. If you don't
> want to take care of the various possible combinations of keywords, you
> can always write the function simply as:
> GetOpenFile(; kwargs...) = tcl("tk_getOpenFile"; kwargs...)
>
> But I'd say it's clearer for users to list all the accepted keyword
> arguments, and raise an error when passing an unsupported one. In R, the
> help page for tkgetOpenFile() and for many Tcl/Tk functions looks like
> this:
> tkgetOpenFile(...)
> tkgetSaveFile(...)
> tkchooseDirectory(...)
> tkmessageBox(...)
> tkdialog(...)
> tkpopup(...)
>
> This is a nightmare when you don't remember the exact name of an
> argument, and auto-completion doesn't work.
>
> Here's a possible way of writing this function, but it's relatively
> verbose:
> function GetOpenFile(; filetypes=nothing, initialdir=nothing,
> initialfile=nothing, multiple=nothing,
> title=nothing)
> args = Dict{Symbol, Any}()
> filetypes != nothing && push!(args, :filetypes=>filetypes)
> initialdir != nothing && push!(args, :initialdir=>initialdir)
> initialfile != nothing && push!(args, :initialfile=>initialfile)
> multiple != nothing && push!(args, :multiple=>multiple)
> title != nothing && push!(args, :title=>title)
> tcl("tk_getOpenFile"; args...)
> end
>
> Any other ideas to handle this situation (which should be quite common
> in Tcl/Tk)? Maybe `to_tcl(::Pair)` should return `""` when the value is
> `nothing`, so that default values can be passed directly without any
> effect?
>
>
> Regards
>
> > Eric
> >
> >
> > On Friday, February 27, 2015 at 12:53:00 PM UTC-6, Milan Bouchet-Valat
> > wrote:
> > Le vendredi 27 février 2015 à 10:31 -0800, Eric S a écrit :
> > > I see from the definition of the Messagebox function much of
> > what I
> > > might do. I'm having a real problem figuring out how to
> > define the
> > > filetypes however. I looked to Python's tk interface for
> > file dialogs
> > > for a clue, but still got stuck.
> > This seems to work:
> > tcl("tk_getOpenFile", filetypes=["Text files {.txt}", "PNG
> > files {.png}"])
> >
> > Thus a definition like this seems to be fine:
> > GetOpenFile(; filetypes="") = filetypes == "" ?
> > tcl("tk_getOpenFile") :
> > tcl("tk_getOpenFile", filetypes=filetypes)
> >
> >
> > But if you want to support the other keyword arguments
> > ( -initialdir,
> > -initialfile, -multiple and -title I think), you'll need a
> > better logic,
> > or the number of possible combinations will explode. There's
> > probably a
> > trick to avoid passing arguments which have been left to their
> > default
> > value.
> >
> > One might also prefer replacing "Text files {.txt}" with
> > something more
> > Julian, like "Text files" => ".txt" and/or
> > ("Text files", ".txt").
> >
> >
> > Regards
> >
> > >
> > > Eric
> > >
> > > On Friday, February 27, 2015 at 12:06:50 PM UTC-6, Eric S
> > wrote:
> > > I did see that code and tried a bit to make it work,
> > but
> > > didn't get anywhere. I was clueless how to add the
> > keywords.
> > > Strings? I could see it should be doable but not how
> > to do it.
> > > I might be able to figure something out if I had
> > some
> > > examples. I should note that I'm competent in MATLAB
> > and
> > > dabble in Python but otherwise I'm not a programmer
> > as my
> > > background is in Mechanical Engineering. 30 years
> > ago I
> > > learned programming in FORTRAN. I've just started
> > playing with
> > > Julia and I'm enjoying it. I'm hoping to displace
> > MATLAB. I
> > > was into Python with Numpy/Scipy but that felt sort
> > of bolted
> > > on and not as elegant. If there was someone willing
> > to help me
> > > along, I could endeavor to add this functionality.
> > >
> > >
> > > Eric
> > >
> > > On Friday, February 27, 2015 at 10:25:20 AM UTC-6, j
> > verzani
> > > wrote:
> > > The Tk dialogs can be redefined easily. For
> > example,
> > > instead of this line
> > >
> > (
> https://github.com/JuliaLang/Tk.jl/blob/master/src/dialogs.jl#L4)
> > >
> > >
> > > GetOpenFile() = tcl("tk_getOpenFile")
> > >
> > >
> > > You had
> > >
> > >
> > > GetOpenFile(;kwargs...) =
> > tcl("tk_getOpenFile";
> > > kwargs...)
> > >
> > >
> > > Then you can pass in the named arguments
> > such as
> > >
> > >
> > > GetOpenFile(initialdir="/tmp")
> > >
> > > You did a good job on the docs, want to put
> > this
> > > together for the function definitions?
> > >
> > >
> > >
> > > On Friday, February 27, 2015 at 9:57:57 AM
> > UTC-5, Eric
> > > S wrote:
> > >
> > > Tim,
> > >
> > >
> > > I did edit the documentation README
> > as
> > > suggested. I've discovered (I
> > think), that
> > > while one can call the various file
> > dialogs,
> > > none of the options are supported
> > such as
> > > specifying file extensions, etc. I'm
> > gathering
> > > those just aren't coded yet. Is
> > there a
> > > obvious way to make this request?
> > >
> > >
> > > Eric
> > >
> > > On Wednesday, February 25, 2015 at
> > 12:53:41 PM
> > > UTC-6, Tim Holy wrote:
> > > Sure, just click on the
> > source file
> > > (e.g., README.md) and then
> > on the
> > > little
> > > pencil icon in the upper
> > right hand
> > > corner.
> > >
> > > See also
> > >
> > https://github.com/JuliaLang/julia/blob/master/CONTRIBUTING.md
> > >
> > > Thanks for tackling this!
> > > --Tim
> > >
> > >
> > > On Wednesday, February 25,
> > 2015
> > > 10:44:28 AM Eric S wrote:
> > > > Is there some
> > documentation
> > > describing how to add to
> > the
> > > documentation? I'd
> > > > be happy to do so if I had
> > a clue
> > > how.
> > > >
> > > > Eric
> > > >
> > > > On Wednesday, February 25,
> > 2015 at
> > > 10:08:41 AM UTC-6, Tim Holy
> > wrote:
> > > > > It's a mix: the author
> > has a lot
> > > of implicit knowledge that's
> > s/he
> > > takes
> > > > > for
> > > > > granted, and that makes
> > it harder
> > > to write good documentation.
> > In
> > > > > combination
> > > > > with edits from the
> > package
> > > author, a user who is just
> > learning a
> > > package
> > > > > is
> > > > > the _perfect_ person to
> > write
> > > documentation.
> > > > >
> > > > > The other point is that
> > developers
> > > who release code are giving
> > a gift to
> > > > > the
> > > > > community, and then
> > being extra
> > > nice by answering questions
> > on the
> > > mailing
> > > > > list. Asking the
> > developers to do
> > > even more is, in a sense,
> > asking too
> > > > > much.
> > > > > In my opinion, it's
> > simply a fair
> > > exchange if the asker then
> > takes that
> > > > > information that s/he
> > has
> > > received, polishes it up as
> > necessary,
> > > and adds
> > > > > it
> > > > > to the README. I help
> > you, you
> > > help me.
> > > > >
> > > > > Converting "one answered
> > question
> > > on the user list" into "one
> > > community-
> > > > > contributed improvement
> > in the
> > > documentation" will go a
> > long, long
> > > ways to
> > > > > improving the
> > documentation for
> > > future users---if everyone
> > did that,
> > > we
> > > > > would
> > > > > erase our documentation
> > problems
> > > very quickly.
> > > > >
> > > > > --Tim
> > > > >
> > > > > On Wednesday, February
> > 25, 2015
> > > 07:35:57 AM Eric S wrote:
> > > > > > I guess I would if I
> > had the
> > > knowledge. I was hoping the
> > author of
> > > the
> > > > > > package might help
> > here since
> > > I'm assuming that person
> > could do it
> > > much
> > > > > > more efficiently.
> > > > > >
> > > > > > Eric
> > > > > >
> > > > > > On Wednesday, February
> > 25, 2015
> > > at 9:27:14 AM UTC-6, Tim
> > Holy wrote:
> > > > > > > By all means, please
> > improve
> > > the documentation!
> > > > > > >
> > > > > > > --Tim
> > > > > > >
> > > > > > > On Wednesday,
> > February 25,
> > > 2015 07:09:33 AM Eric S
> > wrote:
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > This is exactly
> > what I want.
> > > The documentation for the Tk
> > package
> > > > > > >
> > > > > > > doesn't
> > > > > > >
> > > > > > > > list all the
> > available
> > > methods/functions. There
> > needs to be a
> > > more
> > > > > > > > discoverable
> > method of
> > > finding them than asking in
> > the user
> > > group.
> > > > > > > >
> > > > > > > > Eric
> > > > > > > >
> > > > > > > > On Tuesday,
> > February 24,
> > > 2015 at 6:55:52 PM UTC-6, j
> > verzani
> > > wrote:
> > > > > > > > > You can try
> > `GetOpenFile`,
> > > `GetSaveFile`, or
> > `ChooseDirectory`
> > >
>
> ...
