After installing gnome-2.28 and running vmware-workstation I obverse the following: mouse does not seem to know the size of the screen a windows virtual machine. It changes from vm use to host use within the confine of the vm. This make it impossible to click of most of the windows desktop Reproducible: Always paludis 0.42.0 Paludis build information: Compiler: CXX: x86_64-pc-linux-gnu-g++ 4.4.2 CXXFLAGS: -march=core2 -O2 -pipe LDFLAGS: -Wl,-O1 DATE: 2009-10-30T19:23:00-0400 Libraries: C++ Library: GNU libstdc++ 20091015 Paths: DATADIR: /usr/share LIBDIR: /usr/lib64 LIBEXECDIR: /usr/libexec SYSCONFDIR: /etc PYTHONINSTALLDIR: RUBYINSTALLDIR: /usr/lib64/ruby/site_ruby/1.8/x86_64-linux System: Linux harrisl-desktop 2.6.31-gentoo-r4 #1 SMP PREEMPT Mon Oct 26 22:48:22 EDT 2009 x86_64 Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz GenuineIntel GNU/Linux Reduced Privs: reduced_uid: 101 reduced_uid->name: paludisbuild reduced_uid->dir: /var/tmp/paludis reduced_gid: 1000 reduced_gid->name: paludisbuild Environment: Format: paludis Config dir: /etc/paludis World file: /var/db/pkg/world Repository layman: format: unavailable location: /var/db/paludis/repositories/layman sync: tar+http://git.exherbo.org/layman_repositories.tar.bz2 sync_options: Repository installed-virtuals: format: installed_virtuals root: / Repository virtuals: format: virtuals Repository gentoo: format: ebuild location: /usr/portage append_repository_name_to_write_cache: true binary_destination: false binary_keywords: binary_uri_prefix: builddir: /var/tmp/paludis cache: /usr/portage/metadata/cache distdir: /usr/portage/distfiles eapi_when_unknown: 0 eapi_when_unspecified: 0 eclassdirs: /usr/portage/eclass ignore_deprecated_profiles: false layout: traditional names_cache: /usr/portage/.cache/names newsdir: /usr/portage/metadata/news profile_eapi_when_unspecified: 0 profiles: /usr/portage/profiles/default/linux/amd64/10.0/desktop securitydir: /usr/portage/metadata/glsa setsdir: /usr/portage/sets sync: rsync://rsync.gentoo.org/gentoo-portage sync_options: use_manifest: use write_cache: /var/cache/paludis/metadata Package information: app-admin/eselect-compiler: (none) app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.9-r1 dev-lang/python: 2.5.4-r3 2.6.3 3.1.1-r1 dev-python/pycrypto: (none) dev-util/ccache: (none) dev-util/cmake: 2.6.4-r3 dev-util/confcache: (none) sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r1 sys-apps/sandbox: 2.2 sys-devel/autoconf: 2.13 2.63-r1 sys-devel/automake: 1.10.2 1.11 1.7.9-r1 1.9.6-r2 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 (for sys-kernel/linux-headers::installed) Repository installed: format: vdb location: /var/db/pkg builddir: /var/tmp/paludis eapi_when_unknown: 0 names_cache: /var/db/pkg/.cache/names provides_cache: /var/db/pkg/.cache/provides root: / Repository sunrise: format: ebuild location: /var/paludis/repositories/sunrise append_repository_name_to_write_cache: true binary_destination: false binary_keywords: binary_uri_prefix: builddir: /var/tmp/paludis cache: /var/empty distdir: /usr/portage/distfiles eapi_when_unknown: 0 eapi_when_unspecified: 0 eclassdirs: /usr/portage/eclass /var/paludis/repositories/sunrise/eclass ignore_deprecated_profiles: false layout: traditional master_repository: gentoo names_cache: /var/paludis/repositories/sunrise/.cache/names newsdir: /var/paludis/repositories/sunrise/metadata/news profile_eapi_when_unspecified: 0 profiles: /usr/portage/profiles/default/linux/amd64/10.0/desktop securitydir: /var/paludis/repositories/sunrise/metadata/glsa setsdir: /var/paludis/repositories/sunrise/sets sync: svn://overlays.gentoo.org/proj/sunrise/reviewed/ sync_options: use_manifest: use write_cache: /var/cache/paludis/metadata
Probably a client side windows regression - at least if your gtk+ is >=2.18.
(In reply to comment #1) > Probably a client side windows regression > - at least if your gtk+ is >=2.18. > It definately is. @Harris: As a workaround start vmware with GDK_NATIVE_WINDOWS=true vmware from the console, this disables client side windows and should help
I got it working again with export VMWARE_USE_SHIPPED_GTK="force" vmware is GDK_NATIVE_WINDOWS=true vmware better?
(In reply to comment #3) > I got it working again with > > export VMWARE_USE_SHIPPED_GTK="force" > vmware > > > is > > GDK_NATIVE_WINDOWS=true vmware > > better? > In a way it is: shipped gtk is the one, shipped with vmware, the other way still uses system libs. Though it's most probably vmware that has to be fixed upstream.
*** Bug 318627 has been marked as a duplicate of this bug. ***
Which exact versions of vmware-workstation are you talking about?
(In reply to comment #6) > Which exact versions of vmware-workstation are you talking about? > I can tell that this problem manifests at least with app-emulation/vmware-workstation-6.5.3.185404.
Same problem here with: vmware-player 2.5.4.246459 vmware-modules 1.0.0.25-r1 gtk+ 2.20.1-r1 Good workarround: Add at the end of "/etc/vmware/bootstrap" the line 'export VMWARE_USE_SHIPPED_GTK="force"' and restart vmware. Good luck, Thomas
I can confirm the workaround from comment #8 to work for vmware-player. I would suggest to include it into the ebuild until the problem is solved.
Workaround from comment #8 does not work for me. But adding "env GDK_NATIVE_WINDOWS=true" to shortcuts in menu which starts vmware and vmplayer helps to me.
Could someone please take care of this? It's been bugging users for more than a year now, and since there is no gtk+-2.16 in the tree since (at least) October, I suppose it happens to every user of vmware-workstation or vmware-player (in my case, vmware-player-2.5.4.246459). Cheapest solution, which works for me, is adding one line to app-emulation/vmware-player/files/90vmware-player: VMWARE_USE_SHIPPED_GTK="force" I guess the same hold for app-emulation/vmware-workstation/files/90vmware-workstation. Anyone?
workstation 6 was removed from the tree. bug 385727.
