Application Speedup

[PikeNote]

To help ease loading times, I am considering a few options at the moment.

• Separate the taskbar form to a separate exe
• Other exe will be loaded into app data or something of sorts (or included with the program, idk yet)
  • Major concern of how it is going to be fetched.
  • Preferably local as such that no external connection is required (less chance for an attack if something happened)
• Run that as a separate background process
• Load in items as needed when a user opens the shortcut
  • Write to a file in which another file watcher will keep watch of such file and fetch images and display the items accordingly
• Cache ALL groups (including images) to be readily loaded on demand

[AkiTsugi]

Thanks right now this is definitely the main issue stopping me from categorizing more than a few things together. I think just having it a background process to open it up faster should be an option for those who don't mind it. I just don't know how much faster it would be to see if it's worth it. It's not that slow once I've opened that one specifically - recently (around 1s), only annoyingly slow if it's been a while or I've restarted my PC and it's my first time opening it

[PikeNote]

Will delay this feature/update until other updates are implemented. This would require some work to rewrite stuff to a separate .EXE and include some features.

However, seeing the whole background process idea, it may also handle #8, so that will come after this.

Just to leave it here (some ideas), need to check version of the other background process .exe to make sure it is up-to-date. Background .exe will be located in appdata folder with some other items.

The application will attempt to download a new version of said .EXE from GitHub (off by default setting wise) if the current taskbargroups.exe does not match up with that one.

Versions of both exe (should be the same) will be tracked on the main application for convenience purposes and the user can initiate an update from there.

[PikeNote]

@AkiTsugi Looking for some input as of right now. So, I have made the separate exe as a background process and all that, but I have run into quite of an issue.

Issue 1: How should I include this new "background exe"? That exe has to be stationary, since now all shortcuts rely on it. This would be preferably included alongside, but it would make installation just a tad bit harder. I would go with an MSI installer, but logistics of changing the flow of debugging (since applications are installed together elsewhere is quite concerning for anyone trying to contribute). That will have to be figured out at a later date.

Currently, I can either 1) include the background exe in the resources of the Taskbar Groups.exe (Editor) and on launch copy the file from its internal storage to, you know, the appdata where everything is stored 2) tell users to download both and tell them manually where to place it and/or place it in the same place as taskbar groups.exe so that can move it 3) download it from some file server (GitHub maybe) but that introduces the risk of if say something got compromised to install malware, so I do not prefer it 4) create a custom installer .exe that references both the Taskbar Groups.exe (Editor) and the background exe (manually put in). Now this will just simply (nothing fancy) move the background exe file to the AppData folder, write the Taskbar Groups.exe (Editor) to the same directory, and delete itself.

Solution 4 is a very much temporary fix until workflow with the .MSI gets figured out.

Issue 2: As you know, there is a new context menu for edit group implemented in this release. My concern now is that since the exe handling the shortcuts is no longer the same exe that handles the editor. Now I can't simply try to find the editor exe so I came up with a solution currently. Since the other MSI idea is not feasible right now here are my solutions...

1) create a shortcut leading to the main Taskbar Groups.exe (Editor) when that is launched. Every time a user opens up the .exe, it makes sure to set that shortcut path to the current exe location to make sure it keeps up to date. If this path is invalid (since exe is moved and has not been opened) then it will give a user a prompt to reopen Taskbar Groups.exe (Editor). 2) Same custom installer .exe but this time it writes BOTH Taskbar Groups.exe and the background exe file to the AppData folder. Write a shortcut that launches the editor and places it in the same executing directory (where the user launched the installer), and use that to access editing groups.

[PikeNote]

