Announcement

Collapse
No announcement yet.

KDE Delivers More Wayland Fixes & Plasma 6.0 Changes This Week

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by TemplarGR View Post

    These issues do not exist for me.....
    For me neither and I too have AMD only.

    Comment


    • #22
      The only thing missing for me still in Wayland is auto cursor hiding support, like uncluttered on X provides. Tried a few tools that claim to work with Wayland, but none of them functioned or were not even developed anymore. And I submitted a KDE bug report to get it implemented in KDE and despite a few people that also wanted it, they declined my proposal.

      Comment


      • #23
        Originally posted by Vistaus View Post
        The only thing missing for me still in Wayland is auto cursor hiding support, like uncluttered on X provides. Tried a few tools that claim to work with Wayland, but none of them functioned or were not even developed anymore. And I submitted a KDE bug report to get it implemented in KDE and despite a few people that also wanted it, they declined my proposal.
        Add an option to hide the visible pointer cursor. This is primarily useful for embedded and touchscreen-driven systems, where a pointer device may be present (through various input/HID...


        It is a feature of the Wayland reference compositor weston. Do read why the feature is there. So far the requests for KDE it would be nice. Please note KDE also had this feature built in the past and had user complaining that their mouse pointer was disappearing.

        Person submitting to Weston used the embedded case where the interface is touch but a mouse is plugged in and hidden away and not moving leading to a not used pointer remaining on screen.
        Last edited by oiaohm; 19 March 2023, 07:46 PM.

        Comment


        • #24
          Originally posted by oiaohm View Post
          Please note KDE also had this feature built in the past and had user complaining that their mouse pointer was disappearing.
          They could just add it as an option in System Settings and disable it by default. That way, if people do complain, it's their own fault, but users like me who type a lot and don't want to move the cursor out of the way constantly have the option to make it disappear.

          Comment


          • #25
            Originally posted by Vistaus View Post
            They could just add it as an option in System Settings and disable it by default. That way, if people do complain, it's their own fault, but users like me who type a lot and don't want to move the cursor out of the way constantly have the option to make it disappear.
            Again look at the open issues being attempted with KDE. Not asking as a directly optional feature and not using embedded case and not using that the reference compositor Weston has it. There is a quality of request problem.

            Also there are people like me who don't care if the mouse cursor is in way(because the text curses are fairly small) it more knowing where the mouse before hand hits mouse alter choice at times between using keyboard options or using mouse. Basically like using shift/arrow key select or using mouse drag select based on if the mouse is close by or not. I do also type a lot there is a big difference in preference here. Some users find a disappearing mouse pointer really annoying and some of those users do really type a lot.

            Also auto hiding mouse cursor can backfire badly think person playing a game where mouse has to stay still for awhile. So there is the question if this feature owns in the compositor or in the application. In the application can be more selective as only disappear the cursor when you are doing text entry since the application can tell what is keyboard short cuts and other possible special key presses that are not text entry. Problem come about here due to compositors limited information.

            Compositor having the feature to disappear mouse cursor when it appear to be just text entry has it issues but could be useful for some people work around feature but you have to remember compositor not going to have the information to make the correct judgement call here all the time. Yes having the feature as compositor enabled per application work around would be good. Having a universal way like in xdg-desktop-portal to inform applications that they should disappear mouse cursor when doing text entry would be good as well. We do lack a generic platform wide common setting information to applications item.

            Comment


            • #26
              Originally posted by oiaohm View Post

              Again look at the open issues being attempted with KDE. Not asking as a directly optional feature and not using embedded case and not using that the reference compositor Weston has it. There is a quality of request problem.

              Also there are people like me who don't care if the mouse cursor is in way(because the text curses are fairly small) it more knowing where the mouse before hand hits mouse alter choice at times between using keyboard options or using mouse. Basically like using shift/arrow key select or using mouse drag select based on if the mouse is close by or not. I do also type a lot there is a big difference in preference here. Some users find a disappearing mouse pointer really annoying and some of those users do really type a lot.

              Also auto hiding mouse cursor can backfire badly think person playing a game where mouse has to stay still for awhile. So there is the question if this feature owns in the compositor or in the application. In the application can be more selective as only disappear the cursor when you are doing text entry since the application can tell what is keyboard short cuts and other possible special key presses that are not text entry. Problem come about here due to compositors limited information.

              Compositor having the feature to disappear mouse cursor when it appear to be just text entry has it issues but could be useful for some people work around feature but you have to remember compositor not going to have the information to make the correct judgement call here all the time. Yes having the feature as compositor enabled per application work around would be good. Having a universal way like in xdg-desktop-portal to inform applications that they should disappear mouse cursor when doing text entry would be good as well. We do lack a generic platform wide common setting information to applications item.
              Sure, we'll make it application-based then. I'll open 30 bug reports with all the software I'm using, which, btw, includes a lot of KDE software.

              Comment


              • #27
                Originally posted by Vistaus View Post
                Sure, we'll make it application-based then. I'll open 30 bug reports with all the software I'm using, which, btw, includes a lot of KDE software.
                Remember the application side splits in two as well.
                1) application code
                2) toolkit code.
                All KDE software uses the Qt toolkit and all text entry boxes are drawn and processed by the Qt toolkit so there is the possibility of patch the toolkit.

                Doing something right sometimes end up with a horrible number of bug reports. Sometimes it just requires think about where the information is to do the task right. To hide mouse cursor correctly the information is all application side. To hide mouse cursor need to allign with whatever is processing the text boxes and in KDE application cases that the Qt toolkit.

                I only had thought so far. I was thinking just from the compositors point of view and what information it had in the prior post. I was not thinking where in side application functionality had to be.

                There are cases where it would be open a bug on every application but I don't think this is one of them. Yes having to open a bug with every toolkit that draws textbox that is used is still quite a number of bugs this still could be 30 bugs.

                Comment

                Working...
                X