Christian Gollwitzer <aurio...@gmx.de> wrote: > Am 28.11.15 um 13:48 schrieb Ulli Horlacher: > > Christian Gollwitzer <aurio...@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: horlac...@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/ -- https://mail.python.org/mailman/listinfo/python-list