Open Bug 499516 Opened 15 years ago Updated 2 years ago

Provide fullscreen (content only) viewing option

Categories

(Thunderbird :: Message Reader UI, enhancement)

Product:
Thunderbird
Component:
Message Reader UI
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: JoeS1, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Keywords: student-project, Whiteboard: [add-on idea][has draft][gs])

Attachments

(1 file, 3 obsolete files)

Content fullscreener extension 0.3 release (Fixed)
8.03 KB, application/octet-stream
Details 
Sometimes, it's important to have easy quick access to action buttons.
At other times, it's more important to have a clear view of mail/news content.

Use cases:
1. RSS feeds with web-content
2. Newsgroups with web-like content (html/inline binaries)
3. html newsletters in email
4. Long email (usually html with inline binaries) which require scrolling.
5. Bugmail (nothing actionable here in TB)

Implementation:
The same as F11 as it is used in Firefox.
A simple toggle (F11 or another if it conflicts with lightning) to hide the
header UI/toolbars where it is not needed/wanted and show content only.

xref:
bug 480623
bug 456168
(and friends)
I'm not clear if this is core or an extension, nor do I wish to argue one or the other.  What I do know is that this could make a great student project.  Marking as such.
Keywords: student-project
the code is there in http://morelayoutsforthunderbird.mozdev.org for anyone who's interested.  i recall i put it in at Joe's request ;) and did cannibalize F11 from Lightning.
Bug 307340 and bug 370857 are interesting reading on the analogous feature in Firefox for OS X.
I looked over the code in more layouts and it seems to be trying to hide all various message window pane elements.  I think this could be more easily written by using the single message view window instead.

let fs = window.openDialog("chrome://messenger/content/messageWindow.xul",
                           "_blank","all,chrome,dialog=no",
                           gFolderDisplay.selectedMessage, gFolderDisplay.view);
fs.fullScreen = true;

Something like this would give you a new, fullscreen, window that has only content.  I haven't tried this out yet but I think it would give you the same fullscreen experience as the extension.  Also you'd be able to close that window and Thunderbird would still be running.  Making the main thunderbird window fullscreen likely requires us to intercept window close/quit commands so we unfullscreen you first.  (sometimes people don't know how to exit fullscreen so it's recommended to unfullscreen people on any quit/esc/close attempt)

As for the design of a full screen view I think it would be important to know the width of the display and the desired width of the content and take that into account for the display.  Email messages aren't easier to read if they flow across my entire 24" screen.  It would be better to create margins and use that space to inform people of useful things.  Useful things like what the next and previous messages are and if new messages were received while you were rockin out to the full screen email magic.  