@Wolverine1977 Since you also have reacted, I want some input as well from your side about the above comment (if it isn't a problem to you ofc).

[Wolverine1977]

Issue #1 - I like Option 1. Can the background.exe be stored in the same folder as the TaskbarGroups.exe? I'm not a fan of files being located in the %appdata% profile folder. I'd much prefer if all files related to the running of the app are in the same folder. I'm trying to use it on my Work PC and running into policy restrictions as to what can be stored in the profile. Long Term it would be great if the app got an installer that unpacked everything needed :)

Issue #2 - 1 sounds good.

Thanks

[AkiTsugi]

Issue 1- I second @Wolverine1977 view of being in the same folder. A lot of the times I use portable apps just so I can be sure the settings and such stay in the one folder when I drag them around between drives. In this case it sounds like it would not run properly without the exe elsewhere. One of the main purpose of this is to be able to run applications that I have in a special folder without having to create a folder for all shortcuts, or categories for each application type.

Issue 2 - I personally like 1 also. Seems simple and it shouldn't be running into that problem too often for it to be considered a hassle regardless.

[PikeNote]

Thanks for the feedback! My main concern is that all shortcuts point to one application. Adding, not a concrete way to put this somewhere is a bit iffy to me because pathing can get messed up and breaks the whole application.

After I finish this up and get it working, I'll add a way both to see where the background exe gets placed in #1.

[PikeNote]

As an update, I am going to release a beta here so you guys can test out the app. I will need about a day or so to implement a system to change where everything is saved.

Need to clean a few things up and reimplement some features (did not know how some things would interact, so I removed them albeit pre-emptively for no reason at all so now it's a pain).

Will mention a few of you if you don't mind to test it out.

[PikeNote]

Update 2 Will release it sometime today (EST my timezone). Implementing the whole portable mode system took a lot longer than expected. Currently, it would move all your configuration files from AppData to your current directory.

Will have to implement and wrap up the background exe. (If it is not active and a shortcut is pressed, create a new process to activate itself) (Link up the new shortcut system as suggested above for Edit Group)

Currently, only Settings.xml, Config, Shortcuts, and Taskbar Groups Background.exe are moved. The rest like JITComp and the new shortcut remains in AppData local since that does not need to be there for it to work smoothly when moving PCs.

[PikeNote]

Taskbar Groups.zip @AkiTsugi @Wolverine1977 Try this above. I had to zip the exe because GitHub won't let me attach it here.

Do note that you just have to (hopefully anyway) run the .exe, and it should do the setup on its own. One major issue that I still have yet to find a solution to is the buggy closing process (when clicking away from the group, it may not deactivate). I may try to, like, see if the user clicks outside the application or something by tracking the mouse. I am not sure yet.

[Wolverine1977]

When I select Portability Mode I get - The application does not have access to this directory!

Not sure why I get that error when running as an administrator?

[PikeNote]

@Wolverine1977 Hmm- I do suspect it may be because it is open somewhere else, like the background application is still running so it can't move everything. I'll check.

[AkiTsugi]

I get the same error and it doesn't look like it's running still, but it could be. Even my first time running it. I am also on built-in Administrator account. That's the only thing that happens when I run the exe.

[Wolverine1977]

I checked that there are no other instances running but keep getting the same message. Unable to switch to Portable mode. I'm able to run my previous taskbar groups but I just noticed that the right click Edit group (from taskbar) doesn't work any more, I get the hourglass then nothing.

Currently working with the new .exe using the profile shortcuts previously created. I can launch the main .exe and create and edit groups but they use the profile location and can not be switched to portable. Tried closing the background.exe but it didn't make any difference to portable mode.

Hope this helps. Thanks

[PikeNote]

To confirm, no files were moved correct?

[Wolverine1977]

Correct, nothing was moved.

[PikeNote]

Taskbar Groups.zip Been a little busy, but here you go. I couldn't exactly replicate the issue, so I will throw the exception so you guys can see exactly what the issue is. If possible, can you share that here? @Wolverine1977 @AkiTsugi

[AkiTsugi]

What do you need me to share? Sorry, it just gives the same error.

[PikeNote]

The same "The application does not have access to this directory!"? That is odd, I removed that part. Let me check.

[AkiTsugi]

Nah, my error was the Settings.xml may be open in another file. I never got that fixed.

[PikeNote]

Taskbar Groups.zip If that is the case, try this.

[AkiTsugi]

I had trouble downloading cause of Windows Defender, made an exception but it doesn't matter because as far as I can tell it does nothing. I tried using the shortcut with this exe just in case also, and it also does nothing as far as I can tell.

[PikeNote]

Nothing in terms of portability mode not working or nothing as in the groups aren't opening?

[AkiTsugi]

Sorry, I just realized it needed the beta version for it to transfer correctly. Because it needs settings already in the app data folder for it to function. It didn't transfer from the previous version I had as that one did not use the appdata folder (didn't think about this) That was completely my fault as I though it would copy them over or just create a new one (shouldn't it do this in case you don't have a prior version?) Now that I've ran and made a group on this beta version, this prior exe works. However, I do see the portable error now. Do you need a copy of the Unhandled exception details?

[AkiTsugi]

This is probably what you needed? "Source and Destination path must have identical roots. Move will not work across volumes"

[PikeNote]

Yep, I will take a look at the issue you encountered and see if I can prevent that from happening. Also, oh, does that happen because you have windows and the app stored on different drives?

[AkiTsugi]

Correct, I've always had it on my D: drive. As I use that drive for applications storage, that either never update or for settings that I need to keep across PC. It also happens to be that most of the applications are also in that drive, as it's one the main usage for Taskbar Groups.

[PikeNote]

Alright, I will create a patch for that issue. There is a few ways around it.

[PikeNote]

Taskbar Groups.zip @AkiTsugi Here is a fixed version (hopefully), added some few other things such as updating the Background exe.

Before you run it, can you note the md5 hash of the old background exe here and the same exe after you run it?

It checks the exe's hash and replaces it with an internal one if the hashes don't match up to make sure both the editor and background stays up to date.

[Wolverine1977]

Hi - Just downloaded the fixed .exe from above and the portable mode works as expected (on my home PC). It placed all the files in the new folder and ran it. Placed the new exe file in a new folder and ran - it preserved my shortucts and moved them to the folder allowing me to clean up the profile location.

[Wolverine1977]

I had to place the .exe in the same folder and run then select Portable mode on my work laptop to get it to run. I initially tried it in a new folder so as to not mess the old working shortcuts up - I got an error that the settings.xml was not accessible. Dropped the updated exe in the original folder - it opened and I selected Portable mode and it moved everything to the folder - I was able to delete the Profile folder and its all working.

[AkiTsugi]

So, for me the above .exe Portable mode still doesn't work. I would like to add that the prior one while the editor ran, the shortcuts never worked. it did add the shortcuts and I 'saved' them in case I had to do that to update the new shortcut and it opens it up but the actual groups never open. I did check Task Manager and the process does start for background.exe Edit: Forgot to mention currently the groups still don't work. opening the shortcut in taskbar does nothing besides open the process.

Current .exe opens the editor fine, but it does give the, "The application does not have access to this directory!..." when I try to use portable mode. Opening the shortcut to the editor inside the local/appdata folder gives that same error on launch unless I run it as an Administrator.

Hashes did update for background.exe from 78ad116cfad0608e17f1c0ff5268ed3e to 3afd14bcf84920f2ca6435744aa3ce92

[Wolverine1977]

@AkiTsugi are you running from a drive root or root folder? Does the path have spaces in the name?

[AkiTsugi]

Path was - D:\QuickTools\Taskbar Groups so it did have a space. I removed the space now to just TaskbarGroups. It did not change anything.

[Wolverine1977]

@AkiTsugi was worth a shot 😀. Try a folder in the root like D:\TaskbarGroups ?

[AkiTsugi]

Nope, portability mode still doesn't work~ I can try delete all the folders and remake everything with the new .exe I'm not sure it'll do anything, and it might work but it might beat the purpose of trying to get it to work with the older files.

[AkiTsugi]

Well I can tell you that, I can't run the new .exe still without having an appdata folder from previous version already up. It will still give the settings.xml error, cause I have none and I guess it doesn't create new ones. I should have figured that part wasn't fixed so i can't exactly test what I said above then with no files.

[Wolverine1977]

Update - my group lost its icon and I'm not able to edit the group from the context menu - Settings.xml may be open in another file. This happened after a reboot. Group shortcut still works but has a blank icon?

[PikeNote]

Taskbar Groups.zip

@AkiTsugi Sorry, I was out today since I had to rebuild my PC in a new case. On a lighter note, I just realized the bug. The Settings and Paths initialize at different times. Settings may have gone first, and thus no directory was created. I may have fixed it as above. Regarding your "The application does not have access to this directory!.", is it the same it can't move cross volume?

@Wolverine1977 Try the new build above. Can you tell me what error message it says at the end, so I can better diagnose it?

[AkiTsugi]

Still need settings.xml in appdata file, prior to running the new .exe

Tried portability mode, now it's just

[Wolverine1977]

My icon disappearing issue was that the pinned group shortcuts were still pointing to the profile path even though the application was in portability mode? I was able to unpin the group shortcuts and re-pin them after portability mode was enabled.

[PikeNote]

@Wolverine1977 Yeah- that may be a Windows limitation. I remember something along the lines of pinned stuff has its own shortcut created to make sure it stays there. Now it becomes an issue if original stuff were moved.

[PikeNote]

@AkiTsugi Sorry about the issue. Having some trouble replicating specifically the portability mode issues. However, I did track down the issue with needing the AppData folder. Turns out the patch I did earlier was only done in the background exe and not the main one which was a stupid mistake on my part. For the portability mode part of the issue, I decided to make it throw the issue instead, so you see the full thing. That should better help diagnose it.

(Edited: Fixed upload) Taskbar Groups.zip

[Wolverine1977]

@PikeNote I'm using the v0.3.0.0 that was previously uploaded. Is this the same file? When I copy the file above into my folder it doesn't recognize my groups and my list is empty. But the version = 0.3.0.0

[PikeNote]

@Wolverine1977 It has a bug fix included. It isn't the same. Version numbers are just for releases. I don't usually change them for test builds and attempting bug fixes like here. I maybe should to better keep track, but I am not sure.

[AkiTsugi]

So this worked. First, Defender gave me another warning on this one also. But I deleted the appdata folder and ran the exe.

The appdata folder in ROAMING was created but no files. The .exe did not do anything but open the process and close itself. Editor never showed.

I ran the previous one that I know makes appdata folders fine, and that created the app folder in /LOCAL, so then ran this new .exe and works just like before AND portability mode works also. Moved files just fine!

Edit: But the actual group shortcut does not work for me, like at all. It runs the background.exe and stays open, but don't actually see anything.

[JohnLGalt]

In light of the way Windows 11 does things differently with their taskbar, I'm actually (pleasantly!) surprised that 2.0 Alpha works pretty well it.

I'm just now visiting this issue, and since I'm having only minor issues with the 2.0 Alpha, I don't think I need to 'upgrade' as I already have my groups created, and replacing the executable with a newer won't affect those already created, correct?

At any rate, I have discovered a small bug that I'm going to search for and if I can't find it reported, then report it myself. But other than that it's working perfectly fine for me in Win11.

[PikeNote]

@AkiTsugi Not sure if you are still active on this issue. What was the progress on this issue again? I have a hard time tracking, since it's been a while I've worked on this. I'm sure you most likely moved past already, but just in case if you still needed help/willing to, I'm open to work on this issue once again.

[PikeNote]

Closing this issue since it is fully implemented and original issues may no longer exist