tobbe / losi Goto Github PK

It’s possible the user removed the previous shell after installing LiteStep.

Go back to the previous shell when uninstalling if that .exe file still exists, otherwise go back to explorer and reset all registry entries to default.

Seems like one of the depending DLLs by the (age old!) xtaskbar-1.1.5.dll can't be found.

Add another page to the uninstaller where the user is asked what files to keep and what files to remove. Do this to get rid of the message boxes currently shown during the removal of the installed files.

Right now SectionCore installs LiteStep core files, a few modules and the OTS folder structure.

This should be split to a SectionCore and a SectionOTS (section OTS would also install the modules). Maybe even split it to SectionCore, SectionOTS, and SectionModules

Test and make sure that a module built with VC9 runs on a machine that only has the vc9 sp1 redist installed. If it does, LOSI should recommend installing only vc9 sp1, if it doesn’t both vc9 redists and vc9 sp1 redists should be recommended.

It seems like LOSI can’t kill explorer.exe under certain circumstances.

I think it is when I Install LOSI → Uninstall LOSI and then try to install LOSI again. The second time I install LOSI explorer doesn’t die on the finish page of the installer.

Fix by running

```
taskkill /f /im explorer.exe
```

if taskkill exists on the current OS. If it doesn’t exist we have to ask the user to manually kill explorer.

I only checked “Configure Evars” when installing, and I choose to not have any support for profiles. The install log says the following:

```
Målkatalog: C:\Program\LiteStep\Profiles\Tobbe\themes
Extrahera: themeselect.rc… 100%
Extrahera: themeslist.rc… 100%
Målkatalog: C:\Program\LiteStep
Slutförd
```

Those files shouldn’t be extracted at all since I didn’t choose to install the OTS files or the Theme files.

When uninstalling LOSI there’s first a message “Will now try to start explorer”. The next message is “Run: $litestepdir$\LiteStep.exe”. This is confusing. It’s better to just hide the “Run: …” message and the next run message that comes directly after the first.

Andymon has released a new update for xPaintClass, it should be included in the installer.

LOSI should install LiteStep 0.24.8

After running the installer HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\AutoRestartShell is always set to 0 after installing LOSI, no matter what value it had before running the installer.

LOSI needs this reg key to have specific values during installation (and uninstallation), but it should restore the original value before closing.

Username (on your computer): Darrin

Operating System: Windows 7 Ultimate 64-bit

Installer Language: English
Installer Components: LOSS.lua
Destination Folder: C:\LiteStep\utilities
User Profiles Location: C:\LiteStep

Bug: Non-functional logoff/reboot option in the SetShell Utility
Details: When using the command-line options through the desktop shortcuts, or the "full version" through the menu, selecting the logoff/reboot option seems to not work. After the warning box comes up, I hit "Yes" and then a command window flashes briefly for half a second, and then goes away. Then I sit there and watch my computer not logoff or reboot.

Don’t kill the current shell (unless we’re upgrading/updating) and don’t start LS until the very last page of the installer where there should be an option to start LS or not.

Investigate what happens if the user continues to run Explorer (or bb4win) when LiteStep is set as the shell.

When I double click .rc files they open in Notepad. They should open in the program I have associated with .txt files.

When I double click .txt files they open in Notepad++.

The evars configuration dialog properly identified Notepad++ as my text editor.

After installing LOSI to C:\Program\LiteStep and then to C:\LOSI and finally uninstalling LOSI from C:\LOSI I got the following error when trying to set LiteStep as the shell from the start menu icon:

```
-————————————
wxLua Error
-————————————
lua: Error while running chunk
C:\Program\LiteStep\utilities\LOSS.lua:124: attempt to index global ‘hkey’ (a nil value)
stack traceback:
C:\Program\LiteStep\utilities\LOSS.lua:124: in function ‘getLitestepPath’
C:\Program\LiteStep\utilities\LOSS.lua:278: in main chunk

OK
-————————————
```

This is done by setting the shell in HKLM and not in HKCU and by keeping the IniFileMappings at the “SYS;…” setting.

Make sure the “install without rebooting” feature doesn’t break.

Inform the user that any new users added to the system will also get LiteStep as their shell.

I realized this weekend that LOSS doesn't account for global installs, in that it only changes the HKCU settings in the registry. This meant that a "global" installation wouldn't even be able to change the shell using LOSS. The following is an IRC conversation with Tobbe discussing solutions.

Tobbe:
    So, think of it like this 
    "Jane: Who the hell put LS on here? Let's switch back to explorer" 
    "Joe: WTF? didn't I just install LS, let's switch back to LS" etc... 
    That's why the switching is on a per user basis, even if you installed for all users

