Thank you, Dokinik, for your assessment:
> > How would you judge its behavior concerning stability and side effects:
> > Would it be to risky to use it right away in a production system, aka
> > "testing under wild life conditions"?
>
> The worst that can happen is that different windows aren't
>
On Mon, Nov 21, 2016 at 06:25:29PM +, Jürgen Hartmann wrote:
> > It's really complicated, but let me try to explain what's going
> > on, in case we need to understand why I made the current patch -
> > at some time in the distant future.
>
> [Very thorough and enlightening explanation
On Mon, Nov 21, 2016 at 12:27:45AM +, Jürgen Hartmann wrote:
> Concerning side effects, I can't say anything since I have no idea what
> to look for.
>
> > Now, if I'd understand what (a) the patch in
> > HandleMapRequestKeepRaised() is supposed to do,
>
> Which patch do you mean? Does the
> > What would you propose to proceed?
>
> 1) Don't panic. ;)
Truly a wise word... :)
> 2) Try the attached patch.
Done: It works great with respect to our issue. For Player and Workstation.
Concerning side effects, I can't say anything since I have no idea what
to look for.
> Now, if I'd
On Sun, Nov 20, 2016 at 10:02:39PM +, Jürgen Hartmann wrote:
> > > What is the secret behind this move? How does it work?
> >
> > I have no idea, and I'd not even call that a workaround. It just
> > seems that if you change random things, it starts to work.
>
> I see. That obsoletes my next
> > What is the secret behind this move? How does it work?
>
> I have no idea, and I'd not even call that a workaround. It just
> seems that if you change random things, it starts to work.
I see. That obsoletes my next question in the queue addressing side effects.
What would you propose to
On Sun, Nov 20, 2016 at 12:30:55PM +, Jürgen Hartmann wrote:
> > Try commenting out only the body of the if-condition, i.e.
> >
> > --
> > args.do_return_true_cr = False;
> > if (
> > FCheckIfEvent(
> >
> Try commenting out only the body of the if-condition, i.e.
>
> --
> args.do_return_true_cr = False;
> if (
> FCheckIfEvent(
> dpy, , test_withdraw_request,
> (XPointer)))
>
On Sat, Nov 19, 2016 at 08:40:28PM +, Jürgen Hartmann wrote:
>
> > > Unfortunately, this seems not to have any influence to our issue. After
> > > installing the modified binaries, Vmware still shows the old behavior:
> > > Returning from fullscreen mode yields a vanished window. This applies
On Sat, Nov 19, 2016 at 03:58:26PM +, Jürgen Hartmann wrote:
> Thank you for your suggestion, Dominik:
>
> > For the time being you can circumvent the problem by removing the whole
> >
> > if (
> > FCheckIfEvent(
> > dpy,
It turns out that the below patch from 2007 has broken it. Now if
anybody knows where the mailing list archive has gone and how to
find the thread related to this patch ...
For the time being you can circumvent the problem by removing the whole
if (
> A short update: Version 6.0.6 requires an old kernel, version
> 12.5 is downloading now (which is a matter of several hours given
> the local internet speed).
Sorry, I should have mentioned that this might be an issue.
Each version of Vmware Workstation or Player supports only very few
In my last post, I described the creation of a virtual machine, saying that
most of the offered setting can be left on their defaults.
But when it is about to choose the guest operating system, it is better to
select "Windows 3.1" than the default "Windows 7": I encountered some driver
problems
Thank you very much, Dominik, for your reply and the enlightening explanations.
> On the site you mentioned below there are only 64-bit Linux
> binaries available for download, and only for version 12. I'd
> like to help, but I need a 32 bit Linux version that shows the bug
> and that can
>> All of this is kind of a hack. VMWare wants 100% of the mouse and
>> keyboard events to go to the virtual machine without your host
>> environment getting in the way, even if what you're doing normally
>> has special meaning to the host.
>
> I see. However, if it does that, it cannot expect
Previously, I mailed the output of xev for the Vmware's client and frame
windows while switching off fullscreen mode, as advised by Dominik Vogt.
Since therein there were UnmapNotify and MapNotify events on the client side
and a DestroyNotify event for the frame window, I thought that it might be
Thank you, Dominik, for your answer:
> On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote:
>> Previously, I mailed the output of xev for the Vmware's client and frame
>> windows while switching off fullscreen mode, as advised by Dominik Vogt.
>
> Please just call me Dominik.
All
On Thu, Nov 17, 2016 at 08:53:21PM +, Jürgen Hartmann wrote:
> Previously, I mailed the output of xev for the Vmware's client and frame
> windows while switching off fullscreen mode, as advised by Dominik Vogt.
Please just call me Dominik.
> Since therein there were UnmapNotify and MapNotify
On Tue, Nov 15, 2016 at 05:23:09PM -0500, Chris Siebenmann wrote:
> > During immediate function execution fvwm tries to get exclusive
> > control of the pointer (a "grab"). This failed in the given case
> > because some other program held the grab. Fvwm retries grabbing
> > for a second before
> During immediate function execution fvwm tries to get exclusive
> control of the pointer (a "grab"). This failed in the given case
> because some other program held the grab. Fvwm retries grabbing
> for a second before giving up (the function is aborted). It seems
> that for whatever reason
On Tue, Nov 15, 2016 at 01:08:08PM +, Jürgen Hartmann wrote:
> On my Linux host system (Xorg 7.6 / Kernel 3.11.6) I use Fvwm 2.6.7 as window
> manager (congratulation to the new default configuration which I like very
> much) and Vmware Workstation 9.0.4 to run virtual machines that use
21 matches
Mail list logo
