Web lists-archives.com

Re: [kde-linux] Kget "My Downloads" [Is this MS Windows?]




On 04/23/2013 01:54 AM, Kevin Krammer wrote:
On Tuesday, 2013-04-23, James Tyrer wrote:
On 04/21/2013 12:40 PM, Kevin Krammer wrote:

It might not have been that way originally. Some things get added
later on due to changes in the environment, e.g. XDG based paths
becoming available, or original implementors might not have been
aware of standard paths and somebody else added it, etc.

One would basically have to traverse the whole commit history in
order to understand why something is implemented the way it is.

It does appear to be related to XDG and there is the tale.  In
kget/core/kget.cpp a default directory of $XDG_DOWNLOAD_DIR was added.
However, although the coder appears to be skilled at writing C++, he was
not skilled at actual programing.  He hard coded the name of this
"Group" as: "My Downloads" and chose an inappropriate _global_ icon, but
none for that group.

Hardcoding as in specifying a string literal or in not passing it through a
translation function?

No, hard coding as in being in the code and not something that changes with the outside world. It is a string literal in the i18n function. The point here is that it does not conform to the directory name for $XDG_DOWNLOAD_DIR on the users system for a default and the user can not change it. I still call that hard coded even if it would be changed for translation.

The latter would of course be a mistake, the former is a common thing for
labels. If there is a facility to query for standard visualization hints then
this can be pointed out, no developer is constantly up to date with the whole
set of available APIs.

Perhaps this is why there is documentation and mailing lists. Although, I would be the first to say that the documentation for the KDE API is really not adequate when compared to the one for Qt. When I fixed bugs, or patched my personal copy of KDE, I looked up functions in Qt or KDE that I was only not familiar with but had never seen before. It is a skill that you learn in engineering college: reading the documentation -- quickly to find only the information that you need.

Rather than using the name of the
$XDG_DOWNLOAD_DIR directory as the default for the name of the "Group"
and the directory's icon, if one was chosen, or otherwise:
"folder-download" as the default icon.  As well as using "folder" as the
global default icon for the "Groups".

Not sure what you mean with Group, but using the folder icon for a folder
sounds sensible to me.

"Group" is the term used by KGet.

But again, if there is an API that can be queried for visualization hints such
as icons for a special interface item then this might have been added at a
later point, or the developer might not have been aware of its existance if it
already did.

Once you have the PATH for the $XDG_DOWNLOAD_DIR, API functions would only make the job easier. I presume that there is an API for getting that in KGlobalSettings. Yes, it is: KGlobalSettings::downloadPath ( ). Since other apps read the: ".directory" file, I presume that there is an API to do so.

Does this mean that KDE-4 is already being abandoned by the
developers?

No.

Rhetorical question, and not really to be taken literally.

Well, yes, however people sometimes read things like that out of context, e.g.
through a link to the message in the archive.
Clarification is needed if statements are similar to those known to cause
misconceptions.

I may have acted strange in the past few years due to a stroke, but I
still have SJS (Steve Jobs Syndrome) and I was born that way.  I just
have this strange idea that things should work very well, not just 80%
to 90% and I would like to see KDE develop a release process that could
produce a 99% working product as well as producing new nifty features.

Products. Plural :)
Otherwise someone not understanding the conceptional difference between vendor
and product could fall into one of the common traps, e.g. referring to all
products as a single entity.

I was speaking in the abstract sense but point taken.

It is hard for us who do understand to imagine that somebody couldn't but
there are tons of people out there how refer to their operating system as
"Word" ;-)

Anyway, release managment, like any other area of work at KDE, is open for
anyone who wants to contribute.

Already made the suggestion. Not that GNOME does a great job. But, they were using the idea of having a separate release and development versions. In theory, the stable development version would have the bugs fixed while new features would be added to the unstable development version and only migrated to the release version when they became stable. This didn't appear to be working for GNOME in all cases, but that doesn't mean that it isn't a good idea.

There are problems with this since it means that there are various patches to the master branch. GIT permits this to be done easily, but nothing solves the problem of what to do when they conflict with each other. The other alternative is to have the main branch stable and have new work done as patches. Does maintaining new features as separate patches make this problem better or worse?

The advantage of this (having a stable branch, or trunk) is that it would meet the needs of people and companies that use KDE in a production environment. They aren't really interested in nifty new features. What they want is a stable and bug free environment. The current KDE development model of always demanding new features while the existing code base is not yet stable enough does not really meet the needs of the users.

--
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
This message is from the kde-linux mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.