Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98951 > unrolled thread

non-blocking getkey?

Back to article view | Back to comp.lang.python

Contents

  non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 08:39 +0000
    Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-11-18 10:14 +0100
      Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 10:39 +0000
        Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 11:01 +0000
          Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-11-18 12:17 +0100
          Re: non-blocking getkey? Terry Reedy <tjreedy@udel.edu> - 2015-11-18 07:26 -0500
            Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:06 +0000
              Re: non-blocking getkey? Chris Angelico <rosuav@gmail.com> - 2015-11-19 00:24 +1100
                Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:57 +0000
              Re: non-blocking getkey? Steven D'Aprano <steve@pearwood.info> - 2015-11-19 00:38 +1100
                Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 13:51 +0000
                  Re: non-blocking getkey? Chris Angelico <rosuav@gmail.com> - 2015-11-19 01:01 +1100
                  Re: non-blocking getkey? Jussi Piitulainen <harvesting@makes.invalid> - 2015-11-18 16:13 +0200
          Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-18 16:50 +0000
            Re: non-blocking getkey? Terry Reedy <tjreedy@udel.edu> - 2015-11-18 12:55 -0500
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-19 15:48 +0000
                Re: non-blocking getkey? Michael Torrie <torriem@gmail.com> - 2015-11-19 09:31 -0700
                Re: non-blocking getkey? eryksun <eryksun@gmail.com> - 2015-11-20 02:43 -0600
                  Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-23 17:01 +0000
                    askopenfilename() (was: Re: non-blocking getkey?) Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 10:29 +0000
                      Re: askopenfilename() Christian Gollwitzer <auriocus@gmx.de> - 2015-11-28 12:45 +0100
                        Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 12:48 +0000
                          Re: askopenfilename() Christian Gollwitzer <auriocus@gmx.de> - 2015-11-28 14:34 +0100
                            Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 16:45 +0000
                          Re: askopenfilename() Laura Creighton <lac@openend.se> - 2015-11-28 17:02 +0100
                      Re: askopenfilename() Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-11-28 16:05 +0000
          Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 08:28 +0000
            Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-12-10 09:54 +0100
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 10:26 +0000
            Re: non-blocking getkey? Christian Gollwitzer <auriocus@gmx.de> - 2015-12-10 09:57 +0100
              Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 10:40 +0000
            Re: non-blocking getkey? Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2015-12-10 15:52 +0000
      Re: non-blocking getkey? eryksun <eryksun@gmail.com> - 2015-11-18 12:24 -0600

Page 2 of 2 — ← Prev page 1 [2]

#99660 — Re: askopenfilename()

Am 28.11.15 um 11:29 schrieb Ulli Horlacher:
> One of my Windows test users reports, that the file dialog window of
> askopenfilename() starts behind the console window and has no focus.
> On Linux (XFCE) I do not have this problem.
>
> I start it with:
>
>    Tk().withdraw()
>    file = askopenfilename(title='select a file',initialdir=HOME)
>    set_window_focus() # give focus back to console window
>
> Can one force askopenfilename() to start in foreground with focus?

I can't test it right now, but I think it /should/ go into the 
foreground by itself. For a toplevel window, which you create manually, 
there is a lift() method which asks the OS to move the window to the 
top. But on Windows, this file dialog is a native call and cannot be 
influenced that much.

I see two thingd:

1) Tk().withdraw()

- this seems odd to me, because you don't keep a reference to the Tk 
object around. Better do

	root=Tk()
	roo.withdraw()

2) Maybe it helps if you inject an update() after the withdraw(), maybe not

	root.update()

3) I can confirm, that also on OSX the file dialog does not raise above 
the console window, though it is not as bad because the dialog window is 
muhc bigger then the console window.

I think that you are curing a lot of symptoms with the focus setting to 
the console etc. Many problems would simply go away if you wrote the 
whole thing as a GUI program. If I understand correctly, what you want - 
a program to select files and folders to upload to your server - then 
this would not be that much more work than the CLI with input() which 
you are writing, and definitely less work to get it correct than the 
plastering of the symptoms.

