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

[James Tyrer]

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