WIP: Fix keycodes #9

Closed
Ray-V wants to merge 6 commits from bug/fix-keycodes into master
Ray-V commented 4 years ago
Collaborator

Fix keycodes for:

Right shift
Win key
AltGr to select lower right key characters
Menu key
Right control
Num pad divide
Num pad Enter

Fix keycodes for: Right shift Win key AltGr to select lower right key characters Menu key Right control Num pad divide Num pad Enter
Ray-V added the PR/wip label 4 years ago
Owner

Hi Ray,
is this PR still a WIP (as in you want to do more work on it) or is it ready for us to take a look?

Hi Ray, is this PR still a WIP (as in you want to do more work on it) or is it ready for us to take a look?
Ray-V commented 4 years ago
Poster
Collaborator

I've made a number of changes for my own build - some necessary for the app to function as in the keycode changes, and some cosmetic as in a change of background colour.

I realise that not all will be practical or wanted in a source for universal use, so this PR is more a list of possibilities.

It's a rather long list, but I think it will be useful to reproduce the patch here to break down the changes into chunks that can be easily identified and modified or rejected as required.

I've included PR #8 in this, having modified the Num pad characters.

I've also written a help file which I haven't included here because I haven't kept to strict DTD protocols and it won't build with the meinproc --check option. For that reason, I'm assuming that it won't be accepted.
It works in TDE though and can be seen here.
Unless anyone knows how to set line breaks and left align text within <para></para> tags, I won't change it, but what I can do is set up a PR, or attach it to an issue, for it to be modified by others.


There is one outstanding issue which would be good to fix but is beyond my abilities.
What I can't fix is where the shift character is not the upper case of the lower alpha character.

For example, on the French azerty keyboard, Shift eacute should show as 2, but shows as Eacute.

This is only an issue for the character which is shown on the key, the printed character is correct.
So Shift eacute actually prints as 2.

The issue is even more obvious on the Czech keyboard.

I've been looking at
MainWidget::setupText(VButton& v)
and
VButton::shiftPressed(bool press)
for a solution but nothing I've tried works.


## not in this version - introduced for the later qt4 build

sed -i '/CSS Color themes/d' README

## Add a key, LSGT, between 'left shift' and 'z' for non-US keyboards.
## This duplicates '<' and '>' characters for US keyboards, but otherwise leaves the US keyboard fully functional.
## The key which is normally lower left of Enter on non-US keyboards is above the Enter key.
This is required to emulate a non-US keyboard otherwise there will be missing characters - gb=\| fr=<> de=<>| etc

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
#
## add a key[code] to row 4
@@ -46 +46 @@
-#define R4LEN 7
+#define R4LEN 8
#
## add keycode 94 key between l-shift and z key
## gb=\|  fr=<>  de=<>|  [us=<>]  etc
@@ -72,3 +72,3 @@
-	//TQString k4="zxcvbnm"; //,./";
-	//TQString k4s="ZXCVBNM";
-	unsigned int kc4[R4LEN] = {52,53,54,55,56,57,58};//59,60,61};
+	//TQString k4="<zxcvbnm"; //,./";
+	//TQString k4s=">ZXCVBNM";
+	unsigned int kc4[R4LEN] = {94,52,53,54,55,56,57,58};//59,60,61};
#
## reduce width of left shift key
@@ -249 +249 @@
-	lshft->resize ( 80,30 );
+	lshft->resize ( 45,30 );
#
## remove one key space after left shift
## and fix spacing
@@ -262 +262 @@
-		v->move ( stx+35+16+35+ ( 35*a ),sty+ ( 4*35 ) );
+		v->move ( stx+35+15+ ( 35*a ),sty+ ( 4*35 ) );

## Replace text on Num pad keys for a better fit
The existing "Ho\nme" etc texts don't fit well on the key for the real-world use I have for this at the font size required, so I needed to find an alternative.
There are better arrow characters available in a font like DejaVu, but not available in Liberation, so "H\u2190" is a compromise.

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -402 +402 @@
-	TQString txt[9] = { "Ho\nme", TQString::fromUtf8("▲"), "Pg\nUp",
+	TQString txt[9] = { TQString::fromUtf8("H\u2190"), TQString::fromUtf8("▲"), TQString::fromUtf8("P\u2191"),
@@ -404 +404 @@
-		"End", TQString::fromUtf8("▼"), "Pg\nDn" };
+		TQString::fromUtf8("E\u2192"), TQString::fromUtf8("▼"), TQString::fromUtf8("P\u2193") };
@@ -448 +448 @@
-	numl->setText("Num\nLock");
+	numl->setText(TQString::fromUtf8("\u2116"));
#+	numl->setText("N#");

## Set a more realistic initial font size

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -676 +676 @@
-		double rp = (8.0/600.0)*width();
+		double rp = (10.0/600.0)*width();

## Fix keycodes for evdev mapping:
## Right shift, LWin, AltGr, Menu, Right Ctrl, Num pad divide, Num pad Enter
I don't know whether evdev is the norm for all distros ..

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -296 +296 @@
-	rshft->setKeyCode ( 50 );
+	rshft->setKeyCode ( 62 );
@@ -321 +321 @@
-	win->setKeyCode ( 115 );
+	win->setKeyCode ( 133 );
@@ -349 +349 @@
-	ralt->setKeyCode ( 113 );
+	ralt->setKeyCode ( 108 );
@@ -359 +359 @@
-	mnu->setKeyCode ( 117 );
+	mnu->setKeyCode ( 135 );
@@ -370 +370 @@
-	rctrl->setKeyCode ( 37 );
+	rctrl->setKeyCode ( 105 );
@@ -459 +459 @@
-	div->setKeyCode(112);
+	div->setKeyCode(106);
@@ -476 +476 @@
-	ent->setKeyCode(36);
+	ent->setKeyCode(104);

## dead_* characters don't display on keys, so add single click printable character equivalents
## to display on keys - the printed character remains as dead_<whatever>
## Only needed for levels 0 and 1 - higher levels don't show on keys
## NoSymbol shows as an outline square [.notdef] on keys - replace with space=blank
## Re: MainWidget.cpp "* therefore keysymtab[] must remain SORTED by keysym value."

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -999,2 +1021,3 @@
 } keysymtab[] = {
+  { 0x0000, 0x0020 }, /*                  NoSymbol -> <- space */
   { 0x01a1, 0x0104 }, /*                     Aogonek Ą LATIN CAPITAL LETTER A WITH OGONEK */
@@ -1772,2 +1795,18 @@
   { 0x20ac, 0x20ac }, /*                    EuroSign € EURO SIGN */
+  { 0xfe50, 0x0060 }, /*                  dead_grave \` */
+  { 0xfe51, 0x00b4 }, /*                  dead_acute ´ */
+  { 0xfe52, 0x02c6 }, /*             dead_circumflex ˆ */
+  { 0xfe53, 0x02dc }, /*                  dead_tilde ˜ small tilde */
+  { 0xfe54, 0x00af }, /*                 dead_macron ¯ */
+  { 0xfe55, 0x02d8 }, /*                  dead_breve ˘ */
+  { 0xfe56, 0x02d9 }, /*               dead_abovedot ˙ */
+  { 0xfe57, 0x00a8 }, /*              dead_diaeresis ¨ */
+  { 0xfe58, 0x02da }, /*              dead_abovering ° */
+  { 0xfe59, 0x02dd }, /*            dead_doubleacute ˝ */
+  { 0xfe5a, 0x02c7 }, /*                  dead_caron ˇ */
+  { 0xfe5b, 0x00b8 }, /*                dead_cedilla ¸ */
+  { 0xfe5c, 0x02db }, /*                 dead_ogonek ˛ */
+  { 0xfe5d, 0x0269 }, /*                   dead_iota ɩ Latin small iota */
+  { 0xfe64, 0x1fbf }, /*             dead_abovecomma ᾽ Greek Psili */
+  { 0xfe65, 0x1ffe }, /*     dead_abovereversedcomma ῾ Greek Dasia */
 };

## add a tooltip for the panel icon

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -1825,3 +1825,3 @@
 {
-
+	TQToolTip::add ( this, "Virtual keyboard" );
 }

## Fix Num pad numbers where 0-9 aren't the non-shift characters on the keyboard
## E.g. for fr, the num pad '1' [KP_1 keycode 87] appears as '&' [keycode 10] when Num Lock is on
## And fix Del keycode so that KP_Separator prints correctly, eg for gr = comma
## This is a quick-and-dirty fix because it effectively means that this routine is redundant.

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -407 +407 @@
-	int nval[9] = {16,17,18,13,14,15,10,11,12};
+	int nval[9] = {79,80,81,83,84,85,87,88,89};
@@ -427 +427 @@
-	ins->setKeyCode(19,90);
+	ins->setKeyCode(90,90);
@@ -439 +439 @@
-	del->setKeyCode(60,91);
+	del->setKeyCode(91,91);

