LaunchBox positioning #50

Closed
egabrum opened this Issue Apr 22, 2016 · 15 comments

Comments

Projects
None yet
3 participants
@egabrum

egabrum commented Apr 22, 2016

Not that i feel very strongly about this, but it would be nice to be able to configure KP to open the launch box in the same monitor where the mouse pointer is (i.e. where the user us more likely to be looking at the moment), as opposed to always on the primary screen.

@egabrum egabrum changed the title from Request: open launch box on the same screen where the mouse is to Request: open launch box on the same screen where the mouse pointer is Apr 22, 2016

@polyvertex polyvertex changed the title from Request: open launch box on the same screen where the mouse pointer is to Open launch box on the same screen where the mouse pointer is? Apr 22, 2016

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Apr 22, 2016

Member

I'm really not sure about that I'm afraid. And it would also mean registering a new hotkey ("me not like"). You'll have to convince me harder. You or the tens of guys who are about to show up in this thread to back your request.

Member

polyvertex commented Apr 22, 2016

I'm really not sure about that I'm afraid. And it would also mean registering a new hotkey ("me not like"). You'll have to convince me harder. You or the tens of guys who are about to show up in this thread to back your request.

@egabrum

This comment has been minimized.

Show comment
Hide comment
@egabrum

egabrum Apr 22, 2016

Meh... If it were rather quick and easy to code, or if it gets backed by a bunch of people, I'd say it would be a "nice to have". Personally, there are other enhancements that are much higher in my priority list.

Note, however, that what I had in mind would not require a new hotkey. It would be just a new geometry setting, alternative to persistent and auto. Say mouse or something like that.

egabrum commented Apr 22, 2016

Meh... If it were rather quick and easy to code, or if it gets backed by a bunch of people, I'd say it would be a "nice to have". Personally, there are other enhancements that are much higher in my priority list.

Note, however, that what I had in mind would not require a new hotkey. It would be just a new geometry setting, alternative to persistent and auto. Say mouse or something like that.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Apr 22, 2016

Member

Note, however, that what I had in mind would not require a new hotkey. It would be just a new geometry setting, alternative to persistent and auto. Say mouse or something like that.

That would be OK'ish (which means dirty, which still means "me not like") if every user would agree then be absolutely positively sure that each time she wants to popup KP, it should appear next to mouse's coordinates. I cannot believe you find this reasonable :)
Hence the new hotkey.

EDIT it is indeed an easy add technically-wise. That does not mean it should be done.

Member

polyvertex commented Apr 22, 2016

Note, however, that what I had in mind would not require a new hotkey. It would be just a new geometry setting, alternative to persistent and auto. Say mouse or something like that.

That would be OK'ish (which means dirty, which still means "me not like") if every user would agree then be absolutely positively sure that each time she wants to popup KP, it should appear next to mouse's coordinates. I cannot believe you find this reasonable :)
Hence the new hotkey.

EDIT it is indeed an easy add technically-wise. That does not mean it should be done.

@egabrum

This comment has been minimized.

Show comment
Hide comment
@egabrum

egabrum Apr 22, 2016

I use a tiny app that does just that for task switching.
But, in this case, what I envisioned was something like auto: centered in the screen, but in the same screen where the mouse pointer is (not in the exact coordinates of the mouse pointer).

egabrum commented Apr 22, 2016

I use a tiny app that does just that for task switching.
But, in this case, what I envisioned was something like auto: centered in the screen, but in the same screen where the mouse pointer is (not in the exact coordinates of the mouse pointer).

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Apr 22, 2016

Member

If it happens to be implemented one day, it won't be that way.

Member

polyvertex commented Apr 22, 2016

If it happens to be implemented one day, it won't be that way.

@poisonborz

This comment has been minimized.

Show comment
Hide comment
@poisonborz

poisonborz May 5, 2016

