refactor XP Apps [namely XP Apps: GUI] components

RESOLVED WONTFIX

Status

()

P1
major
RESOLVED WONTFIX
18 years ago
7 years ago

People

(Reporter: bugzilla, Assigned: ian)

Tracking

Details

(Reporter)

Description

18 years ago
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].
(Reporter)

Comment 1

18 years ago
filed bug 68623 to rename Browser-General to something...more general. :)
(Reporter)

Comment 2

18 years ago
another name for (1) above-- XP Apps: Browser window only.

Comment 3

18 years ago
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)

Comment 4

18 years ago
I like alec's proposal:simple and clear

Comment 5

18 years ago
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.

Comment 6

18 years ago
<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

Comment 7

18 years ago
XPApps: Clipboard

Comment 8

18 years ago
Hopefully people won't think XP Apps = Apps that run on Windows XP (the next gen 

Win32 operating system), sorry I digress...

Comment 9

18 years ago
I don't think there are nearly enough clipboard bugs to warrent XPApps:
Clipboard
Status: NEW → ASSIGNED

Comment 10

18 years ago
oops, didn't mean to Accept the bug, force of habit, sorry asa

Comment 11

18 years ago
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>
(Reporter)

Comment 12

18 years ago
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]

Comment 13

18 years ago
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...

Comment 14

18 years ago
isn't clipboard a toolkit service?
(Reporter)

Comment 15

18 years ago
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.

Comment 16

18 years ago
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.

Comment 17

18 years ago
> * 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).

Comment 18

18 years ago
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....

Comment 19

18 years ago
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.

Comment 20

18 years ago
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).

Comment 21

18 years ago
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.

Comment 23

17 years ago
(hopefully) next on my list. 
Severity: normal → major
Priority: -- → P1

Updated

17 years ago
QA Contact: lchiang → timeless

Comment 24

17 years ago
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. 

Updated

16 years ago
Blocks: 167518

Updated

16 years ago
No longer blocks: 167518
(Assignee)

Comment 25

16 years ago
->me
Assignee: asa → ian
Status: ASSIGNED → NEW
(Assignee)

Comment 26

16 years ago
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?

Comment 27

16 years ago
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 :)
(Assignee)

Comment 28

16 years ago
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.

Comment 29

16 years ago
I agree, and don't see any obvious net benefit.  Are the current owners
requesting this?

Comment 30

16 years ago
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
(Assignee)

Comment 31

16 years ago
WONTFIX per comments
Status: NEW → RESOLVED
Last Resolved: 16 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.