the-golem
    :-/
    then don't give them the choice in the first place

Tobbe 
    the choice to do what?
    switch shell?

the-golem
    the choice to do it for all users

Tobbe
    that's the way it is. There is no choice to switch shell for all users
    (in LOSS)

the-golem
    no, i mean the choice to install it

Tobbe
    I don't want to limit the posibilities

the-golem 
    ummm ,k so how i understand it, is that when installing, your script says:
    if the user chose to install it on a per user basis, change the IniFileMap to "USR:" 
    otherwise, leave it as "SYS:" SYS points to the localmachine winlogon, usr points 
    to the hkcu winlogon. Now, if the user wants to switch his shell,
    it only changes the hkcu setting.

Tobbe  
    I see where you're going

the-golem  
    since the iniFileMapping points to SYS, changing hkcu has no impact

Tobbe  
    yeah :(. you're right. There is a bug here :(

the-golem
    so, lets revisit our options.
        1) Don't give them the option. Install for current user
        2) Give options, include machine-wide support in LOSS
        3) Keep as is, however, if it's installed per machine, then change the inifilemap 
             so that it changes on a userbasis
        The way I figured it, if someone installed it machine wide, either he's the only user,
        or everyone else is fine with it

Tobbe
    How about this? Always change it to USR: and always make sure the current user
    gets LS as shell. If it's a "global" install, give all users shortcuts on their desktops/start 
    menus to switch to LS, if it's a "local" install, only give the current user those shortcuts.
    Does that sound like a good idea to you?

the-golem
    by "always change it to USR" you mean in LOSS, and the rest for the installer?

Tobbe
    no, always change to USR, even in the installer

the-golem
    ah ok. that's probably the better option, but  we have to change how
    global installations are done then

Tobbe
    yes

LOSI 0.4 sets the the HKEY_CURRENT_USER\Software\LiteStep\SLI\ThemeManager\ThemeDir key to ‘C:\Program Files\LiteStep\Profiles\%username%\themes’ (Where C:\Program Files\LiteStep is the litestep install directory). This causes SLI to not correctly find the themedir, and requires the user to manually set it.

FIX: Make it so that ‘username’ is actually replaced with the current user’s name on install.

Not sure if this should be considered a bug with LOSI for setting the key to this, or a bug with SLI for not recognizing environment variables like it should.

When installing for all users and opting to have support in LiteStep for different user profiles LOSI needs to give all users personal files and themes.

This means LOSI needs to enumerate all users on the computer and create LS profiles directories for every user. Where these directories should be created depends on what choices the user made during installation.

This is how to enumerate the users using NSIS: http://nsis.sourceforge.net/User… (Might be possible to specify an empty computer name to search on the local computer, which is what we want.)

NSIS now comes with an official header for checking Windows version. LOSI should switch to using that instead of the custom header it’s currently using.

All links created by and within the installer point to http://tlundberg.com/LOSI/ , this leads to a 404. They should point to http://tlundberg.com/losi/ .

If LiteStep is detected as running during the installation it will be !quit without first telling the user about this.

It would be nicer to inform the user that LiteStep will be shut down, and why this is necessary before killing it. This should be implemented on a separate page in the installer.

If LiteStep is used by multiple users on the computer and one of the users uninstalls it, it will be uninstalled for all users.

Detect/keep track of how many users are using LiteStep. Maybe by looking at how many profiles folders there are. Allow the user to choose if he wants to completely remove LS or just uninstall it for himself.

Maybe some descriptive text is needed and/or a rewording of the options.

> For example “Only for the currently logged in user” make it seem like no one else will be able to use this particular LiteStep installation.
>
> Whereas “For all users on the computer” sounds more like what people would want, but they may not realize that everyone’s shell will automatically become LiteStep.
>
> And the third option sounds like what the 2nd option actually is.
>
> 1st Option: Set LiteStep as default system shell for all users. (Only select this if you do not want to enable profile support in the next page)
>
> 2nd Option: Set LiteStep as the shell for the current user. (LiteStep may be set as the shell for other users in the future as well)
>
> 3rd Option: Do not set LiteStep as the shell at this time. (File installation only, no systems settings will be changed)
>
> [jugg]

Make the Profiles page show the actual paths that will be used when installing. ($INSTDIR should already be set to the correct value)

Copy the msvcp???.dll files to $litestepdir$ instead of system32 (check system32 if they already exists first)

Sometimes a few files are left behind after uninstalling LiteStep.

I have not been able to find the cause of this.

To solve this bug I need to find a way to reliably reproduce this.

Ran across this at customize.org: http://customize.org/groups/topic/14342

