Closed Bug 51989 Opened 25 years ago Closed 15 years ago

Picking Program Folder in start menu - doesn't allow browsing of subfolders

Categories

(SeaMonkey :: Installer, enhancement)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Windows ME
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: netdragon, Unassigned)

Details

The Start Menu Program Folders picker doesn't allow you to place it in subfolders of a program folder by allowing you to browse the program folders. It should also carry over any new directories you typed in if you change program folders in the browser as I described (bug # 51988) for the directory selector.
I should be lazy and mark this as invalid Mozilla\SeaMonkey should work, installers are stupid ;-) or maybe worksforme, but since I can't get the installer to work at all... Reporter would you accept that workaround? This is also a good candidate for helpwanted or wontfix. Users can move the shortcuts after the install.
If there is a way I could edit the installer without having to download all the other code, then I would be happy to do it (maybe in a few months :) - It probably wouldn't take that long. My laptop has limited capacity. My workstation was stolen. The thing is that people's first impression of a program is its installation package - and they are also a bi*ch to make. I think a fancy smancy installation package would be cool (and put the icing on the cake) - but that can wait for a while. Why don't we set the target milestone to be whatever Milestone you expect the first release of the program to equal (25?). It is not important until then. Then we can stick a helpwanted in the keywords. Hey maybe someone you know is bored and would like to write an installation program that has irregular shaped windows :)
I have no idea what this report is about.
Asa, if you want to stick the Mozilla program folder in start menu/programs/communications/netscape/mozilla, it doesn't let you. It only would let you place the icons in start menu/programs/communications or some new folder. Therefore, there should be a directory browser for what start menu subfolder to stick it in since there can be subfolders of subfolders of subfolders in the start menu. Also, I said in another bug that when you choose a sub folder in the directory picker for the path of the program - such as c:/program files/communications/netscape/mozilla, every time you migrate to a different directory, it erases the final folder name (such as mozilla). This is a problem because you have to retype the folder when you reach the final parent directory for the mozilla folder. This should also not occur for the start menu directory navigator.
OS: Windows 98 → Windows ME
I give up, confirming. This is yet another bug that would probably be fixed by MSI.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please don't use MSI. A stand-alone executable is so much better. You can download programs such as installshield and the likes, but I recommend you write it in an OS independent way (with OS-dependent parts defined within). Of course the files linked in would be different for each OS - but it would be accessed by the same source code. That way - it would look the same no matter what OS it was installed on using the same source code. Since the register is stored in mozregistry (I believe) there will not be too much that is different. ie a very simple version: void main { #define OS_WIN32 1 #define OS_LINUX 2 ... nOS=GetOS(); ... DecompressArchive(); /* Extract the included files (OS independent - but the files are OS dependent */ SelectMethod(); /* Choose which options to install - the options are read in from "InsOptions.txt" - the format of the file is OS independent */ ChooseDirectory(); /* Also OS independent - although the contents of the directory browser window will depend on the OS. The structure of the window will be identical. Backslashes can be interpreted as front slashes and vice-versa*/ CopyFile(); //Ditto if (nOs==OS_WIN32) InstallStartMenu(); if (nOs==OS_LINUX) InstallXWindowsIcons(); //Or whatever You get the idea... I think while the program is installing - windows should appear talking about the program. This should happen during the whole installation since the files won't take long to copy. It should be attached to a system timer so each window stays up for maybe 5 seconds. I think you should do something original for the background of the installation screen. The Blue-screen and the plain green screens are both overused. You should come up with something original.
By the way - the list of files would appear in another text file for each option. This would be standard for all OSes. That way - the same code could copy the files.
Please contact me on irc. The installer is PLATFORM specific. IT IS NOT!! OS GENERIC. MSI is the correct way to do this. but that doesn't matter, it's a different bug.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Priority: P3 → P4
Also remember the option to select shortcuts creation for both "Current User" and "All Users" under Windows NT and 2000.
over to Curt.
Assignee: ssu → curt
Status: ASSIGNED → NEW
Target Milestone: --- → Future
Product: Browser → Seamonkey
QA Contact: bugzilla → general
Assignee: curt → nobody
Priority: P4 → --
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
old XPFE installer is dead.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.