Use this apps instead of making new ones.

[rahmanshaber]

We are a team of people working on a project called CoreApps. This apps uses qt and uses less dependence and have a constancy across all the apps.

So what is this about? We want Lumina team to check out our project and use them in the project instead of making another ones. This will benefit both teams. We can focus on the apps and Lumina team can work on the DE side, improve the DE. Our app can cover all the user cases. There are 19 apps in total. We know some of them is duplicate like FM, Screenshot tool, Image Viewer. But i think we can leave the duplicate and use the other ones and make a great DE.

I am not explaining this clearly, I know that. But we have great plans for CoreApps and in Future we want a DE onboard.

Check out our Gitlab CuboCore and Website. Thanks.

[utrenkner]

I am not a developer but just a user of Lumina. I would very much welcome if the two projects - which seem to be similar in their goal and choice of libraries (Qt) - could work together. Especially, as developer resources are really scarce...!

When you say "minimum dependencies" on the CuboCore website, I hope this means also that the apps can happily run without systemd?!

[q5sys]

One of the focuses of the Lumina Desktop is to have a full featured minimal desktop that's under a MIT/BSD license and is *nix OS agnostic. You're apps are GPL v2 from what I can tell. Since they would be technically stand alone, that's not a licensing issue, but it still takes away from Ken's initial and primary goal. The decision would have to be his.

[beanpole135]

A few quick notes:

1. From their website:

   We make daily apps with constant looks across all the apps and can run in lower system with minimum dependencies. All the apps are based on Qt toolkit and for Linux OS.

This seems to imply that they have never tried running thier apps on any other non-Linux OS

2. A quick search through freshports shows no mention of any "CuboCore" apps available for FreeBSD. This moves my guess about statement 1 to near-certainty - their apps are not ported to FreeBSD and/or any other non-linux operating system.
3. This is a deal-breaker for Lumina, since Lumina is designed to focus on the BSD's first and get Linux compatibility as a side-effect of keeping dependencies to a minimum.
4. While I cannot say this with certainty (since I have not actually run the applications), but from the pictures on the website of their applications I cannot see any feature that their apps provide which the Lumina apps do not have already. In fact, I would hazard a guess that none of the ZFS interactions that the Lumina tools have integrated nor the scientific functions on the lumina-calculator are available in the other utilities.

So I guess the answer is no - there is no compelling reason for us to stop developing our own tools just because somebody else might have done something similar for a different operating system. If you want to ensure your tools are ported to the BSD's and get up to feature parity with the Lumina utilities, then I will gladly try them out and maybe even use them instead of some of the tools I have written. But I will not depricate completely functional utilities just because some other project wants me to use their stuff instead. People should be given choices of applications instead of trying to force people to use particular ones.

[utrenkner]

@q5sys GPL is really a problem. That alone should end the discussion (except if the CuboCore developers considered dual licensing their code).

@beanpole135 , I respect your view and decision - you are the creator/owner of this open source desktop, and anyone who is not happy with it can fork it.

But as a user I have a somewhat different opinion from yours. I find several of the Lumina tools lacking or severely buggy. My various issues with lumina-fm have been documented here... and lumina-pdf is completely unusable on my FreeBSD desktop, due to bad quality font rendering. In that issue, a fix was announced more than a year ago, but the last Lumina release was even longer ago (1.5 years). General lack of developer resources and much additional work from Trident seem to have prevented you from improvements and official releases.

I have continued using Lumina as my main desktop on both, my FreeBSD and HardenedBSD laptops but the quality is only bearable because I hope for improvements. I have no right to ask for anything and I hope I have never complained about the speed of development. But when I read that you do not want to cooperate with similar projects, because of the "focus on BSD" and because you have "completely functional utilities" I am somewhat surprised because it does not match with my experience.

[marcusbritanicus]

When you say "minimum dependencies" on the CuboCore website, I hope this means also that the apps can happily run without systemd?!

Yes no systemd.

[marcusbritanicus]

@utrenkner I am one of the CuboCore devs. I don't see whats the problem with GPL anyways. If you can convince me, without starting a license war, I guess a thought can be given about dual licensing. Though the chances are less.

We at CuboCore too feel that if we integrate our efforts, we will have a very nice and a stable DE. We are mainly working on linux, and hence can help lumina be supported on Linux too.

[utrenkner]

@marcusbritanicus I am also not into license wars. My main issues are:

• I want anyone to use the best code s/he can get. But many companies/individuals have to say "no" to GPL'ed code because they may or may not have to license their own work under GPL if they use it (this - for me - compelling argument was made by Poul Hennig Kamp, FreeBSD developer and author of md5crypt, Varnish cache etc.)
• GPL puts a burden on a company using the code: They have to evaluate if and how they have to make the Code available. E.g. if someone wanted to create a RasperryPi based computer, fully configured with your CuboCore apps, they have to make sure that any customization they made has to be published somewhere. Even if they are ok with sharing the code, it can be difficult to include this in your company's processes.
• BSD/MIT license is so damn easy to explain: 1. Take the code and do with it whatever you want, 2. but do not sue me, if something goes wrong and 3. don't claim you wrote the code. Explaining GPLv2 is much more difficult... and with GPLv3 you are almost lost (at least when you need to explain the details). These are my main reasons why I prefer a permissive license.

[beanpole135]

@utrenkner : Just to make sure that I am being perfectly clear:

I am not against CuboCore or their goals, in fact I wish them tons of success. The Lumina "desktop utilities" are specifically designed as stand-alone tools that do not depend on nor require the Lumina desktop specifically so that others could come along and "adopt" those tools directly so that I don't need to maintain them any more. If another project provides a better desktop applications with more features and none of the Linux bloat then I will switch over to them in a heartbeat. Before I can condone stopping development of the Lumina tools and/or deprecating them though, there are a number of conditions that must be satisfied, and CuboCore currently does not meet these conditions.

1. Cross-OS compatibility: They need to run on the BSD's exactly like they do on Linux without any weird compatibility/dependency shims for things liks dbus/systemd/consolekit.
2. Cross-OS availability: They need to be available on the BSD's in the native package system (FreeBSD ports is what I particularly look at)
3. Feature parity: They need to support the same level of features (or greater) to the existing Lumina utilities.

Once 1 and 2 are met, I will gladly start installing CuboCore tools and running them on my own systems, but I cannot justify changing the default applications for other users until all three conditions are met.

[rahmanshaber]

@beanpole135 and all the users and devs. We all know we don’t have many devs in the small project like us. In result the development is slow. That’s why i gave a proposal.

I added the Linux OS because I wanted to clear that Windows is not an option.

First I see only one or two apps might not run in Unix as they have depends that might not be in Unix.

Second the licensing. We want the codes because we don’t have devs and that will help us.

Third we don’t have any is is based codes I know of. Might be drive mount or getting battery info.

And I am not telling replace all the tools with CoreApps. I know system FM is needed. Just use what is needed like picture viewer, player and most importantly corestuff and corepins. Our crown apps.

We will not do any fancy features like heavy customization options or system heavy features. Basic + good user experience + bug free. We will be good in that.

I don’t know how to package or use the BSD stuff. So some things I said might be wrong.

Thanks.

[rahmanshaber]

Please tryout the apps then let us know in the matrix #cubocore .

[rodlie]

Sorry for being off-topic

@rahmanshaber: I noticed that corefm has taken several source files from qtfm and removed the license/copyright. As the current maintainer of qtfm please re-add the copyright or remove the files. I also noticed that you took my udisk library and added that to csys, that's ok as long as you abide by the license (BSD 3), but you don't include the LICENSE file.