+1
This would be a nice addition. None of the launchers I know had proper multi-monitor support, even while it was an often requested feat on many (http://tinyurl.com/hfl9x5q, http://tinyurl.com/jcsd8fu).
Whether mouse pointer location is the best guess/feasible at all is another question, the location of the currently active window might be a better way.

+1
This would be a nice addition. None of the launchers I know had proper multi-monitor support, even while it was an often requested feat on many (http://tinyurl.com/hfl9x5q, http://tinyurl.com/jcsd8fu).
Whether mouse pointer location is the best guess/feasible at all is another question, the location of the currently active window might be a better way.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex May 5, 2016

Member

@poisonborz You should pay attention about the difference between wanting to be able to configure KP so it gets shown on a different monitor (say "always monitor 2" for example), and KP being shown on the same screen than current mouse position. While the mix of both features is a perfectly credible alternative technically-wise, it is something different than the point of the OP. Which one do you intend to back here?

Member

polyvertex commented May 5, 2016

@poisonborz You should pay attention about the difference between wanting to be able to configure KP so it gets shown on a different monitor (say "always monitor 2" for example), and KP being shown on the same screen than current mouse position. While the mix of both features is a perfectly credible alternative technically-wise, it is something different than the point of the OP. Which one do you intend to back here?

@poisonborz

This comment has been minimized.

Show comment
Hide comment
@poisonborz

poisonborz May 5, 2016

First and foremost basic (pre-set value) multi-monitor support (but maybe that's a separate request).

OP's intention is a further step - maybe a better name for this thread would be: "automatically select which monitor to display KP on". Whether this would be by tracking the mouse (not necessarily ideal solution IMHO), an active window, or something else is up in the air, but it's an idea worth considering.

Possible scenario: having TV/projector hooked up to a PC, KP would automatically show up there if those displays are being currently used.

First and foremost basic (pre-set value) multi-monitor support (but maybe that's a separate request).

OP's intention is a further step - maybe a better name for this thread would be: "automatically select which monitor to display KP on". Whether this would be by tracking the mouse (not necessarily ideal solution IMHO), an active window, or something else is up in the air, but it's an idea worth considering.

Possible scenario: having TV/projector hooked up to a PC, KP would automatically show up there if those displays are being currently used.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex May 5, 2016

Member

To summarize the request so far, the geometry enum would look like this:

  • persistent: manual and persistent positioning/resizing
  • auto: centered and auto-sized on the primary monitor
  • monitor_1, monitor_2, monitor_N: same as auto but monitor can be selected by its ID
  • current_app_monitor: centered in the same screen than the current active app/window
  • mouse_monitor: centered in the same screen than current mouse position
  • mouse_pos: nearby mouse coordinates (no resizing involved and without being spanned on several screens, which means LaunchBox position will be adjusted if needed)
Member

polyvertex commented May 5, 2016

To summarize the request so far, the geometry enum would look like this:

  • persistent: manual and persistent positioning/resizing
  • auto: centered and auto-sized on the primary monitor
  • monitor_1, monitor_2, monitor_N: same as auto but monitor can be selected by its ID
  • current_app_monitor: centered in the same screen than the current active app/window
  • mouse_monitor: centered in the same screen than current mouse position
  • mouse_pos: nearby mouse coordinates (no resizing involved and without being spanned on several screens, which means LaunchBox position will be adjusted if needed)
@poisonborz

This comment has been minimized.

Show comment
Hide comment
@poisonborz

poisonborz May 5, 2016

👍👍👍 that's all that's been mentioned and more! I've been happy with fixed+any of the active tracking, but this would really raise the bar for task launcher display support.

poisonborz commented May 5, 2016

👍👍👍 that's all that's been mentioned and more! I've been happy with fixed+any of the active tracking, but this would really raise the bar for task launcher display support.

@polyvertex polyvertex added the area/core label May 9, 2016

@polyvertex polyvertex changed the title from Open launch box on the same screen where the mouse pointer is? to LaunchBox positioning May 10, 2016

@poisonborz

This comment has been minimized.

Show comment
Hide comment
@poisonborz

poisonborz May 10, 2016

Continuing from #67, positioning is an important aspect of a task launcher - everyone's desktop workspace layout is different (persistent UI elements, multiple, different-sized displays).

One quarter y centering is a popular default, especially on OSX launchers. Launchy, which I used for years, centered at 50%, and my vision on the desktop is drawn more downwards than up. Alfred, a popular alternative to Spotlight has this - propotional - configuration (merely as an illustration):

clipboard02

Rainmeter (a windows desktop widget framework) saves widget positions per each new detected resolution after closing.

As this is purely a visual/preferential issue so it's a bit hard to argue besides the first sentence above. Being a simple propotion value, it actually struck me as a surprise that this was a fixed value. It resembled Apple's "one-size-fits-all" motto, which is a bit contradictory to the universal/configurable ethos described in the docs.

Compared to the multi-monitor discussion in this thread, in itself y positioning is a minor issue, for sure, but it would be very neat if a more comprehensive positioning solution would also solve this aspect too.

poisonborz commented May 10, 2016

Continuing from #67, positioning is an important aspect of a task launcher - everyone's desktop workspace layout is different (persistent UI elements, multiple, different-sized displays).

One quarter y centering is a popular default, especially on OSX launchers. Launchy, which I used for years, centered at 50%, and my vision on the desktop is drawn more downwards than up. Alfred, a popular alternative to Spotlight has this - propotional - configuration (merely as an illustration):

clipboard02

Rainmeter (a windows desktop widget framework) saves widget positions per each new detected resolution after closing.

As this is purely a visual/preferential issue so it's a bit hard to argue besides the first sentence above. Being a simple propotion value, it actually struck me as a surprise that this was a fixed value. It resembled Apple's "one-size-fits-all" motto, which is a bit contradictory to the universal/configurable ethos described in the docs.

Compared to the multi-monitor discussion in this thread, in itself y positioning is a minor issue, for sure, but it would be very neat if a more comprehensive positioning solution would also solve this aspect too.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Jul 2, 2016

Member

@poisonborz While your comment fits into the scope of the current request (i.e. LaunchBox positioning), it would probably require an extra setting so the user can adjust the behavior of the geometry setting (i.e. any automatic and persistent aspect of it). Otherwise, that would make the geometry setting utterly complex considering the nature of its purpose, and more importantly: considering the general design of the application.
In fact, your comment being related to this request and also issue #39, I will stick to the new geometry setting the way I enumerated it earlier, and put your last comment aside for a further release. I will probably work on it along with #39.

Member

polyvertex commented Jul 2, 2016

@poisonborz While your comment fits into the scope of the current request (i.e. LaunchBox positioning), it would probably require an extra setting so the user can adjust the behavior of the geometry setting (i.e. any automatic and persistent aspect of it). Otherwise, that would make the geometry setting utterly complex considering the nature of its purpose, and more importantly: considering the general design of the application.
In fact, your comment being related to this request and also issue #39, I will stick to the new geometry setting the way I enumerated it earlier, and put your last comment aside for a further release. I will probably work on it along with #39.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Aug 2, 2016

Member

FYI, latest news about persistent positioning (issue #39).

Member

polyvertex commented Aug 2, 2016

FYI, latest news about persistent positioning (issue #39).

@polyvertex polyvertex added status/done and removed status/wip labels Aug 4, 2016

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Aug 4, 2016

Member

Implemented. Will be available in the next release.

Member

polyvertex commented Aug 4, 2016

Implemented. Will be available in the next release.

@polyvertex

This comment has been minimized.

Show comment
Hide comment
@polyvertex

polyvertex Aug 20, 2016

Member

Implemented in 2.9

Member

polyvertex commented Aug 20, 2016

Implemented in 2.9

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