Closed Bug 68621 Opened 24 years ago Closed 22 years ago

refactor XP Apps [namely XP Apps: GUI] components

Categories

(bugzilla.mozilla.org :: Administration, task, P1)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bugzilla, Assigned: ian)

Details

XP Apps: Cmd-line could remain the same... it's XP Apps: GUI that needs reorganization. :) here's what i've come up with from the [most recent] discussions over email and n.p.m.xpfe. feel free to add suggestions, or lemme know if i mislabelled/misrepresented something here... [although, in this bug i'm trying to avoid the "move layout/gecko items into their own product" issue, as it's rather...large. i wanna keep the focus of this one as narrow as possible, heh.] 1. XP Apps: Browser only [alternative: Browser Front-end, but sounds too generic, imho] Description: Browser-specific menus and context menus. Helper Application issues. Also, features that appear within the browser window, which aren't covered by existing Browser components. [akin to Mailnews: Front-end, but not as broad.] 2. XP Apps: Shared features Description: Cross-platform items that are shared among the browser, mailnews and composer products. eg, Find dialog, generic dialog issues, menu issues that aren't toolkit-related, but appear across products. other thoughts: methinks XP Apps: Shared features could co-exist with bug 68555 which proposes XP Apps: Drag and Drop. anyone have problems with that? also, i'll file another bug to rename Browser-general to General [or, General-misc].
filed bug 68623 to rename Browser-General to something...more general. :)
another name for (1) above-- XP Apps: Browser window only.
I'd almost rather not see XPApps: browser, just because browser is a component like any other (i.e. we don't have XPApps: History Window, or XPApps: Editor) - the fact that the _netscape_ organization called XPApps happens to work on the browser doesn't need to be reflected in the bug system As for D&D, while it's popularity would seem to warrent a seperate component, I'm not sure that there are that many generic drag & drop problems...i.e. most of them are problems with a particular component like bookmarks or the browser. How about XPApps: Shared XUL (i.e. a direct rename of XPApps: GUI Features) XPApps: D&D XPApps: Architecture (i.e. for shared JS or C++ that has no UI, like Windows DDE support, browserinstance junk, x-remote, etc) Browser: UI (for _Navigator_ menus, back/forward buttons, etc) Browser: Dialogs (like Find Browser: File Handling (for file downloads, MIME types & editor, etc)
I like alec's proposal:simple and clear
With regards to the d&d, yeah, I know that there aren't many generic ones. I'll fix what I can and triage appropriately what I can't/aren't interested in.
<http://groups.google.com/groups?q=xyz&seld=952225234&ic=1> If implementing that proposal was desired, refactoring `Browser' > `XP Apps: GUI' would give: * General > Front End * Browser > Front End * Mail/News > Front End * Editor > Front End
XPApps: Clipboard
Hopefully people won't think XP Apps = Apps that run on Windows XP (the next gen Win32 operating system), sorry I digress...
I don't think there are nearly enough clipboard bugs to warrent XPApps: Clipboard
Status: NEW → ASSIGNED
oops, didn't mean to Accept the bug, force of habit, sorry asa
I want the clipboard component because it seems that clipboard is owned by people other than the default xp apps group. <offtopic>german: Yeah, I think ms decided to capitalize on the value mozilla.org has created in the XP branding</offtopic>
chatted with alecf re: his suggestions [thx a lot, alec!], and came up with these components: * Browser Window Front End [instead of Browser UI]: menus, context menus and other features unique to the browser window. * Browser Dialogs: would include Find, Open Web Location; again only dialogs unique to the browser. * Browser File Handling: file downloads, MIME types/editor, helper apps... * XP Apps: Shared XUL: stuff that spans the browser, mailnews and editor --eg, status bar, shared menus like Tasks, general toolbar issues, general dialog issues. * XP Apps: Architecture: shared JS or C++ that has no UI, like Windows DDE support, browserinstance junk, etc... * XP Apps: Cmd-line: would like to keep this one as it's pretty distinct and an easy component to find/use. :) * XP Apps: Drag and Drop [ie, if we decide to go with this]
Could clipboard be in the same category with drag'n'drop to inc. timeless' idea? This goes together as in data transfer = clipboard + drag and drop. Just a thought...
isn't clipboard a toolkit service?
hmm, i thought clipboard would be more in the selection component, since it deals with copying and pasting... kinda out of my realm, so perhaps i might be misunderstanding what you mean by clipboard.
Thoughts: > * Browser Window Front End [instead of Browser UI]: menus, context menus and > other features unique to the browser window. Many menu and context menu items aren't specific to the browser. And 'other browser-specific stuff' is pretty general; I can't think of too much (any?) XPApps stuff that's truly browser-specific. > * Browser Dialogs: would include Find, Open Web Location; again only dialogs > unique to the browser. Find and Open Web Location aren't really specific to the browser. * XP Apps: Shared XUL: stuff that spans the browser, mailnews and editor --eg, status bar, shared menus like Tasks, general toolbar issues, general dialog issues. I think this is a far too technical name for a non-technical component. If I didn't know what xul was, I'd never report things against this component. > * XP Apps: Cmd-line: would like to keep this one as it's pretty distinct and > an easy component to find/use. :) Sure, but also pretty obscure. I don't think this really deserves its own component anymore if Keyboard Navigation doesn't. > * XP Apps: Drag and Drop [ie, if we decide to go with this] I would like to do it. I think it's a big enough area to warrant its own component. I assume all those Browser Foo components would just be component Foo in the Browser product. Also, I can't tell from your post whether XPApps is intended to be a separate product or not. If not, things are still broken. Most XPApps issues are cross- app, so they shouldn't be in Browser any more than in MailNews or anywhere else. (As a side note, why doesn't Composer have its own product?) XPApps should be a product. I know this would mean a lot of work moving stuff around, etc., as others have said, but I would rather do this once and do it right than tweak current components to cover the fundamentally flawed issue here.
> * Browser File Handling: file downloads, MIME types/editor, helper apps... That doesn't belong in `Browser' either, it belongs in `General' (since it applies equally to the mailer).
clipboard and DND are closely related, not to mention that they both are toolkit services... however, there is a fair amount of glue code that exists in the FE for both of them... I guess between DND & clipboard there are enough bugs for us to have a component (I'm flexible on the name.. XPApps: Data Transfer is actually the same length as XPApps: DND/Clipboard, so I'd lean towards the latter since it's more obvious what it is. As far as reporting things against components like XPApps: Shared XUL: I really think there are just some components that won't have bugs filed against them by the average novice, no matter what we call them. I think we have to just be prepared for someone to file a "Browser Window Front End" bug about the status bar, and hope that a QA person, a bugday person, or an engineer is smart enough to reassign the component when it arrives....
Browser: Front End Browser: Dialogs <- it's possible we'll not use this, however i think we'd need to do a complete inventory before deciding. Right now i'm willing to believe that all browser dialogs are common dialogs so this component need not exist. XP Apps: Architecture XP Apps: Command-line <- we have enough bugs like this and they don't belong anywhere else. XP Apps: DND/Clipboard <- german/alecf's idea sounds good to me XP Apps: Common Dialogs <- shared xul is really a class of common windows. Browser File Handling: file downloads, MIME types/editor, helper apps... This belongs in Network.
mime types, helper apps and such don't belong in networking. They're handled by law and mscott, neither of whom work on core networking issues (and helpers apps/mime types aren't core networking).
no, shared XUL is not a class of common windows - shared XUL is a set of visual widgets and such that decorate many mozilla windows. I highly object to XPApps: Common Dialogs, and stand by XPApps: Shared XUL
Do you agree that having a component tree with links (i.e. a "DAG", directed acyclic graph) would help with this problem? See bug 43940.
(hopefully) next on my list.
Severity: normal → major
Priority: -- → P1
QA Contact: lchiang → timeless
OK, we're already got File Handling and I can easily add a Clipboard to the XPApps D&D component. This leaves the need to cover the "xp apps architecture" bugs and some better way of distinguishing the browser only FE from the cross-app FE. Am I missing something else major here? I really do think that we need to split out the shared stuff from the app-specific stuff at a Product level. I've got some ideas for making our products and components a little more precise, and I hope discoverable but it's not likely to happen for a while so I'd like to try to make the XP Apps stuff a little better in the short term before refactoring Products.
Blocks: 167518
No longer blocks: 167518
->me
Assignee: asa → ian
Status: ASSIGNED → NEW
So it's been nearly a year since this bug was last touched. Does that mean the issue is moot? What components d'y'all want?
Simple bits (for discussion) rename: XP Apps: Autocomplete => XP Toolkit/Widgets: Autocomplete XP Apps: Cmd-line Features => XP Apps: Command-line XP Apps: Drag and Drop => XP Apps: DND/Clipboard XP Apps: GUI Features => XP Apps: Shared XUL Shared XUL would include the Tools and Window menus, the component bar (for as long as it lives), and the offline widget? create: Browser: Menus (This includes navigator menus and context menus but not menus which are loaded from another package) Browser: Toolbar/Statusbar (This is the only other part of browser and it is relatively distinct from menus) XP Apps: Architecture (i.e. for shared JS or C++ that has no UI, browserinstance junk, etc) XP Apps: Dialogs (like Find) note: filehandling and xremote have components, and i think os integration or something else can get DDE bugs (I'll mention DDE and AppleScript in the integration bug). Once we get the list of components we can track down assignees and qa contacts :)
Do we really want this? I don't see those components as being very obvious to bug reporters... *shrug* Seems more like categorising for the sake of it than useful splits.
I agree, and don't see any obvious net benefit. Are the current owners requesting this?
with the removal of UID, XPAGF is the likely dumping ground for bugs. http://bugzilla.mozilla.org/buglist.cgi?product=Browser&component=XP+Apps%3A+GUI+Features
WONTFIX per comments
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.