It would also be interesting to leave space for extensions to add themselves if there is room.  I could imagine an email egg timer extension that lets you know how long you've been staring at the same message.  I digress as usual...
Depends on: 425435
I suppose this could be interesting for small screens. (At least if there were some minimal navigation.)
(In reply to comment #4)
> I looked over the code in more layouts and it seems to be trying to hide all
> various message window pane elements.  I think this could be more easily
> written by using the single message view window instead.
> 
> let fs = window.openDialog("chrome://messenger/content/messageWindow.xul",
>                            "_blank","all,chrome,dialog=no",
>                            gFolderDisplay.selectedMessage,
> gFolderDisplay.view);
> fs.fullScreen = true;
> 
> Something like this would give you a new, fullscreen, window that has only
> content.  I haven't tried this out yet but I think it would give you the same
> fullscreen experience as the extension.  

But would that retain the keyboard navigation for a fullscreen preview or a fullscreen standalone window.


> As for the design of a full screen view I think it would be important to know
> the width of the display and the desired width of the content and take that
> into account for the display.

Fullscreen is whatever the native settings are for the user.
Typically I use background images (mostly in newsgroups) set to 990 px centered with no-repeat. 
Most newsletters send content centered and layout for a more minimal 800x600
view.
  
Email messages aren't easier to read if they
> flow across my entire 24" screen.  It would be better to create margins and >use that space to inform people of useful things.  Useful things like what the next
> and previous messages are and if new messages were received while you were
> rockin out to the full screen email magic.  

Most folks viewing just plaintext, might not have much use for fullscreen.
One exception might be with deeply quoted newsgroup threads.


> 
> It would also be interesting to leave space for extensions to add themselves if
> there is room.  I could imagine an email egg timer extension that lets you know
> how long you've been staring at the same message.  I digress as usual...

I think the idea here is to show more content vs. UI and chrome.
(In reply to comment #4)
> 
> As for the design of a full screen view I think it would be important to know
> the width of the display and the desired width of the content and take that
> into account for the display.  Email messages aren't easier to read if they
> flow across my entire 24" screen.  It would be better to create margins and use
> that space to inform people of useful things.  Useful things like what the next
> and previous messages are and if new messages were received while you were
> rockin out to the full screen email magic.  

Makes sense.  Sounds similar (in a certain sense) to the OS X maximize button: OS X allows the app to decide what to do when maximize is clicked (which itself has good and bad points, but...).  The upshot is that some applications like terminals choose to only maximize themselves vertically and keep the width unchanged.

> It would also be interesting to leave space for extensions to add themselves if
> there is room.  I could imagine an email egg timer extension that lets you know
> how long you've been staring at the same message.  I digress as usual...

Oh, man.  I've really really REALLY wanted this extension for most of a year now.  One of these weekends...

(In reply to comment #6)
> > Something like this would give you a new, fullscreen, window that has only
> > content.  I haven't tried this out yet but I think it would give you the same
> > fullscreen experience as the extension.  
> 
> But would that retain the keyboard navigation for a fullscreen preview or a
> fullscreen standalone window.

The implication seems to be that retaining the keyboard navigation would be an undesirable thing.  Can you elaborate on that?
> (In reply to comment #6)
> > > Something like this would give you a new, fullscreen, window that has only
> > > content.  I haven't tried this out yet but I think it would give you the same
> > > fullscreen experience as the extension.  
> > 
> > But would that retain the keyboard navigation for a fullscreen preview or a
> > fullscreen standalone window.
> 
> The implication seems to be that retaining the keyboard navigation would be an
> undesirable thing.  Can you elaborate on that?

Not at all...
Keyboard navigation should be retained just as it is...
Just wondered if the the new window implementation would break that.
I'd like to open in fullscreen on newsgroups that I know to contain web-like content and use the Nav keys to step through them within the fullscreen mode.
Perhaps the UI buttons could be along a narrow strip at the top, and disappear after a few seconds, and re-appear when the mouse moves near the top - like F11 in Firefox.

Perhaps full-screen mode would be different, depending on whether one is in 3-pane or single-message modes.

BTW: I can't exit full-screen mode in current WinXP nightly of Firefox. The OSs UI doesn't come back. :-\
Taking all considerations in mind, I will be giving this a go as my first project.
Assignee: nobody → nmichaty
Status: NEW → ASSIGNED
Attached file Fullscreener extension 0.1 release (obsolete) — 
Full screen is not exactly full screen, but a new maximized window focused on the selected message. [Using Clark's suggested approach]
F11 pseudo-toggle (F11 in messenger.xul opens window, F11 in window closes window (noted, this may cause future problems))
Message navigation: left & right
Works OK, no errors, a step in the right direction AFAIK
But the idea is to maximize content, since it's only a temporary toggle, why do we need any action buttons at all (toolbars or headers)
Cool, thanks.
But I'm not entirely sure I'm on the same page with your question. Please correct me where I'm being inaccurate.

If you're referring to the window as the temporary toggle until I manage to get Firefox-style fullscreening working, indeed coding/including/excluding the toolbars and headers in the window would be futile. The thing is I find that programmability rather complex, probably more complex than needed just to see the content unobstructed by the rest of the UI.

Or if you mean the toggling of content viewing itself in general, I would find it more efficient to have one button to press to navigate through messages than to untoggle, select, retoggle. Even if the user doesn't want to navigate, some probably would, and it's better to have that feature available.

Anyway, that being said, let me know what you think.
I think the auto-disappearing toolbars in Firefox would be an overkill.
Just think that keyboard navigation would be enough, and just hide the toolbars and header pane. Maybe just show the toolbar as an option.
I see this feature as being used on "special case" messages, but arrival of small
screen netbooks could be a case for keeping some Mouse UI
Alright I got ya. I agree there is a lot more UI than necessary in that 0.1.
And it is an excellent recommendation to consider/accommodate netbook display.
I would see the netbook users as those who would have most reason to use this Addon feature, so making the layout as friendly to such small display settings would be my fundamental priority, while resiliency to larger screens is also important but merely a close second.

With that in mind, I'd like to eventually get feedback from netbook users on action flow: whether or not they would appreciate having the basic toolbar functions such as Reply/+all, Forward, Junk, Delete kept in this Content View.
Attached file Content fullscreener ext 0.2 release (obsolete) — 
Content window now stripped of most UI, some nav. buttons added, minVersion fixed.
Attachment #412481 - Attachment is obsolete: true
That last version looks much better to me.
There is a little conflict with compactheader extension. (Have to toggle it in some cases to exit fullscreen. (But it's worth it )
One glitch:
Opening a message in a new window, rather that a tab, always opens fullscreen.
F11 closes that window, rather than toggling fullscreen.
Awesome, thanks for the feedback and glitch report.
Will keep you updated as I move along.
Major cleanup of sloppy code:
-Toggle now really toggles (from both windows)
-
-Added: icons to nav buttons
Attachment #413776 - Attachment is obsolete: true
Err...

Content fullscreener extension 0.3 release

Major cleanup of sloppy code:
-Toggle now really toggles (from both windows)
-A message must be in focus to go fullscreen
-Fixed bad usage of js global variables
-Added: icons to nav buttons
-Tested with: 640x480, 800x600, 1280x768, 1280x1024 screens
Your attachment description says 0.3 but the xpi says 0.2--wrong version uploaded?

Seems to work OK in tabs, but if message opened in "new message window" there is no visible Menu pane, or Toolbar pane.

Keep up the good work, I this this has great potential.
I knew there was something I missed in my ~twenty repacks!
It's the correct version, I just forgot to update the install.rdf
Major cleanup of sloppy code:
-Toggle now really toggles (from both windows)
-A message must be in focus to go fullscreen
-Fixed bad usage of js global variables
Added: icons to nav buttons
Tested with: 640x480, 800x600, 1280x768, 1280x1024 screens
Attachment #417988 - Attachment is obsolete: true
+Thank you. =)
URL: http://gsfn.us/t/nnlz
Whiteboard: [gs]
(In reply to comment #24)
> Created attachment 418064 [details]
> Content fullscreener extension 0.3 release (Fixed)

is this available yet on AMO?
sounds like something many people might be interested in.
(In reply to comment #26)
> (In reply to comment #24)
> > Created attachment 418064 [details] [details]
> > Content fullscreener extension 0.3 release (Fixed)
> 
> is this available yet on AMO?
> sounds like something many people might be interested in.

Not ready for prime time, the last I checked.
Problem:
Tabs seem to work OK, but open a separate window always gives fullscreen (selected or not)

Yes, I think a lot of folks would like this, especially netbook users.
Maybe someone could pick up development on this as it appears to be stale at the moment.
Ah yes, I seem the limitations. otherwise, works as described with 3.1.2pre (on nvista) and nightly build (on win7)
PgUp and PgDn keys not functioning yet - looks very nice though.
Hi all.
Indeed, development has gone stale for a while. Semester ended and I fell out of groove with the project. Plus a chrome registry problem had been making updating the extension's chrome on startup for testing extremely time consuming, and no help resource I tried had ever known of this problem before.

But alas, I found that Tbird 3.0 doesn't have this conflict with my extension at all, as opposed to v3.2a1, so I'll be continuing development on the former version. Regularity of updates is still unsure, as this is as of now either an in-free-time project or considered course work. Either way, I do intend to bring this baby to 1.0 one day.

For now,
Known bugs to be fixed in 0.4:
-"fullscreen" window is not actually fullscreen, and is resizeable.
-closing the window with ESC is not registered, thus an untoggling F11 is required
-PgUp and PgDn? (not sure what is meant by not functioning, they scroll fine in my tests)
-new window comes up as fullscreen (fs is actually the new window xul with overlay) : they will need to be separate

And going to build Tbird 3.1 tomorrow for a full spectrum compatibility test.
The 3.2 issues you describe could be the ones mentioned at <https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0>.

If they are, do you have any suggestions for how we could publicize changes like this better so that you and other add-on developers would be more likely to become aware of them?
That did it. =)
You have my thanks.

How to better get the word out? Hmm, well I know I used a lot of search terms pertaining to the symptoms of not being up to date. Indeed, I could have just checked Moz's Chrome Reg page, I guess I forgot how frequently things upgrade and change.
Glad it help. :-) I don't think I really understand what sort of search terms you mean.  Can you recall a few examples?
Hrmm, I think most of them were along the lines of:
chrome registry, chrome manifest, manual, extension, refresh chrome, bug, chrome error.
None of which really had anything to do with the Gecko version, as was my case of cluelessness. ;)
I just spun up bug 596009 on making this stuff more findable from search engines; thanks!
No, thank YOU!
=P
Assignee: nmichaty → nobody
OS: Windows XP → All
I feel like quite the irresponsible parent.
So in the same decisive action taken on such parents, I fear I must resign myself from this project. My attention has been elsewhere from one thing to another and I never got in a good solid session to work at figuring out True fullscreening as used in Firefox. As such, no work around I've attempted using the New Window as my fullscreen page can substitute for the actual thing, because as Joe mentioned, there is that collision when someone wants to open a separate window without fs.

One of my bugs, the one for toggling, is symptomatic from using the new window.
Others I've noticed are that Mark As Junk/Fav/etc, anything involving changing flags on a message won't appear right away, the user must go to another message then return to refresh the appearance of such flags.

I hope someone else will one day pick up the torch and get this up and running for the netbookers who would indeed benefit greatly.
Status: ASSIGNED → NEW
Hardware: x86 → All
Whiteboard: [gs] → [gs][has draft extension]
Blocks: tb-netbooks
Some user accidentally ended up in fullscreen mode for the main window, as it seems. See http://gsfn.us/t/38wkc#reply_12131563 for that discussion.

I can reproduce by adding the following to localstore.rdf:

>   <RDF:Description RDF:about="chrome://messenger/content/messenger.xul#messengerWindow"
>                    sizemode="fullscreen" />

It seems to work except for the controls not being there. Thus, would adding the Minimize/Maximize/Close controls and the F11/menu toggles be the only things needed here to implement this?
aceman, can you suggest someone to finish this?
Flags: needinfo?(acelists)
Whiteboard: [gs][has draft extension] → [add-on idea][has draft][gs]
Somebody with knowledge of extension development. Maybe Axel?
Flags: needinfo?(acelists)
(In reply to :aceman from comment #40)
> Somebody with knowledge of extension development. Maybe Axel?

I looked at this, but I haven't got the time to support this right now really :(

See my other UI related addons (MenuOnTop, Titlebar Cleaner) and the infrequency of updating them...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: