[kdeconnect] [Bug 411731] WiFi barcode scanning
https://bugs.kde.org/show_bug.cgi?id=411731 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 411399] KDEConnect slow when bluetooth service is not started
https://bugs.kde.org/show_bug.cgi?id=411399 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #12 from Holger Kaelberer --- (In reply to OlafLostViking from comment #10) > For a functionality that lets me control the phone on my desktop (the best > would be just "mirror" one Android app into a window on my desktop) another > bug report would be better, right? Or would that fit into here, too? Sounds like a new (and different) feature, like a vnc connection or so. ;-) Not sure what exists in the Android world for such use-cases. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #11 from Holger Kaelberer --- kde: https://git.reviewboard.kde.org/r/129727/ Android: https://git.reviewboard.kde.org/r/129728/ -- You are receiving this mail because: You are watching all bug changes.
[gcompris] [Bug 373303] Missing 'L' alphabet from the virtual keyboard.
https://bugs.kde.org/show_bug.cgi?id=373303 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de --- Comment #2 from Holger Kaelberer --- And: which activity in which level? Note, that it is sometimes on purpose, that not all letters are shown. In gletters e.g. the keys on the virtual keyboard are generated from all letters that are contained in the current level, which often results in <26 letters! -- You are receiving this mail because: You are watching all bug changes.
[gcompris] [Bug 372036] Missing GCompris translations
https://bugs.kde.org/show_bug.cgi?id=372036 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #8 from Holger Kaelberer --- Ok, got it. That makes it easier. Give me some time to clean things up and prepare a reviewable version ... -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #6 from Holger Kaelberer --- Thanks for your feedback. (In reply to Albert Vaca from comment #3) > I think this is a needed addition to kdeconnect. About the format of the > packets, ideally it should be the same as the one used for desktop to phone > communication. This way, it will work desktop to desktop (eg:sending keys to > a Raspberry from my main desktop) and phone to phone too. Splitting it in > separate plugins makes sense Ok, then I will 1. split the mousepad-plugin into mousepad and remotekeyboard (new; mobile-to-desktop) and 2. add the desktop-to-mobile remote-keyboard part to the (newly created) remotekeyboard plugin. Right? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #2 from Holger Kaelberer --- (In reply to Holger Kaelberer from comment #1) > * On-the-wire format: Oups, I just realized that I forgot doing the most obvious thing: look at how keys are serialized in the mousepad plugin for mobile-to-desktop key events. I did now and found, that what you used could also serve my purposes, if I map the QKeyboardEvent.key to the specialKey property as used in a PACKAGE_TYPE_MOUSEPAD_REQUEST. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 --- Comment #1 from Holger Kaelberer --- I've got an experimental implementation of an InputMethod on Android to inject key-events from desktop-to-mobile. After some testing and improvements it seems to work pretty well for printable keys and some selected special keys (like Backspace/Arrow-keys/Return etc) and I wanted to ask your opinion on some points, Aleix and Albert (especially because I'm not an Android programmer -- yet ;-): Some misc. remarks/questions: * InputMethod and activation: For now the InputMethodService is baked into the MousePadPlugin. As soon as installed it is visible and selectable from the IME list in the Android settings. Once selected it remains the active InputMethod until it is deselected again by the user or kdeconnect is uninstalled. That means, it remains active also if not currently paired (with a remote device that supports the plugin). For me this behaviour was fine, but I'm not sure if it should remain like that. Depending on what is possible on android we could consider to ... ... De/Activate InputMethod automatically if not paired (if possible)? ... De/activate it based on capabilities of the paired device For now keys are only accepted when the keyboard is visible (InputMethodService.onStartInputView()). I think about adding a setting to enable accepting keys always (e.g. for selecting and starting apps on the home screen with arrow-/return-keys. On the visual side the keyboard only contains one row with a settings- and a keyboard-button for entering directly the settings dialog and the keyboard selection-dialog, resp. I think about adding a isPaired indicator and maybe a Return and a Backspace key. * On-the-wire format: I experimented a bit with the structure of the NetworkPackage payload (type "kdeconnect.keyboard"). Mere transferring of printable characters turned out to be insufficient, because it would become hard to handle special keys like backspace, Shift, etc. Therefore for now the payload basically contains a QKeyEvent serialized to JSON. This carries all information necessary to handle special and modifier keys. The Qt keycodes are then mapped to KeyEvent.KEYCODE_XXX values and some selected keys are handled in a special way (like Backspace, Left, Shift-Left, Home, etc.) and result in KeyEvent sequences on the android side. One could also think about using a (single-)char utf8 payload for the keyevents, mapping (selected) special keys to (corresponding) unicode-values. But this makes serialization on desktop-side more complex, and I'd prefer to stick to the QKeyEvent way. If a keyevent was successfully delivered to the InputMethod it is reported back to the remote keyboard (if requested), to allow for visualizing what arrived on the other side. It might be useful to add additional packages to signal keyboard-activation and disable typing on a remote keyboard if it is not possible to deliver anything or/and error-reporting to notify a remote typer why his keys did not reach their destination. * Plasmoid: To the plasmoid I added a TextField for inputting the remote keys and a second readonly one that echoes the keys confirmed from the remote side. I'm not yet completely happy with that. Ideally I think of a single TextField (or TextInput) not echoing keypresses immediately but only after having been ack-ed by the remote device, thus the user can see immediately what he typed remotely. But that would mean to interpret the echoed kepress-event equivalently to what is done on the remote side. I tried to manually inject a QKeyPress via postEvent directly to the TextField but that was not evaluated by the TextField, dunno why. Also added a command-line flag to kdeconnect-cli for sending keypresses (interactively) to a remote. * Plugin: For my POC everything lives inside the MousepadPlugin on both sides. As you already factored out the sendnotifications I wonder if I should add a new plugin for this direction of the remote-keyboard feature as well? * More possibilities: Add support for defining special keys on the smartphone (e.g. F1-F10) and make them execute special actions when pressed on the remote keyboard (Press menu button, start app X, ...) * Finally: Would you be interested in accepting it in KDE Connect? Please let me know what you think about it. After these first tests it looks promising and might be a nice extension especially for computer people that hate typing on an on-screen keyboard, like me :-P Thanks, regards, Holger -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 370919] Keyboard to smartphone
https://bugs.kde.org/show_bug.cgi?id=370919 Holger Kaelberer changed: What|Removed |Added CC||aleix...@gmail.com, ||holge...@elberer.de -- You are receiving this mail because: You are watching all bug changes.
[gcompris] [Bug 357901] Control bar buttons span out of the window
https://bugs.kde.org/show_bug.cgi?id=357901 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de --- Comment #2 from Holger Kaelberer --- (In reply to Stefan Toncu from comment #1) > Created attachment 96646 [details] > Fix for the Bug > > I added some variables and a function in order to compute the values needed > to resize the buttons. Best next step would be to open a review request on https://git.reviewboard.kde.org/ for gcompris and assign it to group gcompris. Reviewing code is better done there. Anyway, some nitpicks on your diff: + * type: real + * Minimum size for BarZoom + */ +property real minWidth: (parent.width-20- 10 * ApplicationInfo.ratio)/totalWidth properties, that don't change should be readonly property and don't need to be documented (does no harm of course ;-) +totalWidth+=computeWidth(buttonList[def].bid) +noButtons++ You probably could use property binding for totalWidth (http://doc.qt.io/qt-5/qtqml-syntax-propertybinding.html) which is the recommended way to dynamically change such values. But well it works nicely, so fine for me to keep it as is. > It works both in home menu and in activities. Yeah looks nice! Two things I noticed: 1. The levelText is the only element in the bar that is not yet scaled together with the other buttons. We could probably either use pixelSize and scale that down, or keep fontSize (== pointSize) and use a scale value. 2. When the buttons are already downscaled and you go from level 9 to level 10 the bar expands to display the additional digit in levelText and pushes the rightmost button out of the visible area. > > Observation: in some activities, in portrait mode, the "sublevel count" > overrides the "next level" button (i.e. "Algorithm"), but its drawn in every > activity that uses sublevels, so i couldn't make any changes regarding it > from the "bar.qml" file. Ack, in these cases the Score element should be moved to another place (if necessary depending on orientation). Do you want to fix this also? ;-) -- You are receiving this mail because: You are watching all bug changes.
[gcompris] [Bug 357950] Memorize window width/height and restore at startup
https://bugs.kde.org/show_bug.cgi?id=357950 Holger Kaelberer changed: What|Removed |Added CC||holge...@elberer.de -- You are receiving this mail because: You are watching all bug changes.
[gcompris] [Bug 357950] New: Memorize window width/height and restore at startup
https://bugs.kde.org/show_bug.cgi?id=357950 Bug ID: 357950 Summary: Memorize window width/height and restore at startup Product: gcompris Version: git master Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general Assignee: bruno.coud...@gcompris.net Reporter: holge...@elberer.de Currently the window-size is set to the screen dimensions when GCompris is not started in fullscreen mode. On desktop platforms this is annoying because a user might want to launch gcompris with a smaller window-size. It would improve usability in this respect if the last geometry would be stored in the ApplicationSettings (group "Internal") and restored at subsequent startups (unless started in fullscreen mode) for desktop platforms. Reproducible: Always Steps to Reproduce: 1. Start GCompris in non-fullscreen mode 2. resize the window to smaller geometry 3. stop and start the application again Actual Results: application window covers again the whole screen Expected Results: The window should have the same size as it had when it was closed the last time. -- You are receiving this mail because: You are watching all bug changes.
