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

[James Tyrer]

On 04/23/2013 12:50 PM, Kevin Krammer wrote:
> On Tuesday, 2013-04-23, James Tyrer wrote:
>> On 04/23/2013 01:54 AM, Kevin Krammer wrote:
>>> On Tuesday, 2013-04-23, James Tyrer wrote:
>
>>> 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.
>
> Well, all strings are runtime replacable due to the translation system, but it
> might make sense to have certain strings directly user configurable.
> The main question then becomes how to best present this configurability.
>
Yes, the translation will give the default "Group" a different name, but 
the user will not be able to rename that the group.  The name will still 
be part of the code and not subject to the user's wishes.  So, from the 
user's point of view it is hard coded -- it only changes in the i18n space.

>> 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.
>
> Not sure I read this correctly but in case directory name means name of the
> directory in the filesystem then this is wouldn't be such a good idea due to
> localization issues.

It would be the name which the user had assigned to the XDG_DOWNLOAD_DIR 
or the XDG default if he had not changed it.  My system predates XDG, 
but IIUC, the directories are created according to:

	/etc/xdg/user-dirs.defaults

when a new user logs in.

> The path is an identifier in the filesystem, very often used as a key and
> should therefore remain stable.

We need to be clear on that.  A user should choose a name for an 
important directory when he sets up his file system and stick to it 
since he may tell various apps the name and path to that directory. 
However, that is not the same as requiring that the user use a directory 
name that is hard coded in i18n space with only one name available for 
each language and no choice available.

However, before we run too far afield that although XDG gives software 
the ability to reference a directory without using its name as a key, 
and, therefore, allowing users the choice to change names of 
directories, that is not what my point was about.

My point was about the inability of the user to change an arbitrary name 
for the default "Group" in the KGet application.  I also suggested that 
a good choice for the default name for this group would be the name of 
the XDG_DOWNLOAD_DIR for that user on his system whether it was the 
default (Downloads) that came with the: xdg-user-dirs package or 
something else.

> Microsoft made that mistake on several occasions and anyone using a non-
> English Windows knows the mess that originated from that.

That is why FD.o developed a system of identifying the directories 
independent of the names which the user gave them.

> It also becomes a user support nightmare, because you can't just switch
> language or run an application with a different value for language env
> variables to see how something is called in the language the user is using.

That is the purpose of the XDG directories.  But, they are not env 
variables.  You need only consult the file to find the names.

> It also makes it impossible to suggest commandline commands or requires to
> have a list for each language and each command.

This looks like a good suggestion.  It should be possible to add a 
function to the package.  E.G. xdg(download) which would give the path: 
$XDG_DOWNLOAD_DIR so that it could be used in a command line glob.

Perhaps you should mention it on the relevant FD.o list.

>>> 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.
>
> Sure, but one doesn't always ask and potentially wait for an unknown time
> every time one doesn't find something in the API.
> Even if one does do that the answer could be that there is no such API at the
> moment, so one would have to either watch all API changes or repeatedly poll
> by asking.

Then you have to do it he hard way and then perhaps write an API.

> It might make sense though, to mark such occurences in the code to later
> revisit them when code in that area changes for other reasons or one is
> notified that something appropriate became available.

I have almost always found stuff in the documentation.  But, I have a 
pretty good idea of what should be there.  In this case, if it wasn't 
there, it would be a matter of using other software to read the file.

>> 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.
>
> Sure, Qt's documentation is excellent, but it is also maintained by people
> doing that as their main job.
> Like with any other work there are people skilled in documenting things and
> those who aren't and like with any other area in a FOSS project people who are
> good at something are always welcome to improve the things they can do better
> than those currently doing them.
>
> KDE hasn't reached that number of contributors or popularity yet where it
> becomes attractive to technical writers to show and improve their skills by
> working on developer documentation.
>
> Certain outreach programs, e.g. GCI and OPW, do consider such talents eligable
> for support so they will impact the documentation quality as they go along.

Actually, the first thing that is needed is for people to just write more.

It is also disappointing that there isn't more code tutorial on KDE 
techbase.

>>> 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.
>
> That does only retrieve the path but does not provide any visualisation hints
> such as icon or display string like it is done for actions in KGuiItem.
> Display string will become available in Qt5 due to QStandardPaths, which is a
> contribution by KDE developers based on our good experience with
> KStandardDirs, but also extended in various ways, one of them being able to
> query the string to display for the standard location.

It is axiomatic that the path can be pruned to the last element to yield 
the directory name.  I would expect to find a Qt function for that if 
not a KDE one.  The whole path would point to a: ".directory" file if it 
existed.  This is a IF THEN ELSE.  If it does exist, I presume that 
there is a KDE function to extract the icon name from it.  This action 
is used often by Konqueror, Dolphin and other applications.  If there is 
no ".directory" file, then you use a default: "folder-download".

>>>> 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.
>
> Yeah, no problem between those of us actively involved in this discussion but
> there will be a lot of people following this passively or later finding it
> through searches who will not understand the subtle differences.
>
> So I at least personally consider it a matter of professionality to strife for
> accuracy, which of course doesn't always work out :)
>
>>> 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.
>
> True, but while a good suggestion is in itself of course already quite
> helpful, it is often a matter of resources and "prodding" which suggestions
> get into implementation.
>
>> 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.
>
> Right. In fact several teams within KDE's vast community have that as a goal,
> but discussion on how to do it best can lead to delays in implementation ;-)
>
>> 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?
>
> I think the general idea is to make the main branch the stable branch and
> develop in feature branches, but that has some other drawbacks like reducing
> the amount of testing even further due to fewer people being exposed to the
> features during development.
>
> The split and potentially further split in repositories, however, makes it
> easier for differen teams to implement different strategies but changes in
> policy always take time to get buy-in and for actual implementation.
>
>> 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.
>
> Actually no. Each team and ultimately each maintainer is in control of their
> respective code bases.
> Some things are developed separately in feature branches over a longer period
> of time, some teams decide to reuse a version tagged for the previous cycle,
> some decide to not create new release packages at all, thus extending the
> stabilisation period of the previous version, etc.

I will have hopes.  I didn't mean to imply that we shouldn't have 
constant improvement.  That is important.  But, improved stability is 
improvement too.

-- 
James Tyrer

Linux (mostly) From Scratch

-- 
James Tyrer

Linux (mostly) From Scratch