Closed Bug 4177 Opened 26 years ago Closed 25 years ago

AppRunner resources interfere with Viewer resources

Categories

(SeaMonkey :: Build Config, defect, P4)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: pierre, Assigned: chofmann)

References

Details

We can find under res/samples many files that have nothing to do with the Viewer resources, like EditorInitPage.html or nsBrowserController.cpp. These files come from xpfe/AppCores/xul, xpfe/browser/src and maybe other directories. Could you store them in other directories, like res/apprunner or res/editor? I also recommend you to store the resource files into separate folders instead of leaving them together with the source files, that way you can tell the perl script to scan the entire content of the resource folders and we avoid shipping some source files with the beta versions.
Component: Apprunner → Build Config
Target Milestone: M4
pierre, is this the Mac build only that you want changed?
Assignee: pinkerton → don
reassigning to xpapps
I don't know how it is on other platforms. Maybe Windows and Unix need to be changed too.
Target Milestone: M4 → M5
Changed target milestone to M5.
Assignee: don → briano
don, would this be for all platforms? Is this just Mac specific? Trying to get a good feel for Parity Problems here.
Status: NEW → ASSIGNED
Is this really a build/config issue? I don't understand the problem as described, but it _looks_ simple enough to do. Am I missing something?
Assignee: briano → cyeh
Status: ASSIGNED → NEW
Chris, can you help? I don't understand the problem (or the Mac) well enough to do much more that fumble with it. The fact that I think it's trivial, while no one else does, makes me nervous about just changing stuff.
Target Milestone: M5 → M6
so someone stop me if i don't understand the problem: there are actually two problems here: 1) stuff gets dumped into res/viewer that doesn't belong to viewer. 2) it would be nice if resources were kept seperate from source files in the source tree for easier copying and distribution to dist/bin. This is not something that is critical for M5, but something we should clean up. We'd have to change each build system (UNIX, Win32, Mac) in order to have the right things happen. I don't believe this can happen in time for M5. Moving target milestone to M6
Pierre, what's the latest scoop with this bug? Is this still an issue?
Absolutely. We still have tons of files of different types lingering in res/ samples that are necessary to AppRunner. res/samples should only contain the sample files used by Viewer (and eventually AppRunner). It's not a general resource folder. It will certainly not ship in the final product. This bug should probably be reassigned to XPApps since most of these resources are theirs.
QA Contact: 3853 → 2433
Assignee: cyeh → don
Don Melton, come on down! You're the next contestant on "This bug's for you."
I don't know if Don is still allowed to play: he got his chance already.
Assignee: don → matt
Target Milestone: M6 → M7
Pierre, if you want me to notice a bug, then just clear the target milestone field. :-) Matt, how big a can o' worms is this?
We talked about this can of worms and it might be a bit messy. I think we decided to do this in m8 unless we need to do it for the building moz and nscp
Target Milestone: M7 → M8
Target Milestone: M8 → M9
sounds like we decided on early m9 for this. moving it there. let me know if this is not the case.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
moved the resources out of scr.
Status: RESOLVED → REOPENED
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Target Milestone: M9 → M11
Resolution: FIXED → ---
I'm reopening the bug because the cleanup is not over yet: many necessary html, xul, css, and gif files are still present in "res/samples". This directory should only contain the sample files and images used for debugging and that will certainly not be part of the final package. Changing platform to All and target to M11.
Blocks: 12562
so a simpleton like me could fix this bug, if only i knew which files belonged to viewer and which belonged to apprunner. I.E. which files need to come out of res\viewer? or res? Someone point me to a list of files, and I'll move them into chrome. Or wherever.
We should only have in res/samples the files from mozilla/webshell/tests/viewer/samples and, maybe, those from mozilla/xpfe/browser/samples. Note: it's not just a matter a moving the files. You have to update the paths in the code too.
i know about having to update the URL's in the code. I just needed a starting set of the right files to from. While not exactly what I was looking for, it's a start. matt, going to leave you the owner for right now. I might be able to get to this sooner than you. if that's the case, i'll yank the ownership from you.
Most of the files are removed already. I thought bill was going to remove the remaining ones but i guess he didn't. We are only covering the one's that the browser team has put in. As for editor and such i'm not sure which ones get removed.
Assignee: matt → buster
Status: REOPENED → NEW
the answer then is obvious. if the browser ones are gone and we don't know about editor, assign to an editor weenie. re-assigning to buster
Assignee: buster → cmanske
Severity: normal → minor
Priority: P3 → P4
Target Milestone: M11 → M12
assigned to charley, who is wise about such things. set to M12, since it's mostly a cleanup issue.
Assignee: cmanske → chofmann
I don't see any files in res/samples pertaining to editor, except possibly the find dialog, which is shared between browser and editor. But even for that, there are no inappropriate source files there. Simon: Could you please confirm that? I'm not sure who is responsible for confirming that files from other modules have been removed, so I'm reassigning to chofmann
The find dialog is coming from global/content/default. I think there are some obsolete find resource files in res/, but none that we care about.
Status: NEW → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
marking fixed. if some one knows of something specific that needs changin' then put it in the this bug and reopen.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.