ismail-yilmaz / upp-components Goto Github PK

As per request:

it seems reasonable to implement an auto layout widget for U++ similar to wxwidgets' .

Popular vt emulators/widgets support various methods for font substitution.
Terminal ctrl currently doesn't support any such method.
A range-based font substitution option seems both relatively trivial to add with the existing code base of Terminal ctrl and flexible enough to give the client code some freedom.

Terminal <= v0.3 does not draw space character (0x20) with overline or underline SGR attribute.
For example, some applications such as w3m web browser rely on underline attribute to draw empty forms. Space character with some attributes (at least SGR_UNDERLINE) should be allowed.

As discussed here, some of the more popular terminal emulators (VTE-based ones, for one) implemented (or implementing) an OSC to allow hyperlinks.

This feature is useful and much safer than manually detecting the URLs that are not really intended to be hyperlinks.

Hello @jerch,

I don't want to pollute your repos or other active discussion threads with my findings until I can come up with some practical optimization suggestions for your renderer. So I'll put this here.

I've been doing some heavy profiling on my SixelRenderer since last week. Here are some preliminary results:

• I identified both some bottlenecks in my code and the performance sensitive critical parts of sixel rendering in general.
• I achieved some nice progress by some simple tweaks since last week:
  • I have managed to sequeze out a steady 42 MiB/s (2.90 secs) (parsing + rendering) on your sixel-bench animation, which means ~12 MiB/s gain. for me
  • There is a small performance penalty associated with displaying the animation due to the gui event handling (latency) of our GUI toolkit, But my SixelViewer app (a small testing and benchmarking app) can display the full sixel-bench video on average 38.00 Mib (3.10 secs.). As you can guess, this does not translate 1:1 to final terminal performance, because other variables also effect the vte rendering performance. Still it can achieve slightly higher performance than MLTerm now.

The above improvements are all due to some really simple tricks -one of which I borrowed from you- and the examination of the produced assembly code. I am confident that we can raise the throughput bar even higher, because there is still room for optimization.

In the following days this week I'd like to share my findings (code changes/alterations) with you, which you might find interesting and, hopefully, useful for your c/wasm decoder.

Given that we have UppHub up and running now, it seems reasonable to move the developmental packages of Ultimate++ terminal widget, TerminalCtrl, to its own repository and register it to UppHub.

This will,

• Allow the users of Ultimate++ to access Terminal package via TheIDE's distributed 3rd-party source package manager.
• Spare the users from downloading the whole upp-components repository just to get TerminalCtrl and its examples.

This move, however, does not mean that upp-components is going to be abandoned. upp-component will be maintained and expandend as planned. Terminal package within the upp-components repository will be regularly synced with its new home repo as well.

Ultimate++ terminal widget (v0.3/2020.1) added support for iTerm2's inline images protocol.
However, iTerm2's original protocol does not seem to explicitly specify the following:

1. When to scroll the page, if at all? (Currently, we are relying on DECSDM)
2. What happens when the preserveAspectRatio parameter is set to 0 with only, say, width parameter is specified. (E.g. this is the case with ranger file manager.) Should the terminal use the original height of the image (treat it as auto)? If so, should it scroll the page, or crop the image, if the original height of the image exceeds the height of terminal's page height?

@gnachman, If you have time , I would be grateful if you could clarify these two points about iTerm2's.inline images protocol.

Should be relatively easy, given the current design of SSH package...
(experimental)

While we already have support for windows 10 pseudoconsole api, the winpty library and winpty-agent executable allow native console support on Windows XP/Vista/7/8/10, by behaving as a middleware between console apps and terminals.

See this forum post for more details.

It is already prototyped, up and working. Let's get it ready for 2021.1 tag.

Hello Oblivion,

It seems that in top README.md there is not too many information. You should add at least the list of components and what they supposed to do. It will be much easier for the other people to localize what they want from your repository.

Of course good job with the components. I am gald you are part of our community!

Klugier

U++: upp-win-15400
Toolchain: MSVS19x64
OS: Windows 10 64bits

You added a linebreak even the selected text is only a single line. I think that's not what we expected at most situations. For example:

I want to input something like below:

export LD_LIBRARY_PATH=$(pwd)/lib:$LD_LIBRARY_PATH:/$(pwd)/last/lib

export LD_LIBRARY_PATH=$(pwd)/lib:$

Now, I copy the LD_LIBRARY_PATH, that's not the last text absolutely, I want to input more chars later, but the '\r'
will break the work.

Hi.

I found another bug on windows.

U++: upp-win-15400
Toolchain: MSVS19x64
OS: Windows 10 64bits

Steps to reproduce the bug:

• connect to a remote linux machine
• open VIM
• press 'i' to insert anything
• press ESC, it can't exit from edit mode.

Once there was a ChromiumBrowser widget for U++. It appears to be dead now (as the engine/API is now very outdated.)
Let us implement a new ctrl, using the latest CEF.

I have already managed to compile and statically link winpty library with stock Upp and the bundled clang compiler with very little wrestling . Not to mention that winpty has MIT license.. This means we can simply provide the library with the PtyProcess package, and preferably make it the default backend, for easy maintenance and development. This shouldn't take more than a week or so.

chiv@chiv-vpc:~$ uname -a
Linux chiv-vpc 5.4.0-53-generic #59-Ubuntu SMP Wed Oct 21 09:38:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
chiv@chiv-vpc:~$ uname aaaaaaa

CTRL+U will clear the command, but Terminal does not response this hot key, so dose CTRL+P, ....

Given the increasing popularity of inline images support in virtual terminal emulators, and the usage of SVG in general, the SVG rendering support can be added to TerminalCtrl as a compile-time option, since U++ already provides the necessary and easy-to-use SVG rendering functions.

As for the required changes in the wire protocols: This option doesn't necessarily require any modification of supported/existing wire protocols (DECSIXEL/jexer/iterm2), since TerminalCtrl already uses a generic infrastructure to identify and decode images.