askopenfilename()

[Ulli Horlacher]

Christian Gollwitzer <auriocus at gmx.de> wrote:

> Am 28.11.15 um 13:48 schrieb Ulli Horlacher:
> > Christian Gollwitzer <auriocus at gmx.de> wrote:
> >> Many problems would simply go away if you wrote the whole thing as a GUI
> >> program.
> >
> > Too much hassle.
> > The predecessor was a Perl/Tk program and I have had to invest 90% of the
> > programming work into the GUI handling. No fun at all.
> 
> As I see it, the program consists only of user interface - or is there 
> any "algorithm" working behinds the scenes?

There is a lot of "algorithms", about 50 kB of code:
- resuming upload and download after link failures
- sending multiple files as zip or tar containers
- deleting files
- configuring login
- handling HTTP proxy
- many other things...


> Maybe you could pass the task on to somebody who enjoys GUI programming?

No, I then have to maintain it. I do not like to support foreign code. I
was in this situation already. The client was written in Java, which I do
not know. I have had to throw it away some day, because I was not able to
fix the bugs.

Therefore I started to write the new client fexit in Python.
Here we are :-)


> > This is only one of the tasks. The main menu looks:
> >
> > [s]  send a file or directory
> > [g]  get a file
> > [c]  change login data (user, server, auth-ID)
> > [l]  login with webbrowser
> > [u]  update fexit
> > [h]  help
> > [q]  quit
> 
> All of this is easily integrated into a GUI like the one I posted (have 
> you tried it?)

As I wrote: I have done this already with Perl/Tk and it was HASSLE.
No fun at all.


> IMO the most common GUI pattern for this kind of thing is a side-by-side
> view of the directories on the server and on the client

There is no directory view on server side.


> For an experienced GUI script writer it'll take a weekend to get the
> basics running.

I am not even a beginner GUI script writer and I do not want to become one.
GUIs are most superfluous and delay the work flow.


> for guided user input, an interface which prompts the user for input has
> never been a good solution. You have to work very hard to make that
> convenient. 

This is easy, because they have no alternative :-)


> Have a look at lftp, for instance. 

Yes. Horrible user interface and even more horrible to program :-}


> A (still) alternative solution would be an interface to the OS to make 
> it a remote mounted folder 

There are no remote folders.


> (works for WebDAV on any modern OS, for instance) or a daemon, which
> watches and synchronizes a directory (this is how Dropbox works).

A VERY bad idea, if you have to send TB files.


> This way it feels much more integrated to the user 

It shall not look integrated. The user should think before using it.


> they can use whatever file manager they like to do the transfer

There are no file manager which supports the F*EX protocol.
Therefore I am forced to write my own clients.
I am a lazy guy: if there is already a program, I will happily use it.
Only if there is none, I program it by myself.


> or even "save" from any application (like Word, Firefox, ...) into the
> remote folder.

There are no remote folders.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher at tik.uni-stuttgart.de
Universitaet Stuttgart         Tel:    ++49-711-68565868
Allmandring 30a                Fax:    ++49-711-682357
70550 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/