[Feature Request] Add portable .exe back

[L144563]

The new Rust update does not have a portable .exe file like the previous version. This makes it impossible to use the app for people who don't have admin priviliges on their machines (f. e. because they have been forced to use Windows by their employer 😅). Also the new Zebar should either be included in that .exe or have its own portable file. If making a standalone .exe is not longer possible for some reason, consider making an option to install GlazeWM in the user appdata directory without the need for admin rights.

[zadirion]

yes please, I need this to continue working without needing admin privileges

[ParasiteDelta]

Refer to #669. Basically, this is not a possibility without losing at least some functionality, since GWM V3 not only is a signed application and must be installed globally, but it also depends on Zebar, which may or may not require global installation as well to maintain functionality. You can either compile it and see where that gets you, or stick with V2 for the moment.

[zadirion]

Refer to #669. Basically, this is not a possibility without losing at least some functionality, since GWM V3 not only is a signed application and must be installed globally, but it also depends on Zebar, which may or may not require global installation as well to maintain functionality. You can either compile it and see where that gets you, or stick with V2 for the moment.

Don't see why any of those in particular would require global installation and/or elevation.

[ParasiteDelta]

That is actually part of the requirements for full management of windows, including Admin-based windows: it must be a signed application, and it must be installed to Program Files. Lars went over it a bit in #dev-chat on the Discord server a while back. Basically, it's Microsoft's BS that's the reason. As to the Zebar part, as mentioned, that's speculation, given how it's a separate program and communicates to a signed app, but it's much less likely that Zebar needs a global install.

Don't get me wrong, I wish we could have a portable/custom installer too, but the path taken to manage all windows for sure with no real hiccups requires those two attributes. Any workarounds could be appreciated.

[akthe-at]

Is there any chance for a variant that has less functionality but is still portable? I don't know how much of the underlying architecture that would change...However, I am curious because the admin install requirement makes this a 100% no-go for my work/corporate computer (ultimately I would rather have a limited tiling WM than none) when working 8-10 hours a day. :(

[alimbada]

Also looking for a portable option. I'm perfectly fine with not having elevated windows managed by GlazeWM.

[ceuk]

I'd be fine with a reduced functionality version.

As some background/insight portable is a no-go for me as the only time I even use Windows is when I'm forced to for contract work and it's usually inside a heavily locked-down VDI with no admin privileges.

It must be a solvable problem since AHK/bug.n manage to distribute a portable tiling WM with similar functionality. Plus I also use portable versions of:

• Git
• Msys2
• Windows Terminal
• VS Code
• (Neo)Vim
• FlowLauncher

and many others

[zadirion]

I think simply asking the user if he wants to install a self-elevating version in program files or if he wants to install in a user location with no admin requirements, during installation, is the best option.

You need to make the installer not require elevation by default for this, and only elevate if the admin version has been selected. This is doable

On Tue, 13 Aug 2024, 19:19 CEUK, @.***> wrote:

I'd be fine with a reduced functionality version.

As some background/insight portable is a no-go for me as the only time I even use Windows is when I'm forced to for contract work and it's usually inside a heavily locked-down VDI with no admin privileges.

It must be a solvable problem since AHK/bug.n manage to distribute a portable tiling WM with similar functionality. Plus I also use portable versions of:

• Git
• Msys2
• Windows Terminal
• VS Code
• (Neo)Vim
• FlowLauncher

and many others

— Reply to this email directly, view it on GitHub https://github.com/glzr-io/glazewm/issues/656#issuecomment-2286853722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEH4B5IIM7YRKCP45R7GO63ZRJE4XAVCNFSM6AAAAABMD4QA2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBWHA2TGNZSGI . You are receiving this because you commented.Message ID: @.***>

[lars-berger]

Yeah as @ParasiteDelta mentioned, we switched to be a global install for the sake of enabling uiAccess which is a special privilege that can only be enabled if installed to C:\Program Files\**.

How uiAccess affects the WM:

• Able to move windows that are run as admin (without running the WM as admin)
• Allows keybinds using the Windows key

We also separated out the watcher into its own executable (in v2 we had a hacky impl where the executable launches itself again with a flag to spawn a watcher process).

It's possible to have a portable version but with the caveat of no watcher and no uiAccess. It'll be a bit of a pain dealing with the fragmentation and different behaviors depending on how it's installed but it's understandable that some have a need for a portable version

[lars-berger]

If we add a separate release asset on the GH release, it's hard to make it clear that the behavior is different on portable vs. normal installs. IMO the ideal would be something like what Rainmeter does:

If portable install is enabled, then show a destination folder screen:

[SlyCedix]