The complaint contains a link to a screencap of an error message that shows when trying to uninstall LS: http://min.us/llB9ia

Go through all the NLM sites and make sure they're still running.

Perhaps add new ones (greywool's?)

For some reason explorer doesn’t always start at the end of the LOSI uninstallation.

I have experienced this myself, and gotten reports about it.

> Running an XP system, no alt-shell ever installed, so Explorer was running during installation. I did a custom install, but selected everything to install. The only pre-req missing was the optional vc9 runtimes, and I didn’t install those. I chose to install “only for current user” and chose to install no profile support. I installed to C:\shells\litestep. The default theme for LS/LOSI was running when I uninstalled. [jugg]

1. Proposed solution

Check to see if there is an explorer.exe process running after a while. If there isn’t, try to run it again.

If it still isn’t running after some additional time, tell the user explorer is having trouble starting and use windows’ task scheduler to schedule a start of explorer.exe in the next minute. This will need an OS check as this is only available on Win2000 and up.

Last option is to tell the user to manually launch explorer.exe using the Task Manager.

Kill litestep and go back to explorer as soon as possible during uninstall. After a while if explorer isn’t running, try again. If explorer at the end of the uninstall still isn’t running. Tell the user what to do to bring it back.

If an old evars.rc is found it should be parsed and as many values as possible should be used. These values should be the suggestions for the evar config pages.

The evars.rc file should be searched for in the directory LOSI is being installed to and in any other LiteStep folder the installer finds.

Sanity checks should be made on all paths so they actually point to an executable file.

If you chose to install LiteStep for all users (=setting the shell in HKLM) any new users added to the computer after the LiteStep install will not have a working shell. They will get LiteStep error messages complaining about a missing ThemeDir.

Currently if a litestep.exe process is detected during the install this process is killed. This is done to make it possible to upgrade the LiteStep you are currently using. However, if no litestep.exe is found in the directory the user is installing to, it isn’t needed to kill litestep.exe.

Of course it needs to be killed at the end of the installation when we’re about to launch the new LiteStep.

The WhereProfiles page should only be shown if the OTS files are selected for installation.

Switch to /refreshsilent and add [!recycle] to the popup command.

When installing LOSI to a new directory on a system that already has LiteStep running the very first output in the extracting files dialog is confusing.

Let’s say LOSI/LiteStep is already installed to C:\Program\LiteStep and running from there. Now the user installs LOSI to C:\LOSI. The first line of output is now going to be

```
Run: C:\LOSI\litestep.exe !quit
```

Expected output would be

```
Extracting: C:\LOSI\litestep.exe
Run: C:\LOSI\litestep.exe !quit
```

or even better

```
Run: C:\Program\LiteStep\litestep.exe !quit
```

Best option would be to solve issue #3 removing the need for this altogether.

This only applies when installing while another instance of LiteStep is already running.

> Definite bug here. Because the evars were configured After the LOSI litestep was launched, none of their settings took affect. For example, I was just trying to figure out why notepad was being launched when I tried to open the $txteditor$, and looking at !alert “$txteditor$” showed that it was configured as “notepad”, yet that is not what “evars.rc” had defined. Quite confusing at first. [jugg]

This will have to be solved either by configuring the evars before launching LiteStep, or by calling !recycle after updating the evars.

InstFiles should be called as late as possible during installation. The reason for this is that you can’t cleanly cancel the installation after InstFiles has run. InstFiles is the page that copies all the files to the installation directory.

The HowLS page should only be shown if SectionCore is selected.

The default step.rc contains

*NetLoadModuleSite “http://www.modules.nbi-studio.com/”

And that site is no longer functioning.

You can replace it with:

*Netloadmodulesite “http://www.ls-themes.org/modules/download/”

Doing a standard/default install LOSI 0.4 (and 0.4.5) crashes right after copying all files (after the InstFiles page) if the user has an apostrophe in his username.

In Windows Vista and 7 you get a "This program might not have installed correctly" message when closing the installer.

Add RequestExecutionLevel to the nsis script to fix this

The default step.rc in LOSI has the following line:

include “$ThemeDir$config_compatibility_patch.rc”

This is only needed for OTS1 themes. However, the remainder of the step.rc does not implement the necessary architecture for complete support of an OTS1 theme.

I suggest removing that include line all together and moving the themeselect.rc include line right above the remaining include lines.

Add some text like "if some preconditions don't have a green checkmark, please install the corresponding software first." If all prerequisites are met it's not clear if the green check marks are just eye candy, or if the installer really checked to make sure everything is installed.

Using the Swedish translation the bottom of letters like ‘g’ and ‘y’ gets cut off in the bottom option on the “WhereProfiles” page.