The sidebar can not be resized, so when the details shown in the sidebar are too long, the sidebar can use a lot of space. For example, when a symbolic link is selected and the target file has a really long name/path. In order to reproduce, create a simple archive tar.something archive (with symlinks) with the following directories: mydir/datadir Inside datadir, create a file with a really long name, Inside mydir, create a symbolic link (the name does not matter) which points to the file with the really long name. Open the archive and select the symbolic link. The sidebar will use a lot of space. An example when such events can happen is an archive generated by sosreport. Reproducible: Always
Created attachment 99275 [details] A simple archive which shows the issue The archive contains the structure described in the bug summary.
Created attachment 99277 [details] A simple archive which shows the issue The archive contains the structure described in the bug summary; select mydir/a_link.txt (The previous version of the archive had an extra useless file inside).
Git commit e042955233662282813feac3d02e38beb2048929 by Elvis Angelaccio. Committed on 01/06/2016 at 08:19. Pushed by elvisangelaccio into branch 'master'. Fix non-resizable infopanel when symlinks have a long target When a symbolic link points to an entry with a long filename, the infopanel takes almost all available horizontal space and, even worse, cannot be resized. This is because there is a single QLabel with a multi-line text, one of which is the symlink's target. This patch replaces this label with a vertical layout containing different labels. The targetLabel is now a KSqueezedTextLabel so that a long target name won't mess up anymore the infopanel size. FIXED-IN: 16.08.0 Differential Revision: D1728 M +23 -13 part/infopanel.cpp M +1 -1 part/infopanel.h M +38 -13 part/infopanel.ui http://commits.kde.org/ark/e042955233662282813feac3d02e38beb2048929
Please also apply this fix to the "Type" field, which can also get somewhat long. For example, I'm currently experiencing "Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", which makes the sidebar take half of my (960-pixel-wide) Ark window.
(In reply to Brendon Higgins from comment #4) > Please also apply this fix to the "Type" field, which can also get somewhat > long. For example, I'm currently experiencing "Type: > application/vnd.openxmlformats-officedocument.spreadsheetml.sheet", which > makes the sidebar take half of my (960-pixel-wide) Ark window. Can you attach a test archive with this issue? I tried to compress an Excel file (.xlsx), but in the "Type:" field I get "Microsoft Excel Worksheet"
Hmm. I only ever see raw MIME types, not friendly names, for any file. (For this specific case I can reproduce it with simply an empty .xlsx made in LibreOffice.) Maybe something is busted in my install, settings, or the packages I'm using (Debian testing/unstable). Trying to edit the file type's description in File Associations doesn't seem to stick for me, though it looks as if it ought to. If that description is what becomes the type's friendly name used by Ark, that means Ark should format nicely for arbitrary strings anyway...
(In reply to Brendon Higgins from comment #6) > Hmm. I only ever see raw MIME types, not friendly names This should not happen... You do have have shared-mime-info installed, right? , for any file. (For > this specific case I can reproduce it with simply an empty .xlsx made in > LibreOffice.) Maybe something is busted in my install, settings, or the > packages I'm using (Debian testing/unstable). What about the Open dialog(CTRL+O) ? In the "Filter:" picker, do you see the raw mimetypes or the friendly names > > Trying to edit the file type's description in File Associations doesn't seem > to stick for me, though it looks as if it ought to. If that description is > what becomes the type's friendly name used by Ark, that means Ark should > format nicely for arbitrary strings anyway... Yeah, there is no reason why we shouldn't apply "just in case" the same fix to the other strings, so I'm reoping this bug.
(I hesitate to respond, as this seems like a digression from the bug here, but since you asked...) (In reply to Elvis Angelaccio from comment #7) > This should not happen... You do have have shared-mime-info installed, right? Yes, the shared-mime-info package is installed. > What about the Open dialog(CTRL+O) ? In the "Filter:" picker, do you see the > raw mimetypes or the friendly names In Ark's open dialog, I also see mimetypes. Same with Dragon, but interestingly not KMail or KMyMoney. I start to wonder if it's just KF5 programs, not those still on KF4. FWIW, two machines I use exhibit this mimetype issue.
(In reply to Brendon Higgins from comment #8) > (I hesitate to respond, as this seems like a digression from the bug here, > but since you asked...) Indeed, feel free to open a dedicated bug report and we can continue there. > > (In reply to Elvis Angelaccio from comment #7) > > This should not happen... You do have have shared-mime-info installed, right? > > Yes, the shared-mime-info package is installed. > > > What about the Open dialog(CTRL+O) ? In the "Filter:" picker, do you see the > > raw mimetypes or the friendly names > > In Ark's open dialog, I also see mimetypes. Same with Dragon, but > interestingly not KMail or KMyMoney. I start to wonder if it's just KF5 > programs, not those still on KF4. FWIW, two machines I use exhibit this > mimetype issue.
Git commit a6a38b5bf64a58df332aa83441154fb85b68464d by Elvis Angelaccio. Committed on 12/11/2016 at 18:09. Pushed by elvisangelaccio into branch 'master'. infopanel: always use KSqueezedTextLabel This ensures that resizing of the panel always works, no matter what the Type label might contain. FIXED-IN: 16.12.0 M +10 -10 part/infopanel.ui http://commits.kde.org/ark/a6a38b5bf64a58df332aa83441154fb85b68464d