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