Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay after opening Application Menu (mainmenu) #1770

Open
jetibest opened this issue Apr 8, 2022 · 6 comments · May be fixed by #1771
Open

Delay after opening Application Menu (mainmenu) #1770

jetibest opened this issue Apr 8, 2022 · 6 comments · May be fixed by #1771

Comments

@jetibest
Copy link

jetibest commented Apr 8, 2022

Expected Behavior

I configured the SUPER/WIN key to open up the application menu (mainmenu).
So I press the SUPER/WIN key, and after the key is released, the application menu opens up, with the focus set to the search bar.
Then I can immediately type a keyword, to search for a program, and type Enter/Return to start it.

Current Behavior

After pressing the SUPER/WIN key, the application menu takes maybe 200ms to open up, then puts the focus to the search bar.
When typing on my keyboard: Super_L + H + E + L + L + O, in a regular fast typing speed, the menu is too slow, and the search bar now only contains "llo" instead of "hello".

Possible Solution

Either make the menu popup instantly, with proper caching or something, I don't know how it works, but maybe already show the panel invisibly, and then only turn it visible, so that it is either faster to display or can already set focus to the search bar even while it is not visible yet.

Or register the keys from the keyboard before showing the menu, and re-simulate the keypresses after the menu is showing. Also, for instance, if pressing Super_L + Arrow_Up + Arrow_Up + Return, to quickly lock the screen ('lock screen' being just above the search bar).

Since I am not familiar with the code, it's hard to tell what could solve this, but these are just generic ideas that might help you brainstorm a proper solution.

Steps to Reproduce (for bugs)
  1. Right-click Application Menu in the panel
  2. In Main Menu settings, setup Keyboard Shortcut to Super_L, and close the dialog.
  3. Press Super_L, and immediately keep on typing any word, such as "hello".
  4. Notice that only "ello" or "llo" is typed into the search bar.
Context

I know it can be done, because I'm used to KDE Plasma, and I've always found it incredibly useful to be able to run a program or use arrow keys to run a "favorite" program within a few quick keypresses. I have by no means a slow computer, or slow disk (using M.2 SSD), but still this delay exists. I can only imagine how counterproductive this issue must be on a computer less fast.

A separate shortcut would work, but it is easier to remember the name of the application you want to run (hard to forget), than to remember which shortcut you assigned it to (like Super_L + R to start a terminal application). I've found the start menu more accessible for this purpose, and it seems like the goal of a start menu to do this particular task.

Using the mouse there would not be a problem. However, you want to use a keyboard, because for instance, while programming, you are already having your hands on the keyboard. Then you want to quickly run some stuff in a terminal, after which you need the keyboard again. Grabbing your mouse, is an additional action that will simply slow you down.

System Information
  • LXQt Version: 1.0.0
  • Distribution & Version: Arch Linux 5.17.1-arch1-1 build fails #1 SMP PREEMPT Mon, 28 Mar 2022 20:55:33 +0000 x86_64 GNU/Linux
  • Qt Version: 5.15.3
  • liblxqt Version: ?
@palinek
Copy link
Contributor

palinek commented Apr 8, 2022

This was introduced a long time ago as a workaround for gathering focus problem -> #131
So the delay has nothing to do with slowness, but is there intentionally.
Now when looking at this I believe the root cause of the focus problem was in the lxqt-globalkeys and its "catching" of shortcut on KeyPress intead of KeyRelease. That was addressed recently (I don't remember the exact time).

Now removing the delay doesn't introduce any focus problems for me. I'll make a PR for others to confirm also.

@palinek palinek linked a pull request Apr 8, 2022 that will close this issue
@palinek
Copy link
Contributor

palinek commented Apr 8, 2022

@jetibest Can you, please, check if #1771 fixes this and doesn't cause any other problems?

@jetibest
Copy link
Author

jetibest commented Apr 8, 2022

@palinek That's unexpectedly fast. This explains a lot, thank you.

I would like to try it, I've already tried cloning the repository and checkout your menu-drop-delay branch, but I'm not sure how to compile this. I'm not very familiar with build tools in general.

The readme says something like: "To build run make, to install make install which accepts variable DESTDIR as usual." However, there is no Makefile. Then I tried running cmake (seeing there is a cmake directory), but that doesn't work out either. Any ideas?

@palinek
Copy link
Contributor

palinek commented Apr 8, 2022

If you don't intend to develop LXQt or use your self-built components in the future, then don't bother with the building feature branches.
As you're on arch, you can wait until PR merged and use the git versions of packages from AUR.

@jetibest
Copy link
Author

jetibest commented Apr 8, 2022

Nevermind, reading the error message more carefully I found out about lxqt-build-tools. I followed the instructions, which is sort of like:

export CMAKE_INSTALL_PREFIX="/usr"
mkdir build
cd build
cmake /opt/lxqt-build-tools
make
sudo make install

And then repeated the same for lxqt-panel. This worked out well. As for the installing, I just copied the necessary files from /usr/local to /usr to apply the newly compiled files, this worked fine too.

After restarting lxqt, I can now see that the delay is gone, but a new problem exists with quickly typing something (again something I'm not used to in KDE Plasma). As far as my initial description of the problem goes, this is sort of the same issue, but I could open a new issue if you want.

If I previously searched using Super_L + "konsole", then wait for the results, and then press Return. It opens Konsole. However, if I then quickly type Super_L + "dolphin" + Return, before any search results show up, then it will again open Konsole (the previously opened one). Expected result is that Dolphin is opened instead of Konsole. This only works if Return is pressed before any result can be returned.

Also, after using: Super_L + "aoeuaoeu" (anything that does not exist) + Return, then after pressing return, the focus is lost. I cannot go back to correct the spelling. In reality, I do see that one of the folders is highlighted in blue just before it collapses to show that no results are found. If I do not press Return quickly, then it does not lose focus. Pressing ESC does return me to giving the start menu, but still, the focus is not in the Search bar.

@tsujan
Copy link
Member

tsujan commented Apr 8, 2022

sudo make install

Installing directly from the source may cause two problems in all distros: (1) You may inadvertently install it under /usr/local, which could cause a headache later; and (2) the package manager won't be aware of the installation.

In Arch and its derivatives, you almost never need to do so. instead, use/make a PKGBUILD and create an installable package.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants