[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: Dolphin - hide blank metadata
From:       Frank Reininghaus <frank78ac () googlemail ! com>
Date:       2012-08-29 11:22:38
Message-ID: CAFoZWWgD4r5fEZas80PGtF8_8tB=ULCo1sQ5LR1xfqauk94SZA () mail ! gmail ! com
[Download RAW message or body]

Hi Todd,

first of all, thanks for your message and for your interest in
improving Dolphin!

2012/8/29 Todd Jennings:
> Hi,
>
> My name is Todd, and I am interested in doing some fixes and enhancements
> for dolphin.  The first issue I would like to fix, if it isn't fixed
> already, is the handling of empty metadata in dolphin's file browser view.
> In 4.9.0, when a particular file doesn't have a given metadata item, that
> item is listed as a "-" below the file, while still taking up the line.

Yes, this is https://bugs.kde.org/show_bug.cgi?id=304752, and I agree
that this should be fixed.

> In my opinion, this limits the usefulness of mimetype-specific metadata such
> as "word count" or "image size", since files belonging to a mimetype that
> that metadata is not relevant to will still show that blank line.
>
> I see two possible approaches to solving this:
>
> 1. restrict that metadata to only files of a valid mimetype.  So, for
> example, word count would apply only to text mimetypes.  There are two
> problems with this approach.  In this example, not all documents that have
> word counts are in the text mimetype, some are in the application mimetype
> (like vnd.ms-word).  The second problem is that there is at least possible
> relevance of some of these to different mimetypes, for instance the
> "orientation" could apply to documents as well as images, and just because
> it doesn't do that now doesn't mean it never will.
>
> 2. hide empty lines.  So any line for metadata that is not present for a
> file will not show up at all.  This avoids the problems with 1.  However, it
> has the problem that you can't always tell what metadata might apply to a
> file so you can't add it manually.  I don't see this being that much of an
> issue, personally.
>
> I prefer approach 2.  It should also be much easier to implement.
>
> However, I don't want to do this if it is already done, or if this change is
> opposed by the developers, so I wanted to check first before starting.

I also prefer option 2. Feel free to work on this! If you have any
questions or you encounter any problem, just ask!

Best regards,
Frank
[prev in list] [next in list] [prev in thread] [next in thread]