## Cosmetic changes:
## Set F4-F5 spacing as per F8-F9
I find the Dock image too intrusive, so have reduced its size on screen.
This doesn't reduce the image size, just shows 2/3 of it.

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -97 +97 @@
-		f->move ( stx+esc->width() + ( 35*a ) +20,sty );
+		f->move ( stx+esc->width() +3 + ( 35*a ) +25,sty );
@@ -107 +107 @@
-		f->move ( stx+esc->width() + ( 35*a ) +40+ ( 4*35 ),sty );
+		f->move ( stx+esc->width() +3 + ( 35*a ) +40+ ( 4*35 ),sty );
@@ -118 +118 @@
-		f->move ( stx+esc->width() + ( 35*a ) +45+ ( 8*35 ) +10,sty );
+		f->move ( stx+esc->width() +3 + ( 35*a ) +45+ ( 8*35 ) +10,sty );
#
## resize keys for alignment on right side of keyboard
@@ -139 +139 @@
-	bksp->resize ( 46,30 );
+	bksp->resize ( 48,30 );
@@ -149 +149 @@
-	tab->resize ( 47,30 );
+	tab->resize ( 48,30 );
## reduce size of Dock image
@@ -929 +929 @@
-	resize ( 96,47 );
+	resize ( 64,31 );

## set keyboard background colour
User set option in the build script - e.g. these are all the same colour and any one will work
BGCOLR=\"antiquewhite3\" || BGCOLR=\"#cdc0b0\" || BGCOLR=205,192,176

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -397,2 +397,2 @@
-	setPaletteBackgroundColor ( TQt::black );
	setFocusPolicy ( TQ_NoFocus );
+	setPaletteBackgroundColor ( TQColor($BGCOLR) );
	setFocusPolicy ( TQ_NoFocus );

## use icons for quit and num pad show/hide buttons
## these are the 16x16/actions icons used for the system selected icon set

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
#
## num pad show button
@@ -388 +388 @@
-	extent->setText(">>");
+	extent->setPixmap(TQIconSet(SmallIcon("media-seek-forward")).pixmap());
@@ -689 +689 @@
-		extent->setText(">>");
+		extent->setPixmap(TQIconSet(SmallIcon("media-seek-forward")).pixmap());
#
## num pad hide button
@@ -693 +693 @@
-		extent->setText("<<");
+		extent->setPixmap(TQIconSet(SmallIcon("media-seek-backward")).pixmap());
#
## quit button
--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -380 +380 @@
-	quit->setPaletteBackgroundColor ( TQt::red );
+	quit->setPixmap(TQIconSet(SmallIcon("application-exit")).pixmap());

## Display '&' where it is the lower key character on the key
## E.g. fr be azerty keyboards

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -886,5 +897,9 @@
 	TQString btn_text(TQChar((uint)ret));
 	
-	v.setText(btn_text);
+		TQChar c((uint)ret);
+		if (c=='&')
+			v.setText("&&");
+		else
+			v.setText(btn_text);
 
 	TQString btn_upper(btn_text.upper());

## Add RWin button

## new button added
--- src/MainWidget.h
+++ src/MainWidget.h
@@ -96,2 +96,3 @@
	VButton *win;
+	VButton *rwin;
	VButton *mnu;
--- src/MainWidget.cpp
+++ src/MainWidget.cpp
#
## differentiate between Win keys for documentation
@@ -320 +320 @@
-	win->setText ( "Win" );
+	win->setText ( "LWin" );
#
## reduce the width of the space bar by 45=RWin width and 5=space between keys
@@ -339 +339 @@
-	space->resize ( 5*35+28,30 );
+	space->resize ( 5*35+28-45-5,30 );
#
## RWin 'locks' with mouse click
@@ -353,2 +354,11 @@
 
+	rwin = new VButton ( this,"" );
+	rwin->resize ( 45,30 );
+	rwin->move ( 5+ralt->x() +ralt->width(), sty+ ( 5*35 ) );
+	rwin->setText ( "RWin" );
+	rwin->setKeyCode ( 134 );
+	rwin->setToggleButton ( true );
+	mod_keys.append( rwin );
+	rwin->res();
+
 
#
## Menu now follows RWin not Alt Gr
@@ -357 +367 @@
-	mnu->move ( 5+ralt->x() +ralt->width(), sty+ ( 5*35 ) );
+	mnu->move ( 5+rwin->x() +rwin->width(), sty+ ( 5*35 ) );

## resize quit, num pad show/hide, configure buttons to see the icons better at reduced size of keyboard

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -387,2 +387,2 @@
-	quit->resize ( 15,30 );
-	quit->move ( 525,15 );
+	quit->resize ( 20,30 );
+	quit->move ( 526,15 );
@@ -395,2 +395,2 @@
-	extent->resize( 15,65 );
-	extent->move(525, 85 );
+	extent->resize ( 20,65 );
+	extent->move(526, 85 );
@@ -551,2 +551,2 @@
-		popup_menu->resize ( 15,30 );
-		popup_menu->move ( 525,15+35 );
+		popup_menu->resize ( 20,30 );
+		popup_menu->move ( 526,15+35 );
#
## move numpad after resizing buttons
--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -410 +410 @@
-	int padx= 550;
+	int padx= 552;
#
## move and resize keyboard
--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -76 +76 @@
-	int stx=15;
+	int stx=17;
@@ -593 +593 @@
-	int d_width=550;
+	int d_width=552;
@@ -639,2 +639,2 @@
-		sdxs = width() - (width() * (150.0/700.0));
-		VButton::pw=700.0;
+		sdxs = width() - (width() * (150.0/702.0));
+		VButton::pw=702.0;
@@ -642 +642 @@
-		setMinimumSize(700/3,235/3);
+		setMinimumSize(702/3,235/3);
@@ -646,2 +646,2 @@
-		sdxb = width() + (width() * (150.0/550.0));
-		VButton::pw=550.0;
+		sdxb = width() + (width() * (150.0/552.0));
+		VButton::pw=552.0;
@@ -649 +649 @@
-		setMinimumSize(550/3,235/3);
+		setMinimumSize(552/3,235/3);
--- src/VButton.cpp
--- src/VButton.cpp
@@ -5 +5 @@
-double VButton::pw=550.0;
+double VButton::pw=552.0;

## missing characters in keysymtab[] - for AC12 -> AD13 key on ua keyboard

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
@@ -1251,2 +1251,3 @@
   { 0x06ac, 0x045c }, /*               Macedonia_kje ќ CYRILLIC SMALL LETTER KJE */
+  { 0x06ad, 0x0491 }, /*   Ukrainian_ghe_with_upturn ґ CYRILLIC SMALL LETTER GHE WITH UPTURN */
   { 0x06ae, 0x045e }, /*         Byelorussian_shortu ў CYRILLIC SMALL LETTER SHORT U */
@@ -1266,2 +1267,3 @@
   { 0x06bc, 0x040c }, /*               Macedonia_KJE Ќ CYRILLIC CAPITAL LETTER KJE */
+  { 0x06bd, 0x0490 }, /*   Ukrainian_GHE_WITH_UPTURN Ґ CYRILLIC CAPITAL LETTER GHE WITH UPTURN */
   { 0x06be, 0x040e }, /*         Byelorussian_SHORTU Ў CYRILLIC CAPITAL LETTER SHORT U */

## generate keycode for Win keys with single click so that they can be used for xmodmap
User set option in the build script

