167914 - Option to Save as Text is too hard to find in HTML Composer

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, enhancement)

Description

[timeless]

(see also bug 45628)

Browser can save html as text, but if i'm using composer to delete lots of
rows/cols from bonsai just to get a file list, i don't want to have to save as
html, load browser just to save as text.

this should be pretty easy to do.

Comment 1

[Frank Wein [:mcsmurf]]

ההhm, "Severity:Blocker"? Whats blocking at this bug? I'd recommed
"Severity:Normal" for this bug.

Comment 2

[timeless]

*shrug* i thought i filed with sev: enhancement, i blame mozilla :-)

Comment 3

[Charles Manske]

We already do this. It's called "Export to Text" in the file menu. We must call
it that because if we called it "Save As", people might think they were now editing
a plaintext version of the doc, which we don't do.

Comment 4

[timeless]

That's silly.
1. i'd never find it.
2. look at what wordpad does:
file>save as
test
save as type: text document

WordPad
/!\ You are about to save the document in a Text-Only format, which will remove
all formatting. Are you sure you want to do this?
[ Yes  ] [  No  ]

If it's good enough for browser and wordpad then it should be good enough for
composer.

Comment 5

[Akkana Peck]

Would it help if Export to Text was grouped with Save As in the menus?  I find
it very easy to miss where it is now, but if it was next to Save and Save As,
I'd be more likely to see it.

Comment 6

[Charles Manske]

While technically more correct, I certainly agree that the "Export to Text" 
distinction is probably lost for most users!
I would be very happy to use "Save As Text..." and move it under the 
"Save As Charset..." menuitem if no one else objects.

Comment 7

[timeless]

I'd still prefer to combine all the save options into a single dialog; wordpad
and browser do it, composer should be able to.

But moving at least moving the option next to the other save items would at
least give users a chance to discover the feature, so I'm in favor of it.

Comment 8

[Charles Manske]

timeless: You think using the "common" dialog and selecting "Text file" from
the "Save as type" dropdown is easier to find?
If I remember correctly, the problem in Windows is we can't tell what the user
changed to in that dropdown -- we only have the file extension returned, and 
that's not very dependable as a means to decide when to save HTML vs. text.

Comment 9

[Akkana Peck]

I think it would be harder to find if it was part of the dropdown in the common
dialog.  At least, I never think to look there (it almost never means anything
useful on linux).  (Whatever way you decide is fine with me; I'm just letting
you know that some people won't notice it there.)

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

>If I remember correctly, the problem in Windows is we can't tell what the user
>changed to in that dropdown

nsIFilePicker:
 94   * The filter which is currently selected in the File Picker dialog
 95   *
 96   * @return Returns the index (0 based) of the selected filter in the filter
list. 
 97   */
 98   attribute long filterIndex;

also, this does of course work, just see how the save dialog works in browser.

Comment 11

[timeless]

obviously wordpad is able to get it right, if our api fails on that point, then
it needs to be fixed. however browser seems to be able to do the right thing
using our saveasdialog interface.

akk: do you ever switch between save as web complete and save as html in
browser? I guess not, you're missing an interesting feature.  I had hoped to
file a bug about something similar to that after I got this fixed (Save complete
page v. Save html and correct links v. Save html).

While I'm talking about that dialog here's a bit of food for thought....
Notepad's interface has:

File _name:
Save as _type: (Text Documents, All Files)
_Encoding: (ANSI, Unicode, Unicode Big Endian, UTF8)

I don't think our api can offer an encoding option, that's probably a bug.

Wordpad has:
File _name:
Save as _type: (Word for Windows 6.0, Rich Text Format (RTF), Text Document,
Text Document - MS-DOS Format, Unicode Text Document)
[ ] Save in this format by _default

That last item is also spiffy, right now, I have:

Save as _type: Rich Text Format (RTF)
[x] Save in this format by _default
and the checkbox/label is disabled, which clearly tells me that this *is* my
default.

You'll note that WordPad got rid of All Files, it doesn't make sense to have it
when you output different file formats, It's ok for Notepad because the formats
are handled by the Encoding option.

I guess what I'd like is:
File _name:
Save as _type: (Complete web page, Web page with links, HTML Document, Annotated
Text Document, Plain Text File)
_Encoding: (ANSI, Unicode, Unicode Big Endian, UTF8, <whatever else we need>)

The complete web page would do slurping (like browser, n3g/n4composer)
The web page with links would fix all links so that they'd work from the
destination location
The html document wouldn't munge links at all
Annotated Text Document would do what browser does (<b>a</b> => *a*, <a
href="about:">b</a> => b <about:>, <u>c</u> => _c_, ...)
Plain Text File would drop all non #text nodes.

Of course all terms would be negotiable, i'm not sure if I like Annotated or
Formated or something else, but it's just a starting point.

Comment 12

[Samir Gehani]

Composer triage team: nsbeta1-

Comment 13

[Robert Kaiser]

MASS-CHANGE:
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

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420