<div dir="ltr"><div><div><div><div>Hi Ton,<br><br></div>The thing is: you can subscribe to all the events and process them _before_ the OS default window manager handles them. I have no recent experience with the message processing loop in Windows 7/8 and in Linux, but in XP you can capture any event you want to before Windows handles them, except Ctrl-Alt-Delete.<br>
<br></div>E.g. in XP, if you do a click on the Window area, you have a chance to handle that with a WM_LBUTTONDOWN event (<a href="http://msdn.microsoft.com/en-us/library/ms645607%28VS.85%29.aspx">http://msdn.microsoft.com/en-us/library/ms645607%28VS.85%29.aspx</a>). An Alt is just a modifier that is being passed in the message.<br>
<br></div>I do not know about Unity/Gnome, but I do not think the Window Manager would prioritize its event processing over the applications event processing. If so, there should be an ability to hook in a pre-WM handler. But, no clue, just this would be the rational architecture for the WM. Adding a hook would not change change the environment, the Window Manager, it is a per WND class action, and so specific to the application in Windows. Same should be true for Linux.<br>
<br></div><div>A Linux developer should be much more knowledgeable with this, but if you guys are completely lost, let me know, and I will try to investigate this and create a sample. Knowing me nothing about Linux, this may take months though :-).<br>
</div><br>Tibor<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 23, 2012 at 12:44 PM, Ton Roosendaal <span dir="ltr"><<a href="mailto:ton@blender.org" target="_blank">ton@blender.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Blender doesn't ever change anything in your environment.<br>
First your desktop environment handles events, and then Blender gets it (if it gets passed on even).<br>
<br>
That's standard behaviour for any application, a reason why window managers have to be careful with adding shortcut conventions.<br>
<br>
-Ton-<br>
<br>
------------------------------------------------------------------------<br>
Ton Roosendaal Blender Foundation <a href="mailto:ton@blender.org">ton@blender.org</a> <a href="http://www.blender.org" target="_blank">www.blender.org</a><br>
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands<br>
<div class="HOEnZb"><div class="h5"><br>
On 19 Dec, 2012, at 16:04, Jason van Gumster wrote:<br>
<br>
><br>
> Tibor Futo <<a href="mailto:tiborfuto@gmail.com">tiborfuto@gmail.com</a>> wrote:<br>
><br>
>> But please note my advice: if the Blender developers create a mouse/key<br>
>> hook that processes Alt-Click and does not allow it to propagate to the OS,<br>
>> then this discussion does not need more attention.<br>
><br>
> I could be wrong, but I don't think it works that way. In fact, it's the<br>
> reverse. AFAIK, the Alt key is intercepted by the window manager before it even<br>
> makes it to Blender. Plenty of other applications run into Alt key collisions<br>
> as well (hence the reason for the option to switch to Super in a lot of window<br>
> managers). This isn't something that can be fixed from Blender's end (and it's<br>
> not likely to be changed from the end of the various window managers because<br>
> not every keyboard has a Super key).<br>
><br>
> Probably the best solution for documentation issues like these is a compromise.<br>
> The general solution exists (e.g. remap the window manager's Alt to Super), but<br>
> each WM does it a bit differently. As such, we should provide the generic<br>
> solution and point to the documentation (if easily found) of various window<br>
> managers that show specifically how to do it... perhaps as footnotes. When the<br>
> window manager changes, we need but change the link or remove it. For the<br>
> window managers that aren't mentioned, at least the reader will know what to<br>
> look/ask for.<br>
><br>
> Blender users don't always use the typical window manager options... In fact,<br>
> it's been my experience that we avoid the likes of Gnome and KDE in favor of<br>
> XFCE, Openbox, and (for weirdos like me) Enlightenment in an effort have<br>
> improved workflow or performance. Documenting each of them in-page is going to<br>
> end up being difficult to maintain and potentially confusing to read (or at<br>
> the very least, the relatively small nuggets of relevant information will be<br>
> accidentally skimmed over).<br>
><br>
> Just my 2 cents...<br>
><br>
> -Jason<br>
> _______________________________________________<br>
> Bf-docboard mailing list<br>
> <a href="mailto:Bf-docboard@blender.org">Bf-docboard@blender.org</a><br>
> <a href="http://lists.blender.org/mailman/listinfo/bf-docboard" target="_blank">http://lists.blender.org/mailman/listinfo/bf-docboard</a><br>
<br>
_______________________________________________<br>
Bf-docboard mailing list<br>
<a href="mailto:Bf-docboard@blender.org">Bf-docboard@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-docboard" target="_blank">http://lists.blender.org/mailman/listinfo/bf-docboard</a><br>
</div></div></blockquote></div><br></div>