You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 6, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 6, 2026. It is now read-only.
When installing Kolibri, it would perhaps make sense that we add an application launcher, such that people can continue after installing without too much hassle.
Example:
Have an icon in the default desktop environments's application launcher that says "Kolibri" and launches Firefox on http://127.0.0.1:8080
Solution:
It is quite possible that using service kolibri start and service kolibri status, together with xdg-open can launch kolibri at its currently served location.
We should not add new dependencies because of this, as the Desktop launcher can exist despite there being now XDG or browser.. in this case, a user won't see the launcher anyways.
Scope:
This issue does NOT propose to create a new UI or open up a discussion about a notification area, control panel or similar.
If this requires new UI to be written, we should not do this.
If I understand this correctly, it would be for the cases where kolibri is not installed to start on boot, right?
in that case I see a couple of possible conflict points:
Why using service kolibr start and stop? when being in the userland, only kolibri startis needed , so we don't have to deal with sudo or other possible problems to start a service from an user account
Being Linux a multiuser system, we should find a way to show a dialog warning if the user tries to start kolibri and it can't because the port is open. That could happen in systems using LTSP or similar solutions. Normal desktop users should not have this problem.
@benjaoming what do you think about these questions?
If I understand this correctly, it would be for the cases where kolibri is not installed to start on boot, right?
Not exactly: It's also to ensure that users don't end up installing Kolibri and being like "now what?". Meaning that they expect a program to appear, not understanding that they should open up a browser on http://<ip>:<port>.
I agree that multi-user and sudo stuff poses a clever solution, perhaps a conditional statement that understands the system service's Kolibri username.
If we can solve this for a simple launcher, we have also solved it for any subsequent control panel UI.
It's also to ensure that users don't end up installing Kolibri and being like "now what?". Meaning that they expect a program to appear, not understanding that they should open up a browser on http://<ip>:<port>.
FYI the current direction we're moving is to distinguish multi-user environments from single-user desktop applications. See the current work on mac here:
We'll eventually extend this to other operating systems. I'd prefer that we spend time working in that direction and would propose we close this particular feature as "won't fix".
Closing as stale ahead of archiving this repository. The Debian package now lives in the Kolibri monorepo; please open a fresh issue on learningequality/kolibri if this is still wanted.
Activity
jredrejo commentedon Aug 27, 2019
If I understand this correctly, it would be for the cases where kolibri is not installed to start on boot, right?
in that case I see a couple of possible conflict points:
service kolibr startand stop? when being in the userland, onlykolibri startis needed , so we don't have to deal with sudo or other possible problems to start a service from an user account@benjaoming what do you think about these questions?
benjaoming commentedon Aug 27, 2019
Not exactly: It's also to ensure that users don't end up installing Kolibri and being like "now what?". Meaning that they expect a program to appear, not understanding that they should open up a browser on
http://<ip>:<port>.I agree that multi-user and sudo stuff poses a clever solution, perhaps a conditional statement that understands the system service's Kolibri username.
If we can solve this for a simple launcher, we have also solved it for any subsequent control panel UI.
indirectlylit commentedon Sep 5, 2019
FYI the current direction we're moving is to distinguish multi-user environments from single-user desktop applications. See the current work on mac here:
We'll eventually extend this to other operating systems. I'd prefer that we spend time working in that direction and would propose we close this particular feature as "won't fix".
benjaoming commentedon Sep 6, 2019
@indirectlylit re-iterating what I wrote right above your comment:
"Any subsequent" also includes whatever application container that launches Kolibri in a single user environment.
rtibbles commentedon Oct 4, 2026
Closing as stale ahead of archiving this repository. The Debian package now lives in the Kolibri monorepo; please open a fresh issue on learningequality/kolibri if this is still wanted.