For example, a very simple approach would use a listbox with a + and a - 
button. upon hitting - (or the delete key), you delete the selected 
entries. Upon hitting +, you pop up the file selection dialog. upon 
hitting a Go button, you send the files to the server. A minimalistic 
version of it is included below. That is less then 50 lines of code, 
including comments, without all the focus problems, providing a standard 
desktop GUI metaphor. I haven't seen your command line code, but I doubt 
that it is significantly simpler.

Of course, the code below can still use a great deal of polishing, like 
scrollbars for the listbox, allowing multiple selection both for the 
file dialog and the listbox, nice icons for the buttons, trapping the 
close button on the main window with an "are you sure?"-type question, 
maybe wrapping it up in a class, a progress bar during the upload and a 
way to interrupt it... which is left as an exercise to the reader.

	Christian

=================================
import Tkinter as tk, tkFileDialog as fd, ttk
from Tkinter import N,S,W,E
# create one ttk::frame to fill the main window
root=tk.Tk()
main=ttk.Frame(master=root)
# tell the pack geometry manager to completely
# fill the toplevel with this frame
main.pack(fill=tk.BOTH, expand=1)

# now create a listbox and a button frame
lb=tk.Listbox(master=main)
bf=ttk.Frame(master=main)

# use the grid manager to stack them, whereby
# the listbox should expand
lb.grid(row=0, column=0, sticky=(N,S,E,W))
bf.grid(row=1, column=0, sticky=(N,S,E,W))
main.rowconfigure(0, weight=1)
main.columnconfigure(0, weight=1)

def addfile():
	filename=fd.askopenfilename()
	if filename:
		lb.insert(tk.END, filename)

def remove(*args):
	sel=lb.curselection()
	if sel:
		lb.delete(sel)

def submit():
	print("Submitting files:")
	for filename in lb.get(0,tk.END):
		print("Sending %s"%filename)

# create the three buttons
btnplus=ttk.Button(master=bf, text="+", command=addfile)
btnminus=ttk.Button(master=bf, text="-", command=remove)
btngo=ttk.Button(master=bf, text="Submit", command=submit)

btnplus.pack(side=tk.LEFT)
btnminus.pack(side=tk.LEFT)
btngo.pack(side=tk.LEFT)

# bind also the delete and Backspace keys
lb.bind('<Delete>', remove)
lb.bind('<BackSpace>', remove)

root.mainloop()
===================================================

[toc] | [prev] | [next] | [standalone]

#99661 — Re: askopenfilename()

Christian Gollwitzer <auriocus@gmx.de> wrote:

> Am 28.11.15 um 11:29 schrieb Ulli Horlacher:
> > One of my Windows test users reports, that the file dialog window of
> > askopenfilename() starts behind the console window and has no focus.
> > On Linux (XFCE) I do not have this problem.
> >
> > I start it with:
> >
> >    Tk().withdraw()
> >    file = askopenfilename(title='select a file',initialdir=HOME)
> >    set_window_focus() # give focus back to console window
> >
> > Can one force askopenfilename() to start in foreground with focus?
> 
> I can't test it right now, but I think it /should/ go into the 
> foreground by itself. 

This is what I think, too :-)
But my test user reports me, it is not so.


> I see two thingd:
> 
> 1) Tk().withdraw()
> 
> - this seems odd to me, because you don't keep a reference to the Tk 
> object around. 

I thought, I need it for Tk initialization.
But true, it is superfluous


> I think that you are curing a lot of symptoms with the focus setting to 
> the console etc.

This is done after the file selection window is closed. This works.


> 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.
Now, with fexit in Python, I skipped most of these problems.
The only GUI part is the file selection.


> If I understand correctly, what you want - a program to select files and
> folders to upload to your server 

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

(with more features to come in the future)

And the CLI:

framstag@juhu:~: ./fexit.py -h
usage: fexit [-C "comment"] [-a container] file(s) recipient[,...]
example: fexit flupp.avi framstag@rus.uni-stuttgart.de
example: fexit -C "more data" -a labdata *.png x1@flupp.org,x2@flupp.org

usage: fexit FEX-download-URL
example: fexit http://fex.rus.uni-stuttgart.de/fop/jHn34yp7/flupp.avi


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#99663 — Re: askopenfilename()