If we add a separate release asset on the GH release, it's hard to make it clear that the behavior is different on portable vs. normal installs. IMO the ideal would be something like what Rainmeter does:

Looks like Glaze uses Wix for the installer bundling. Wix natively supports installation scope selection with InstallScopeDlg. It's not super well documented, as is tradition with most of Wix v4/v5, but I used the following fragments for the entire installer on an app I recently developed to do this.

MainUI.wxs:

<Wix xmlns:ui="http://wixtoolset.org/schemas/v4/wxs/ui"
     xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Fragment>
        <Property Id="WixAppFolder" Value="WixPerUserFolder"/>
        <Property Id="ALLUSERS" Value="2"/>
        <Property Id="Privileged" Value="0"/>
        <Property Id="MSIINSTALLPERUSER" Value="1"/>

        <UI Id="MainUI">
            <ui:WixUI Id="WixUI_Advanced"/>
            <UIRef Id="WixUI_ErrorProgressText"/>
            <Publish Dialog="InstallScopeDlg"
                     Control="Next"
                     Property="MSIINSTALLPERUSER"
                     Value="1"
                     Order="3"
                     Condition='WixAppFolder = "WixPerUserFolder"'/>
            <Publish Dialog="InstallScopeDlg"
                     Control="Next"
                     Property="MSIINSTALLPERUSER"
                     Value="{}"
                     Order="2"
                     Condition='WixAppFolder = "WixPerMachineFolder"'/>
            <Publish Dialog="InstallScopeDlg"
                     Control="Next"
                     Event="DoAction"
                     Value="WixSetDefaultPerMachineFolder"
                     Order="3"
                     Condition='WixAppFolder = "WixPerMachineFolder"'/>
            <Publish Dialog="InstallScopeDlg"
                     Control="Next"
                     Event="DoAction"
                     Value="WixSetDefaultPerUserFolder"
                     Order="3"
                     Condition='WixAppFolder = "WixPerUserFolder"'/>
        </UI>
    </Fragment>
</Wix>

Folders.wxs:

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
    <Fragment>
        <StandardDirectory Id="ProgramFiles6432Folder">
            <Directory Id="INSTALLFOLDER"
                       Name="!(bind.Property.ProductName)"/>
        </StandardDirectory>
        <!-- Pretty sure the GUID seed can be any valid GUID as long as it's different than the INSTALLFOLDER GUID-->
        <Directory Id="APPLICATIONFOLDER"
                   Name="!(bind.Property.ProductName)"
                   ComponentGuidGenerationSeed="GUID-SEED-HERE"/>
    </Fragment>
</Wix>

[SlyCedix]

Decided to take a deeper look into this. Compiled both the upstream Zebar and GlazeWM from source, added the target directories to my path and with zero changes was able to get everything at the very least running on a computer where I do not have admin rights.

Both Zebar and Glaze seem to be running without a hitch. (even as far as being able to control Task Manager and Task Scheduler, which I thought impossible)

The watcher was instantiated when launching Glaze this way, but I'm unsure how to verify its functionality other than killing glazewm and seeing if any of the windows were "eaten".

My next steps are going to see if I can modify the Wix scripts to get an installer which can install both in the PerUserFolder (usually %LOCALAPPDATA%\Programs) without admin and the Program Files directory with admin

This should theoretically also allow for scoop installation as well.

edit: It looks like Zebar uses Wix V3 and Glaze uses Wix V5, which is going make this a little more of a headache than I thought, since both need to be installable in perUser scope.

For Zebar, changing the package scope from perMachine to perUser does yield an installer which works without admin rights, but, Wix V3 has no native dialogs with support for modifying the install scope on the fly. WixUI_Advanced from WixUIExtension does include an InstallScopeDlg which would work, but as far as I can tell the tauri build wix handling has no way to specify extensions to pass to light.exe. It may be best to completely ignore Tauri's inbuilt Wix support and replace it with a WixV5 implementation. (Wix V3 support also ends in February, so it's probably a good idea to transition anyways)

For GlazeWM, Wix V5 has an package scope option perUserOrMachine. Integrating functionality for that is fairly trivial and could piggy-back off of InstallScopeDlg from WixToolset.UI.wixext which is already included in the install toolchain. The issue is that perUserOrMachine is not supported by bundling. The options, then, are as follows:

1. No bundling for perUser installations

• Requires people utilizing perUser installs to manually install each component themselves
• Does not require significant changes to the GlazeWM Wix scripts and build pipelines

2. Separate bundles for perUser installations

• Requires modifying the build pipeline and Wix scripts to create both a perUser and perMachine and separately bundling each

3. Create a custom installer which, instead of bundling the existing installers, instead just installs both individual, with Zebar being optional.

