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

Sun Dec 23 20:44:18 CET 2012

>Discussions of design philosophy aside, I don't think that the mechanism
you describe in Windows exists in other systems. And if it did, I
personally would not be in favor of Blender superseding my window manager's
behavior.

Well, I would rather have Blender take control of Alt-Click than require a
system-wide change so that the Linux WM respects Alt-Click passing to
Blender... The best would be to have an internal message processing and
passing queue that handles all the raw mouse and key events...

T.

On Sun, Dec 23, 2012 at 3:24 PM, Jason van Gumster <
jason at handturkeystudios.com> wrote:

> Tibor Futo <tiborfuto at gmail.com> wrote:
>
> >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
> >>>
> >>
> >>
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >Bf-docboard mailing list
> >Bf-docboard at blender.org
> >http://lists.blender.org/mailman/listinfo/bf-docboard
>
> FWIW, the same thing happens in MacOS on the function keys. This is less
> of an issue in Windows because it's window manager equivalent doesn't even
> offer the same "drag a window form some place other than the header" that
> Alt+LMB is often bound to in Linux window managers. And if it did, it would
> be bound to the Super key because that was Microsoft's creation. Many Linux
> users (though fewer now) don't have Super keys on their keyboards (hence
> the reason why so many window managers have defaulted to Alt).
>
> Discussions of design philosophy aside, I don't think that the mechanism
> you describe in Windows exists in other systems. And if it did, I
> personally would not be in favor of Blender superseding my window manager's
> behavior.
>
>   -Jason
> _______________________________________________
> 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/59b7e829/attachment.htm 