Am 28.11.15 um 13:48 schrieb Ulli Horlacher:
> Christian Gollwitzer <auriocus@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? Maybe you could pass the 
task on to somebody who enjoys GUI programming?

> Now, with fexit in Python, I skipped most of these problems.
> The only GUI part is the file selection.
>
>
>> If I understand correctly, what you want - a program to select files and
>> folders to upload to your server
>
> 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?), either as a button or as a menu entry. 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, and a button (or 
drag'n'drop) to move files between both views. I understand this is not 
as easy as the script posted by me - nonetheless quite doable. For an 
experienced GUI script writer it'll take a weekend to get the basics 
running.

> (with more features to come in the future)
>
> And the CLI:
>
> framstag@juhu:~: ./fexit.py -h
> usage: fexit [-C "comment"] [-a container] file(s) recipient[,...]
> example: fexit flupp.avi framstag@rus.uni-stuttgart.de
> example: fexit -C "more data" -a labdata *.png x1@flupp.org,x2@flupp.org
>
> usage: fexit FEX-download-URL
> example: fexit http://fex.rus.uni-stuttgart.de/fop/jHn34yp7/flupp.avi
>

This part should probably stay as it is. For a command line tool, an 
scp-like interface seems well-fitting. But 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. Have a 
look at lftp, for instance. In the end, real GUI programming will be 
easier (and more accessible)

A (still) alternative solution would be an interface to the OS to make 
it a remote mounted folder (works for WebDAV on any modern OS, for 
instance) or a daemon, which watches and synchronizes a directory (this 
is how Dropbox works). This way it feels much more integrated to the 
user - they can use whatever file manager they like to do the transfer, 
or even "save" from any application (like Word, Firefox, ...) into the 
remote folder.

	Christian

[toc] | [prev] | [next] | [standalone]

#99669 — Re: askopenfilename()

Christian Gollwitzer <auriocus@gmx.de> wrote:

> Am 28.11.15 um 13:48 schrieb Ulli Horlacher:
> > Christian Gollwitzer <auriocus@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@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/

[toc] | [prev] | [next] | [standalone]

#99665 — Re: askopenfilename()

Maybe Wei Li Jiang's  hack will work for you?
http://stackoverflow.com/questions/3375227/how-to-give-tkinter-file-dialog-focus

But then see if it works under MacOS.  I fear it will not.

Laura

[toc] | [prev] | [next] | [standalone]

#99666 — Re: askopenfilename()

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> One of my Windows test users reports, that the file dialog window of
> askopenfilename() starts behind the console window and has no focus.

I have got a followup: this happens only with Windows XP, not with Windows
7. Therefore I will ignore this problem :-)


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#100221

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> > But... is there a windows program with which one can select files and the
> > result is written to STDOUT?
> 
> Found it:
> 
>         from Tkinter import Tk
>         from tkFileDialog import askopenfilename
> 
>         Tk().withdraw()
>         file = askopenfilename()

