From kde-core-devel  Thu Apr 12 13:09:30 2007
From: Thomas Zander <zander () kde ! org>
Date: Thu, 12 Apr 2007 13:09:30 +0000
To: kde-core-devel
Subject: Re: [Bulk] Re: RFC: KRecentFilesAction: hide urls
Message-Id: <200704121509.32235.zander () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=117638304404087
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart8289014.tQxYvbfnrC"

--nextPart8289014.tQxYvbfnrC
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 12 April 2007 14:38, Johnathan Burchill wrote:
> > I'm against hiding the url information. Although it may be
> > application dependend. In kate/kwrite at least it is bad, because the
> > numbering is arbitrary you can't tell eg what Makefile, Makefile(1),
> > Makefile(2),Makefile(3) .... are, so the recent file acation would be
> > quite unusable for me.
>
> If we're not going to have the option of hiding the url information,
> then what is the point of having the short name?

To make it easier to read by making sure the user does not have to scan to=
=20
the last directory separator and start to read.

> IMHO it is application-dependent. In KDar the archives usually have
> unique names with dates automatically written into the filename.=20

How did you reach that conclusion? Is it impossible to move the files?  Or=
=20
have them on several remote locations?
You assume that users of KDar are somehow different from the set of users=20
that also use this action, and you are leaving all users of KDar with a=20
slightly different UI from the rest of KDE.   As well as those that do=20
not follow the 'wanted' way of working with a clumsy UI.

> Long=20
> pathnames can be harder to scan than just the list of short names.
> Particularly true when all of the files are in the same "backup"
> directory.=20

If there was just one directory the user could ever put his files in, then=
=20
sure.  Is that the case?

=2D-=20
Thomas Zander

--nextPart8289014.tQxYvbfnrC
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGHi+MCojCW6H2z/QRAmjrAKCp4dvohVNVOCWzHy46b1iZ4pCalgCg6Rzj
YzNeinzKCm8LpkaVr6adtH0=
=YzXk
-----END PGP SIGNATURE-----

--nextPart8289014.tQxYvbfnrC--