Review Request 113175: Always use an external viewer application to view files
Sven Brauch
svenbrauch at googlemail.com
Tue Oct 8 20:49:48 BST 2013
> On Oct. 8, 2013, 4:47 p.m., Jonathan Marten wrote:
> > I'm not totally happy with this change. Yes, the internal viewer is limited in functionality, but it has advantages: (1) it is fast to open and can be closed again with a single keystroke; (2) it remembers its size and can be resized without affecting the default window size of, say, KWrite or whichever external application is used; (3) it can be forced to display an archive component of any type as plain text.
> >
> > There's nothing wrong with having the facility to open an archive component in its default application (or any other application), but it should be an option. Either a configuration setting (Use internal viewer - Use external application), or a context menu with options View (in the internal viewer), Open (in the default application) or Open With... (any other application).
>
> Sven Brauch wrote:
> I guessed some people would not be happy with it, but it was worth a try ;)
>
> How about a context menu action? Or, since the context menu is currently empty, just opening the external viewer on right-click?
>
> Jonathan Marten wrote:
> Not sure that changing the function of the right-click would be approved of (but then, I'm not the ark maintainer or authority, just an intensive user of it). Maybe the middle button?
>
> There has been some discussion about adding a context menu to Ark before now - e.g. bug #166203.
>
>
> Sebastian Kügler wrote:
> Honestly, to most people the internal viewer just looks broken, like an incomplete stepchild of the real viewer application.
>
> Can we please at least make the default to open the application, not the crippled viewer?
I feel like Sebastian does and I have watched people use Ark before which obviously felt the same (i.e. which were confused because the PDF viewer was missing all the buttons). I do see the point of the viewer in some corner cases, but in almost all cases I don't want it.
Maybe we could do this: The side panel is currently quite useless (huge amount of space occupied + little information in there). We could embed the viewer there, and change the action on click to select the file and display it there. That would serve the (I guess?) common use case, which is looking through several images and deciding which one you want to extract even better than the current solution. Then there could be a button below the viewer widget to open the file in the actual application.
I'm not sure this is a good idea, what do you think?
- Sven
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113175/#review41400
-----------------------------------------------------------
On Oct. 8, 2013, 3:23 p.m., Sven Brauch wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113175/
> -----------------------------------------------------------
>
> (Updated Oct. 8, 2013, 3:23 p.m.)
>
>
> Review request for KDE Base Apps.
>
>
> Repository: ark
>
>
> Description
> -------
>
> This patch makes ark always use an external viewer application instead of using the clunky internal preview thing. The internal viewer would just embed a plain kpart into a window, but without providing any of the XMLGUI or whatever from that part. Thus, when you for example clicked a PDF, you couldn't print it. The advantages of the internal viewer are imo overall quite questionable, and are far outweighted by its disadvantages.
>
> Plus, it removes code ;)
>
>
> Diffs
> -----
>
> part/CMakeLists.txt 9e384438b60322f1d51d31e40c556b2912970ceb
> part/arkviewer.h bb41472eaec985e2e1b3d9c2f7c257c949316bf4
> part/arkviewer.cpp 053cd1c0502d3bb88895dc8d3653eaea9e6c3c83
> part/part.cpp b4ebcd27c462d2b8037b5ea40c56969eda71bdcb
>
> Diff: http://git.reviewboard.kde.org/r/113175/diff/
>
>
> Testing
> -------
>
> Clicking files opens them in the default application, as it should.
>
>
> Thanks,
>
> Sven Brauch
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131008/4377d79b/attachment.htm>
More information about the kde-core-devel
mailing list