26 May
2018
26 May
'18
9:59 a.m.
On Saturday 26 of May 2018 07:30:16 wofgdkncxojef(a)gmail.com wrote:
Ok, everyone listen.
I'm proposing to split the programs, in official trinity
and extra. The list of official packages should be restricted.
They should be of good enough quality and as a whole should
be close to the functionality of DE like MATE and xfce. The devs
should decide upon the list, and then make sure they maintain
their quality. They should be renamed, with proper names, not
kdename-trinity, and pulled out of opt. In extra will be everything
else. The idea is, for the official part to be more appealing to
distros. If trinity get's in to distros, it will have more exposure and
get more devs.
an initial proposal of what the official packages could be:
all the base system and libs of course
kdesktop, kicker, tdenetwork manager, tdm, kmix, klipper, control
center, dolphin, kwrite, kmail, kwallet, kaffeine, konsole, amarok,
kalculator, gwenview, ark, kpdf other?.
konqueror is not good enough for a default file manager because of
it's outdated web browsing component.
all the above should get proper names, not kdename-trinity
and moved out of opt. Even the libs, should be renamed something
like trinity libs, not tqt. The stuff in extra can stay in opt as it
is. And don't forget, the quality of what will be in the list must stay
good enough, you can't just shove everything. Once the list will be
desided, then it will need to be decided how to rename them.
The whole point of this, is to have something nice, the distros can
accept taking in. They should not see "Konqueror-trinity" that
can't render facebook or youtube. The whole point of getting accepted
by distros, is so that the project gets more exposure and hence more
devs.
Hi all, wofgdkncxojef,
at begin, I would start with formality. It is good to imagine yourself in
society at first. Using a very anonymous email with no signature is not a
very trusted method.
Second: Trinity is simply not just a basic programs, but we have to manage
the entire 'ecosystem'. That is why we provide a new home for all Trinity
and old KDE3 applications that our users desire. That's why we provide
binary packages for a large number of distributions and versions -
both 'deb' and 'rpm' based. At the same time, it gives us some
independence from distributions, their goals, their development cycles.
The division of applications into "first category" and "other" I do
not
see as useful. We simply need applications "to be able to compile and
functional". The fact that some applications get more patches and other
less patches is a natural way to split applications. At the same time,
less patches do not indicate that the application is not useful, is not
used, is not good. It's always about whether users are interested in the
application and whether someone can contribute by code and find time to
put their hands on the work.
By the way, one basic division already exists. There are basic packages
such as tdelibs, tdebase, tdegraphics,... that contain common libraries
and also some applications, and besides, the application folder that
contains other applications. Your proposed list of "first category"
application completely ignores the fact of what part the source code is.
Are you currently unaware of the source code structure or are you
suggesting breaking the existing tdebase, tdegraphics,...?
Claiming that a Konqueror is not a good file manager because an outdated
web component is a bit funny. What is the impact of web component on
managing local files? We all know that Konqueror is not enough on modern
websites for the role of the Internet browser. But it does not disqualify
it from the file manager role.
At different intervals, there is a demand that we need to "rename
completely everything" to allow become part of official distributions.
Yes, we are all aware that the conflicting names and the resulting
location in /opt/trinity is a thing that prevents us from doing so. Yes,
we all know it would be good to do it. The problem, however, is that a
renaming of everything is a very challenging task, for which we do not
have enough time of developers to devote to this. Additionally, here is
also the fact that renaming will not be beneficial for existing users -
rather, they will not be delighted. I do not say we do not want to rename
everything. I just say we prefer other things that seem to be more useful
for our users.
If there is a strong enough will to prepare a renaming of everything, it
is appropriate first to prepare a complete list of things to rename and
their new names. This means not only applications as seen by users but
also related libraries. And also the names of the objects and the method.
For example, kate, libkatepart, libkatepartinterfaces, libkateinterfaces,
libkateutils. As soon as we have a complete renaming plan, we can begin
to address its implementation.
Cheers
--
Slávek