My users do not like it :-(
They want to drag&drop files.
Therefore I have added it as another option to enter files:

	[f] select a file
	[d] select a directory
	[e] enter a file or directory (with drag&drop or copy&paste)

With [f] starts askopenfilename and [d] starts askdirectory

The problem with [e] is: my users do not press ENTER after pasting.

My idea now is: instead of raw_input() I use a get_paste() function, which
reads input character for input character and after a (say) 1 s timeout it
returns the string. Pasting a string with the mouse is rather fast, there
should be no big delay between the characters.

How can I implement such a get_paste() function?
I need a non-blocking getkey() function.

It must work on Windows and Linux.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#100222

Am 10.12.15 um 09:28 schrieb Ulli Horlacher:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>> Found it:
>>
>>          from Tkinter import Tk
>>          from tkFileDialog import askopenfilename
>>
>>          Tk().withdraw()
>>          file = askopenfilename()
>
> My users do not like it :-(
> They want to drag&drop files.
> Therefore I have added it as another option to enter files:
>
> 	[f] select a file
> 	[d] select a directory
> 	[e] enter a file or directory (with drag&drop or copy&paste)


Well I know that you won't take my advice but.....

There are standard protocols for drag'n'drop of files and folders on all 
three major platforms. Tk supports this using the optional TkDND module, 
which unfortunately isn't installed with a standard Python distribution. 
Beware there is a "Tkdnd" Python module which implements local 
Drag'n'drop only; you need the "real thing" from here

	http://sourceforge.net/projects/tkdnd/

plus the correct Python bindings: Maybe this is the correct one: 
http://osdir.com/ml/python.tkinter/2005-07/msg00000.html
I'm not sure - never used it from Python, only from Tcl. Using "the real 
thing" also allows you to accept multiple files/drectories dragged from 
the system file manager. Of course, you need a Tk main window to 
implement this, which you refused earlier.

> With [f] starts askopenfilename and [d] starts askdirectory
>
> The problem with [e] is: my users do not press ENTER after pasting.
>
> My idea now is: instead of raw_input() I use a get_paste() function, which
> reads input character for input character and after a (say) 1 s timeout it
> returns the string. Pasting a string with the mouse is rather fast, there
> should be no big delay between the characters.
>
> How can I implement such a get_paste() function?
> I need a non-blocking getkey() function.
>
> It must work on Windows and Linux.

Raw tty input. You'll have to write two different versions for Windows 
and Linux. Sorry I can't help with that one.

	Christian

[toc] | [prev] | [next] | [standalone]

#100225

Christian Gollwitzer <auriocus@gmx.de> wrote:

> > My users do not like it :-(
> > They want to drag&drop files.
> > Therefore I have added it as another option to enter files:
> >
> >       [f] select a file
> >       [d] select a directory
> >       [e] enter a file or directory (with drag&drop or copy&paste)
> 
> 
> Well I know that you won't take my advice but.....
> 
> There are standard protocols for drag'n'drop of files and folders on all 
> three major platforms. Tk supports this using the optional TkDND module, 
> which unfortunately isn't installed with a standard Python distribution. 

Then this is no-go.
My users cannot install any additional software.


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#100223

Am 10.12.15 um 09:28 schrieb Ulli Horlacher:
> Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
> My users do not like it :-(
> They want to drag&drop files.

Another cheap solution comes to mind: On windows, dropping files onto an 
icon on the desktop is interpreted as "launch the program with 
additional arguments", where the arguments are the file names. Maybe you 
could try interpreting the cmdline args first? I'm not so sure how it 
will work with non-ASCII characters, though. On Linux, you can probably 
also create simliar icons. The only drawback is that you start a new 
instance of your file manager each time.

	Christian

[toc] | [prev] | [next] | [standalone]

#100226

Christian Gollwitzer <auriocus@gmx.de> wrote:

> Another cheap solution comes to mind: On windows, dropping files onto an 
> icon on the desktop is interpreted as "launch the program with 
> additional arguments", where the arguments are the file names.

Ohhh... great! This helps me a lot!


> Maybe you could try interpreting the cmdline args first?

I have implemented this since the beginning of the project :-)


> I'm not so sure how it will work with non-ASCII characters, 

My users have to test it. I do not have non-ASCII filenames.

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#100240

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:

> My idea now is: instead of raw_input() I use a get_paste() function, which
> reads input character for input character and after a (say) 1 s timeout it
> returns the string. Pasting a string with the mouse is rather fast, there
> should be no big delay between the characters.
> 
> How can I implement such a get_paste() function?
> I need a non-blocking getkey() function.

I found a solution for Windows:

  print("\nCopy&paste a filename or drag&drop a file into this window")
  file = get_paste()
  print('\n"%s"' % file)


def get_paste():
  import msvcrt
  c = msvcrt.getch()
  if c == '\n' or c == '\r': return ''
  paste = c
  while msvcrt.kbhit():
    c = msvcrt.getch()
    if c == '\n' or c == '\r': break
    paste += c
  return paste

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum IZUS/TIK         E-Mail: horlacher@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/

[toc] | [prev] | [next] | [standalone]

#98993

On Wed, Nov 18, 2015 at 3:14 AM, Christian Gollwitzer <auriocus@gmx.de> wrote:
> The standard terminal on Windows is very ugly, can't resize the width, and
> pasting works only if you right-click -> paste.

The console UI is improved in Windows 10:
http://blogs.windows.com/buildingapps/2014/10/07/console-improvements-in-the-windows-10-technical-preview

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web