Bug 86184

In this one I disagree, Jay, because you could apply the very same argument to add such an option to a web browser, “because it speeds the thing up”. And what if we made LibreOffice faster instead?

This reminds me of this interesting article: http://limi.net/checkboxes-that-kill

The very same thing could happen to LibreOffice users.

Well my statement of it being faster when viewing a document isnt the only argument for the advantage of this menu entry (by the way, i do have that option in my browser's menu bar :D).

I had recently seen it in the WordPerfect's View menu and remembering the bug reports of users editing documents with images that caused LibO to heavily slow down in performance (bug 78529, bug 80659, bug 82214) and i thought it would be useful to have it in an easily accessible place.

Though I support Adolfos warning 
     This reminds me of this interesting
     article: http://limi.net/checkboxes-that-kill

I tend to say ths is useful.

However I regularly see 'some people' complaining about cluttered menus too :)

(In reply to Jay Philips from comment #2)
> I had recently seen it in the WordPerfect's View menu and remembering the
> bug reports of users editing documents with images that caused LibO to
> heavily slow down in performance (bug 78529, bug 80659, bug 82214) and i
> thought it would be useful to have it in an easily accessible place.

Sorry to disappoint, but those aren’t arguments. Just fix the goddamn slowdowns instead of adding clutter. This is an *advanced* option that must not appear in main menus. It’s relegated to the Options dialog for a reason. And it’s a candidate for removal even there, IIRC. It actually should exist only in the Expert Configuration list. It’s simply against user experience, I won’t be surprised at all if a user gets confused because suddenly their app “broke” and refuses to load images (a basic feature), only to discover that they mistakenly enabled an option to break viewing. Frustration and bad press to come.

The only valid use case I can think of for the “Disable Images” option is if you’re running LO through a VM or a thin client. And that’s not a use case of the typical home user, so why give it such prominence? Please don’t.

Well we discussed it at the design meeting and Kendy felt it shouldnt be included, it even crashed LO for some strange reason while he was checking how it worked. :D

(In reply to Adolfo Jayme from comment #4)
> This is an *advanced* option that must
> not appear in main menus. It’s relegated to the Options dialog for a reason.

Maybe its just me, but i dont consider this an advanced feature. I dont think WordPerfect thinks of it as an advanced feature as well. I consider View > Data Sources as an advanced feature, because i dont use it and consider most casual word processor users dont use it either.

> It’s simply against user experience,
> I won’t be surprised at all if a user gets confused because suddenly their
> app “broke” and refuses to load images (a basic feature), only to discover
> that they mistakenly enabled an option to break viewing. Frustration and bad
> press to come.

Everyone's user experience is different and that is one of the reasons we provide choices. I had a guy who pressed the insert key file a bug that the cursor was large and overwriting characters. Users who never opened the View menu would never mistakenly turn it on and it not having a shortcut would mean that they wouldnt mistakenly turn it on by a key combination.

> The only valid use case I can think of for the “Disable Images” option is if
> you’re running LO through a VM or a thin client. And that’s not a use case
> of the typical home user, so why give it such prominence? Please don’t.

Well Cor agreed it would be useful, so lets see what valid reason he had to that agreement. Having it in the menu isnt giving it any type of special prominence. Putting it in the toolbar or creating a new menu category for it would be giving it prominence.

This is a fine request - whether anyone implements it is another deal. If UX ever decides not to move this forward they should close as WONTFIX but it should be some kind of consensus and not one individual disliking the idea.

As for the counter-arguments - "just fix the goddamn slowdowns" is a bit naive. The code for our pictures handling is admittedly quite tangled and the amount of work needed to fix it is quite extensive. Adding a single button obviously is much easier at least until those other issues are worked out. 1 hour of time vs. 100's of hours of dev time is a pretty solid argument why this should be implemented at least as a stop-gap measure.

Well i just checking my twitter feed and noticed a tweet from @libreoffice < https://twitter.com/libreoffice/status/537944904648118272 > which said:

Many images in your writer document? Speed up the display by disabling Tools > Options > LibreOffice Writer > View ▸ Graphics & objects

And then a few tweets later, i see a tweet from @AskLibreOffice < https://twitter.com/AskLibreOffice/status/538006850017312768 > saying, "Q: Images slow down performace" in which cloph suggests the same thing of toggling off graphics, as well as stating that we already have the uno command (.uno:Graphic).

Yousuf Philips committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f8001effbdb9c0f09fe544b7bdbae9c15c82006f

fdo#86184 addition of .uno:Graphic to writer's view menu

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.

Yousuf Philips committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=371e3dfc271ad617c7d200e27a8bb5b759b3b361&h=libreoffice-4-4

fdo#86184 addition of .uno:Graphic to writer's view menu

It will be available in 4.4.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.