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
@@ -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 ..
## 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."
## 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.
## 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.
## 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
## 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 );
```
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?
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 keycodes4 years ago
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.
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.
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.
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?
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.
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:
To enable user to select their own colours for the keyboard and/or keys/buttons.
Save the selected colours to the configuration file and load them when Kvkbd is restarted.
Needs a restart when the key colour is changed.
Signed-off-by: Ray-V <ray-v@inbox.lv>
The keyboard geometry is saved when either Quit or Hide keyboard is selected.
If the num pad is visible [extent_visible=true] when Kvkbd is closed down - ie Quit from the configuration menu - then when it is run again, with the default being extent_visible=false, the keyboard will display without the numpad but at an x-axis size which includes the num pad, ie elongated.
To fix this, add the state of extent_visible to the configuration file and start with that when Kvkbd is re-started.
Signed-off-by: Ray-V <ray-v@inbox.lv>
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).
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):
Use icons for quit and num pad show/hide buttons.
Resize quit, num pad show/hide, configure buttons.
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.
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.
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).
@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.
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.
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:
after startup of kvkdb
after pressing lshift. Note characters are still lowercase
after pressing again lshift to release the key. Characters now become uppercase
after pressing lshift again. Characters turn to lowercase
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?
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.
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.
the lowercase/uppercase issue. I will work at fixing that
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.
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.
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.
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.
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.
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.
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.
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?
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!!
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:
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<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"> 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<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.
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.
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.
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.
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:
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.
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!!
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.
Fix keycodes for:
Right shift
Win key
AltGr to select lower right key characters
Menu key
Right control
Num pad divide
Num pad Enter
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?
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
## 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
## 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.
## Set a more realistic initial font size
## 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 ..
## 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."
## add a tooltip for the panel icon
## 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.
## 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.
## 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
## use icons for quit and num pad show/hide buttons
## these are the 16x16/actions icons used for the system selected icon set
## Display '&' where it is the lower key character on the key
## E.g. fr be azerty keyboards
## Add RWin button
## resize quit, num pad show/hide, configure buttons to see the icons better at reduced size of keyboard
## missing characters in keysymtab[] - for AC12 -> AD13 key on ua keyboard
## generate keycode for Win keys with single click so that they can be used for xmodmap
User set option in the build script
How do I remove the WIP: from the title?
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)
WIP: Fix keycodesto Fix keycodes 4 years agoI'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.
Fussy about what formats it will accept for file uploads isn't it!
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.
attached file == commit in the branch.
The previous 3 commits have been included in this new commit which adds the 3 new issues.
Presumably this comment is if attached file != commit in the branch.
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.
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.
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?
@MicheleC
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.
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.
This is also what I see. In my opinion it is a bug 😉
I don't think this is a feature, it looks more like a bug to me.
The point is that small discrete commits makes the job of a reviewer easier 😄
Great, thanks for the additional commits and for splitting them up, appreciated 😉
Commit
3503aa510b
slightly reworked and pushed asd1fca94
(R14.1) and2c38847
(R14.0).Further work to come.
Fix keycodesto WIP: Fix keycodes 3 years agoLock on screen functionality added and improved in commits
0da79dd
,b53e333
,aae2b17
(R14.1) and16e7cd4
,9ef732a
,bea04fd
(R14.0)RWin key has been added in commit
2af99da
(R14.1) and69b02ce
(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) and3374fd5
(R14.0).Tooltip for system tray icon added in commit
1342053
(R14.1) andabbc87e
(R14.0)Renaming of numpad keys (Home, End, PgUp, PgDn, NumLock) will not be added to the code.
Commit
ed6e395
(R14.1) and51c93c1
(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):Commit
2aaedb4
(R14.1) anddf86438
(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.Keycodes fixed in commit
8bbaa8f
(R14.1) and543ee09
(R14.0).Commit
47d89f2
(R14.1) andcf258cd
(R14.0) simplify the code related to numpad buttons. No more duplicated keycodes required.Commit
8371e74692
(select keyboard colors) has been reworked and merged in commitdd8d527
(R14.1) and9834ca3
(R14.0).The color of the keyboard keys can now be changed without the need to restart the application. Commits
64d40d9
,94e4d4d
(R14.1) and4918c52
,d26a127
(R14.0).Less-than/greater-than key added near left shift in commit
f84f133
(R14.1) and6ceda6a
(R14.0).Additional translations added in commit
2c080a7
(R14.1) and9e2e5d8
(R14.0).@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.
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.
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:
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?
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.
Commit
00e207e
(R14.1) and1865767
(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.
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.
Hi Ray,
first of all thanks for testing and reporting.
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.
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.
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)
Confirmed. It could be a Keramik style issue or a palette issue.
I can confirm this is something I broke in the last commit. I will fix it in the next one, thanks for highlighting this.
The wrong behavior of CAPS on non-alpha keys has been fixed in commit
48c1053
(R14.1) and37c2617
(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.
Correct visualization of key's text when CAPS/shift is first pressed has been fixed in commit
af106fa
(R14.1) and221d437
(R14.0).Also this commit includes a small part of Ray's patch to correctly display & when it is a lowercase key.
Commit
9baea35
(R14.1) and0ed64e3
(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:
What do you think?
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.
dock.png added in commit
9b8a822
(R14.1) andbc887b7
(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!!
@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.
Referencing the patches I set up to differentiate between lower, shift, and upper characters:
MainWidget.cpp:
VButton.cpp:
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.
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.
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.
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.
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.
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.
Yes please, I'm happy to be just mentioned as a contributor to the project.
ok, done 😄
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.
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.
Yes, much better than before 👍
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!!
@Ray-V
please let us know if we can close this PR. AFAICT, all work has been merged, except those points mentioned in comments.
@MicheleC
Yes, everything on this PR has been covered.