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

[Tibor Futo]

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/146a649a/attachment.htm