LaunchBox positioning

[egabrum]

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.

[polyvertex]

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.

[polyvertex]

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]

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]

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]

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.

[polyvertex]

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]

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]

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]

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

[polyvertex]

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

[poisonborz]

+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.

[poisonborz]

+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]

@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?

[polyvertex]

@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]

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.

[poisonborz]

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]

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)

[polyvertex]

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]

👍👍👍 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]

👍👍👍 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]

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):

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]

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):

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]

@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]

@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]

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

[polyvertex]

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

[polyvertex]

Implemented. Will be available in the next release.

[polyvertex]

Implemented. Will be available in the next release.

[polyvertex]

Implemented in 2.9

[polyvertex]

Implemented in 2.9