Fix win32 app loading #78
Conversation
use LnkResolvedPath which is the original lnk path, rather than using the FullPath property which is assigned with the path to the actual exe
|
Should we use LnkResolved Path to distinct programs so that there won't be multiple program items from multiple Link pointing to the same exe? |
|
yeah makes sense, will take a look. When they are pointing to the same exe, how do we know which to pick? |
Well I think we can pick those with distinct descriptions, and only pick the one with no description when none contains a description. |
private class Win32ComparatorBasedonDescription : IEqualityComparer<Win32>
{
public static Win32ComparatorBasedonDescription Default = new Win32ComparatorBasedonDescription();
public bool Equals([AllowNull] Win32 x, [AllowNull] Win32 y)
{
return x.Description == y.Description;
}
public int GetHashCode([DisallowNull] Win32 obj)
{
return obj.Description.GetHashCode();
}
}
private static Win32[] ProgramsHasher(ParallelQuery<Win32> programs)
=> programs
.GroupBy(p => p.FullPath.ToLower())
.SelectMany(g =>
{
var tempList = g;
if (tempList.Count() > 1 && tempList.Any(p => !string.IsNullOrEmpty(p.Description)))
return g.Where(p => !string.IsNullOrEmpty(p.Description))
.Distinct(Win32ComparatorBasedonDescription.Default);
else
return g.Take(1);
}).ToArray();Take a look on this, but I think the performance isn't quite satisfied. |
|
There is a weird situation..... if replacing Parallel Query with IEnumerable, the running time can reduce hugely significantly...... in my computer, it is about 1000-2000ms to 1-10ms, which is unreasonable. |
|
Seems sometime PLINQ do performs slower than LINQ…… especially when the task is simple for each one but contains a lot of split. |
|
Found out that changing the Parallel query to sequential query make indexing Win32 programs faster, should we remove the use of parallel indexing? (from about 2600 ms to 1600ms) Should I push the change so that you can test it on your computer? |
…e it performs better.
yep push it up please and i will have a look |
Please take a look |
|
@taooceros I added match on path as well as this is one of the things the PR tries to resolve, eg. cmd should return Command Prompt result. Please have a look. |
|
one strange thing i noticed, is this duplicate despite only having one result returned
|
Let me check that out because when duplicate results present, only the one with different descriptions should be kept. The one without description should be removed. |
Haha this has been removed at about v1.4.0 I think? Let't only do that for lnk program to avoid duplicate match because exe program should have Name equal to their file name. |
ok make sense. I will update it |
@taooceros It's from Explorer, lol, of course. OK Let me know if PR is good to go. I also want to get the other UWP one in as well |
Oh haha. Give me a few minutes to have a last check. |
|
emmm are you able to debug the program? I think I have encountered some assembly issue because of the migration of ISavable. |
|
ok found the issue. Everything plugin utilizes the old infrastructure, so that its ISavable is from there, which cause the type load issue. |
|
@jjw24 I fix a few logic in HighlightData, please take a look. Also, I make the ExecutableName field be the file name we want for LnkProgram so that we don't need to get it every time. |
|
@taooceros LGTM, lets get this in |
jjw24
removed
the
review in progress
This fixes some win32 app loading for Program plugin.
More specifically, it is able to retrieve the correct file path for programs in the start menu that have LNK extension, ie. Command Prompt from start menu.
Fix the issue where type 'cmd' does not get you Command Prompt
Remove ShObjldITIb.dll which was for launching applications using Application Activation Manager and loading app info using Shell Links. We now directly use the code, not needing this dll to be embedded.
Remove duplicate lnk program pointing to the same exe with the same description. close Combine/remove duplicate entries #307