--- src/MainWidget.cpp
+++ src/MainWidget.cpp
#
## don't lock the LWin button
@@ -322 +322 @@
-	win->setToggleButton ( true );
+	win->setToggleButton ( false );
## don't lock the RWin button
@@ -359 +359 @@
-	rwin->setToggleButton ( true );
+	rwin->setToggleButton ( false );
#
## generate keycode on click rather than wait for next key-click for keycode
--- src/MainWidget.cpp
+++ src/MainWidget.cpp
#
## for LWin
@@ -323 +323,2 @@
-	mod_keys.append ( win );
+	connect ( win, TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( keyPress ( unsigned int ) ) );
+	other_keys.append( win );
#
## for RWin
@@ -360 +361,2 @@
-	mod_keys.append( rwin );
+	connect ( rwin, TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( keyPress ( unsigned int ) ) );
+	other_keys.append( rwin );
I've made a number of changes for my own build - some necessary for the app to function as in the keycode changes, and some cosmetic as in a change of [background colour](https://github.com/Ray-V/tde-slackbuilds/blob/master/Apps/kvkbd/doc/en/kvkbds.png). I realise that not all will be practical or wanted in a source for universal use, so this PR is more a list of possibilities. It's a rather long list, but I think it will be useful to reproduce the patch here to break down the changes into chunks that can be easily identified and modified or rejected as required. I've included PR #8 in this, having modified the [Num pad](https://github.com/Ray-V/tde-slackbuilds/blob/master/Apps/kvkbd/doc/en/num-pad.png) characters. I've also written a help file which I haven't included here because I haven't kept to strict DTD protocols and it won't build with the meinproc --check option. For that reason, I'm assuming that it won't be accepted. It works in TDE though and can be seen [here](https://github.com/Ray-V/tde-slackbuilds/blob/master/Apps/kvkbd/doc/en/index.docbook). Unless anyone knows how to set line breaks and left align text within \<para>\</para> tags, I won't change it, but what I can do is set up a PR, or attach it to an issue, for it to be modified by others. ----------- There is one outstanding issue which would be good to fix but is beyond my abilities. What I can't fix is where the shift character is not the upper case of the lower alpha character. For example, on the French azerty keyboard, Shift eacute should show as 2, but shows as Eacute. This is only an issue for the character which is shown on the key, the printed character is correct. So Shift eacute actually prints as 2. The issue is even more obvious on the Czech keyboard. I've been looking at MainWidget::setupText(VButton& v) and VButton::shiftPressed(bool press) for a solution but nothing I've tried works. --------------- \#\# not in this version - introduced for the later qt4 build ``` sed -i '/CSS Color themes/d' README ``` \#\# Add a key, LSGT, between 'left shift' and 'z' for non-US keyboards. \#\# This duplicates '<' and '>' characters for US keyboards, but otherwise leaves the US keyboard fully functional. \#\# The key which is normally lower left of Enter on non-US keyboards is above the Enter key. This is required to emulate a non-US keyboard otherwise there will be missing characters - gb=\\| fr=<> de=<>| etc ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp # ## add a key[code] to row 4 @@ -46 +46 @@ -#define R4LEN 7 +#define R4LEN 8 # ## add keycode 94 key between l-shift and z key ## gb=\| fr=<> de=<>| [us=<>] etc @@ -72,3 +72,3 @@ - //TQString k4="zxcvbnm"; //,./"; - //TQString k4s="ZXCVBNM"; - unsigned int kc4[R4LEN] = {52,53,54,55,56,57,58};//59,60,61}; + //TQString k4="<zxcvbnm"; //,./"; + //TQString k4s=">ZXCVBNM"; + unsigned int kc4[R4LEN] = {94,52,53,54,55,56,57,58};//59,60,61}; # ## reduce width of left shift key @@ -249 +249 @@ - lshft->resize ( 80,30 ); + lshft->resize ( 45,30 ); # ## remove one key space after left shift ## and fix spacing @@ -262 +262 @@ - v->move ( stx+35+16+35+ ( 35*a ),sty+ ( 4*35 ) ); + v->move ( stx+35+15+ ( 35*a ),sty+ ( 4*35 ) ); ``` \#\# Replace text on Num pad keys for a better fit The existing "Ho\nme" etc texts don't fit well on the key for the real-world use I have for this at the font size required, so I needed to find an alternative. There are better arrow characters available in a font like DejaVu, but not available in Liberation, so "H\u2190" is a compromise. ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -402 +402 @@ - TQString txt[9] = { "Ho\nme", TQString::fromUtf8("▲"), "Pg\nUp", + TQString txt[9] = { TQString::fromUtf8("H\u2190"), TQString::fromUtf8("▲"), TQString::fromUtf8("P\u2191"), @@ -404 +404 @@ - "End", TQString::fromUtf8("▼"), "Pg\nDn" }; + TQString::fromUtf8("E\u2192"), TQString::fromUtf8("▼"), TQString::fromUtf8("P\u2193") }; @@ -448 +448 @@ - numl->setText("Num\nLock"); + numl->setText(TQString::fromUtf8("\u2116")); #+ numl->setText("N#"); ``` \#\# Set a more realistic initial font size ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -676 +676 @@ - double rp = (8.0/600.0)*width(); + double rp = (10.0/600.0)*width(); ``` \#\# Fix keycodes for evdev mapping: \#\# Right shift, LWin, AltGr, Menu, Right Ctrl, Num pad divide, Num pad Enter I don't know whether evdev is the norm for all distros .. ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -296 +296 @@ - rshft->setKeyCode ( 50 ); + rshft->setKeyCode ( 62 ); @@ -321 +321 @@ - win->setKeyCode ( 115 ); + win->setKeyCode ( 133 ); @@ -349 +349 @@ - ralt->setKeyCode ( 113 ); + ralt->setKeyCode ( 108 ); @@ -359 +359 @@ - mnu->setKeyCode ( 117 ); + mnu->setKeyCode ( 135 ); @@ -370 +370 @@ - rctrl->setKeyCode ( 37 ); + rctrl->setKeyCode ( 105 ); @@ -459 +459 @@ - div->setKeyCode(112); + div->setKeyCode(106); @@ -476 +476 @@ - ent->setKeyCode(36); + ent->setKeyCode(104); ``` \#\# dead_* characters don't display on keys, so add single click printable character equivalents \#\# to display on keys - the printed character remains as dead_\<whatever> \#\# Only needed for levels 0 and 1 - higher levels don't show on keys \#\# NoSymbol shows as an outline square [.notdef] on keys - replace with space=blank \#\# Re: MainWidget.cpp "* therefore keysymtab[] must remain SORTED by keysym value." ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -999,2 +1021,3 @@ } keysymtab[] = { + { 0x0000, 0x0020 }, /* NoSymbol -> <- space */ { 0x01a1, 0x0104 }, /* Aogonek Ą LATIN CAPITAL LETTER A WITH OGONEK */ @@ -1772,2 +1795,18 @@ { 0x20ac, 0x20ac }, /* EuroSign € EURO SIGN */ + { 0xfe50, 0x0060 }, /* dead_grave \` */ + { 0xfe51, 0x00b4 }, /* dead_acute ´ */ + { 0xfe52, 0x02c6 }, /* dead_circumflex ˆ */ + { 0xfe53, 0x02dc }, /* dead_tilde ˜ small tilde */ + { 0xfe54, 0x00af }, /* dead_macron ¯ */ + { 0xfe55, 0x02d8 }, /* dead_breve ˘ */ + { 0xfe56, 0x02d9 }, /* dead_abovedot ˙ */ + { 0xfe57, 0x00a8 }, /* dead_diaeresis ¨ */ + { 0xfe58, 0x02da }, /* dead_abovering ° */ + { 0xfe59, 0x02dd }, /* dead_doubleacute ˝ */ + { 0xfe5a, 0x02c7 }, /* dead_caron ˇ */ + { 0xfe5b, 0x00b8 }, /* dead_cedilla ¸ */ + { 0xfe5c, 0x02db }, /* dead_ogonek ˛ */ + { 0xfe5d, 0x0269 }, /* dead_iota ɩ Latin small iota */ + { 0xfe64, 0x1fbf }, /* dead_abovecomma ᾽ Greek Psili */ + { 0xfe65, 0x1ffe }, /* dead_abovereversedcomma ῾ Greek Dasia */ }; ``` \#\# add a tooltip for the panel icon ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -1825,3 +1825,3 @@ { - + TQToolTip::add ( this, "Virtual keyboard" ); } ``` \#\# Fix Num pad numbers where 0-9 aren't the non-shift characters on the keyboard \#\# E.g. for fr, the num pad '1' [KP_1 keycode 87] appears as '&' [keycode 10] when Num Lock is on \#\# And fix Del keycode so that KP_Separator prints correctly, eg for gr = comma \#\# This is a quick-and-dirty fix because it effectively means that this routine is redundant. ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -407 +407 @@ - int nval[9] = {16,17,18,13,14,15,10,11,12}; + int nval[9] = {79,80,81,83,84,85,87,88,89}; @@ -427 +427 @@ - ins->setKeyCode(19,90); + ins->setKeyCode(90,90); @@ -439 +439 @@ - del->setKeyCode(60,91); + del->setKeyCode(91,91); ``` \#\# Cosmetic changes: \#\# Set F4-F5 spacing as per F8-F9 I find the Dock image too intrusive, so have reduced its size on screen. This doesn't reduce the image size, just shows 2/3 of it. ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -97 +97 @@ - f->move ( stx+esc->width() + ( 35*a ) +20,sty ); + f->move ( stx+esc->width() +3 + ( 35*a ) +25,sty ); @@ -107 +107 @@ - f->move ( stx+esc->width() + ( 35*a ) +40+ ( 4*35 ),sty ); + f->move ( stx+esc->width() +3 + ( 35*a ) +40+ ( 4*35 ),sty ); @@ -118 +118 @@ - f->move ( stx+esc->width() + ( 35*a ) +45+ ( 8*35 ) +10,sty ); + f->move ( stx+esc->width() +3 + ( 35*a ) +45+ ( 8*35 ) +10,sty ); # ## resize keys for alignment on right side of keyboard @@ -139 +139 @@ - bksp->resize ( 46,30 ); + bksp->resize ( 48,30 ); @@ -149 +149 @@ - tab->resize ( 47,30 ); + tab->resize ( 48,30 ); ## reduce size of Dock image @@ -929 +929 @@ - resize ( 96,47 ); + resize ( 64,31 ); ``` \#\# set keyboard background colour User set option in the build script - e.g. these are all the same colour and any one will work BGCOLR=\\\"antiquewhite3\\\" || BGCOLR=\\\"#cdc0b0\\\" || BGCOLR=205,192,176 ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -397,2 +397,2 @@ - setPaletteBackgroundColor ( TQt::black ); setFocusPolicy ( TQ_NoFocus ); + setPaletteBackgroundColor ( TQColor($BGCOLR) ); setFocusPolicy ( TQ_NoFocus ); ``` \#\# use icons for quit and num pad show/hide buttons \#\# these are the 16x16/actions icons used for the system selected icon set ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp # ## num pad show button @@ -388 +388 @@ - extent->setText(">>"); + extent->setPixmap(TQIconSet(SmallIcon("media-seek-forward")).pixmap()); @@ -689 +689 @@ - extent->setText(">>"); + extent->setPixmap(TQIconSet(SmallIcon("media-seek-forward")).pixmap()); # ## num pad hide button @@ -693 +693 @@ - extent->setText("<<"); + extent->setPixmap(TQIconSet(SmallIcon("media-seek-backward")).pixmap()); # ## quit button --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -380 +380 @@ - quit->setPaletteBackgroundColor ( TQt::red ); + quit->setPixmap(TQIconSet(SmallIcon("application-exit")).pixmap()); ``` \#\# Display '&' where it is the lower key character on the key \#\# E.g. fr be azerty keyboards ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -886,5 +897,9 @@ TQString btn_text(TQChar((uint)ret)); - v.setText(btn_text); + TQChar c((uint)ret); + if (c=='&') + v.setText("&&"); + else + v.setText(btn_text); TQString btn_upper(btn_text.upper()); ``` \#\# Add RWin button ```diff ## new button added --- src/MainWidget.h +++ src/MainWidget.h @@ -96,2 +96,3 @@ VButton *win; + VButton *rwin; VButton *mnu; --- src/MainWidget.cpp +++ src/MainWidget.cpp # ## differentiate between Win keys for documentation @@ -320 +320 @@ - win->setText ( "Win" ); + win->setText ( "LWin" ); # ## reduce the width of the space bar by 45=RWin width and 5=space between keys @@ -339 +339 @@ - space->resize ( 5*35+28,30 ); + space->resize ( 5*35+28-45-5,30 ); # ## RWin 'locks' with mouse click @@ -353,2 +354,11 @@ + rwin = new VButton ( this,"" ); + rwin->resize ( 45,30 ); + rwin->move ( 5+ralt->x() +ralt->width(), sty+ ( 5*35 ) ); + rwin->setText ( "RWin" ); + rwin->setKeyCode ( 134 ); + rwin->setToggleButton ( true ); + mod_keys.append( rwin ); + rwin->res(); + # ## Menu now follows RWin not Alt Gr @@ -357 +367 @@ - mnu->move ( 5+ralt->x() +ralt->width(), sty+ ( 5*35 ) ); + mnu->move ( 5+rwin->x() +rwin->width(), sty+ ( 5*35 ) ); ``` \#\# resize quit, num pad show/hide, configure buttons to see the icons better at reduced size of keyboard ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -387,2 +387,2 @@ - quit->resize ( 15,30 ); - quit->move ( 525,15 ); + quit->resize ( 20,30 ); + quit->move ( 526,15 ); @@ -395,2 +395,2 @@ - extent->resize( 15,65 ); - extent->move(525, 85 ); + extent->resize ( 20,65 ); + extent->move(526, 85 ); @@ -551,2 +551,2 @@ - popup_menu->resize ( 15,30 ); - popup_menu->move ( 525,15+35 ); + popup_menu->resize ( 20,30 ); + popup_menu->move ( 526,15+35 ); # ## move numpad after resizing buttons --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -410 +410 @@ - int padx= 550; + int padx= 552; # ## move and resize keyboard --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -76 +76 @@ - int stx=15; + int stx=17; @@ -593 +593 @@ - int d_width=550; + int d_width=552; @@ -639,2 +639,2 @@ - sdxs = width() - (width() * (150.0/700.0)); - VButton::pw=700.0; + sdxs = width() - (width() * (150.0/702.0)); + VButton::pw=702.0; @@ -642 +642 @@ - setMinimumSize(700/3,235/3); + setMinimumSize(702/3,235/3); @@ -646,2 +646,2 @@ - sdxb = width() + (width() * (150.0/550.0)); - VButton::pw=550.0; + sdxb = width() + (width() * (150.0/552.0)); + VButton::pw=552.0; @@ -649 +649 @@ - setMinimumSize(550/3,235/3); + setMinimumSize(552/3,235/3); --- src/VButton.cpp --- src/VButton.cpp @@ -5 +5 @@ -double VButton::pw=550.0; +double VButton::pw=552.0; ``` \#\# missing characters in keysymtab[] - for AC12 -> AD13 key on ua keyboard ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp @@ -1251,2 +1251,3 @@ { 0x06ac, 0x045c }, /* Macedonia_kje ќ CYRILLIC SMALL LETTER KJE */ + { 0x06ad, 0x0491 }, /* Ukrainian_ghe_with_upturn ґ CYRILLIC SMALL LETTER GHE WITH UPTURN */ { 0x06ae, 0x045e }, /* Byelorussian_shortu ў CYRILLIC SMALL LETTER SHORT U */ @@ -1266,2 +1267,3 @@ { 0x06bc, 0x040c }, /* Macedonia_KJE Ќ CYRILLIC CAPITAL LETTER KJE */ + { 0x06bd, 0x0490 }, /* Ukrainian_GHE_WITH_UPTURN Ґ CYRILLIC CAPITAL LETTER GHE WITH UPTURN */ { 0x06be, 0x040e }, /* Byelorussian_SHORTU Ў CYRILLIC CAPITAL LETTER SHORT U */ ``` \#\# generate keycode for Win keys with single click so that they can be used for xmodmap User set option in the build script ```diff --- src/MainWidget.cpp +++ src/MainWidget.cpp # ## don't lock the LWin button @@ -322 +322 @@ - win->setToggleButton ( true ); + win->setToggleButton ( false ); ## don't lock the RWin button @@ -359 +359 @@ - rwin->setToggleButton ( true ); + rwin->setToggleButton ( false ); # ## generate keycode on click rather than wait for next key-click for keycode --- src/MainWidget.cpp +++ src/MainWidget.cpp # ## for LWin @@ -323 +323,2 @@ - mod_keys.append ( win ); + connect ( win, TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( keyPress ( unsigned int ) ) ); + other_keys.append( win ); # ## for RWin @@ -360 +361,2 @@ - mod_keys.append( rwin ); + connect ( rwin, TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( keyPress ( unsigned int ) ) ); + other_keys.append( rwin ); ```
Ray-V removed the PR/wip label 4 years ago
Ray-V commented 4 years ago
Poster
Collaborator

