Menu
▾
▴
mlterm-dev-en
|
From: Ian W. <ia...@ex...> - 2005-01-01 21:47:52
|
I'm developing a curses-based UI library for python (http://excess.org/urwid/) and I've noticed that when I call start_color the cursor in mlterm becomes invisible. Calling curs_set to enable the cursor doesn't have any effect. The same thing happens with the curses demos included in the python package (found under examples/Demo/curses). Demos that use start_color have an invisible cursor. I'm running Debian Sid and I've tested with mlterm 2.8.0 and 2.9.1, and python 2.1 and 2.3. Any ideas? |
|
From: MINAMI H. <mi...@mi...> - 2005-01-02 00:59:45
|
On Sat, 2005-01-01 at 16:48 -0500, Ian Ward wrote: > I'm developing a curses-based UI library for python > (http://excess.org/urwid/) and I've noticed that when I call start_color > the cursor in mlterm becomes invisible. Calling curs_set to enable the > cursor doesn't have any effect. ... > I'm running Debian Sid and I've tested with mlterm 2.8.0 and 2.9.1, and > python 2.1 and 2.3. In the days of 2.8.0, mlterm did not support changing cursor visibility and curs_set should have no effect on it. After 2.9.0, or 2004/05 in CVS, that should work. i.e. echo -e "\033[?25l" or tput civis makes cursor invisible and echo -e "\033[?25h" or tput cnorm reverts it. So your problem occurs both of them, it seems to be in the color for drawing cursor not in the cursor state. I couldn't find a demo that uses "start_color" under python2.3-2.3.4/Demo/curses and not sure what the problem is. Could you prepare some tiny test case? BTW, cursor state(invis/norm) currently doesn't save/restored and are sheared between normal/alternate screen. Are they intentional ?> Sato san regards, -- minami <mi...@mi...> |
|
From: Ian W. <ia...@ex...> - 2005-01-02 01:56:18
|
On Sun, 2005-02-01 at 09:58 +0900, MINAMI Hirokazu wrote:
> I couldn't find a demo that uses "start_color" under
> python2.3-2.3.4/Demo/curses and not sure what the problem is.
> Could you prepare some tiny test case?
Ah, you're right. The demos call curses.wrapper, which calls
start_color for color terminals.
Here is a test case:
-----------------------
#!/usr/bin/python
import curses
import sys
s = curses.initscr()
curses.start_color()
s.addstr("No cursor")
s.refresh()
sys.stdin.read(1)
curses.endwin()
-----------------------
Without start_color the cursor is visible.
> BTW, cursor state(invis/norm) currently doesn't save/restored
> and are sheared between normal/alternate screen.
> Are they intentional ?> Sato san
I'm not sure what you mean by "intentional". Would you rephrase the
question?
Ian
|
|
From: MINAMI H. <mi...@mi...> - 2005-01-02 04:44:51
|
On Sat, 2005-01-01 at 20:57 -0500, Ian Ward wrote: > On Sun, 2005-02-01 at 09:58 +0900, MINAMI Hirokazu wrote: > > I couldn't find a demo that uses "start_color" under > > python2.3-2.3.4/Demo/curses and not sure what the problem is. > > Could you prepare some tiny test case? > > Ah, you're right. The demos call curses.wrapper, which calls > start_color for color terminals. > > Here is a test case: ... I've tried your script on the default setting and on "mlterm -f white -b black". When default color (black on white) is used, the cursor couldn't be seen because it's rendered by black on black background. In the latter case (white on black), I could see white rectangle. These result seems to be identical to xterm/rxvt. Are you requesting to draw cursor differently to be always visible? I'm afraid it may rather annoying in some cases. > Without start_color the cursor is visible. > > > BTW, cursor state(invis/norm) currently doesn't save/restored > > and are sheared between normal/alternate screen. > > Are they intentional ?> Sato san > > I'm not sure what you mean by "intentional". Would you rephrase the > question? Don't mind. In this case, as far as cursor visibility is not touched, It shouldn't matter anyway. minami |
|
From: Ian W. <ia...@ex...> - 2005-01-02 06:15:40
|
On Sun, 2005-02-01 at 13:44 +0900, MINAMI Hirokazu wrote: > I've tried your script on the default setting > and on "mlterm -f white -b black". > > When default color (black on white) is used, the cursor couldn't > be seen because it's rendered by black on black background. > In the latter case (white on black), I could see white rectangle. > These result seems to be identical to xterm/rxvt. > > Are you requesting to draw cursor differently to be always visible? > I'm afraid it may rather annoying in some cases. xterm always flips the foreground and background colors of the character the cursor is on (white on blue becomes blue on white etc.) rxvt uses black on white if the background of the character the cursor is on is black, otherwise it uses white on black. I don't want to tell people "Never use a black background because mlterm users won't be able to see the cursor". I'm sorry if this is annoying. Ian BTW, I'm hoping to add support for all mlterm's supported encodings to Urwid (http://excess.org/urwid/). Can you recommend any good texts that I may use as a reference? At the moment I am using: http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html |
|
From: MINAMI H. <mi...@mi...> - 2005-01-04 02:49:43
Attachments:
mlterm_curscolor.diff
|
On Sun, 2005-01-02 at 01:16 -0500, Ian Ward wrote: > xterm always flips the foreground and background colors of the character > the cursor is on (white on blue becomes blue on white etc.) rxvt uses > black on white if the background of the character the cursor is on is > black, otherwise it uses white on black. I've prepared a patch for the xterm-like scheme (attached). i.e. make cursor's fg/bg color be taken from the character under cursor. When cursor's fg/bg color was specified in your config file or by a command line option, Those color would be used as they had been. Though cursor would be remain invisible in a sick situation (like the "black on black" case), it seems acceptable for me. > BTW, I'm hoping to add support for all mlterm's supported encodings to > Urwid (http://excess.org/urwid/). Can you recommend any good texts that > I may use as a reference? At the moment I am using: > http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html Sorry, I couldn't find the better one. Just curious: what function are you going to add? I'm assuming that the knowledge of encoding should not be neccesary to simply display some strings. -- minami |
|
From: Ian W. <ia...@ex...> - 2005-01-10 14:13:02
|
On Tue, 2005-04-01 at 11:49 +0900, MINAMI Hirokazu wrote:
> On Sun, 2005-01-02 at 01:16 -0500, Ian Ward wrote:
>
> > xterm always flips the foreground and background colors of the character
> > the cursor is on (white on blue becomes blue on white etc.) rxvt uses
> > black on white if the background of the character the cursor is on is
> > black, otherwise it uses white on black.
>
> I've prepared a patch for the xterm-like scheme (attached).
> i.e. make cursor's fg/bg color be taken from the character under cursor.
I tried the patch on 2.9.1 and the cvs version, but I still can't see a
cursor in my small test case. I couldn't find a config file setting for
the cursor colour. Any Ideas?
-------------------------
#!/usr/bin/python
import curses
import sys
s = curses.initscr()
curses.start_color()
s.addstr("No cursor")
s.refresh()
sys.stdin.read(1)
curses.endwin()
|
|
From: MINAMI H. <mi...@mi...> - 2005-01-11 13:42:29
|
On Mon, 2005-01-10 at 09:14 -0500, Ian Ward wrote: > On Tue, 2005-04-01 at 11:49 +0900, MINAMI Hirokazu wrote: > > I've prepared a patch for the xterm-like scheme (attached). > > i.e. make cursor's fg/bg color be taken from the character under cursor. > > I tried the patch on 2.9.1 and the cvs version, but I still can't see a > cursor in my small test case. I couldn't find a config file setting for > the cursor colour. Any Ideas? Hmm, I could see a cursor in "white" after the message "No cursor". Could you try to display some colored chars ex) tput cup 2 0;echo -e "\033[31mcolored_cursor";tput cup 0 0 and see what happened if you move a cursor into them? Though You can specify fg/bg color for cursor by adding corresponding entries (cursor_fg_color/cursor_bg_color) to your ~/.mlterm/main, my patch would do nothing in that case since the color you set, not the color of a character under cursor, would be always used. -- minami |
|
From: Ian W. <ia...@ex...> - 2005-01-12 03:10:54
|
On Tue, 2005-11-01 at 22:42 +0900, MINAMI Hirokazu wrote: > > I tried the patch on 2.9.1 and the cvs version, but I still can't see a > > cursor in my small test case. I couldn't find a config file setting for > > the cursor colour. Any Ideas? > > Hmm, I could see a cursor in "white" after the message "No cursor". > Could you try to display some colored chars > ex) > tput cup 2 0;echo -e "\033[31mcolored_cursor";tput cup 0 0 > and see what happened if you move a cursor into them? Yes, the cursor turns red when I move it over the red text. Also, if I move the cursor over the "No cursor" text in the curses program it appears as a white cursor. It seems that if I put it anywhere else on the screen it is invisible (black on black?), including when I put the cursor on the space in between "No" and "cursor". xterm and rxvt seem to default to white on black for the entire screen in my test case. gnome-terminal uses light gray on black. Ian |
|
From: Seiichi S. <ss...@sh...> - 2005-01-12 20:03:01
Attachments:
mlterm_curscolor2.diff
|
Hi Ian, On Tue, Jan 11, 2005 at 10:12:26PM -0500, Ian Ward wrote: > > > I tried the patch on 2.9.1 and the cvs version, but I still can't see a > > > cursor in my small test case. I couldn't find a config file setting for > > > the cursor colour. Any Ideas? I made a little change to the patch. Please try it again. Regards, -- Seiichi |
|
From: Seiichi S. <ss...@sh...> - 2005-01-09 11:00:08
|
On Sun, Jan 02, 2005 at 09:58:35AM +0900, MINAMI Hirokazu wrote: > BTW, cursor state(invis/norm) currently doesn't save/restored > and are sheared between normal/alternate screen. > Are they intentional ?> Sato san Those are not intentional. I submitted: <https://sourceforge.net/tracker/index.php?func=detail&aid=1098851&group_id=40891&atid=429201> -- Seiichi |
|
From: Ambrose Li <ac...@ad...> - 2005-01-02 06:25:54
|
On Sun, Jan 02, 2005 at 01:16:24AM -0500, Ian Ward wrote: > xterm always flips the foreground and background colors of > the character the cursor is on (white on blue becomes blue on > white etc.) rxvt uses black on white if the background of the > character the cursor is on is black, otherwise it uses white > on black. Old versions of xterm and rxvt both can have the invisible cursor problem, but can be worked around because they accept a command-line option to set the cursor colour (I usually set it to orange or other equally improbable colour). I don't think this is possible with mlterm. |
|
From: Mike F. <mf...@su...> - 2005-01-02 16:33:55
|
Ambrose Li <ac...@ad...> さんは書きました: > Old versions of xterm and rxvt both can have the invisible > cursor problem, but can be worked around because they accept a > command-line option to set the cursor colour (I usually set it > to orange or other equally improbable colour). I don't think > this is possible with mlterm. You can set the cursor colour in mlterm as well, either with command line options or in ~/.mlterm/main: mike@kibou:~$ grep cursor .mlterm/main cursor_fg_color=white cursor_bg_color=blue mike@kibou:~$ -- Mike FABIAN <mf...@su...> http://www.suse.de/~mfabian 睡眠不足はいい仕事の敵だ。 |
|
From: MINAMI H. <mi...@mi...> - 2005-01-04 03:03:48
|
On Sun, 2005-01-02 at 17:33 +0100, Mike FABIAN wrote: > Ambrose Li <ac...@ad...> さんは書きました: > > > Old versions of xterm and rxvt both can have the invisible > > cursor problem, but can be worked around because they accept a > > command-line option to set the cursor colour (I usually set it > > to orange or other equally improbable colour). I don't think > > this is possible with mlterm. > > You can set the cursor colour in mlterm as well, either with > command line options or in ~/.mlterm/main: > > mike@kibou:~$ grep cursor .mlterm/main > cursor_fg_color=white > cursor_bg_color=blue > mike@kibou:~$ The cursor color can be also configured dynamically -- though it's not accessible from GUI configuration helper. If you have recent version of "mlcc", you can do $ mlcc cursor_bg_color orange to make your cursor orange and $ mlcc cursor_bg_color none to revert to the default. (or, if you really want, you can send a escape sequence by hand. see mlterm/doc/en/PROTOCOLS) -- minami |
|
From: Ian W. <ia...@ex...> - 2005-01-04 06:21:33
|
On Tue, Jan 04, 2005 at 11:49:21AM +0900, MINAMI Hirokazu wrote: > On Sun, 2005-01-02 at 01:16 -0500, Ian Ward wrote: > > > xterm always flips the foreground and background colors of the character > > the cursor is on (white on blue becomes blue on white etc.) rxvt uses > > black on white if the background of the character the cursor is on is > > black, otherwise it uses white on black. > > I've prepared a patch for the xterm-like scheme (attached). > i.e. make cursor's fg/bg color be taken from the character under cursor. Thanks! I will try it soon. > > BTW, I'm hoping to add support for all mlterm's supported encodings to > > Urwid (http://excess.org/urwid/). Can you recommend any good texts that > > I may use as a reference? At the moment I am using: > > http://www.debian.org/doc/manuals/intro-i18n/ch-codes.en.html > > Sorry, I couldn't find the better one. > > Just curious: what function are you going to add? > I'm assuming that the knowledge of encoding should not > be neccesary to simply display some strings. I need to know the encoding for things like word wrapping and cursor movement in edit boxes (sometimes the cursor should move 2 spaces). I will also have to know how the terminal will behave when I send it combining characters and BiDi text. I don't support BiDi yet -- That will be an interesting challenge. Ian |
|
From: MINAMI H. <mi...@mi...> - 2005-01-09 14:22:20
|
On Tue, 2005-01-04 at 01:21 -0500, Ian Ward wrote: > > Just curious: what function are you going to add? > > I'm assuming that the knowledge of encoding should not > > be neccesary to simply display some strings. > > I need to know the encoding for things like word wrapping and cursor > movement in edit boxes (sometimes the cursor should move 2 spaces). I > will also have to know how the terminal will behave when I send it > combining characters and BiDi text. I don't support BiDi yet -- That > will be an interesting challenge. As far as, I know there are no standard which defines "proper" behavior of a terminal for BiDi/full-width/combining etc. For mlterm, there are many options to do what is expected: --comb --dyncomb --multicol --ac --bi Since most of these options are dynamically configurable, it's very difficult to know what mlterm will do for a application running on it. Maybe you can refer the way of mined (http://towo.net/mined/, an unicode capable text editor runs on a terminal). If mlterm was the only terminal in the world, we could take another approach. i.e. change the mlterm's configuration as your library want. But that won't work other terminal emulators... -- minami |
|
From: Seiichi S. <ss...@sh...> - 2005-01-10 11:31:27
|
On Sun, Jan 09, 2005 at 08:00:02PM +0900, Seiichi SATO wrote: > On Sun, Jan 02, 2005 at 09:58:35AM +0900, > MINAMI Hirokazu wrote: > > > BTW, cursor state(invis/norm) currently doesn't save/restored > > and are sheared between normal/alternate screen. > > Are they intentional ?> Sato san > > Those are not intentional. > I submitted: > > <https://sourceforge.net/tracker/index.php?func=detail&aid=1098851&group_id=40891&atid=429201> TD's xterm(197): - saved/restored .... no - shared between normal/alternate screen .... yes rxvt 2.6.4: - saved/restored .... no - shared between normal/alternate screen .... no mlterm (2.9.1 pre/cvs-1.806) - saved/restored .... no - shared between normal/alternate screen .... yes In the implementation of cursor state, it seems to be compatible with TD's xterm. -- Seiichi |
|
From: MINAMI H. <mi...@mi...> - 2005-01-15 04:36:45
|
On Mon, 2005-01-10 at 20:31 +0900, Seiichi SATO wrote: > TD's xterm(197): > - saved/restored .... no > - shared between normal/alternate screen .... yes > > rxvt 2.6.4: > - saved/restored .... no > - shared between normal/alternate screen .... no > > mlterm (2.9.1 pre/cvs-1.806) > - saved/restored .... no > - shared between normal/alternate screen .... yes > > In the implementation of cursor state, it seems to be compatible > with TD's xterm. Thanks for checking. The rxvt's behavior may be desireble for some purposes since tere is no way to know current cursor visibility from an application running on a terminal. However, it should be almost whenever enough to simply revert cursor to the normal state after drawing finished. So I'd like to leep current implementation for a while. -- minami |
|
From: Ian W. <ia...@ex...> - 2005-01-13 01:56:39
|
On Thu, 2005-13-01 at 05:02 +0900, Seiichi SATO wrote: > I made a little change to the patch. > Please try it again. Perfect. Removing that optimization fixed it. Perhaps the problem could also be solved by just temporarily disabling that optimization when clearing the screen. Thanks! Ian |
|
From: MINAMI H. <mi...@mi...> - 2005-01-14 03:20:45
|
On Wed, Jan 12, 2005 at 08:58:19PM -0500, Ian Ward wrote: > On Thu, 2005-13-01 at 05:02 +0900, Seiichi SATO wrote: > > I made a little change to the patch. > > Please try it again. > > Perfect. Removing that optimization fixed it. Perhaps the problem > could also be solved by just temporarily disabling that optimization > when clearing the screen. The optimization, unify all space's fg color to be default one, seems to be no longer useful for me. I'm going to drop it and introduce another optimization, assume we can draw blank characters in whatever color we want, into text rendering subsystem. Comments? P.S. in unicode, 0x20 is not the only blank character. It may better to apply same optimization anyway for other characters like 0x3000<IDEOGRAPHIC SPACE>, 0x2002<EN SPACE> etc. Does anyone have a list of them? -- minami |
|
From: Seiichi S. <ss...@sh...> - 2005-01-14 14:25:41
|
On Fri, Jan 14, 2005 at 12:20:21PM +0900, MINAMI Hirokazu wrote: > The optimization, unify all space's fg color to be default one, > seems to be no longer useful for me. I think so too. > I'm going to drop it and introduce another optimization, > assume we can draw blank characters in whatever color we want, > into text rendering subsystem. That sounds good. Some people said the scrolling speed of mlterm is slow. To solve this proble, we need to replace --enable-optimize-redrawing with another optimization. Designing new rendering model is not easy. But I hope it will be placed top of TODO for mlterm-3.x. Of course, I will cooperate with you. -- Seiichi |
|
From: MINAMI H. <mi...@mi...> - 2005-01-23 07:29:55
|
On Wed, 2005-01-12 at 20:58 -0500, Ian Ward wrote: > On Thu, 2005-13-01 at 05:02 +0900, Seiichi SATO wrote: > > I made a little change to the patch. > > Please try it again. > > Perfect. Removing that optimization fixed it. Perhaps the problem > could also be solved by just temporarily disabling that optimization > when clearing the screen. Thanks for tesing. I've commited modified version of the patch to CVS. (The cursors sould looks better when mlterm's windows were unfocused) -- minami |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X