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

[Kevin Krammer]

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.

> 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.
The path is an identifier in the filesystem, very often used as a key and 
should therefore remain stable.

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

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.

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

> > 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.

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.

> 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.

> > 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.

> >> 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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20130423/7fe4631a/attachment.sig>