whathecode / abc Goto Github PK

Chrome's shadow windows stay behind when opening the context menu of a tab, and while it is open, switching to a different desktop.

As it stands it seems like these shadow windows are ignored by the VDM, but perhaps something goes wrong when hiding the parent window (Chrome)?

On my Windows 8 installation desktop icons do not seem to be stored since a window can't be found. The following returns 0 in the IconManager helper class.

vHandle = User32.FindWindowEx(vHandle, IntPtr.Zero, "SysListView32", "FolderView");

Furthermore, merging icon workspaces is currently not implemented. A desirable behavior needs to be decided on here. Remember that closing down the workspace manager merges all workspaces with the startup workspace! Different behavior might be desirable when merging two workspaces than when closing the manager.

The IconManager might also need to be refactored, moving some of its components to the FCL extensions PInvoke library.

Move the 'activity context library' implementation of Laevo to the ABC toolkit as a 'LibraryManager' extending from AbstractWorkspaceManager.

In commit 42cb47f process versions were included into configuration files which should not be specified. Most notably, what lead us to noticing this is the "windows_7.xml" definition, which now targets version 6.1 of 'explorer', using TargerProcessVersion="6.1". This leads to things breaking on Windows 8 since this uses a newer version of explorer.

By default, processes should intentionally target 'any version'. Only when specific version dependencies are known does it make sense to add version number configurations, which then override the 'default' any version. Otherwise, configurations would break at any given update, even though they might still work out of the box. Likewise, a more defined version has precedence over a less defined one.

E.g. given two configuration files, one version 'any' and another version '6.1'. The 'any' configuration file would be used when a version '6.2' is encountered, but when a version '6.1.3' is encountered, the '6.1' configuration should be used.

Also, please change TargerProcessVersion to TargetProcessVersion.

When the VDM is running without elevated privileges, windows which were started with administrator rights can't be handled by the VDM.

In case the VDM is running without elevated privileges and windows which require elevated privileges are found, a warning should be given.

Applications which force to have only once instance available cause many problems. They need to be handled separately from applications which start up as several instances.

Some suggestions:

• Always show those applications across all activities. Optionally only store minimized or maximized state, or their position.
• Smarter handling when they receive focus or become visible for some reason.

A unified solution needs to found so that behavior of those applications is predictable.

I was experiencing a consistent slow (about 4s) desktop switch, but only to the home activity, so I decided to investigate which particular process/window was causing the delay.

I pinned it down to exactly one application causing the delay:
netsession_win.exe, which is the Akamai NetSession Client by Akamai Technologies, Inc.

Now we can easily ignore this through VdmSettings, however, what is it that causes this delay? In case there is nothing we can do about it, can we at least detect the applications causing these delays automatically?

This particular one is a rather suspicious app.

Right now, ABC.PInvoke is a huge copy/paste from FCL extension. This was done since FCL extension does not want to publicly expose win32 DLLs, but rather wrap them in proper C# classes/calls.

A quick proper solution would be to use a common PInvoke library in both FCL extension and ABC. Over time calls which the ABC toolkit does on the PInvoke library are ideally wrapped somehow within FCL extension so in the long run ABC toolkit does not rely on PInvoke.

In case windows for some reason do not respond to Window Messages, the VDM should include a mechanism to circumvent Win32 messages to idle or crash.

The virtual desktop manager originally checked the company name of processes in order to more accurately differentiate between different processes. However, this proved to be difficult for some processes since they seemed to be signed in different ways, and thus CompanyName is not always available. Therefore @StevenHouben removed the check in the loaded settings of the VDM (33f1338).

However, the ProcessBehaviors .xsd still contains this setting as do the existing configuration files. Either this setting needs to be removed entirely, CompanyName needs to become optional, or another guaranteed way to better differentiate between similarly named processes needs to be found.

RepositionWindows can fail when a hung application is repositioned.

Could we ensure that at least the responsive windows are repositioned, and ignore the irresponsive windows to then decide what to do with them?

Reposition Win32 calls:

• BeginDeferWindowPos
• EndDeferWindowPos

Some related possibly interesting links:

• SetWindowPos
• IsHungApp
• WM_WINDOWPOSCHANGED

When trying to retrieve process information for a process located on a mapped network drive GetVersionInfo() throws a FileNotFoundException.

The process information is needed in order to see which of its windows need to be managed by the VDM and so forth, as specified in the settings.

Steps to reproduce:

• Run sysinternals process explorer (probably under admin rights)
• Start up Laevo (possibly without admin rights?)
• Laevo should crash with the following stack trace.

System.IO.FileNotFoundException: S:\IT Support\Software installation files= Portable tools =\Windows system tools\procexp64.exe
at System.Diagnostics.FileVersionInfo.GetVersionInfo(String fileName)
at System.Diagnostics.ProcessModule.get_FileVersionInfo()
at ABC.Windows.Desktop.Settings.LoadedSettings.GetProcessSettings(WindowInfo window)
at ABC.Windows.Desktop.Settings.LoadedSettings.b__11(WindowInfo w)
at ABC.Windows.Desktop.VirtualDesktopManager.GetNewWindows()
at ABC.Windows.Desktop.VirtualDesktopManager..ctor(ISettings settings)
at Laevo.ViewModel.ActivityOverview.ActivityOverviewViewModel..ctor(Laevo model)
at Laevo.ViewModel.Main.MainViewModel.EnsureActivityOverview()
at Laevo.ViewModel.Main.MainViewModel..ctor(Laevo model)
at Laevo.App.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catch

The VirtualDesktopManager part of the ABC toolkit still contains its original licenses, referring to the older project.

We need to decide on a license and make sure all files are annotated properly.

Currently the VDM manager crashes when VDM settings files are loaded containing IgnoreWindows without any containing windows. E.g.: <IgnoreWindows Mode="AllExcept" />. The crash occurs since the Window collection is set to null, whereas it should simply be loaded as empty instead to prevent null checks all around the place.

The applications need to be running for the crash to occur. The current two settings files including such a collection are skype.xml and spotifyhelper.xml.

On Windows 10, universal apps seem to be handled differently from older applications.

They seem to introduce some background workers, seemingly hosted in an 'ApplicationFrameHost' process. E.g. for "Photos":
Process: ApplicationFrameHost
Company: Microsoft Corporation
Class: ApplicationFrameWindow
Title: Photos
Visible: yes

This application also has to following associated window:
Process: Microsoft.Photos
Company: Microsoft Corporation
Class: Windows.UI.Core.CoreWindow
Title: Photos
Visible: yes

Cutting this application does hide it, but it does not disappear from the task bar.

How to support universal application windows properly?