14257 - Unimplemented menu items need to be removed for Beta 1

Status: VERIFIED DUPLICATE of bug 25135

(SeaMonkey :: MailNews: Message Display, defect, P3)

Description

[lchiang]

Unimplemented menu items need to be removed for Beta 1

Per the beta 1 criteria document, all unimplemented menu items need to be
removed.

Mail window
Compose window
Address book window

(Note: I don't really agree with this - I think we should leave the menu item in
with a period convention (which we have now) to designate unimplemented menu
items.  This way, the user will know that we plan to have a particular feature,
but it's not yet working.)

But, I'm logging this bug since it's supposed to be in for Beta.

Comment 1

[Phil Peterson]

cc'ing all the XUL owners in the group. Guys, do you want separate bugs on this
for the 3 pane, AB, compose window, etc.?

Comment 2

[hangas]

After looking at the code for this I feel that we cannot "remove" the menu items

for features that are not implemented.  Instead I think that we need to add an

attribute to each menu item and button that is not implemented:  notimplemented=

"true".  I will then add a style to xul.css that hides these menu items and

buttons.  This way we only need them hidden for the beta1 release, other builds

will have the menu items displayed but in a different color (also done through

xul.css) so that we can see they are in the correct location but not implemented.



Sol has approved this plan and I will add the xul.css style during M12

development.

Comment 3

[Phil Peterson]

Sounds great, Paul.

Comment 4

[brendan-obsolete]

I heard (in a hallway conversation) this starting to turn into extra work for
hangas, saari, et al. (the list grew).  That's wrong right there.

Worse, Mozilla is an open source project.  mozilla.org and the community it
serves do not care about hiding semi-operational or non-operational (but soon to
be working) UI elements.  If a company using Mozilla sources wants to hide such
things in its beta or final release, that company must fork certain files or use
existing or better UI parameterization (to avoid "partial" file forks where
half the file must track the public source -- and note that changes to NPL/MPL
files must be provided freely with executables purveyed by such companies) to
tweak the UI.

Therefore this bug should not result in any change to the public cvs.mozilla.org
sources; it should be a Netscape-proprietary bug.  My advice to Netscape is to
hide as little of the unimplemented UI as possible, and to take as few hours of
its contributors' time as possible.

/be

Comment 5

[Alec Flett]

my only issue with that is this: who is "mozilla.org" who makes this decision.
is it the mozilla.org leaders... i.e. shaver, brendan, leaf, dawn, dmose, etc...
or is it the contributers to the project?

I'm not saying that "Netscape" is The Contributor to the project, or that just
because most of the contributors work for Netscape that netscape gets the
biggest vote, but I think this kind of decision should be put to the
contributors themselves. This doesn't mean netscape management or marketing,
this means the people who contribute to mozilla.org every day, i.e. developers,
testers, etc.

Isn't mozilla.org a confederation of contributors, not a jedi council?

I suspect that the decision may still end up agreeing with brendan and shaver,
but I'd like to see this discussed amongst the contributors instead of thrown
down from on high.
(on high being mozilla.org, not netscape)

Comment 6

[Phil Peterson]

> Therefore this bug should not result in any change to the public
> cvs.mozilla.org sources

> My advice to Netscape is ... to take as few hours of its contributors'
> time as possible.

Those two statements sound like a contradiction to me. By making it a
commercial-tree-only problem, we increase the amount of time it takes.

Comment 7

[Mike Shaver (:shaver emeritus)]

alecf's sentiment that this deserves more public discussion is dead on, of
course, but in the absence of consensus -- nobody was discussing this in public,
just ripping UI elements out -- brendan's Linus card carries the trick.  Removal
of unimplemented menu items reduces substantially the likelihood that someone
will choose to scratch that itch, and one of the central goals of the Mozilla
beta is to encourage that sort of scratching.

I'm all for a public discussion about this, and suggest mozilla.seamonkey as
venue for the showdown.

Other alternatives to wholesale removal include use of the disabled attribute (I
presume it works), or a common NYI function that can be used as a placeholder
event handler, and which would tell the user that the function in question isn't
ready yet.  It could even point them to a bugzilla entry for further information
or easy sign-up.

As far as any contradiction in brendan's comment, I don't see one.  He's saying,
AFAICT: "I recommend that you (Netscape) not bother with this now, since it uses
valuable engineer time that could be put to better use.  If you insist on doing
so, however, you should be aware that you'll be paying the stupid tax, because
mozilla.org isn't interested in changes that make it less tempting to
contribute."

Comment 8

[brendan-obsolete]

Sorry for my hard-line antithesis, but I was in fact representing members of the
community, including notables such as hangas, saari, and hyatt.  We should have
a public discussion about this, and I don't want to preempt that with "I'm in
charge here" [e-mail] over-management.  But I'm not the one who started
a "backroom deal", I'm trying to stop the one that was already initiated within
netscape.com, which manifested itself in this bug (the first public mention I've
seen of the "what's disabled or yanked from UI for beta" issue).

A mozilla.seamonkey post is overdue -- who should do it?  It should allow for
the leading period convention, which hangas mentions here.  It should also bring
up the editor/composer-out-for-netscape.com-b1 issue, which is separate from
what the mozilla.org-hosted sources should configure and build.

/be

Comment 9

[chris hofmann]

lets try stick to the key issues and see if we can frame them
correctly before a widespread discussion.

The main issue is.  "all unimplemented menu items need to be removed."
-this is based on feedback that folks are using or won't use
a mozilla or netscape beta in its current state if they
click around and find lots of stuff not hooked up behind the
UI....  The fix for this is not nessissarily to remove, but
maybe just to "comment out" to reduce this user frustration
on the milestone and beta releases coming up.   There is common
benefit to mozilla and anyone who uses the seamonkey source to
doing this clean up.   If the cost of this is high, or the cost
of this must paid by massive/complex forking xul and css files,
we would strongly consider not doing it.

Is there dispute about the frustration in clciking around
on a lot of UI that is just non funtional?

How do we get widespread knowledge of this "." UI indicator
to mean = Not Hooked Up Yet.  Is there presidence for this in other
beta products?

What is the cost of this clean up work?

Lets get good answers on these questions and work from there.

Comment 10

[Mike Shaver (:shaver emeritus)]

Menu items can be marked disabled, and they turn a pretty grey and become
unclickable.  Is that enough?

Comment 11

[cpratt]

I'm with shaver on this one - greying unavailable (or unimplemented) menu items
out has other precedents in other apps, is probably relatively easy to do, and
is acceptable to (at least) the Browser QA group.

Comment 12

[chris hofmann]

The only problem is that "greyed" menu items is the convention
that is used to show that this option doesn't work in a particular
context, leaving users to scratch their heads and wonder which
menu items don't work at all v. which menu items might have
a bug associated with not getting the greyed state displayed
correctly.

Comment 13

[lchiang]

That's why we (at least mail) have been using the "." convention which we've
release noted (I believe).  It's worked through several milestones so far in
that we don't get any false bugs about "this dlg doesn't work" when the feature
hasn't been implemented yet.

Comment 14

[Mike Shaver (:shaver emeritus)]

We have menus in 4.x on Unix that never become enabled, and the world didn't
end.  We can use class=NYI if you want to make them a different colour or
something, but I really don't think it's worth it.

``How do I enable FeatureFoo(tm)?'' ``You write the code.'' =)

Comment 15

[Phil Peterson]

I need to break this bug into several bugs to assign to different people. New
bug numbers are bug 25135, bug 25137 and bug 25139


*** This bug has been marked as a duplicate of 25135 ***

Comment 16

[Ninoschka Baca]

Verified Duplicate.