New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add color support for input bar #764

Merged
merged 5 commits into from Feb 5, 2018

Conversation

Projects
None yet
3 participants
@GinjaNinja32
Contributor

GinjaNinja32 commented Oct 6, 2017

This is mostly a rebase of this patch, with a few bugfixes (a segfault in gui_entry_transpose_words, and a pointer-to-int assignment).

Allows scripts to specify that ranges of characters in the input bar should be rendered in specific colors; the original intent for this was to implement a spellchecker, my use is to colorise nicks in the input bar.

Example script using this, mostly based on my rewritten colorize_nicks.pl: https://thanatos.gn32.uk/f/colorise_input.pl (I'll likely clean up the code a little and submit for scripts.irssi.org, assuming this PR gets merged)

Show outdated Hide outdated src/fe-text/gui-entry.c
Show outdated Hide outdated src/fe-text/gui-entry.c
Show outdated Hide outdated src/fe-text/gui-entry.c
Show outdated Hide outdated src/fe-text/gui-entry.c
Show outdated Hide outdated src/fe-text/gui-entry.c
@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Oct 11, 2017

Contributor

seems mostly ok, but I don't like having to use the internal colour attributes from XS -- maybe we can add in some functions to do colour code conversions between \004, % and this. And another thing: it doesn't do 24bit "true colour" (api is term_set_color2, didn't exist back then)

The more general question is if we like this implementation. Alternative would be to have in-line colours like in print text / gui prompt. But this code here is much simpler.

In general I think it would be a nice to have feature for your and the other use case

Contributor

ailin-nemui commented Oct 11, 2017

seems mostly ok, but I don't like having to use the internal colour attributes from XS -- maybe we can add in some functions to do colour code conversions between \004, % and this. And another thing: it doesn't do 24bit "true colour" (api is term_set_color2, didn't exist back then)

The more general question is if we like this implementation. Alternative would be to have in-line colours like in print text / gui prompt. But this code here is much simpler.

In general I think it would be a nice to have feature for your and the other use case

@LemonBoy

This comment has been minimized.

Show comment
Hide comment
@LemonBoy

LemonBoy Oct 11, 2017

Member

maybe we can add in some functions to do colour code conversions between \004, % and this.

What if we reuse the same parsing logic that's used for themes formats? It's not that good but at least spares us from writing another parser and having the script writers learn a new set of specifiers.

Alternative would be to have in-line colours

The principle of separation between data and metadata applies here.
A script may as well render the inline colours though, that's an interesting idea.

other use case

I'm using it to turn the whole prompt red whenever there's a cmdchar with leading rubbish, no more accidental commands for me 😃

Member

LemonBoy commented Oct 11, 2017

maybe we can add in some functions to do colour code conversions between \004, % and this.

What if we reuse the same parsing logic that's used for themes formats? It's not that good but at least spares us from writing another parser and having the script writers learn a new set of specifiers.

Alternative would be to have in-line colours

The principle of separation between data and metadata applies here.
A script may as well render the inline colours though, that's an interesting idea.

other use case

I'm using it to turn the whole prompt red whenever there's a cmdchar with leading rubbish, no more accidental commands for me 😃

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Oct 11, 2017

Contributor

I'm using it to turn the whole prompt red whenever there's a cmdchar with leading rubbish, no more accidental commands for me

if we had something more generic like in line colours then it could offer more flexibility like also in line altering of the actual displayed text. think of a blinking "warning" appended to the prompt or an in line display of spelling suggestions after the unrecognised word

Contributor

ailin-nemui commented Oct 11, 2017

I'm using it to turn the whole prompt red whenever there's a cmdchar with leading rubbish, no more accidental commands for me

if we had something more generic like in line colours then it could offer more flexibility like also in line altering of the actual displayed text. think of a blinking "warning" appended to the prompt or an in line display of spelling suggestions after the unrecognised word

@GinjaNinja32

This comment has been minimized.

Show comment
Hide comment
@GinjaNinja32

GinjaNinja32 Oct 11, 2017

Contributor

I'm not entirely sure how inline colors would work here.

Using format codes instead of ints sounds good, though. get_nick_color2 appears to return \004-style codes, so it'd be good if it accepts those - perhaps a string containing either a \cD.. code or a %#/%X## code?

I have no idea how I'd implement that, but I can take a look and poke around IRC and see if I can put something together.

Contributor

GinjaNinja32 commented Oct 11, 2017

I'm not entirely sure how inline colors would work here.

Using format codes instead of ints sounds good, though. get_nick_color2 appears to return \004-style codes, so it'd be good if it accepts those - perhaps a string containing either a \cD.. code or a %#/%X## code?

I have no idea how I'd implement that, but I can take a look and poke around IRC and see if I can put something together.

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Oct 13, 2017

Contributor

just conceptually speaking, one way to think about inline colours would be to take the input

 /whois xxx

then call a function (e.g. XS) which would change it to

[NOT COMMAND!]  /whois xxx

and that's what would then be visible. This would demand the callback to transform "input" into "displayed input" to be called at basically every change to the prompt

colours would then be realised by "returning"

%R /whois xxx

from the signal handler. There /should/ be some methods in irssi (which may need to be moved to some util/misc function) that turn %codes into the appropriate attributes

Contributor

ailin-nemui commented Oct 13, 2017

just conceptually speaking, one way to think about inline colours would be to take the input

 /whois xxx

then call a function (e.g. XS) which would change it to

[NOT COMMAND!]  /whois xxx

and that's what would then be visible. This would demand the callback to transform "input" into "displayed input" to be called at basically every change to the prompt

colours would then be realised by "returning"

%R /whois xxx

from the signal handler. There /should/ be some methods in irssi (which may need to be moved to some util/misc function) that turn %codes into the appropriate attributes

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Oct 23, 2017

Contributor

todo: change XS to work on %-codes (maybe exposing some functions for \004 conversion at the same time)

Contributor

ailin-nemui commented Oct 23, 2017

todo: change XS to work on %-codes (maybe exposing some functions for \004 conversion at the same time)

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Jan 10, 2018

Contributor

first version, still some errors, feel free to play with it and fix the remaining bugs

Contributor

ailin-nemui commented Jan 10, 2018

first version, still some errors, feel free to play with it and fix the remaining bugs

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Jan 18, 2018

Contributor

Irssi::gui_input_clear_extents(pos, len)
Irssi::gui_input_get_extent(pos)
Irssi::gui_input_set_extents(pos, len, left, right)

Contributor

ailin-nemui commented Jan 18, 2018

Irssi::gui_input_clear_extents(pos, len)
Irssi::gui_input_get_extent(pos)
Irssi::gui_input_set_extents(pos, len, left, right)

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Jan 19, 2018

Contributor

@GinjaNinja32 I changed the api again slightly,extent -> extents. hope you can test this again and discuss any usability issues that we may need to fix before merge

Contributor

ailin-nemui commented Jan 19, 2018

@GinjaNinja32 I changed the api again slightly,extent -> extents. hope you can test this again and discuss any usability issues that we may need to fix before merge

@ailin-nemui

This comment has been minimized.

Show comment
Hide comment
@ailin-nemui

ailin-nemui Feb 2, 2018

Contributor

@irssi/developers I think we should merge this

Contributor

ailin-nemui commented Feb 2, 2018

@irssi/developers I think we should merge this

@ailin-nemui ailin-nemui merged commit 8183180 into irssi:master Feb 5, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment