::starkit::topdir on MS Windows?

[bill...@alum.mit.edu]

I have a program distributed as a starpack that includes a set of
sample input files. The procedure that reads input files contains the
code:

if {[info exists ::starkit::topdir] } {
set initdir [file join $::starkit::topdir Wordlists]
} else {
set initdir [pwd]
}

and uses the value of initdir as the argument to the -initialdir
option of tk_getOpenFile. When I run the starpack on my Linux system
everything works correctly and tk_getOpenFile presents the Wordlist
directory within the virtual file system as the initial directory. The
same is true when I run the MS Windows starpack under Wine on my Linux
system. Yesterday, however, I tried this on an MS Windows system
(Vista) and it didn't work. The directory in the starpacks VFS was not
shown - instead I got the desktop.

Can anyone explain this? Does ::starkit::topdir not exist on Vista?

[APN]

I use starkit::topdir in a similar fashion on Windows without any
issues. Are you doing a

package require starkit
starkit::startup

in your main.tcl file at the root of the starkit?

/Ashok

[Jeff Godfrey]

bill...@alum.mit.edu wrote:

> Can anyone explain this? Does ::starkit::topdir not exist on Vista?

I'd guess that it's due to the native windows file dialogs
(tk_getOpenFile in your case) not recognizing the VFS. Do the other
environments you mentioned testing use the Tk-based version of
tk_getOpenFile, which does recognize the VFS?

Jeff

[bill...@alum.mit.edu]

On Dec 20, 2:58 am, APN <palm...@yahoo.com> wrote:
> I use starkit::topdir in a similar fashion on Windows without any
> issues. Are you doing a
>
> package require starkit
> starkit::startup
>
> in your main.tcl file at the root of the starkit?

Yes, I am.

Jeff Godrey wrote:

> Do the other environments you mentioned testing use the Tk-based version of
> tk_getOpenFile, which does recognize the VFS?

That might be it. I wasn't aware that there were two versions of
tk_getOpenFile.

[bill...@alum.mit.edu]

The wiki mentions something called like this as an alternative to
tk_getOpenFile. Is this what you're referring to?

set filename [::tk::dialog::file:: open arg arg..]

[peter....@gmail.com]

That is the one. Here is how I use it in the special
case when I know it is needed:

# A wrapper for tk_getOpenFile
proc myOpenFile {args} {
# When in tutorial mode, make sure the Tcl file dialog is used
# to be able to access the files in the starkit.
if {[info exists ::diff(tutorial)] && $::diff(tutorial)} {
# Only do this if tk_getOpenFile is not a proc.
if {[info procs tk_getOpenFile] eq ""} {
# If there is any problem, call the real one
if {![catch {set res [eval ::tk::dialog::file:: open
$args]}]} {
return $res
}
}
}
return [eval tk_getOpenFile $args]
}

/Peter

[Mark Janssen]

On Dec 20, 3:39 pm, Jeff Godfrey <jeff_godf...@pobox.com> wrote:

IMO this is one of the reasons why a VFS (however nice it is that Tcl
provides it) really should be provided by the OS.

Mark (will tip removal of VFS as it's an OS concern first, will tip
hell freezing over next) Janssen

[jemptymethod]

On Dec 20, 12:13 am, billpo...@alum.mit.edu wrote:
>
> Can anyone explain this? Does ::starkit::topdir not exist on Vista?

