jupyter-xeus / cpp-terminal

C++ library for writing multiplatform terminal applications
https://jupyter-xeus.github.io/cpp-terminal/
Other
490 stars 53 forks source link

Event (2) #282

Closed flagarde closed 1 year ago

flagarde commented 1 year ago

Thx for your nice review @TobiasWallner, this is the changes based on your comments. I think I have saved one useless assignement of std::String on event. Now we just copy it when all parsing have failed thus it's considered as CopyPaste event.

TobiasWallner commented 1 year ago

Can you explain the MetaKey for me. Is it just for information prozessing, or does it store information too?

Will it replace Key or is just an addition?

The Member is an enum of (None, Ctrl, Alt) but can it also store other unicode or only those three?

Does that mean we can have, for example, Ctrl+Alt+J key combinations now?

Will this fix Ctrl+I or Ctrl+M confusions with Tab and Enter?

Are there plans to include Shift as well in the future, to have for example Ctrl+Shift+Z?

flagarde commented 1 year ago

Can you explain the MetaKey for me. Is it just for information prozessing, or does it store information too?

It's an helper for the user to be able to do strange Key arithmetic. I wantd to be able to do Ctr+Alt+K but not M+M the first one have a meaning in term of keyboard the other one is meaningless. That why I created MetaKey you can do Meta+Meta+****+Meta or Meta+Key that it.

Will it replace Key or is just an addition?

It's an helper fonction in your code you should be able to do Ctrl+A if you want for example. For control alone it's better to have Ctrl_A but we need to be able to have Ctrl+Alt+F1 etc and so the enum would explode :). The drawback it's that for example Ctrl+Alt+Key is valid even if the OS can't detect this combinaison but it's user responsability to detect this and not do crazy key combinaison.

The Member is an enum of (None, Ctrl, Alt) but can it also store other unicode or only those three?

Only those three, can't be used alone (not all OS terminal recognize Ctrl press alone etc so it's better to avoid the detection). In windows in the input we will just ignore them.

Does that mean we can have, for example, Ctrl+Alt+J key combinations now?

YES :) that's the goal, but remember it's not because you can write Ctrl+Alt+J that the OS can detect it (for this one it should);

Will this fix Ctrl+I or Ctrl+M confusions with Tab and Enter?

NO that is because Tab and Enter are shortcut for C0 char and Ctrl is the default to obtain such chars. In some terminal or OS it is possible to detect them but as all can't and as the library is cross platform it is better to NOT disentangle. Keyboard press is not a bijective operation :(

Are there plans to include Shift as well in the future, to have for example Ctrl+Shift+Z? Shift is Already detected but again this is strange because you need to detect CapsLock too :

CapsLock+Shift+A=a etc... In practice you already have this detection on some combinaisons :

Ctrl+A=Ctrl+a but Ctrl+Alt+Z != Ctrl+Alt+z

TobiasWallner commented 1 year ago

ok, nice, thx

flagarde commented 1 year ago

@TobiasWallner Does this PR simplify your use of the library?

TobiasWallner commented 1 year ago

yes definitelly

flagarde commented 1 year ago

@TobiasWallner Did you already test it on Lime ? Maybe I can merge it if no bug has been added

TobiasWallner commented 1 year ago

I have not yet, I will tell you as soon as I managed to do so.

TobiasWallner commented 1 year ago

I just tried it and I get the following warning:

warning: arithmetic between different enumeration types ('Term::MetaKey::Value' and 'Term::Key::Value') is deprecated [-Wdeprecated-enum-enum-conversion]
                case Term::MetaKey::Ctrl + Term::Key::q : this->quit(); break;
                     ~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~