betsegaw / windowwalker Goto Github PK

I am thinking of removing the MahApps window theme from the app. While it does marginally make the app look better than usual, this is not really the kind of app that MahApps excels at.

Any thoughts @mjrichmond?

This should also enable closing multiple windows quickly.

This will allow us to use the same method to write out various settings in the future.

Proposed format is:

{
    "ver":"v1",
    "shortcuts",{
        "v":"devenv",
        "i":"iexplore.exe"}
}

@mjrichmond any thoughts? I can do the implementation, which should be quite simple but I wanted to see if you had any input :)

This was introduced around e27c57e when fixing the shortcut occlusion issue

This feature is already built in but was dropped during the transition to MVVM. Enabling it should be super easy.

When populating the windows with items, we look to make sure that it doesn't extend beyond the bounds of the screen.

        if (this.Height > screen.Bounds.Height)
        {
            this.Height = screen.Bounds.Height;
            this.resultsListBox.MaxHeight = screen.Bounds.Height - 30;
        }

However this does not account for the fact that the window might have been moved, which was not the case when this method was written.

Suggested update would be to take into account the current location of the window.

Also, must account for moving of the window.

Search does not match anything after the first letter (see screenshots for example) starting from commit 64d6a32

For one letter you get:

When you add 2 you get:

@mjrichmond I hadn't noticed that commit. I am reverting it for the following two reasons,

1. It is more useful to have score based on overall distribution of letters.(eg. for a search of "moo", "mxxoxxo" should score higher than "mxxxxxxoxxxxxxxxo")
2. The original one has been "overused" by me so a bunch of corner cases were discovered and accounted for. Even though there are tests bundled along with the old one, there is not enough coverage to verify the new one thoroughly (as shown by the bug). I should have invested a little bit more time in creating more tests but I had gotten lazy lol :)

Not sure if this is expected but there seems to be an exception that is thrown whenever I switch back from the settings page.

@mjrichmond Does this happen to you?

Just search for a letter not in the window title but present in the process title.

Title says it all. The current release is built targeting x64, and the project does too.

Rebuilding the project targeting Any CPU on a 32bit machine results in undebuggable code:

A call to PInvoke function 'Window Walker!WindowWalker.Components.InteropAndHelpers::DwmSetWindowAttribute' has unbalanced the stack.

Whenever we are displaying matching window lists, we should only highlight either the title OR the process name (whichever one is a better match).

Here is an example of the wrong highlighting. In the below picture, only the title a or the process name a should have been highlighted (based on highest score and since these have the same score for both the title and the process name, we should pick the title in this particular example).

Idea is to enable a user to execute different types of command from within the app using the consistent method of starting an entry in the search box using :.

Right now the search window is kind of stuck at what is (hopefully) the middle top of the screen. It would be super cool and super easy to allow people to move their window + remember where there window was set to appear the next time they open the app.

@mjrichmond I am going to look into the way you save the settings and see if I can tag along on that code to save this settings as well.

Repro Steps

1. Invoke using the shortcut
2. While the window list is populating press esc

Expected: The window list disappears
Actual: Window disappears but the desktop is in live preview mode

Since this is an app for keyboard enthusiasts, having keyboard shortcuts is pretty important

Right now, you are not doing so. It's the line second to last in the fuzzybestmatch method

If you type the fast enough, the focus will be captured by whatever window you were on when you invoked window walker

Make. Less. Ugly. Now.

We should write to file more frequently since we don't expect people to be quitting the app unless they are rebooting, in which case it is more likely that they will forget to shut it down properly.

Had a random crash In UpdateHighlighting with substring(blah blah) having index out of range

Every time the window is invoked, we reload the list of apps from scratch. This means that most of the time, people have to wait to see everything load. Instead of doing that we can follow the following steps to optimize this to both decrease the number of loads we do and just general perceived perf.

• Don't clear window list until you have the first window loaded
• Merge each individual incoming result into current list

Probably only possible if the window uses a standard windows API for creating the menus.

• Find an API to browse through a windows menu's using the handle
• Proof of concept code that browses and clicks on the new file option in notepad

In a three monitor setup, closing window walker when in multimonitor setup and then reopening it when the extra monitors are disconnected results in it being misplaced.

Bug repro steps

1. Launch app and type a letter that gets some windows to show up in the results list
2. Click on one of the results

Expected: We switch to the window we clicked on and Window Walker dismisses.

Actual: we don't switch to the window and Window Walker does not dismiss.

Not sure why but whenever i switch back, the main list flashes as it loads

Such as when clicking outside the window, when in debug mode, etc...