• Requires the inclusion of Zebar as a submodule or cloning with the packaging script as well as inclusion in the build pipeline.
• Will require a near total rewrite of the wix and build scripts as well as the build pipeline.

Personally, I'm partial to option number 3 with Zebar as a submodule. I think it would give the best flexibility when it comes to user experience and maintainability of the installers. I'd like to hear from @lars-berger before I start working on any such overhaul, since it will be fairly invasive to the overall pipeline structure.

[SlyCedix]

Upon further evaluation, it seems that Zebar can keep using wix V3 without messing with the Wix V5 installer for GlazeWM. Since it can just be compiled as is, with the --no-bundle flag and pulled into the GlazeWM installer as a feature. This does open it up to another issue where the version installed by GlazeWM and the version you would install from the original installer are installed in two differing ways, and as a result aren't uninstalled the same way. Wix V3 places an uninstaller executable inside the install directory, while Wix V5 uses windows inbuilt system to store the installation msi elsewhere, and run it from the Add or remove programs dialog; that's what the Change/Repair/Remove dialog is for when rerunning the installer.

This results in two problems:

• Without bundling (a requirement for a dual perUser/perMachine installers) you would be locked into a single installer type:
  • If you initially installed Zebar through GlazeWM, you can only manage the install through the GlazeWM installer
  • If you initially installed Zebar through the standalone Zebar installer, you can only manage the install through the Zebar installer
• If Zebar receives an update, GlazeWM will need to release a new installer to allow users to update, even if the original version was not iterated.

Both issues are solvable in one of the following two ways:

• Use bundling and deploy a user installer and a machine installer separately
• Create a shared installer repository, which handles deployment for both GlazeWM and Zebar, this would still be capable of deploying individual releases in each repository

Another issue that I've not yet grappled with is that we would still be deploying an Arm and x86_64 version of the installer seperately. ~~But as I understand it, this isn't technically necessary, and MSIs can run crossplatform. The question is whether Wix actually supports this or not.~~ edit: it's actually not supported by MSI.

@lars-berger I'd love to hear your thoughts on what would be preferred going forward.

edit: Also, I'm struggling to get Zebar to even build cross platform due to an issue with the dependency ring, requiring a C compiler, and the default LLVM install of clang for windows not shipping with cross platform headers. It's not technically impossible, but I can't seem to get it working on my system. The issue is known but i have not been able to find a clear answer on what the solution is, because everything I've tried from those issues results in the same error.

[viadee-BiM]

Just a quick note on how I tackled this (since I prefer portable software), assuming a PowerShell session inside a directory which contains standalone-glazewm-v3.8.1-x64.msi:

msiexec /a "$(Get-Location)\standalone-glazewm-v3.8.1-x64.msi" /qb TARGETDIR="$(Get-Location)\glazewm-v3.8.1-x64"

This will provide you with a folder named glazewm-v3.8.1-x64, which will contain all the binaries under PFiles64\glzr.io\GlazeWM (with a cli folder inside there as well) :). Works fine for me. Same for Zebar.

Could this introduce unforeseen problems? I'm sure! Have I run into any yet? Not personally, no.

[fervflow]

@viadee-BiM excuse my ignorance, after running the command to unpack the installer, what executables do I have to run and for what does serve the other one inside /cli?

And, where can I edit the config files?

[Patpatolino]

Just a quick note on how I tackled this (since I prefer portable software), assuming a PowerShell session inside a directory which contains standalone-glazewm-v3.8.1-x64.msi:

msiexec /a "$(Get-Location)\standalone-glazewm-v3.8.1-x64.msi" /qb TARGETDIR="$(Get-Location)\glazewm-v3.8.1-x64"

This will provide you with a folder named glazewm-v3.8.1-x64, which will contain all the binaries under PFiles64\glzr.io\GlazeWM (with a cli folder inside there as well) :). Works fine for me. Same for Zebar.

Could this introduce unforeseen problems? I'm sure! Have I run into any yet? Not personally, no.

Are you still running it like that? Because it doesn’t work for me. Zebar.exe start - no issues. Glazewm.exe start - applications get tiled, but then an error pops up: zebar not found. (Zebar is still running in the taskbar, glazewm is already dead at this point)

[fervflow]

So, I want to share my solution on a corporate laptop without admin rights.

Install Scoop and then install Zebar and GlazeWM from Scoop, since the installations are separate you may have to edit the config file of zebar to use the config that is compatible with glazewm.

Works fine, just a few bugs because of the nature of the installation but completely usable.

[travis-fm]

I can confirm @fervflow comment works great! I'm a weirdo that doesn't use Zebar, so all I had to do after is remove the default start/stop commands in the config.yaml.

I wish I knew about Scoop earlier...