[Bf-docboard] Page Update (Doc:2.6/Manual/Introduction/Installing Blender/Linux)

[Tibor Futo]

Actually, it is pretty funny how other apps suffer from this stupid Linux
monopolization of Alt-Click. E.g. Inscape (search for "How can I make
Alt+click and Alt+drag work on Linux?")

http://wiki.inkscape.org/wiki/index.php/Frequently_asked_questions#How_can_I_make_Alt.2Bclick_and_Alt.2Bdrag_work_on_Linux.3F

T.


On Sun, Dec 23, 2012 at 2:45 PM, Tibor Futo <tiborfuto at gmail.com> wrote:

> Hi Ton,
>
> 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.
>
> 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 (
> http://msdn.microsoft.com/en-us/library/ms645607%28VS.85%29.aspx). An Alt
> is just a modifier that is being passed in the message.
>
> 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.
>
> 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 :-).
>
> Tibor
>
>
> On Sun, Dec 23, 2012 at 12:44 PM, Ton Roosendaal <ton at blender.org> wrote:
>
>> Hi,
>>
>> Blender doesn't ever change anything in your environment.
>> First your desktop environment handles events, and then Blender gets it
>> (if it gets passed on even).
>>
>> That's standard behaviour for any application, a reason why window
>> managers have to be careful with adding shortcut conventions.
>>
>> -Ton-
>>
>> ------------------------------------------------------------------------
>> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>
>> On 19 Dec, 2012, at 16:04, Jason van Gumster wrote:
>>
>> >
>> > Tibor Futo <tiborfuto at gmail.com> wrote:
>> >
>> >> But please note my advice: if the Blender developers create a mouse/key
>> >> hook that processes Alt-Click and does not allow it to propagate to
>> the OS,
>> >> then this discussion does not need more attention.
>> >
>> > I could be wrong, but I don't think it works that way. In fact, it's the
>> > reverse. AFAIK, the Alt key is intercepted by the window manager before
>> it even
>> > makes it to Blender. Plenty of other applications run into Alt key
>> collisions
>> > as well (hence the reason for the option to switch to Super in a lot of
>> window
>> > managers). This isn't something that can be fixed from Blender's end
>> (and it's
>> > not likely to be changed from the end of the various window managers
>> because
>> > not every keyboard has a Super key).
>> >
>> > Probably the best solution for documentation issues like these is a
>> compromise.
>> > The general solution exists (e.g. remap the window manager's Alt to
>> Super), but
>> > each WM does it a bit differently. As such, we should provide the
>> generic
>> > solution and point to the documentation (if easily found) of various
>> window
>> > managers that show specifically how to do it... perhaps as footnotes.
>> When the
>> > window manager changes, we need but change the link or remove it. For
>> the
>> > window managers that aren't mentioned, at least the reader will know
>> what to
>> > look/ask for.
>> >
>> > Blender users don't always use the typical window manager options... In
>> fact,
>> > it's been my experience that we avoid the likes of Gnome and KDE in
>> favor of
>> > XFCE, Openbox, and (for weirdos like me) Enlightenment in an effort have
>> > improved workflow or performance. Documenting each of them in-page is
>> going to
>> > end up being difficult to maintain and potentially confusing to read
>> (or at
>> > the very least, the relatively small nuggets of relevant information
>> will be
>> > accidentally skimmed over).
>> >
>> > Just my 2 cents...
>> >
>> >  -Jason
>> > _______________________________________________
>> > Bf-docboard mailing list
>> > Bf-docboard at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-docboard
>>
>> _______________________________________________
>> Bf-docboard mailing list
>> Bf-docboard at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-docboard
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-docboard/attachments/20121223/f6a6d1ea/attachment.htm