I ran into essentially your same problem earlier this month (http://
groups.google.com/group/comp.lang.tcl/browse_thread/thread/
f009d0b3026d6c38#) though on a Mac. And as explained above in this
thread, it has to do with starkits containing a VFS (virtual file
system), and the tk_getOpenFile widget being unable to access the VFS.

My short-term solution has been to take the following proc's posted to
this list 5 years ago by Jeff Hobbs, put them into a file I name
vfsTkFileDialogPatches.tcl and then source them; these procs
effectively replace the 3 TK file widgets with the same names, so you
just use them like you would the original. Note however you will lose
the look and feel native to your operating system and end up with the
much disparaged TK look and feel; to do better from an aesthetic
standpoint you will have to look into changing options
to ::tk::dialog::file::

proc ::tk_getOpenFile {args} {
return [eval ::tk::dialog::file:: open $args]
}
proc ::tk_getSaveFile {args} {
return [eval ::tk::dialog::file:: save $args]
}
proc ::tk_chooseDirectory {args} {
return [eval ::tk::dialog::file::chooseDir:: $args]
}

[Donal K. Fellows]

jemptymethod wrote:
> I ran into essentially your same problem earlier this month (http://
> groups.google.com/group/comp.lang.tcl/browse_thread/thread/
> f009d0b3026d6c38#) though on a Mac.  And as explained above in this
> thread, it has to do with starkits containing a VFS (virtual file
> system), and the tk_getOpenFile widget being unable to access the VFS.

[...]

The issue is that we don't tell the OS about the VFS (I've no idea how
that could work!) and we don't have any control over how the native
dialogs get their file listings. As you mention, the fix is to use the
dialog that's used on classic Unix, which is fully Tcl-scripted.

Donal.

[APN]

The scripted dialog looks so incongruous and downright ugly on an XP
desktop, I would (only half-joking) consider making the vfs available
to native Explorer dialogs through Webdav. All it takes :-) is some
glue (google webdav tcl) since Windows has a webdav file redirector
built in.

OK, there are security issues to consider but I'm told on Windows
looks count more than security :-)

/Ashok

[Uwe Klein]

Donal K. Fellows wrote:
> jemptymethod wrote:
>
>>I ran into essentially your same problem earlier this month (http://
>>groups.google.com/group/comp.lang.tcl/browse_thread/thread/
>>f009d0b3026d6c38#) though on a Mac. And as explained above in this
>>thread, it has to do with starkits containing a VFS (virtual file
>>system), and the tk_getOpenFile widget being unable to access the VFS.
>
> [...]
>
> The issue is that we don't tell the OS about the VFS (I've no idea how
> that could work!) and we don't have any control over how the native

Farnsworth would mandate:

fuse it!

tclfuse did/does this : export the (tcl)vfs to the underlying OS.

uwe

[jemptymethod]

On Dec 24, 9:30 am, APN <palm...@yahoo.com> wrote:
>
> The scripted dialog looks so incongruous and downright ugly on an XP
> desktop

I'd like to know how Brian Oakley mocked up the file dialog he used as
a screenshot for the following answer on stackoverflow....it doesn't
look half bad....this is what I was alluding to when I said that
apparently you can make the pure Tk file dialogs look better

http://stackoverflow.com/questions/349409/why-are-tk-guis-considered-ugly#349792

[Donal K. Fellows]

jemptymethod wrote:
> I'd like to know how Brian Oakley mocked up the file dialog he used as
> a screenshot for the following answer on stackoverflow....it doesn't
> look half bad....this is what I was alluding to when I said that
> apparently you can make the pure Tk file dialogs look better
>
> http://stackoverflow.com/questions/349409/why-are-tk-guis-considered-ugly#349792

There's an open Patch (#1520742) on this which we plan to deal with
before 8.6 finishes with the beta cycle.
https://sourceforge.net/support/tracker.php?aid=1520742

Donal.

[Schelte Bron]

jemptymethod wrote:

> On Dec 24, 9:30 am, APN <palm...@yahoo.com> wrote:
>>
>> The scripted dialog looks so incongruous and downright ugly on an XP
>> desktop
>
> I'd like to know how Brian Oakley mocked up the file dialog he used as
> a screenshot for the following answer on stackoverflow....it doesn't
> look half bad....this is what I was alluding to when I said that
> apparently you can make the pure Tk file dialogs look better
>

I'm probably a little biased, but I think the tile file dialog on the wiki
(http://wiki.tcl.tk/15897) looks much better. At least I've been quite
content with it.

Schelte.