On Saturday 26 of May 2018 07:30:16 wofgdkncxojef@xxxxxxxxx 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
