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

Option to dismiss on focus lost #10

Closed
robert-sandor opened this issue Oct 21, 2021 · 8 comments
Closed

Option to dismiss on focus lost #10

robert-sandor opened this issue Oct 21, 2021 · 8 comments

Comments

@robert-sandor
Copy link

Add an option to dismiss the app on focus lost.
This would be much easier for a mouse user, than dismissing with Esc in case of a mis-click.
At the moment, losing focus just hides the window behing others, and leaves it open.

@sonnyp
Copy link
Owner

sonnyp commented Oct 21, 2021

A close button is a better solution.

  • Loosing focus by mistake is too easy - in which case you also risk looking the URL/path if it came from a ephemeral source
  • Junction may also loose focus because you want to check something first by alt-tabbing.
  • Or something unexpectedly grabs the focus.

@robert-sandor
Copy link
Author

The problem with a close button is that it still requires action from the user. Since the app opens on the middle of the screen, that would make it harder to close than hitting escape, negating the usefulness of it.

I would still argue that having the option to close of focus lost would be good to have, even if it would be an opt-in option, instead of being the default. Maybe with an on-window option to keep it open on a per-window basis, if losing an ephemeral sourced URL is a concern.

@sonnyp
Copy link
Owner

sonnyp commented Oct 21, 2021

Loosing focus also requires an action from the user right?

I concede that it's slightly harder to press the close button but

  1. it's familiar and unsurprising
  2. if Junction popups it's likely in response to user action so dismissing Junction is less of a concern

Do you have a special use case for this feature that I may not be thinking of?

@robert-sandor
Copy link
Author

I guess this comes out more from how i use the application - for myself, this works as a browser selector per link that i click.
Hence i expect it to act more like a pop-up, than a full-fledged application - meaning that if focus is lost to it, it goes away. That's the expectation i have based on my use-case.

I recognize that i am not everyone, hence was considering whether adding the option to do so, even if not enabled by default would bring value to the app.

@sonnyp
Copy link
Owner

sonnyp commented Oct 22, 2021

Ok, I also use it the same way but don't feel the need for this.

Anyway, feel free to send a PR, should be quite simple

You want to do something like (pseudo code ahead)

in window.js when window object looses focus, call action win.close (or directly method window.close)

Once you have that - you can put it behind a setting by using https://docs.gtk.org/gio/class.Settings.html

We don't have a preferences window yet and I'm not sure I want this to have UI anyway but users can use dconf or gsettings CLI to set/unset this

Happy to help

@sonnyp
Copy link
Owner

sonnyp commented Oct 22, 2021

@sonnyp
Copy link
Owner

sonnyp commented Oct 24, 2021

I have been thinking of making Junction keeping the history of requested locations, in which case I would be open to this being default since closing by accident could be recovered.

I had a look how to do this out of curiosity and unless I'm missing something, it is rather tricky

  window.connect("notify::is-active", () => {
    if (window.is_active) {
      window.close();
    }
  });

On GNOME Shell / wayland ; the window closes when

  • moving it
  • when opening the application menu
  • when opening the window menu (right click on header bar)
  • when opening the entry menu (right click on the resource location)

there is also no way to skip the task bar on GTK4 or Wayland so AFAIK Junction will never really feel like a modal.

There are probably ways to workaround these but unless we want close on blur as standard behavior I don't think it's worth it.

@defini-tiv
Copy link

sad.
I think it would be the most intuitive option since e.g. the android dialogues behave the same.
It is definetly a flaw of gtk4 (or wayland) that such a usecase is not thought of.
So there should be comunicated somehow i guess...

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

No branches or pull requests

3 participants