Hi Ray,
is this PR still a WIP (as in you want to do more work on it) or is it ready for us to take a look?

How do I remove the WIP: from the title?

> Hi Ray, > is this PR still a WIP (as in you want to do more work on it) or is it ready for us to take a look? How do I remove the WIP: from the title?
Owner

Wow, thanks for the excellent work Ray. We will look into this and see what can be merged, what needs to be modified and what will not be merged.

Also thanks for the help file, we will find a way to make it build with meinproc so it can be included.

I put down this PR for R14.0.10 inclusion.

PS: to remove WIP from the title, you just need to edit it (there is an Edit button on the right side of it)

Wow, thanks for the excellent work Ray. We will look into this and see what can be merged, what needs to be modified and what will not be merged.<br/> Also thanks for the help file, we will find a way to make it build with meinproc so it can be included. I put down this PR for R14.0.10 inclusion. PS: to remove WIP from the title, you just need to edit it (there is an Edit button on the right side of it)
MicheleC added this to the R14.0.10 release milestone 4 years ago
MicheleC changed title from WIP: Fix keycodes to Fix keycodes 4 years ago
Ray-V commented 4 years ago
Poster
Collaborator

I've removed the previous 3 commits because I've fixed some more issues with Kvkbd.

This new commit includes the previous diffs, but I'd updated and re-arranged some of the patches and it was going to be a lot of hassle modifying them based on the previous commits.

I've attached the patch I used to set up this commit. It contains comments and the individual chunks for each change.

So the commit list remains as before, and additional patches are for:

Fix Caps and Shift characters on eg French and Czech keyboards not all being displayed, or being displayed vice versa. To do that I revised the Caps and Shift lock algorithms.

