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.
On 05/25/2018 10:30 PM, wofgdkncxojef@gmail.com wrote:
Ok, everyone listen.
Please, who are you and what's your motivation?
Cheers,
On Saturday 26 May 2018 07:52:18 Jimmy Johnson wrote:
On 05/25/2018 10:30 PM, wofgdkncxojef@gmail.com wrote:
Ok, everyone listen.
Please, who are you and what's your motivation?
Cheers,
I'm systemd and want to assimilate trinity
On Saturday 26 of May 2018 07:30:16 wofgdkncxojef@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
Hi wofgdkncxojef,
Just in case you didn't know, TDE will almost never accept even the slightest change in _anything_, so if you want to do some things, you either have to fork, or go away...
Lol, I am exagerating it a bit here, but see that there is very few dev, very few time for what would be needed to re-arrange so many packages. Even the project ''owner'' does not work on it anymore, maybe because of time constraints or lack of interest. Have you already looked at how many packages are in TDE in Synaptic?
I agree with you that the default theme is a joke, and this is partly why I make my remaster with PCLinuxOS and TDE: To show that there is something to do with TDE, while retaining the good work flow of KDE3.
At this moment, I see TDE to be quite like Debian: Horrible out-of-the-box experience, but great experience afters days of tweaking.
-Alexandre
________________________________ De : Slávek Banko slavek.banko@axis.cz Envoyé : 26 mai 2018 09:59:03 À : trinity-devel@lists.pearsoncomputing.net Objet : Re: [trinity-devel] Renaming and split in to official and extra
On Saturday 26 of May 2018 07:30:16 wofgdkncxojef@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
On Sat May 26 2018 07:26:29 Alexandre Couture wrote:
At this moment, I see TDE to be quite like Debian: Horrible out-of-the-box experience, but great experience afters days of tweaking.
Hi Top-Poster,
I disagree. As do all my users. TDE works great. It works as they expect. It works for getting work done. That's what all my users want. If they wanted to play with Plasma or themes or tweaks or other DEs or Factorio they could but they just want to get work done. And for getting work done TDE works great.
Is TDE perfect? No. If you have suggestions for improvement why no post them for discussion? Or if it takes you days to tweak TDE why not ask for help with *specific* issues rather than oddly claiming that the DE you choose to use is horrible? Or if PCLinuxOS really needs days of tweaks to get TDE working why not post information to help other PCLinuxOS users?
Thank you KDE 3 devs and Tim and TDE devs all,
--Mike
Mike Bird wrote:
I disagree. As do all my users. TDE works great. It works as they expect. It works for getting work done. That's what all my users want. If they wanted to play with Plasma or themes or tweaks or other DEs or Factorio they could but they just want to get work done. And for getting work done TDE works great.
+1 here - exactly my motivation - I turn the PC on and can work. I configured it maybe 12y ago and managed to migrate to TDE - this was only effort in configuration. This is my motivation to use TDE - it is extremely reliable and also light weight.
Is TDE perfect? No. If you have suggestions for improvement why no post them for discussion? Or if it takes you days to tweak TDE why not ask for help with *specific* issues rather than oddly claiming that the DE you choose to use is horrible? Or if PCLinuxOS really needs days of tweaks to get TDE working why not post information to help other PCLinuxOS users?
exactly
Thank you KDE 3 devs and Tim and TDE devs all,
Amen
On Saturday 26 of May 2018 16:26:29 Alexandre Couture wrote:
Hi wofgdkncxojef,
Just in case you didn't know, TDE will almost never accept even the slightest change in _anything_, so if you want to do some things, you either have to fork, or go away...
Lol, I am exagerating it a bit here, but see that there is very few dev, very few time for what would be needed to re-arrange so many packages. Even the project ''owner'' does not work on it anymore, maybe because of time constraints or lack of interest. Have you already looked at how many packages are in TDE in Synaptic?
I agree with you that the default theme is a joke, and this is partly why I make my remaster with PCLinuxOS and TDE: To show that there is something to do with TDE, while retaining the good work flow of KDE3.
At this moment, I see TDE to be quite like Debian: Horrible out-of-the-box experience, but great experience afters days of tweaking.
-Alexandre
Hi Alexandre,
I am sorry that you have this attitude. But I understand - the reactions of users here to your proposals were often too personal and unnecessarily inadequate. However, remember that the current splash screen is the result of a consensus from your proposal. Likewise, the opening screen in Konqueror, KMail, the look of help pages, and so on. Let me say that the impressions of your designs here are written down significantly.
During your earlier activity, I assumed that your theme will be incorporated as another of the basic themes. Unfortunately, you have been discouraged by users feedback and therefore this work is still awaiting to completion. Although we have conservative users as well as developers, we are not closed to new proposals.
Cheers
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi Alexandre,
I am sorry that you have this attitude. But I understand - the reactions of users here to your proposals were often too personal and unnecessarily inadequate. However, remember that the current splash screen is the result of a consensus from your proposal. Likewise, the opening screen in Konqueror, KMail, the look of help pages, and so on. Let me say that the impressions of your designs here are written down significantly.
During your earlier activity, I assumed that your theme will be incorporated as another of the basic themes. Unfortunately, you have been discouraged by users feedback and therefore this work is still awaiting to completion. Although we have conservative users as well as developers, we are not closed to new proposals.
Cheers
Hi everyone, in addition to Slavek's excellent replies, a few extra notes from me.
- From time to time, people come around with new ideas that they would like to see in TDE. I also followed that path initially and put in a lot of ideas for improvements and for giving TDE more exposure. But as many of you have realized, most of those ideas never got implemented. This is not because TDE is closed or against changes, but because of: 1) TDE wants to remain slim and efficient (i.e. don't want to become another KDE4, Gnome3 or whatever...)
2) any change affects lot of people. So if I like a button in a specific place or a particular theme, it doesn't mean that the other users will like it. Changes should keep this into account and be reasonable and possibly provide an enable/disable of new featues
3) lack of developers. Yes, I know, that's the main problem :-) Example: renaming a class seems trivial, but it means renaming, testing all, make sure everything is fine and most of all (since renaming would go into the next minor release) it means that every new fix made in a minor release would require extra work when backporting to a maintenance release (because the names are different). So something that looks trivial is not always trivial.
All these to say that we appreciate all contributions that we get and all the effort that you do, but also to remind you that we need to keep our feet on the ground since the project is maintained on a voluntary effort and the workforce is what it is.
Don't get discourage if some (or most) of your changes never get anywhere, we are doing the best that we can :-)
Cheers Michele
On 05/26/2018 09:52 AM, Slávek Banko wrote:
On Saturday 26 of May 2018 16:26:29 Alexandre Couture wrote:
Hi wofgdkncxojef,
Just in case you didn't know, TDE will almost never accept even the slightest change in _anything_, so if you want to do some things, you either have to fork, or go away...
Lol, I am exagerating it a bit here, but see that there is very few dev, very few time for what would be needed to re-arrange so many packages. Even the project ''owner'' does not work on it anymore, maybe because of time constraints or lack of interest. Have you already looked at how many packages are in TDE in Synaptic?
I agree with you that the default theme is a joke, and this is partly why I make my remaster with PCLinuxOS and TDE: To show that there is something to do with TDE, while retaining the good work flow of KDE3.
At this moment, I see TDE to be quite like Debian: Horrible out-of-the-box experience, but great experience afters days of tweaking.
-Alexandre
Hi Alexandre,
I am sorry that you have this attitude. But I understand - the reactions of users here to your proposals were often too personal and unnecessarily inadequate. However, remember that the current splash screen is the result of a consensus from your proposal. Likewise, the opening screen in Konqueror, KMail, the look of help pages, and so on. Let me say that the impressions of your designs here are written down significantly.
During your earlier activity, I assumed that your theme will be incorporated as another of the basic themes. Unfortunately, you have been discouraged by users feedback and therefore this work is still awaiting to completion. Although we have conservative users as well as developers, we are not closed to new proposals.
Slavek you are referring to Trinity R14.0.5 release theme? Maybe a user theme contest is in order, where one Trinity person is sent themes made by Trinity users and they are posted for all interested eyes and then voted on by interested Trinity users for the theme they like the best.
If it's not to late maybe we can have such a contest, I'm pretty sure we have some people here with graphic experience that would love to take part in such a contest for the desktop they love? Or have you all ready made a theme contest announcement and got little response?
Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 2018/05/27 11:52 AM, Jimmy Johnson wrote:
Slavek you are referring to Trinity R14.0.5 release theme? Maybe a user theme contest is in order, where one Trinity person is sent themes made by Trinity users and they are posted for all interested eyes and then voted on by interested Trinity users for the theme they like the best.
If it's not to late maybe we can have such a contest, I'm pretty sure we have some people here with graphic experience that would love to take part in such a contest for the desktop they love? Or have you all ready made a theme contest announcement and got little response?
Cheers, -- Jimmy Johnson
Some graphic was updated for R14.0.0 release, with an effort to make it consistent across application. Some time ago there was a discussion on the forum on changing the TDE logo (proposed by some new users) but it ended up in nothing since there were to many different opinion.
IMO, the current graphic looks ok, could be better of course, but at least it is clean and tidy. If a user want to propose a new theme, he can prepare the require work and submit for inclusion in TDE. Some themes were added in the past (like baghira, ia-ora or something like that). There is also one proposed by Alex and currently waiting for inclusion. A new theme may not become the default one, but if someone puts in the effort to get it to work and it looks nice and tidy, it can definitely be added to TDE.
Much more long term (and again it clashes with the lack of developers) there has been discussions about a plan to have a web site to host themes and other things, and then let the user download and install them as they see fit.
Cheers Michele
On Saturday 26 May 2018 16:26:29 Alexandre Couture wrote:
Hi wofgdkncxojef,
Just in case you didn't know, TDE will almost never accept even the slightest change in _anything_, so if you want to do some things, you either have to fork, or go away...
Lol, I am exagerating it a bit here, but see that there is very few dev, very few time for what would be needed to re-arrange so many packages. Even the project ''owner'' does not work on it anymore, maybe because of time constraints or lack of interest. Have you already looked at how many packages are in TDE in Synaptic?
properly rename a subset, not everything. The rest can stay in opt, and slowly be renamed.
Seriously, about the owner.... I think a new leader is needed. Pearson has not enough time for trinity. This project is effectively leaderless.
It seams that Slavek is the most invested person in the project right now. Maybe he should be in charge?
I agree with you that the default theme is a joke, and this is partly why I make my remaster with PCLinuxOS and TDE: To show that there is something to do with TDE, while retaining the good work flow of KDE3.
actually i wasn't criticizing the theme. More like, remove kde branding. tdm comes by default with a kubuntu wallpaper. I think upstream should keep it's default theme simple and conservative. It's up to distros to do weird stuff.
At this moment, I see TDE to be quite like Debian: Horrible out-of-the-box experience, but great experience afters days of tweaking.
-Alexandre
wofgdkncxojef@gmail.com wrote:
Seriously, about the owner.... I think a new leader is needed. Pearson has not enough time for trinity. This project is effectively leaderless.
Perhaps you'll understand it better if I try to explain by example:
The owner of the company does not have to work in the company, so that the company moves forward. The company is missing man power and cache. Timothy accepts donations - if you wish write down what you want to see done and if I am not wrong he can make estimate in terms of work hours and cost. If you are ready to pay the price, you can have what you want. People have their roles and duties. Handle the people with respect and care.
regards
On Saturday 26 May 2018 21:53:33 deloptes wrote:
wofgdkncxojef@gmail.com wrote:
Seriously, about the owner.... I think a new leader is needed. Pearson has not enough time for trinity. This project is effectively leaderless.
Perhaps you'll understand it better if I try to explain by example:
The owner of the company does not have to work in the company, so that the company moves forward. The company is missing man power and cache. Timothy accepts donations - if you wish write down what you want to see done and if I am not wrong he can make estimate in terms of work hours and cost. If you are ready to pay the price, you can have what you want. People have their roles and duties. Handle the people with respect and care.
regards
Who's in charge then?
wofgdkncxojef@gmail.com wrote:
Who's in charge then?
look if I don't like something for example in Microsoft Windows, I will not call Bill Gates to complain.
Your voice was heard and you got multiple answers.
I think it is enough talking. There is the bug list - get to work ;-)
regards
On Sunday 27 May 2018 01:11:55 deloptes wrote:
wofgdkncxojef@gmail.com wrote:
Who's in charge then?
look if I don't like something for example in Microsoft Windows, I will not call Bill Gates to complain.
Your voice was heard and you got multiple answers.
I think it is enough talking. There is the bug list - get to work ;-)
regards
Who is in charge here? No one?
Why trinity is not in any distro?
You really think there's no corelation between the questions?
Hello again Mr or Ms Curiously Anonymous,
On Sat May 26 2018 16:37:08 wofgdkncxojef@gmail.com wrote:
Why trinity is not in any distro?
Depending on the distro: * Because it's not profitable enough. * Because KDE teams block it. * Because they haven't got a round tuit.
You want to try to get TDE back into Debian? Fine. The Debian KDE team will probably block you but you're welcome to try. It's your time to waste. But whether or not Debian includes TDE is a question for Debian. Why are you raising it here?
Are you a DD? Are you a DM? Do you have a sponsor? Have you filed an ITP? Do you plan on using Alternatives or not? Do you intend to create the new TDE packages in Debian, or will you pay someone else to create them. Do you intend to maintain the new TDE packages in Debian, or will you pay someone else to maintain them?
Debian is FLOSS. If Debian turns you down you are welcome to fork Debian and include TDE in your fork. You could call it Tedian or Wofgdkncxojefian.
But I still don't understand why you are wasting our time with Debian questions on TDE mailing lists.
TDE software is working, and working well. Which means the project is working, and working well. With Debian, with Devuan, with Ubuntu, and with many other distros and derivatives. Those are facts. Your opinion about TDE project governance is your opinion only. Perhaps if you told us of some of the successful projects you have led we could attribute more weight to your opinion.
--Mike
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,...?
You read my list too literally. It's just an initial sloppy proposal. All the basic stuff stay in.
Distributions don't want to take in stuff that **seem** not to be maintained by upstream, they are afraid, they will end up doing all the support. Their users expect a minimum of quality. The important word here is ****SEEM****
The split will in practice change nothing for trinity devs. It just about putting forward a bundle, that trinity devs reasonably guarantee they will maintain. This way distros will be more open in taking it in. You already want kdesktop not to crash, you already want kicker not to crash, you already want sound etc.....
For example, from what i've seen.... kmines seam to work perfectly. Yet, it will not be included in the official/main bundle, because other stuff are more important to guarantee they work well enough, like kdesktop. If kmines is in the main bundle and it brakes, and it's not fixed, the distros will get very annoyed.
It's like .... i think gstreamer, that splits it's packages in normal, bad and ugly. Extra doesn't imply they are shit, just that they are less maintained. Distros want to see maintainers upstream.
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.
Distros will never accept konqueror as is. Dolphin on the other hand, looks ok. Unless you want to put the effort of either fixing konqueror, or gutting web browsing out until it's fixed and maintaining a second unofficial version with konqueror as is for users that want it. Yea, just give dolphin to the distros, and let users add a repo and install konqueror them selves.
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.
Properly rename just a small subset of stuff. Leave the rest in opt, or just give them a very generic rename like "trinity-oldname". Not renaming, and putting stuff in opt was stupid to begin with.
Properly renaming stuff, will give the impression to distros that things are been maintained. Perceptions matter.
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
And this is why i'm starting this discussion. The whole point of doing this is to get included in distros. Been included in distros matters. You get more users and more devs.
for your example, leave kate in extra. kate could be renamed as trinity-kate, then mechanically libtrinity-katepart..... on the other hand kwrite could become trinity-editor or something like that. If it uses libkate then maybe libkate should change to something else too, like libtrinity-editor and still be used by kate and konqueror and whatever....
On Saturday 26 of May 2018 19:13:08 wofgdkncxojef@gmail.com wrote:
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,...?
You read my list too literally. It's just an initial sloppy proposal. All the basic stuff stay in.
Distributions don't want to take in stuff that **seem** not to be maintained by upstream, they are afraid, they will end up doing all the support. Their users expect a minimum of quality. The important word here is ****SEEM****
The split will in practice change nothing for trinity devs. It just about putting forward a bundle, that trinity devs reasonably guarantee they will maintain. This way distros will be more open in taking it in. You already want kdesktop not to crash, you already want kicker not to crash, you already want sound etc.....
For example, from what i've seen.... kmines seam to work perfectly. Yet, it will not be included in the official/main bundle, because other stuff are more important to guarantee they work well enough, like kdesktop. If kmines is in the main bundle and it brakes, and it's not fixed, the distros will get very annoyed.
It's like .... i think gstreamer, that splits it's packages in normal, bad and ugly. Extra doesn't imply they are shit, just that they are less maintained. Distros want to see maintainers upstream.
I'm going to say that you are missing the awareness of the structure of the code and its relationships. Some examples:
Here is the tdelibs source package. From a developer perspective, it's one source package, from a distributor's point of view, it's one source package but at the same time several binary packages. This package contains the TDE base libraries. These are basic things like tdecore, tdeui, tdefx, dcop, other things like katepart, tdewallet, tderandr, but also other like tdehtml, kjs. Some may have reservations about tdehtm and kjs quality. Some may request removal of arts. Others may request of renaming Kate. All within one single source package.
Here is the tdebase source package. From a developers perspective, it's once again one source package, from a distributor's point of view, it's one source package and a many binary packages. In addition to libraries, there are applications like tdm, twin, ksmserver, kdesktop, kicker, control center, konqueror, kate, klipper, and many more.
So here's one source packages from which distributors should build only something like "main", while others would build something else, something installed in /usr, something in /opt/trinity. And you want to say that nothing would be changed for developers? For users, the result would also be interesting because they would get only a portion of TDE contained in distributions, while for the remaining parts would have to look again at external repositories and hope that it will work together.
If the split should be like tdecore yes, but tdehtm no, kdesktop yes, but konqueror no, then it is unrealistic for such division to take place within a single source package. I can not imagine how this could work and be beneficial to someone.
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.
Distros will never accept konqueror as is. Dolphin on the other hand, looks ok. Unless you want to put the effort of either fixing konqueror, or gutting web browsing out until it's fixed and maintaining a second unofficial version with konqueror as is for users that want it. Yea, just give dolphin to the distros, and let users add a repo and install konqueror them selves.
Sorry, but Dolphin (at least the version from Trinity) certainly can not be described as a good replacement for Konqueror as file manager. By the way, Dolphin depends on libkonq library... So here again we need to build Konqueror.
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.
Properly rename just a small subset of stuff. Leave the rest in opt, or just give them a very generic rename like "trinity-oldname". Not renaming, and putting stuff in opt was stupid to begin with.
Properly renaming stuff, will give the impression to distros that things are been maintained. Perceptions matter.
If there is a strong will to do renaming to allow for inclusion in distributions, it must be done completely and not just a part. It's the same as example above - we've already renamed for example kdecore => tdecore, but are not renamed kded, kjs, kcookiejar - all within same source package (tdelibs).
Remember that if, for example, kshell were to be renamed to tde-kshell, it's also a renaming with exactly the same level of difficulty. There is no difference between "proper" renaming and "partial" renaming.
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
And this is why i'm starting this discussion. The whole point of doing this is to get included in distros. Been included in distros matters. You get more users and more devs.
for your example, leave kate in extra. kate could be renamed as trinity-kate, then mechanically libtrinity-katepart..... on the other hand kwrite could become trinity-editor or something like that. If it uses libkate then maybe libkate should change to something else too, like libtrinity-editor and still be used by kate and konqueror and whatever....
As I said - we are all aware that renaming is necessary in the long run. We also know that this will be a very challenging task. And that we do not have enough developers to do this now. This is the simple reason why we chose the way to place Trinity to /opt/trinity. This allows us to provide Trinity for users without having to immediately do renaming of everything.
If you feel motivated enough and you have a lot of persistence, stop talking here, put your hands to the work and start working on the list for a complete renaming. I recommend to start on etherpad.trinitydesktop.org
Cheers
On Sunday 27 May 2018 03:08:08 Slávek Banko wrote:
On Saturday 26 of May 2018 19:13:08 wofgdkncxojef@gmail.com wrote:
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,...?
You read my list too literally. It's just an initial sloppy proposal. All the basic stuff stay in.
Distributions don't want to take in stuff that **seem** not to be maintained by upstream, they are afraid, they will end up doing all the support. Their users expect a minimum of quality. The important word here is ****SEEM****
The split will in practice change nothing for trinity devs. It just about putting forward a bundle, that trinity devs reasonably guarantee they will maintain. This way distros will be more open in taking it in. You already want kdesktop not to crash, you already want kicker not to crash, you already want sound etc.....
For example, from what i've seen.... kmines seam to work perfectly. Yet, it will not be included in the official/main bundle, because other stuff are more important to guarantee they work well enough, like kdesktop. If kmines is in the main bundle and it brakes, and it's not fixed, the distros will get very annoyed.
It's like .... i think gstreamer, that splits it's packages in normal, bad and ugly. Extra doesn't imply they are shit, just that they are less maintained. Distros want to see maintainers upstream.
I'm going to say that you are missing the awareness of the structure of the code and its relationships. Some examples:
Here is the tdelibs source package. From a developer perspective, it's one source package, from a distributor's point of view, it's one source package but at the same time several binary packages. This package contains the TDE base libraries. These are basic things like tdecore, tdeui, tdefx, dcop, other things like katepart, tdewallet, tderandr, but also other like tdehtml, kjs. Some may have reservations about tdehtm and kjs quality. Some may request removal of arts. Others may request of renaming Kate. All within one single source package.
Here is the tdebase source package. From a developers perspective, it's once again one source package, from a distributor's point of view, it's one source package and a many binary packages. In addition to libraries, there are applications like tdm, twin, ksmserver, kdesktop, kicker, control center, konqueror, kate, klipper, and many more.
So here's one source packages from which distributors should build only something like "main", while others would build something else, something installed in /usr, something in /opt/trinity. And you want to say that nothing would be changed for developers? For users, the result would also be interesting because they would get only a portion of TDE contained in distributions, while for the remaining parts would have to look again at external repositories and hope that it will work together.
If the split should be like tdecore yes, but tdehtm no, kdesktop yes, but konqueror no, then it is unrealistic for such division to take place within a single source package. I can not imagine how this could work and be beneficial to someone.
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.
Distros will never accept konqueror as is. Dolphin on the other hand, looks ok. Unless you want to put the effort of either fixing konqueror, or gutting web browsing out until it's fixed and maintaining a second unofficial version with konqueror as is for users that want it. Yea, just give dolphin to the distros, and let users add a repo and install konqueror them selves.
Sorry, but Dolphin (at least the version from Trinity) certainly can not be described as a good replacement for Konqueror as file manager. By the way, Dolphin depends on libkonq library... So here again we need to build Konqueror.
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.
Properly rename just a small subset of stuff. Leave the rest in opt, or just give them a very generic rename like "trinity-oldname". Not renaming, and putting stuff in opt was stupid to begin with.
Properly renaming stuff, will give the impression to distros that things are been maintained. Perceptions matter.
If there is a strong will to do renaming to allow for inclusion in distributions, it must be done completely and not just a part. It's the same as example above - we've already renamed for example kdecore => tdecore, but are not renamed kded, kjs, kcookiejar - all within same source package (tdelibs).
Remember that if, for example, kshell were to be renamed to tde-kshell, it's also a renaming with exactly the same level of difficulty. There is no difference between "proper" renaming and "partial" renaming.
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
And this is why i'm starting this discussion. The whole point of doing this is to get included in distros. Been included in distros matters. You get more users and more devs.
for your example, leave kate in extra. kate could be renamed as trinity-kate, then mechanically libtrinity-katepart..... on the other hand kwrite could become trinity-editor or something like that. If it uses libkate then maybe libkate should change to something else too, like libtrinity-editor and still be used by kate and konqueror and whatever....
As I said - we are all aware that renaming is necessary in the long run. We also know that this will be a very challenging task. And that we do not have enough developers to do this now. This is the simple reason why we chose the way to place Trinity to /opt/trinity. This allows us to provide Trinity for users without having to immediately do renaming of everything.
If you feel motivated enough and you have a lot of persistence, stop talking here, put your hands to the work and start working on the list for a complete renaming. I recommend to start on etherpad.trinitydesktop.org
Cheers
-_- just forget it.
On Sunday 27 of May 2018 06:54:54 wofgdkncxojef@gmail.com wrote:
As I said - we are all aware that renaming is necessary in the long run. We also know that this will be a very challenging task. And that we do not have enough developers to do this now. This is the simple reason why we chose the way to place Trinity to /opt/trinity. This allows us to provide Trinity for users without having to immediately do renaming of everything.
If you feel motivated enough and you have a lot of persistence, stop talking here, put your hands to the work and start working on the list for a complete renaming. I recommend to start on etherpad.trinitydesktop.org
Cheers
-_- just forget it.
The moment I tell you to put your hand to the work, are you giving up? Are you serious? Really just a lot of talk, but not work?
Cheers
On Sunday 27 May 2018 10:35:48 Slávek Banko wrote:
On Sunday 27 of May 2018 06:54:54 wofgdkncxojef@gmail.com wrote:
As I said - we are all aware that renaming is necessary in the long run. We also know that this will be a very challenging task. And that we do not have enough developers to do this now. This is the simple reason why we chose the way to place Trinity to /opt/trinity. This allows us to provide Trinity for users without having to immediately do renaming of everything.
If you feel motivated enough and you have a lot of persistence, stop talking here, put your hands to the work and start working on the list for a complete renaming. I recommend to start on etherpad.trinitydesktop.org
Cheers
-_- just forget it.
The moment I tell you to put your hand to the work, are you giving up? Are you serious? Really just a lot of talk, but not work?
Cheers
All the stuff i'm saying, have the long term strategy of attracting more devs. There's no willingless at all to do that. There's no leader here to keep the project on tract to a long term goal like that. It's only the next bug fix that matters here.
-
Alexandre Couture -
deloptes -
Jimmy Johnson -
Michele Calgaro -
Mike Bird -
Slávek Banko -
wofgdkncxojef＠gmail.com