The button/key colour defaults to the system colour, but can be overridden and set in the build [set to #f0f0f0 in the patch - it's a user option in my build script]. But that introduces a bleed through around the edges of the keys for the shaped keys of the plastik and keramik styles. Fixed that by moving the setFocusPolicy in MainWidget::MainWidget.

Font auto resize - when the num pad is clicked into view, the font size immediately increases, although the keyboard size hasn't effectively changed. Fixed that by basing the font size on the main keyboard size regardless of whether the num pad is showing.

And I've updated the help file.

I've removed the previous 3 commits because I've fixed some more issues with Kvkbd. This new commit includes the previous diffs, but I'd updated and re-arranged some of the patches and it was going to be a lot of hassle modifying them based on the previous commits. I've attached the patch I used to set up this commit. It contains comments and the individual chunks for each change. So the commit list remains as before, and additional patches are for: Fix Caps and Shift characters on eg French and Czech keyboards not all being displayed, or being displayed vice versa. To do that I revised the Caps and Shift lock algorithms. The button/key colour defaults to the system colour, but can be overridden and set in the build [set to #f0f0f0 in the patch - it's a user option in my build script]. But that introduces a bleed through around the edges of the keys for the shaped keys of the plastik and keramik styles. Fixed that by moving the setFocusPolicy in MainWidget::MainWidget. Font auto resize - when the num pad is clicked into view, the font size immediately increases, although the keyboard size hasn't effectively changed. Fixed that by basing the font size on the main keyboard size regardless of whether the num pad is showing. And I've updated the help file.
Ray-V commented 4 years ago
Poster
Collaborator

Fussy about what formats it will accept for file uploads isn't it!

Fussy about what formats it will accept for file uploads isn't it!
Owner

Hi Ray, sorry I am a bit confused. I haven't do a comparison yet between your attached file and the commits in the branch, but are they the same or are they complementing each other?

In general it would be better if you upload all your changes as commits in a branch, easier to work with. Even better if you could split the work in multiple commits, one for each particular task/change, so it would be much easier to review.

Hi Ray, sorry I am a bit confused. I haven't do a comparison yet between your attached file and the commits in the branch, but are they the same or are they complementing each other? In general it would be better if you upload all your changes as commits in a branch, easier to work with. Even better if you could split the work in multiple commits, one for each particular task/change, so it would be much easier to review.
Ray-V commented 4 years ago
Poster
Collaborator

a comparison .. between your attached file and the commits in the branch, but are they the same or are they complementing each other?

attached file == commit in the branch.
The previous 3 commits have been included in this new commit which adds the 3 new issues.

In general it would be better if you upload all your changes as commits in a branch

Presumably this comment is if attached file != commit in the branch.

Even better if you could split the work in multiple commits, one for each particular task/change

From my point of view, this should be one commit. I think the issues are best considered as a whole as there are some interdependencies. It will be easier to remove/edit any issue you don't accept for any final merge, than it will be to rebase and merge about 20 individual commits.

so it would be much easier to review.

I attached the file I used to patch this branch to produce this commit based on latest master so that you can see why and how I've tackled individual issues.

> a comparison .. between your attached file and the commits in the branch, but are they the same or are they complementing each other? attached file == commit in the branch. The previous 3 commits have been included in this new commit which adds the 3 new issues. > In general it would be better if you upload all your changes as commits in a branch Presumably this comment is if attached file != commit in the branch. > Even better if you could split the work in multiple commits, one for each particular task/change From my point of view, this should be one commit. I think the issues are best considered as a whole as there are some interdependencies. It will be easier to remove/edit any issue you don't accept for any final merge, than it will be to rebase and merge about 20 individual commits. > so it would be much easier to review. I attached the file I used to patch this branch to produce this commit based on latest master so that you can see why and how I've tackled individual issues.
Owner

Hi Ray, I gave it a go and a quick test and defintely I can see the result of your effort. I will work into merging this PR, but will probably break it down into multiple commits. May come back with some questions if I have any.

BTW,I see some strange behavior here (with or without the PR, no difference). If I press Shift, then decide I don't need Shift, so I press it again to "cancel" the first press, the symbols displayed on the keyboard change to upper case. Only after I press shift+any letter, the symbols go down to lower case again. Do you see the same issue?

Hi Ray, I gave it a go and a quick test and defintely I can see the result of your effort. I will work into merging this PR, but will probably break it down into multiple commits. May come back with some questions if I have any. BTW,I see some strange behavior here (with or without the PR, no difference). If I press Shift, then decide I don't need Shift, so I press it again to "cancel" the first press, the symbols displayed on the keyboard change to upper case. Only after I press shift+any letter, the symbols go down to lower case again. Do you see the same issue?
Ray-V commented 3 years ago
Poster
Collaborator

@MicheleC

BTW,I see some strange behavior here ... Do you see the same issue?

Sort of. What I see is all the shift characters which are Caps where the lower is an alpha.
This mixing of upper and shift characters where they are the same [Caps] character caused me a lot of head stratching when I was trying to sort out the characters displayed on the keys. This is the main reason I changed the designation of shift characters to 's' and l.upper() to 'u' to more easily differentiate between the two - I hope you'll accept that.

I guess this is something to be looked at but the fix may have a less useful consequence.

As I've mentioned in the help file, there is a useful undocumented feature where if both Shift keys are clicked, the shift characters are displayed and then clicking on a key will print the character shown.

I prefer that behaviour compared to what you've observed where clicking either Shift key twice will show the shift characters, but then clicking the key will print the lower character.

Otherwise, Shift+key exhibits normal behaviour and prints the shift character as expected, but the user needs to know which key the shift character is on as the lower characters are displayed.

but will probably break it down into multiple commits.

For my build, I've added some tweaks to resizing the keyboard; translations; tooltips; and ColorDialog for the user to select and override the keyboard and key/button colours.

As you like commits in discrete chunks, I'll do separate 'feat' PRs for each of these.

@MicheleC > BTW,I see some strange behavior here ... Do you see the same issue? Sort of. What I see is all the shift characters which are Caps where the lower is an alpha. This mixing of upper and shift characters where they are the same [Caps] character caused me a lot of head stratching when I was trying to sort out the characters displayed on the keys. This is the main reason I changed the designation of shift characters to 's' and l.upper() to 'u' to more easily differentiate between the two - I hope you'll accept that. I guess this is something to be looked at but the fix may have a less useful consequence. As I've mentioned in the help file, there is a useful undocumented feature where if both Shift keys are clicked, the shift characters are displayed and then clicking on a key will print the character shown. I prefer that behaviour compared to what you've observed where clicking either Shift key twice will show the shift characters, but then clicking the key will print the lower character. Otherwise, Shift+key exhibits normal behaviour and prints the shift character as expected, but the user needs to know which key the shift character is on as the lower characters are displayed. > but will probably break it down into multiple commits. For my build, I've added some tweaks to resizing the keyboard; translations; tooltips; and ColorDialog for the user to select and override the keyboard and key/button colours. As you like commits in discrete chunks, I'll do separate 'feat' PRs for each of these.
Owner

Sort of. What I see is all the shift characters which are Caps where the lower is an alpha.

This is also what I see. In my opinion it is a bug 😉

As I've mentioned in the help file, there is a useful undocumented feature where if both Shift keys are clicked, the shift characters are displayed and then clicking on a key will print the character shown.

I don't think this is a feature, it looks more like a bug to me.

As you like commits in discrete chunks, I'll do separate 'feat' PRs for each of these.

The point is that small discrete commits makes the job of a reviewer easier 😄

> Sort of. What I see is all the shift characters which are Caps where the lower is an alpha. This is also what I see. In my opinion it is a bug :wink: > As I've mentioned in the help file, there is a useful undocumented feature where if both Shift keys are clicked, the shift characters are displayed and then clicking on a key will print the character shown. I don't think this is a feature, it looks more like a bug to me. > As you like commits in discrete chunks, I'll do separate 'feat' PRs for each of these. The point is that small discrete commits makes the job of a reviewer easier :smile:
Ray-V added 5 commits 3 years ago
a3d17bf958
Key alignment and spacing
559d223032
Add translations
8371e74692
Add TQColorDialog
b91a1768a0
Add tooltips to the buttons and update dock.png
3503aa510b
extent_visible
Owner

Great, thanks for the additional commits and for splitting them up, appreciated 😉

Great, thanks for the additional commits and for splitting them up, appreciated :wink:
Owner

Commit 3503aa510b slightly reworked and pushed as d1fca94 (R14.1) and 2c38847 (R14.0).

Further work to come.

Commit 3503aa510b slightly reworked and pushed as d1fca94 (R14.1) and 2c38847 (R14.0). Further work to come.
MicheleC changed title from Fix keycodes to WIP: Fix keycodes 3 years ago
Owner

Lock on screen functionality added and improved in commits 0da79dd, b53e333, aae2b17 (R14.1) and 16e7cd4, 9ef732a, bea04fd (R14.0)

Lock on screen functionality added and improved in commits 0da79dd, b53e333, aae2b17 (R14.1) and 16e7cd4, 9ef732a, bea04fd (R14.0)
Owner

RWin key has been added in commit 2af99da (R14.1) and 69b02ce (R14.0).
Since LWin and RWin are used as Super_L/R modifiers, the keys have been set back as toggle keys in commit 74abd47 (R14.1) and 3374fd5 (R14.0).

RWin key has been added in commit 2af99da (R14.1) and 69b02ce (R14.0). Since LWin and RWin are used as Super_L/R modifiers, the keys have been set back as toggle keys in commit 74abd47 (R14.1) and 3374fd5 (R14.0).
MicheleC self-assigned this 3 years ago
Owner

Tooltip for system tray icon added in commit 1342053 (R14.1) and abbc87e (R14.0)

Tooltip for system tray icon added in commit 1342053 (R14.1) and abbc87e (R14.0)
Owner

Renaming of numpad keys (Home, End, PgUp, PgDn, NumLock) will not be added to the code.

Renaming of numpad keys (Home, End, PgUp, PgDn, NumLock) will not be added to the code.
Owner

Commit ed6e395 (R14.1) and 51c93c1 (R14.0) added the following functionality (sorry Ray, I mentioned you as author of the commit but forgot to add sign-off for you, so only my sign-off is shown on such commits):

  1. Use icons for quit and num pad show/hide buttons.
  2. Resize quit, num pad show/hide, configure buttons.
  3. Add tooltips to the buttons.
Commit ed6e395 (R14.1) and 51c93c1 (R14.0) added the following functionality (sorry Ray, I mentioned you as author of the commit but forgot to add sign-off for you, so only my sign-off is shown on such commits): 1. Use icons for quit and num pad show/hide buttons. 2. Resize quit, num pad show/hide, configure buttons. 3. Add tooltips to the buttons.
Owner

Commit 2aaedb4 (R14.1) and df86438 (R14.0) increased the size of the button icons. The original size was a bit small on high density screens, so Medium size is now used.

Commit 2aaedb4 (R14.1) and df86438 (R14.0) increased the size of the button icons. The original size was a bit small on high density screens, so Medium size is now used.
Owner

Keycodes fixed in commit 8bbaa8f (R14.1) and 543ee09 (R14.0).

Keycodes fixed in commit 8bbaa8f (R14.1) and 543ee09 (R14.0).
Owner

Commit 47d89f2 (R14.1) and cf258cd (R14.0) simplify the code related to numpad buttons. No more duplicated keycodes required.

Commit 47d89f2 (R14.1) and cf258cd (R14.0) simplify the code related to numpad buttons. No more duplicated keycodes required.
Owner

Commit 8371e74692 (select keyboard colors) has been reworked and merged in commit dd8d527 (R14.1) and 9834ca3 (R14.0).

Commit 8371e74692 (select keyboard colors) has been reworked and merged in commit dd8d527 (R14.1) and 9834ca3 (R14.0).
Owner

The color of the keyboard keys can now be changed without the need to restart the application. Commits 64d40d9, 94e4d4d (R14.1) and 4918c52, d26a127 (R14.0).

The color of the keyboard keys can now be changed without the need to restart the application. Commits 64d40d9, 94e4d4d (R14.1) and 4918c52, d26a127 (R14.0).
Owner

Less-than/greater-than key added near left shift in commit f84f133 (R14.1) and 6ceda6a (R14.0).

Less-than/greater-than key added near left shift in commit f84f133 (R14.1) and 6ceda6a (R14.0).
Owner

Additional translations added in commit 2c080a7 (R14.1) and 9e2e5d8 (R14.0).

Additional translations added in commit 2c080a7 (R14.1) and 9e2e5d8 (R14.0).
Owner

@Ray-V in your patch you mentioned that you fixed the shift/caps algorithm, but it still does not work properly here.
Looking into the code is seems the status of shift/caps is read before triggering the pressed event in the vbutton, which is why things do not fuction well.

Do you see problems on your side? In any case I will work on fixing this problem in the coming days, just wanted to double check what you see.

@Ray-V in your patch you mentioned that you fixed the shift/caps algorithm, but it still does not work properly here. Looking into the code is seems the status of shift/caps is read before triggering the pressed event in the vbutton, which is why things do not fuction well. Do you see problems on your side? In any case I will work on fixing this problem in the coming days, just wanted to double check what you see.
Ray-V commented 3 years ago
Poster
Collaborator

The correct characters have always been printed - the issue was the characters displayed on the keyboard.

With the previous algorithm, there was never an issue with the Caps and Shift display on US and GB qwerty keyboards where there is a separation of lower/caps[or shift] and other/shift character keys.
I.e. 2=2, Shift+2=@ or ", Caps+2=2

The problem was on, say, a FR azerty keyboard where, for example, the é key has a different Caps character.
I.e. é=é, Shift+é=2, Caps+é=É
The original algorithm couldn't cope with that [don't remember now what the actual result was], but, post patch, the correct characters are displayed.

Are you referring to what I call a useful feature but you call a bug?
I.e. Shift+key will print the correct character without displaying it on the keyboard, but L_Shift+R_Shift+key will display and print the shift character.

If you'll let me know the specific situation which isn't right, I'll check that out and let you know what I see.

The correct characters have always been printed - the issue was the characters displayed on the keyboard. With the previous algorithm, there was never an issue with the Caps and Shift display on US and GB qwerty keyboards where there is a separation of lower/caps[or shift] and other/shift character keys. I.e. 2=2, Shift+2=@ or ", Caps+2=2 The problem was on, say, a FR azerty keyboard where, for example, the é key has a different Caps character. I.e. é=é, Shift+é=2, Caps+é=É The original algorithm couldn't cope with that [don't remember now what the actual result was], but, post patch, the correct characters are displayed. Are you referring to what I call a useful feature but you call a bug? I.e. Shift+key will print the correct character without displaying it on the keyboard, but L_Shift+R_Shift+key will display and print the shift character. If you'll let me know the specific situation which isn't right, I'll check that out and let you know what I see.
Owner

Hi Ray, thanks for the feedback. What I see here is that using shift swap the characters displayed on the visual keyboard after the first time. The character actually sent to the X server are correct.
I have taken a few screenshots, you can find them in the attached zip file.
I have seen this problem with the original code, with original code + your original patch fully applied, with the current code in master. All the same.
Screenshot list:

  1. after startup of kvkdb
  2. after pressing lshift. Note characters are still lowercase
  3. after pressing again lshift to release the key. Characters now become uppercase
  4. after pressing lshift again. Characters turn to lowercase
  5. after pressing 'a' key. 'A' is correctly displayed in the application.

As you can see the characters on the virtual keyboard are not displayed correctly.
Could you try the same steps and let me know if you see a different behavior?

Hi Ray, thanks for the feedback. What I see here is that using shift swap the characters displayed on the visual keyboard after the first time. The character actually sent to the X server are correct. I have taken a few screenshots, you can find them in the attached zip file. I have seen this problem with the original code, with original code + your original patch fully applied, with the current code in master. All the same. Screenshot list: 1. after startup of kvkdb 2. after pressing lshift. Note characters are still lowercase 3. after pressing again lshift to release the key. Characters now become uppercase 4. after pressing lshift again. Characters turn to lowercase 5. after pressing 'a' key. 'A' is correctly displayed in the application. As you can see the characters on the virtual keyboard are not displayed correctly. Could you try the same steps and let me know if you see a different behavior?
172 KiB
Ray-V commented 3 years ago
Poster
Collaborator

Yes, I see exactly the same - but - this isn't the issue the algorithm change addresses.

[1] Displayed behaviour

I agree this isn't ideal, but I'm not a programmer and work with what there is and this is why I say that LShift+RShift+a will display and print the A character, which to me is a good result, albeit a workaround.

If you can code this along the lines of Shift+a displays A and click-on-A prints A, then that will be an excellent result.

[2] The algorithm

You'll need to consider a non-US keyboard for this.

Look at the affect of Shift and/or Caps Lock on the é and other accented keys on a French azerty keyboard, and/or any other keyboard where alpha and non-alpha characters share a key.

Yes, I see exactly the same - but - this isn't the issue the algorithm change addresses. [1] Displayed behaviour I agree this isn't ideal, but I'm not a programmer and work with what there is and this is why I say that LShift+RShift+a will display and print the A character, which to me is a good result, albeit a workaround. If you can code this along the lines of Shift+a displays A and click-on-A prints A, then that will be an excellent result. [2] The algorithm You'll need to consider a non-US keyboard for this. Look at the affect of Shift and/or Caps Lock on the é and other accented keys on a French azerty keyboard, and/or any other keyboard where alpha and non-alpha characters share a key.
Owner

Yes, I see exactly the same - but - this isn't the issue the algorithm change addresses.

[1] Displayed behaviour

I agree this isn't ideal, but I'm not a programmer and work with what there is and this is why I say that LShift+RShift+a will display and print the A character, which to me is a good result, albeit a workaround.

If you can code this along the lines of Shift+a displays A and click-on-A prints A, then that will be an excellent result.

[2] The algorithm

You'll need to consider a non-US keyboard for this.

Look at the affect of Shift and/or Caps Lock on the é and other accented keys on a French azerty keyboard, and/or any other keyboard where alpha and non-alpha characters share a key.

Thansk for checking Ray. I think there are two issues here.

  1. the lowercase/uppercase issue. I will work at fixing that
  2. the display of dead/accented characters on non-US keyboard. Planning to integrate your work after fixing point 1. I will test on an italian keyboard which has plenty of accented symbols.
> Yes, I see exactly the same - but - this isn't the issue the algorithm change addresses. > > [1] Displayed behaviour > > I agree this isn't ideal, but I'm not a programmer and work with what there is and this is why I say that LShift+RShift+a will display and print the A character, which to me is a good result, albeit a workaround. > > If you can code this along the lines of Shift+a displays A and click-on-A prints A, then that will be an excellent result. > > [2] The algorithm > > You'll need to consider a non-US keyboard for this. > > Look at the affect of Shift and/or Caps Lock on the é and other accented keys on a French azerty keyboard, and/or any other keyboard where alpha and non-alpha characters share a key. Thansk for checking Ray. I think there are two issues here. 1. the lowercase/uppercase issue. I will work at fixing that 2. the display of dead/accented characters on non-US keyboard. Planning to integrate your work after fixing point 1. I will test on an italian keyboard which has plenty of accented symbols.
Owner

Commit 00e207e (R14.1) and 1865767 (R14.0) fix the issue with the key text display when shift is used.
Caps is still not working properly, at least here.

@Ray-V @SlavekB: would you be able to run a test on your system with the latest commit and confirm that caps is not working as well? Just to gather more info.

Commit 00e207e (R14.1) and 1865767 (R14.0) fix the issue with the key text display when shift is used. Caps is still not working properly, at least here. @Ray-V @SlavekB: would you be able to run a test on your system with the latest commit and confirm that caps is not working as well? Just to gather more info.
Ray-V commented 3 years ago
Poster
Collaborator

Built to commit 00e207e..

What I see is Shift shows shift characters, and click on character prints that shift character - all OK

When kvkbd is first launched, clicking on Caps doesn't change the key display, but the key clicked prints the correct caps character. The key display then changes, and the correct character is still printed.

However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though.


BTW, there is still an issue with the change of background colour, which also happened with my patches. If you run kvkbd with the keramik style, you'll see that on a change of background colour, there is a bleed through of the previous colour at the edge of the rectangular footprint of the key. That disappears after a restart.

Built to commit 00e207e.. What I see is Shift shows shift characters, and click on character prints that shift character - all OK When kvkbd is first launched, clicking on Caps doesn't change the key display, but the key clicked prints the correct caps character. The key display then changes, and the correct character is still printed. However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though. -------- BTW, there is still an issue with the change of background colour, which also happened with my patches. If you run kvkbd with the keramik style, you'll see that on a change of background colour, there is a bleed through of the previous colour at the edge of the rectangular footprint of the key. That disappears after a restart.
Owner

Hi Ray,
first of all thanks for testing and reporting.

What I see is Shift shows shift characters, and click on character prints that shift character - all OK

Thanks. Actually here I see something weird in a special case. If I run kvkbd from the menu, all is good. If I run kvkbd from command line, the first time I press Shift does not changes the displayed characters, although the correct character is printed. I tried debugging this and I can see the correct characters are passed to TQPushButton::setText() but for some reasons it is not updated. I don't know why and didn't wanted to waste more time looking into TQPushButton at the moment, given it is a very specific and limited case.

When kvkbd is first launched, clicking on Caps doesn't change the key display, but the key clicked prints the correct caps character. The key display then changes, and the correct character is still printed.

Here (TDE inside VirtualBox) CAPS didn't seem to work at all from kvkbd yesterday. But it seems to work now, not sure VB or Windows or AHK played a part in it. Anyhow it is a good news to see CAPS working again.
I can confirm the bug with the characters not changing when you first press CAPS, I will investigate and see if it is related to what I wrote above for shift.

However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though.

Confirmed. Believe it or not, I had never noticed that CAPS didn't shift non alpha characters in 25+ years (ok, I never use CAPS, so that is a mitigation factor 😄 In fact I remapped CAPS to work as ESC or LCTRL depending how long I keep it pressed)

BTW, there is still an issue with the change of background colour, which also happened with my patches. If you run kvkbd with the keramik style, you'll see that on a change of background colour, there is a bleed through of the previous colour at the edge of the rectangular footprint of the key. That disappears after a restart.

Confirmed. It could be a Keramik style issue or a palette issue.

Hi Ray, first of all thanks for testing and reporting. > What I see is Shift shows shift characters, and click on character prints that shift character - all OK Thanks. Actually here I see something weird in a special case. If I run kvkbd from the menu, all is good. If I run kvkbd from command line, the first time I press Shift does not changes the displayed characters, although the correct character is printed. I tried debugging this and I can see the correct characters are passed to TQPushButton::setText() but for some reasons it is not updated. I don't know why and didn't wanted to waste more time looking into TQPushButton at the moment, given it is a very specific and limited case. > When kvkbd is first launched, clicking on Caps doesn't change the key display, but the key clicked prints the correct caps character. The key display then changes, and the correct character is still printed. Here (TDE inside VirtualBox) CAPS didn't seem to work at all from kvkbd <b>yesterday</b>. But it seems to work now, not sure VB or Windows or AHK played a part in it. Anyhow it is a good news to see CAPS working again. I can confirm the bug with the characters not changing when you first press CAPS, I will investigate and see if it is related to what I wrote above for shift. > However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though. Confirmed. Believe it or not, I had never noticed that CAPS didn't shift non alpha characters in 25+ years (ok, I never use CAPS, so that is a mitigation factor :smile: In fact I remapped CAPS to work as ESC or LCTRL depending how long I keep it pressed) > BTW, there is still an issue with the change of background colour, which also happened with my patches. If you run kvkbd with the keramik style, you'll see that on a change of background colour, there is a bleed through of the previous colour at the edge of the rectangular footprint of the key. That disappears after a restart. Confirmed. It could be a Keramik style issue or a palette issue.
Owner

However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though.

I can confirm this is something I broke in the last commit. I will fix it in the next one, thanks for highlighting this.

> However, the Caps display on the keys is the same as Shift, i.e. it shifts the non-alpha characters [not OK] as well as the alpha characters [OK] - the correct character is printed though. I can confirm this is something I broke in the last commit. I will fix it in the next one, thanks for highlighting this.
Owner

The wrong behavior of CAPS on non-alpha keys has been fixed in commit 48c1053 (R14.1) and 37c2617 (R14.0).
The strange behavior with the key text not behaving correctly the first time CAPS/shift is pressed is still open and need further investigation.

There is also some more code to merge from the original patch proposed by Ray.

The wrong behavior of CAPS on non-alpha keys has been fixed in commit 48c1053 (R14.1) and 37c2617 (R14.0). The strange behavior with the key text not behaving correctly the first time CAPS/shift is pressed is still open and need further investigation. There is also some more code to merge from the original patch proposed by Ray.
Owner

Correct visualization of key's text when CAPS/shift is first pressed has been fixed in commit af106fa (R14.1) and 221d437 (R14.0).
Also this commit includes a small part of Ray's patch to correctly display & when it is a lowercase key.

Correct visualization of key's text when CAPS/shift is first pressed has been fixed in commit af106fa (R14.1) and 221d437 (R14.0). Also this commit includes a small part of Ray's patch to correctly display & when it is a lowercase key.
Owner

Commit 9baea35 (R14.1) and 0ed64e3 (R14.0) adds the remaining part of Ray's patch, except the picture dock.png.
@Ray-V would you be able to test the current version and check/confirm I didn't miss or break anything else?

Regarding dock.png, I would like to propose different default colors, more TDE-stylish (see attached picture).
From kvkbdrc:

keyboardBackgroundColor=#4b96e1
keysColor=#ffffff

What do you think?

Commit 9baea35 (R14.1) and 0ed64e3 (R14.0) adds the remaining part of Ray's patch, except the picture dock.png. @Ray-V would you be able to test the current version and check/confirm I didn't miss or break anything else? Regarding dock.png, I would like to propose different default colors, more TDE-stylish (see attached picture). From kvkbdrc: ``` keyboardBackgroundColor=#4b96e1 keysColor=#ffffff ``` What do you think?
Owner

I discussed with Slavek on IRC. He prefers the colors alrady in master, so forget the question about the new color scheme. Will push dock.png as is.

I discussed with Slavek on IRC. He prefers the colors alrady in master, so forget the question about the new color scheme. Will push dock.png as is.
Owner

dock.png added in commit 9b8a822 (R14.1) and bc887b7 (R14.0). This concludes the merging of this PR.

@Ray-V as mentioned above, please test and let me know if there is any issue or if I missed anything.

Thanks for the great contribution!!

dock.png added in commit 9b8a822 (R14.1) and bc887b7 (R14.0). This concludes the merging of this PR. @Ray-V as mentioned above, please test and let me know if there is any issue or if I missed anything. Thanks for the great contribution!!
Ray-V commented 3 years ago
Poster
Collaborator

@MicheleC

I've done a build to the latest commit, e52070a, and for the FR azerty, IT qwerty, etc keyboards, it needs more work.

Starting with an example for eacute<AE02> key on the French keyboard.

French - é - prints        Shift=2   Caps=É   Caps+Shift=2

Character displayed on key:
             commit        Shift=2   Caps=2   Caps+Shift=é
             my patch      Shift=2   Caps=É   Caps+Shift=2  

Referencing the patches I set up to differentiate between lower, shift, and upper characters:

MainWidget.cpp:

void MainWidget::setupText(VButton& v)
{
	
	KeyCode keycode=v.getKeyCode();
// first level character keysym
	KeySym keysym_l = XkbKeycodeToKeysym(display, keycode, 0, 0);
// second level, ie shift, character keysym
	KeySym keysym_s = XkbKeycodeToKeysym(display, keycode, 0, 1);

	long retl = keysym2ucs(keysym_l);
	
		TQChar l((uint)retl);
		if (l=='&')
			v.setText("&&");
		else
			v.setText(l);

	long rets = keysym2ucs(keysym_s);

		TQChar s((uint)rets);
		if (s=='&')
			v.setShiftText("&&");
		else
			v.setShiftText(s);
}

VButton.cpp:

void VButton::shiftPressed(bool press)
{
	if (press==true)
		TQPushButton::setText(s);
	else
		TQPushButton::setText(l);
}
void VButton::capsPressed(bool press)
{
	if (press==true) {
		TQString tu=l.upper();
		TQPushButton::setText(tu); }
	else
		TQPushButton::setText(l);
}

The way I see it, there are three character sets to consider:

[1] The first level, lower, character is derived from:
XkbKeycodeToKeysym(display, keycode, 0, 0)

[2] The second level, shift, character is derived from:
XkbKeycodeToKeysym(display, keycode, 0, 1)

and these two are defined in the keyboard mapping files in /etc/X11/xkb/symbols or /usr/share/X11/xkb/symbols.

[3] The caps character is derived from:
l.upper()

[I don't know the reference source for that]

kvkbd code only covers 1st and 2nd level characters, l and s, so the following is true in that context only.

On the US qwerty keyboard, the alpha characters are separate from non-alpha characters, and Caps becomes a sub-set of Shift.
I.e. pressing Caps will generate upper case characters from the lower alpha keys, but will not shift the non-alphas, whereas pressing Shift will generate upper case characters from the lower alpha keys, and WILL shift the non-alphas.

In that context, the original algorithm, and your commits, work.

HOWEVER, many international keyboards don't have this neat division of separate keys for alpha and non-alpha characters, as per the French and Italian examples.

The original algorithm tried to separate shift and upper characters from a comparison of l to l.upper() and for those non-US keyboards this just doesn't work, and it seems you're thinking along similar lines [ref commit 48c1053fa1e5:

+connect ( caps,TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( toggleShift ( unsigned int ) ) );
 other_keys.append(caps);
-connect ( caps,TQT_SIGNAL ( clicked() ),this,TQT_SLOT ( toggleCaps() ) );
-connect ( caps,TQT_SIGNAL ( keyClick ( unsigned int ) ),this,TQT_SLOT ( keyPress ( unsigned int ) ) );

My programming abilities are way down the list compared to yours, but I would ask you to reconsider the algorithm I set up, especially with respect to separately considering lower[l], shift[s], and uppercase[u] characters.

It's not perfect as this example for an Italian keyboard shows, but for the key combinations that are most likely to be used, i.e. lower, shift, and caps, it works, and I imagine could be adapted to cover the Caps+Shift situation.

Example for ograve<AC10> on the Italian keyboard.

Italian - ò - prints       Shift=ç   Caps=Ò   Caps+Shift=Ç

Character displayed on key:
              commit       Shift=ç   Caps=ç   Caps+Shift=ò
              my patch     Shift=ç   Caps=Ò   Caps+Shift=ç  

As for crediting me as an author, I appreciate the intent but feel my input is less than authorship, and more a contribution of ideas, with an attempt at a solution.

@MicheleC I've done a build to the latest commit, e52070a, and for the FR azerty, IT qwerty, etc keyboards, it needs more work. Starting with an example for eacute&lt;AE02> key on the French keyboard. ``` French - é - prints Shift=2 Caps=É Caps+Shift=2 Character displayed on key: commit Shift=2 Caps=2 Caps+Shift=é my patch Shift=2 Caps=É Caps+Shift=2 ``` Referencing the patches I set up to differentiate between lower, shift, and upper characters: **MainWidget.cpp:** ``` void MainWidget::setupText(VButton& v) { KeyCode keycode=v.getKeyCode(); // first level character keysym KeySym keysym_l = XkbKeycodeToKeysym(display, keycode, 0, 0); // second level, ie shift, character keysym KeySym keysym_s = XkbKeycodeToKeysym(display, keycode, 0, 1); long retl = keysym2ucs(keysym_l); TQChar l((uint)retl); if (l=='&') v.setText("&&"); else v.setText(l); long rets = keysym2ucs(keysym_s); TQChar s((uint)rets); if (s=='&') v.setShiftText("&&"); else v.setShiftText(s); } ``` **VButton.cpp:** ``` void VButton::shiftPressed(bool press) { if (press==true) TQPushButton::setText(s); else TQPushButton::setText(l); } void VButton::capsPressed(bool press) { if (press==true) { TQString tu=l.upper(); TQPushButton::setText(tu); } else TQPushButton::setText(l); } ``` The way I see it, there are three character sets to consider: [1] The first level, lower, character is derived from: XkbKeycodeToKeysym(display, keycode, 0, 0) [2] The second level, shift, character is derived from: XkbKeycodeToKeysym(display, keycode, 0, 1) and these two are defined in the keyboard mapping files in /etc/X11/xkb/symbols or /usr/share/X11/xkb/symbols. [3] The caps character is derived from: l.upper() [I don't know the reference source for that] kvkbd code only covers 1st and 2nd level characters, l and s, so the following is true in that context only. On the US qwerty keyboard, the alpha characters are separate from non-alpha characters, and Caps becomes a sub-set of Shift. I.e. pressing Caps will generate upper case characters from the lower alpha keys, but will not shift the non-alphas, whereas pressing Shift will generate upper case characters from the lower alpha keys, and WILL shift the non-alphas. In that context, the original algorithm, and your commits, work. HOWEVER, many international keyboards don't have this neat division of separate keys for alpha and non-alpha characters, as per the French and Italian examples. The original algorithm tried to separate shift and upper characters from a comparison of l to l.upper() and for those non-US keyboards this just doesn't work, and it seems you're thinking along similar lines [ref commit 48c1053fa1e5: <span style="color:blue">+connect ( **caps**,TQT_SIGNAL ( keyClick ( unsigned int ) ), this, TQT_SLOT ( **toggleShift** ( unsigned int ) ) ); <span style="color:black">&nbsp;other_keys.append(caps); <span style="color:red">-connect ( **caps**,TQT_SIGNAL ( clicked() ),this,TQT_SLOT ( **toggleCaps**() ) ); -connect ( caps,TQT_SIGNAL ( keyClick ( unsigned int ) ),this,TQT_SLOT ( keyPress ( unsigned int ) ) );</span> My programming abilities are way down the list compared to yours, but I would ask you to reconsider the algorithm I set up, especially with respect to separately considering lower[l], shift[s], and uppercase[u] characters. It's not perfect as this example for an Italian keyboard shows, but for the key combinations that are most likely to be used, i.e. lower, shift, and caps, it works, and I imagine could be adapted to cover the Caps+Shift situation. Example for ograve&lt;AC10> on the Italian keyboard. ``` Italian - ò - prints Shift=ç Caps=Ò Caps+Shift=Ç Character displayed on key: commit Shift=ç Caps=ç Caps+Shift=ò my patch Shift=ç Caps=Ò Caps+Shift=ç ``` As for crediting me as an author, I appreciate the intent but feel my input is less than authorship, and more a contribution of ideas, with an attempt at a solution.
Owner

Hi Ray,
thanks for testing and for such detailed report. I will look into this today or tomorrow. If I have further questions, I will ask here.

As for crediting me as an author, I appreciate the intent but feel my input is less than authorship, and more a contribution of ideas, with an attempt at a solution.

You have done some major improvements here, credit is due 😄 Anyhow if you don't want to be mentioned there, I can remove your name. Perhaps I should have asked first, my bad.

Hi Ray, thanks for testing and for such detailed report. I will look into this today or tomorrow. If I have further questions, I will ask here. > As for crediting me as an author, I appreciate the intent but feel my input is less than authorship, and more a contribution of ideas, with an attempt at a solution. You have done some major improvements here, credit is due :smile: Anyhow if you don't want to be mentioned there, I can remove your name. Perhaps I should have asked first, my bad.
Owner

Ok, I finally read through the long report. Extremely useful! Clearly my assumptions/test cases were not enough, so I will look back at the shift/caps algorithm in your patch and will integrate the part that I missed. Will also try to see if we can fix the weird cases with special characters.

Ok, I finally read through the long report. Extremely useful! Clearly my assumptions/test cases were not enough, so I will look back at the shift/caps algorithm in your patch and will integrate the part that I missed. Will also try to see if we can fix the weird cases with special characters.
Owner

Hi @Ray-V,
PR #10 should fix the problem. I tested with the test cases you reported above and it now seems ok to me.
I will wait for you to test with PR #10 before I merge that, just in case.

Hi @Ray-V, PR #10 should fix the problem. I tested with the test cases you reported above and it now seems ok to me. I will wait for you to test with PR #10 before I merge that, just in case.
Ray-V commented 3 years ago
Poster
Collaborator

Anyhow if you don't want to be mentioned there, I can remove your name.

Yes please, I'm happy to be just mentioned as a contributor to the project.

> Anyhow if you don't want to be mentioned there, I can remove your name. Yes please, I'm happy to be just mentioned as a contributor to the project.
MicheleC referenced this issue from a commit 3 years ago
MicheleC referenced this issue from a commit 3 years ago
Owner

Anyhow if you don't want to be mentioned there, I can remove your name.

Yes please, I'm happy to be just mentioned as a contributor to the project.

ok, done 😄

> > Anyhow if you don't want to be mentioned there, I can remove your name. > > Yes please, I'm happy to be just mentioned as a contributor to the project. ok, done :smile:
Ray-V commented 3 years ago
Poster
Collaborator

I will wait for you to test with PR #10 before I merge that, just in case.

Built to commit b1c1fd9.

Those issues now check out OK.

@MicheleC

I think the app was looking a bit tired before and I was ready to dump it for something more useful.
But there's nothing like a real world application to create an incentive to sort something out.

Thanks for tolerating my attempts at programming.
It's looking good and working well now and I hope you'll agree, it's been worth the time and effort.

>I will wait for you to test with PR #10 before I merge that, just in case. Built to commit b1c1fd9. Those issues now check out OK. @MicheleC I think the app was looking a bit tired before and I was ready to dump it for something more useful. But there's nothing like a real world application to create an incentive to sort something out. Thanks for tolerating my attempts at programming. It's looking good and working well now and I hope you'll agree, it's been worth the time and effort.
Owner

Hi @Ray-V,
thanks for testing #10. Code merged already, so I believe all the features of this PR have been added to master, except those points which I mentioned in previous comments that would not be added.
If there is something still missing, please let me know. Otherwise if ok for you, I will close this PR as well.

It's looking good and working well now and I hope you'll agree, it's been worth the time and effort.

Yes, much better than before 👍

Thanks for tolerating my attempts at programming.

Open source is about team work, so everyone is welcome to contribute and by working together the whole project will benefit. It took a while before we had time to look at your PR in detail, but in the end we got there.
So big THANK YOU to you for the good work and if you feel like contributing more fixes or features somewhere else we will definitely have a look in the same way 😄
Keep it up!!

Hi @Ray-V, thanks for testing #10. Code merged already, so I believe all the features of this PR have been added to master, except those points which I mentioned in previous comments that would not be added. If there is something still missing, please let me know. Otherwise if ok for you, I will close this PR as well. > It's looking good and working well now and I hope you'll agree, it's been worth the time and effort. Yes, much better than before :+1: > Thanks for tolerating my attempts at programming. Open source is about team work, so everyone is welcome to contribute and by working together the whole project will benefit. It took a while before we had time to look at your PR in detail, but in the end we got there. So big <b>THANK YOU</b> to you for the good work and if you feel like contributing more fixes or features somewhere else we will definitely have a look in the same way :smile: Keep it up!!
Owner

@Ray-V
please let us know if we can close this PR. AFAICT, all work has been merged, except those points mentioned in comments.

@Ray-V please let us know if we can close this PR. AFAICT, all work has been merged, except those points mentioned in comments.
Ray-V commented 3 years ago
Poster
Collaborator

@MicheleC

please let us know if we can close this PR. AFAICT, all work has been merged, except those points mentioned in comments.

Yes, everything on this PR has been covered.

@MicheleC > please let us know if we can close this PR. AFAICT, all work has been merged, except those points mentioned in comments. Yes, everything on this PR has been covered.
Ray-V closed this pull request 3 years ago
MicheleC deleted branch bug/fix-keycodes 3 years ago
This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: TDE/kvkbd#9
Loading…
There is no content yet.