| *** ChanServ sets mode: +v T4 | 05:23 | |
| Leif_Erikson | I can build the glacier home and lipstick example project. But I can’t deploy them, yet. | 08:29 |
|---|---|---|
| Leif_Erikson | The error message of the glacier project is the following: cp: cannot stat `/home/mersdk/share/SailfishOS/projects/build-glacier-home-SailfishOS_2_2_0_29_i486_in_Sailfish_OS_Build_Engine-Debug/rpm/lipstick.service': No such file or directory“ | 08:29 |
| Leif_Erikson | The error message of the lipstick example project is the following: | 08:30 |
| Leif_Erikson | Error on file "/home/deploy/installroot/usr/share/applications/*.desktop": No such file or directory | 08:30 |
| Leif_Erikson | I’ve created a subdirectory rpm in the lipstick example project and added a .yaml file by using another file, that was created by the wizard as a template. The .spec file is not automatically created. | 08:30 |
| NeoChapay | Leif_Erikson: you can't build master of glacier home in sdk | 08:30 |
| Leif_Erikson | 1. What has to be configured in the .desktop file? | 08:30 |
| Leif_Erikson | 2. How and where is a lipstick implementation deployed? It’s not an app, that is visible in the launcher, isn’t it? | 08:30 |
| Leif_Erikson | If I look at the .desktop file of glacier home, the second line seems to be the relevant: Exec=/usr/bin/lipstick. Can someone help? | 08:30 |
| Leif_Erikson | NeoChapay: Why not? The build engine includes the full platform sdk | 08:31 |
| NeoChapay | Leif_Erikson: it's rpm problem...i fix it in devel branch | 08:32 |
| Leif_Erikson | The build was successful for the two projects | 08:32 |
| Leif_Erikson | NeoChapay: I will switch to the devel branch then | 08:33 |
| NeoChapay | Leif_Erikson: i move installing desktop and other files from .spec file to pro and all is well | 08:33 |
| NeoChapay | Leif_Erikson: yea...devel branch in developming | 08:34 |
| r0kk3rz | new sdk has new rpm, so it might be ok now | 08:52 |
| T4 | <akaWolf> .spec generated by spectacle from .yaml | 08:55 |
| T4 | <akaWolf> Btw, @neochapay , correct case is to edit yaml | 08:57 |
| r0kk3rz | correct case is to nuke the yaml from orbit :P | 08:57 |
| T4 | <akaWolf> Why? | 08:58 |
| r0kk3rz | because spectacle is stupid | 08:58 |
| r0kk3rz | not even jolla uses it anymore | 08:58 |
| r0kk3rz | nobody maintains it | 08:58 |
| T4 | <akaWolf> It have about 1k commits | 08:59 |
| r0kk3rz | im not even sure what problem its supposed to solve | 09:00 |
| T4 | <akaWolf> What was purpose of that scheme? | 09:00 |
| T4 | <akaWolf> Hmm | 09:00 |
| r0kk3rz | maybe its a slightly easier to parse version of the spec for some tool | 09:00 |
| T4 | <neochapay> @akaWolf [Btw, @neochapay , correct case is to edit yaml], Don't use yaml | 09:02 |
| T4 | <akaWolf> spec isnt better | 09:02 |
| Leif_Erikson | Using a .yaml file is the recommended way for deployment: https://sailfishos.org/wiki/Application_SDK_Packaging_Apps#The_.yaml_File | 09:03 |
| r0kk3rz | no it isnt :P | 09:03 |
| T4 | <neochapay> @akaWolf [spec isnt better], Spec is awesome! | 09:04 |
| Leif_Erikson | Using a .yaml file is the recommended way for deployment: https://sailfishos.org/wiki/Application_SDK_Packaging_Apps#The_.yaml_File | 09:04 |
| T4 | <neochapay> @Leif_Erikson [Using a .yaml file is the recommended way for …], We. Are not Jolla don't forget it :))) | 09:05 |
| Leif_Erikson | Quote: "For Sailfish OS projects, you don’t usually create or modify the .spec file directly. Instead, a more human-readable intermediate metadata file, a .yaml file, is used. The .spec file itself is generated automatically during the build process from the .yaml file." | 09:05 |
| r0kk3rz | fine, ignore people with actual experience, read some outdated document instead | 09:05 |
| r0kk3rz | you're asking for help and then arguing about what we tell you | 09:07 |
| T4 | <faenil> Relax people, relax :) | 09:08 |
| T4 | <neochapay> (Sticker, 512x512) http://149.202.119.142:9090/JomyN6Y6kk.png | 09:09 |
| T4 | <faenil> Leif_Erikson: the documentation might be outdated or not reflect actual best practices for Nemo, so the best way is to trust guys in this chat :) | 09:09 |
| Leif_Erikson | r0kk3rz: I would be glad about any advice or documentation. I learned, that people of this community use a .spec file, but I don't find a documentation for this file and I don't know the terminal commands to build and deploy a project and last but not least to automise this process for efficient development. | 09:09 |
| T4 | <faenil> Leif_Erikson: and once you get to the solution, bonus points for writing/updating the wiki :) | 09:10 |
| r0kk3rz | .spec and .rpm are standard things from redhat | 09:10 |
| r0kk3rz | used all over the place | 09:10 |
| r0kk3rz | you dont need terminal commands, you can just deploy it from the qt creator | 09:12 |
| r0kk3rz | you dont need a .yaml file to do that | 09:12 |
| Leif_Erikson | r0kk3rz: Good news, but how? | 09:13 |
| T4 | <neochapay> mb2 build ? | 09:13 |
| r0kk3rz | 'deploy as rpm' dun dun dun | 09:13 |
| r0kk3rz | i wonder what that does | 09:13 |
| T4 | <akaWolf> Too many time was spent for that spectacle. I think, should be real reason | 09:14 |
| Leif_Erikson | We asked several companies for an offering for the development environment setup including Jolla to come to an end with this discussion. However I will try to make the project running this week. | 09:15 |
| Leif_Erikson | Is Galcier-UX deployed like an app like other apps? What is the difference for the deployment? | 09:16 |
| T4 | <neochapay> Yeap like other apps just install rpm | 09:17 |
| Leif_Erikson | T4: Sure I would be happy to write a tutorial in the Wiki as soon I have the solution. | 09:17 |
| r0kk3rz | Leif_Erikson: everything is deployed as rpm, there is no distinction between 'apps' and everything else | 09:23 |
| Leif_Erikson | T4: What is the difference? A lipstick implementation is obviously not visible in the app grid. This is different to Android, where you can have several launchers. | 09:36 |
| Leif_Erikson | Launcers are defined within the AndroidManifest.xml with the line <category android:name="android.intent.category.HOME" /> | 09:37 |
| Leif_Erikson | Is there something similar to Nemo Mobile respectively Sailfish? | 09:37 |
| Leif_Erikson | Maybe is the .desctop file? It's also still an open question for me, how to write this file. | 09:38 |
| r0kk3rz | yep this isnt android, knowledge of it wont help you here | 09:39 |
| Leif_Erikson | For Android there is also the category <category android:name="android.intent.category.LAUCNHER" /> | 09:39 |
| Leif_Erikson | r0kk3rz: I quoted Android to explain my question. A lipstick implementation in not visible as an app but build and deployed like an app. This there are two questions: | 09:41 |
| Leif_Erikson | 1. How do I have to configure a lipstick implementation as the system UI (home screen, launcher, etc)? | 09:42 |
| r0kk3rz | don't try and map android concepts onto things that arent android :P you'll confuse yourself | 09:42 |
| Leif_Erikson | 2. Is it possible to deploy a lipstick implementation, that is visible like an app to switch between implementations like in Android? | 09:43 |
| r0kk3rz | no | 09:43 |
| r0kk3rz | all you need to do is deploy lipstick and run it | 09:44 |
| r0kk3rz | lipstick is more analogous to surfaceflinger on android, not merely a homescreen ux | 09:44 |
| Leif_Erikson | r0kk3rz: Ok. Let me rephrase my question: How does the system know, that a lipstick implementation is not a regular app? I guess, there is some entry in the .rpm file. | 09:45 |
| r0kk3rz | no | 09:46 |
| r0kk3rz | apps are installed into a different place, thats pretty much it | 09:46 |
| r0kk3rz | the launcher icon is the .desktop file | 09:46 |
| Leif_Erikson | And how is it defined in the project, that a lipstick implementation is installed into a different place? | 09:47 |
| r0kk3rz | in the spec | 09:48 |
| NeoChapay | anybody tryed windowed mode patch ? | 09:54 |
| NeoChapay | ....okay....anybody trying devel branch ^_^ ? | 09:54 |
| T4 | <akaWolf> with which envir? | 09:58 |
| Leif_Erikson | r0kk3rz: So the OS expects an implementation in a specific directory? This is %{_bindir}/lipstick in the .specc file of Glacier? | 10:04 |
| r0kk3rz | not really | 10:05 |
| r0kk3rz | it gets started by systemd using the .service file | 10:05 |
| T4 | <akaWolf> .spec is for building rpm | 10:07 |
| r0kk3rz | it is, but it does define where stuff gets installed | 10:12 |
| T4 | <akaWolf> ofc =) | 10:17 |
| T4 | <akaWolf> like any other description of the package | 10:17 |
| T4 | <faenil> Leif_Erikson: to sum up what r0kke3rz said, the launcher scans some folder for .desktop files and shows those apps in its UI for the grid of apps. The launcher is started as part of the booting procedure, which is defined, in Nemo's case, throught systemd "unit" files. | 11:01 |
| T4 | <faenil> Both are pretty much generic Linux systems, so you can look it up and you will find plenty of info about them. '.desktop' files and systemd units and services | 11:02 |
| T4 | <faenil> Once you have that knowledge, you will be able to apply to Nemo and easily figure out how the system boots and shows app in its launcher. If there's any doubt, ask here | 11:03 |
| Leif_Erikson | So the .rpm file is created by the .spec file. I think the Sailfish sdk suggests a workflow of yml file -> spec file -> rpm file. | 11:16 |
| Leif_Erikson | In my opinion the project management could be more efficient. We have a pro, (optionally) a yaml, a spec and an rpm file. It quite a lot of overhead. | 11:16 |
| Leif_Erikson | r0kk3rz: The service file defines the location of the installation? | 11:17 |
| Leif_Erikson | Again: How does the system know, that it use the lipstick implementation? Does the installation modifies a system configuration? | 11:20 |
| Leif_Erikson | It looks like that way, if I read the following line in the .service file of the Glacier project: | 11:20 |
| Leif_Erikson | EnvironmentFile=-/var/lib/environment/compositor/*.conf | 11:20 |
| Leif_Erikson | EnvironmentFile=-/usr/share/lipstick-glacier-home-qt5/nemovars.conf | 11:20 |
| r0kk3rz | the service file tells systemd what to run | 11:22 |
| r0kk3rz | you only need a .pro and a .spec | 11:23 |
| r0kk3rz | thats not too much overhead | 11:24 |
| Leif_Erikson | Do I have to modify the make or qmake file of the sdk to tell the sdk, that it doesn't expect a yaml file? | 11:51 |
| T4 | <akaWolf> @r0kk3rz [thats not too much overhead], I would say this is minimum... | 11:58 |
| T4 | <akaWolf> I don't know how SFOS SDK modify standart workflow, but in general there are no relations between Qt project and directions in yaml | 12:00 |
| r0kk3rz | Leif_Erikson: just remove yaml from pro and delete file | 12:10 |
| T4 | <akaWolf> r0kk3rz, what did especial in SDK? | 12:10 |
| r0kk3rz | ? | 12:11 |
| T4 | <akaWolf> I mean what different in SFOS SDK flow from common generic Qt project flow | 13:01 |
| T4 | <akaWolf> what is for yaml | 13:02 |
| r0kk3rz | no idea, i cant see any benefit to it | 13:02 |
| r0kk3rz | learning how to read and write spec files is much more useful | 13:03 |
| ol | Leif_Erikson: http://rpm.org/documentation.html | 13:58 |
| ol | RPM is a package. It contains archive of files (along with pathnames where to install them) and package metainformation containing name, version, dependencies etc. Just like apk file in Android, but much more powerful and flexible. | 13:58 |
| ol | The main power of RPM is dependencies. A package can depend not only on other packages, but on libraries, files or any arbitrary names (capabilities) that can be provided by other packages (like "webserver" or "mta"). All these dependencies can be versioned and a package can depend on specific version range of a capability. | 13:58 |
| ol | A ".spec" file describes how to buld a package. It contains: | 13:58 |
| ol | * headers that describe package name ("Name:"), version ("Version:"), what capabilities package provides ("Provides:"), what capabilities package depends on ("Requires:"), what capabilities it depends on for build ("BuildRequires:"), source tarball ("Source:") etc.; | 13:58 |
| ol | * "%description" section with detailed description of the package; | 13:58 |
| ol | * "%prep" section with a script that unpacks the tarball into %{_builddir} and applies all necessary patches to unpacked source; | 13:58 |
| ol | * "%build" section with a script to build the package; please note that it can be anything, RPM doesn't care about a particular build system; if you build with make, then run make in this section, if you generate your makefile with qmake, run qmake and then make, if you build with Apacke Ant, run Apache Ant in this section; | 13:58 |
| ol | * "%install" section with a script to install the results of the script in "%build" section into %{buildroot}; again, this script depends on build system you use; | 13:58 |
| ol | * "%files" section that lists installes files; please note that pathnames are treated relative to %{buildroot} when packaging rpm file, but they are treated as absolute pathnames when installing rpm into your system; hence, the hierarchy of files installed in %{buildroot} by your %install section should be exactly the same as the one on target system where you're going to install rpm file (but without "%{buildroot}" prefix). | 13:58 |
| T4 | <akaWolf> :) | 14:01 |
| T4 | <akaWolf> I think it's already documented in a good way | 14:02 |
| T4 | <akaWolf> in the internet | 14:02 |
| T4 | <akaWolf> no need to describe basics of package management here I guess | 14:02 |
| ol | @akaWolf: Leif_Erikson was trying to compare rpm with some Java-specific build system before, so I think it would be beneficial to clarify this confusion. | 14:04 |
| T4 | <akaWolf> yeah maybe.. | 14:06 |
| T4 | <akaWolf> how is Glacier started? | 14:15 |
| T4 | <akaWolf> by set QT_QUICK_CONTROLS_STYLE to Nemo? | 14:15 |
| T4 | <akaWolf> r0kk3rz, do you know? | 14:17 |
| r0kk3rz | @akaWolf what do you mean? | 14:21 |
| T4 | <akaWolf> what is for QT_QUICK_CONTROLS_STYLE? | 14:24 |
| r0kk3rz | theming | 14:24 |
| T4 | <akaWolf> so if QT_QUICK_CONTROLS_STYLE is unset, what is happen? | 14:26 |
| T4 | <akaWolf> starting Jolla UX? | 14:26 |
| T4 | <locusf> no | 14:27 |
| r0kk3rz | probably not, it would use the qt theme | 14:27 |
| T4 | <locusf> its just going to look bad | 14:27 |
| T4 | <akaWolf> hmm | 14:28 |
| T4 | <akaWolf> but how to start Glacier then? | 14:28 |
| r0kk3rz | what do you mean 'start glacier' | 14:28 |
| r0kk3rz | you mean the homescreen? | 14:28 |
| T4 | <akaWolf> right | 14:29 |
| r0kk3rz | follow the instructions | 14:29 |
| T4 | <akaWolf> I want to understand what is happening when I follow | 14:30 |
| T4 | <locusf> its /usr/bin/lipstick | 14:30 |
| T4 | <akaWolf> okay.. can I have both UX at a time? | 14:30 |
| T4 | <locusf> which UX? | 14:31 |
| T4 | <locusf> jolla, no | 14:31 |
| T4 | <akaWolf> Glacier and Jolla | 14:31 |
| T4 | <locusf> because it overwrites the binary | 14:31 |
| T4 | <locusf> though you can copy it as backup | 14:31 |
| T4 | <akaWolf> hm | 14:31 |
| T4 | <locusf> lipstick is just a library to make a homescreen with | 14:31 |
| T4 | <akaWolf> okay I see | 14:31 |
| T4 | <locusf> and then glacier is just an implementing software for it | 14:32 |
| T4 | <locusf> or jolla | 14:32 |
| T4 | <akaWolf> why glacier and jolla write binary /usr/bin/lipstick then | 14:32 |
| T4 | <akaWolf> if lipstick is just a library | 14:32 |
| T4 | <locusf> it doesn't have to be like that :) | 14:32 |
| T4 | <locusf> its just easier to have a single systemd user service | 14:33 |
| T4 | <akaWolf> we can abstract from systemd unit: one service, which makes decision at config, what to start | 14:33 |
| T4 | <locusf> https://github.com/nemomobile-ux/glacier-home/blob/master/src/main.cpp#L35 | 14:33 |
| T4 | <locusf> no | 14:33 |
| T4 | <locusf> as you can see its baked in to c++ | 14:34 |
| T4 | <locusf> HomeApplication is what lipstick provides | 14:34 |
| T4 | <locusf> glacier helps with the qml portion thats presented as the lipstick compositor | 14:34 |
| T4 | <locusf> its responsibility is to manage windows, show notifications etc | 14:35 |
| T4 | <akaWolf> let me explain: if both packages (jolla home and glacier home) both provide the same binary `/usr/bin/lipstick`, then we can rename that binary in both packages, make simple wrapper, which reads configuration from `/etc` or even show graphical dialog which home we should start. in systemd service we will start that wrapper, which will sta | 14:37 |
| T4 | rt corresponding home | 14:37 |
| T4 | <locusf> sure | 14:37 |
| T4 | <akaWolf> so? | 14:37 |
| r0kk3rz | why? | 14:37 |
| T4 | <locusf> yeah why thats needed? | 14:37 |
| T4 | <locusf> since you can backup the binary | 14:38 |
| T4 | <locusf> and then rename it back if you want to do something else | 14:38 |
| T4 | <akaWolf> @locusf [yeah why thats needed?], well I dont want to hurt my device, for example | 14:38 |
| T4 | <locusf> restart lipstick service | 14:38 |
| T4 | <akaWolf> that's doesn't look too handy | 14:38 |
| T4 | <akaWolf> better to have it in such way as I described | 14:38 |
| T4 | <akaWolf> it would be handy to test Glacier UX | 14:39 |
| r0kk3rz | you can do whatever you like, its your device | 14:39 |
| T4 | <locusf> yeah | 14:39 |
| T4 | <akaWolf> I cant change the name of jolla's home... | 14:39 |
| r0kk3rz | neither can we | 14:39 |
| T4 | <akaWolf> but we can change main service units | 14:40 |
| T4 | <akaWolf> in such way that Jolla should modify their package | 14:40 |
| T4 | <locusf> one can only hope :) | 14:40 |
| T4 | <locusf> right now glacier is the only alternative homescreen that I know of | 14:41 |
| r0kk3rz | i suggest you talk to the jolla guys and get them on board | 14:41 |
| T4 | <akaWolf> so we can make wrapper, contribute it to Mer, so that Jolla will be forced to use that solution | 14:41 |
| T4 | <locusf> so making such a change would really require more than just one | 14:41 |
| T4 | <locusf> hahah | 14:41 |
| T4 | <locusf> Jolla controls mer :) | 14:41 |
| T4 | <akaWolf> @locusf [Jolla controls mer :)], =\ | 14:41 |
| T4 | <locusf> or well, the maintainers might not integrate it to it since Jolla says no | 14:42 |
| T4 | <locusf> and also Jolla isn't the only vendor that uses mer | 14:42 |
| T4 | <akaWolf> sounds sadly | 14:42 |
| r0kk3rz | all key mer people are jolla employees though | 14:42 |
| T4 | <locusf> welcome to nemo then :) | 14:43 |
| T4 | <akaWolf> but if we have no value to make such changes that we want | 14:43 |
| r0kk3rz | its not that sad, they're getting better at allowing non jolla contributions | 14:43 |
| T4 | <locusf> indeed | 14:43 |
| T4 | <locusf> but this is quite invasive IMO | 14:44 |
| r0kk3rz | yeah... | 14:44 |
| T4 | <akaWolf> who have control to Mer's servers? | 14:44 |
| T4 | <akaWolf> over* | 14:45 |
| T4 | <locusf> afaik lbt | 14:45 |
| T4 | <akaWolf> is he from Jolla? | 14:45 |
| T4 | <locusf> last I checked, yes | 14:45 |
| T4 | <locusf> dunno now though | 14:45 |
| T4 | <akaWolf> okay | 14:45 |
| T4 | <locusf> he's a proper fine chap though and understands the situation quite well | 14:46 |
| T4 | <akaWolf> I'm not sure if I can name Mer truly open source project due to the newly discovered circumstances... | 14:47 |
| r0kk3rz | hes still a jolla person | 14:47 |
| r0kk3rz | how is it not open source? | 14:47 |
| T4 | <locusf> the source is deffo open | 14:47 |
| T4 | <akaWolf> like Telegram | 14:47 |
| T4 | <akaWolf> it's open | 14:47 |
| T4 | <akaWolf> but going it's own way | 14:47 |
| T4 | <locusf> its just that the vendor for platform X doesn't want to integrate some changes to Mer to their platform | 14:48 |
| r0kk3rz | all open source projects usually have their own agenda | 14:48 |
| r0kk3rz | otherwise they probably wouldnt exist | 14:48 |
| T4 | <akaWolf> well, but if they are going in such way to forbid another UX (in our example) | 14:49 |
| r0kk3rz | they arent | 14:49 |
| T4 | <locusf> yeah | 14:49 |
| T4 | <locusf> they aren't at all | 14:49 |
| r0kk3rz | you can replace their lipstick with your own quite happily | 14:49 |
| T4 | <locusf> or installing nemo on j1 or other jolla devices | 14:49 |
| r0kk3rz | or possibly even kwin or phosh | 14:50 |
| T4 | <akaWolf> no, I mean if they will against home screen manager | 14:50 |
| T4 | <locusf> can be done but could void varranty :) | 14:50 |
| T4 | <akaWolf> this will be clearly policit decision | 14:50 |
| r0kk3rz | @akaWolf: you can make one, but you cant force jolla to use it | 14:50 |
| T4 | <akaWolf> yeah, I mean, if they will decline, it will clear for me... | 14:51 |
| T4 | <akaWolf> at least we should try :) | 14:52 |
| r0kk3rz | it depends how much you plan to butcher lipstick | 14:52 |
| r0kk3rz | really we could just install glacier homescreen to a different location | 14:52 |
| r0kk3rz | lipstick-glacier or something | 14:52 |
| T4 | <akaWolf> not so much: just instead of home screen start something like desktop manager | 14:53 |
| T4 | <locusf> .... | 14:53 |
| T4 | <locusf> WTF | 14:53 |
| T4 | <locusf> this isn't sddm | 14:53 |
| r0kk3rz | err | 14:53 |
| r0kk3rz | lipstick is the compositor | 14:53 |
| r0kk3rz | without that you have a blank screen | 14:54 |
| T4 | <akaWolf> ofc no, but if you look at Android, there are ability to start different launcher | 14:54 |
| r0kk3rz | yeah, and? | 14:54 |
| T4 | <locusf> which is still in the implementation side, in the same compositor | 14:55 |
| T4 | <akaWolf> at PC we have desktop manager | 14:55 |
| r0kk3rz | i dont see your point | 14:55 |
| T4 | <locusf> aand we have a club | 14:56 |
| T4 | <akaWolf> I mean at Mer platform there should be something similar | 14:56 |
| T4 | <akaWolf> @locusf [which is still in the implementation side, in …], is there really important? | 14:56 |
| T4 | <akaWolf> @locusf [which is still in the implementation side, in …], [Edit] is that really important? | 14:56 |
| T4 | <locusf> yes | 14:56 |
| T4 | <akaWolf> why? | 14:56 |
| r0kk3rz | yeah, thats going to need major surgery to lipstick | 14:56 |
| T4 | <locusf> since its just a shell in android | 14:56 |
| T4 | <locusf> you can decide what is displayed on the homescreen | 14:57 |
| T4 | <locusf> lipstick isn't that simple | 14:57 |
| T4 | <akaWolf> okay, at least we can make a simple manager, which reads text config from /etc | 14:57 |
| T4 | <akaWolf> for first iteration | 14:57 |
| T4 | <locusf> my forehead is blushing from this virtual facepalmin, gotta eat something | 14:58 |
| T4 | <akaWolf> what is wrong with that? | 14:58 |
| T4 | <samzn> Think of lipstick as the core of the windows shell, then glacier is the "explorer" | 14:58 |
| T4 | <samzn> It exposes the core components | 14:58 |
| T4 | <akaWolf> and still if different packages have the same binary, what is problem to make a simple wrapper, which decide, which one binary to start? | 15:00 |
| T4 | <akaWolf> I don't see any | 15:00 |
| r0kk3rz | you can do that if you want | 15:01 |
| T4 | <akaWolf> I understand that this is only point of view from system point of view, but what is wrong with another points? | 15:01 |
| T4 | <akaWolf> @r0kk3rz [you can do that if you want], I understand, but I want to make a correct decision according to overall architecture | 15:02 |
| r0kk3rz | what 'correct decision'? | 15:04 |
| r0kk3rz | this is open source, its a house of cards :) | 15:04 |
| T4 | <akaWolf> what can be a part of Mer | 15:04 |
| r0kk3rz | replace cards as you like, but the house might fall down | 15:05 |
| T4 | <akaWolf> 'correct decision' is making house more strong | 15:05 |
| r0kk3rz | it depends on how you want it to act | 15:08 |
| r0kk3rz | swapping one bin for another might leave you stuck | 15:08 |
| T4 | <akaWolf> @locusf said me that this approach isn't correct | 15:08 |
| T4 | <akaWolf> ofc it can be, since I did not read sources of lipstich yet | 15:09 |
| r0kk3rz | tbh the correct approach is to leave it alone :P | 15:09 |
| T4 | <akaWolf> I dont understand why | 15:09 |
| Leif_Erikson | Seems to be similar questions I have to understand the deployment of lipstick. | 15:10 |
| r0kk3rz | if it aint broke, dont fix it | 15:10 |
| Leif_Erikson | The background of my question is a convergence use case. The solution of Sentio and other for Android is an additional Launcher. I learned, that this is not possible. | 15:10 |
| Leif_Erikson | So we need an adaption of the system as soon an external screen and keyboard or a device like Superbook is connected. | 15:10 |
| T4 | <akaWolf> it's possible with some changes | 15:10 |
| T4 | <akaWolf> it's easy to say: you are wrong … but it's hard to explain, why | 15:12 |
| r0kk3rz | i'm not saying you're wrong | 15:12 |
| T4 | <akaWolf> locusf said | 15:12 |
| r0kk3rz | i expect it will be a lot of work to get lipstick to hotswap UXs with fallback | 15:14 |
| T4 | <akaWolf> why? we can choice, which UX to start before starting lipstick | 15:15 |
| T4 | <akaWolf> it will be first step | 15:15 |
| T4 | <akaWolf> that sounds logical for me | 15:15 |
| r0kk3rz | then like, do that? | 15:15 |
| T4 | <akaWolf> then start to make changes in lipstick to hotswap | 15:16 |
| r0kk3rz | i wouldnt bother | 15:16 |
| T4 | <akaWolf> so: … 0. rename /usr/bin/lipstick in glacier package … 1. make a simple wrapper, which reads from /etc, which one home screen to start … 2. make graphical UI to choice, which one home screen to start if there are many | 15:19 |
| r0kk3rz | you dont need anything in etc | 15:20 |
| Leif_Erikson | Is the intention to switch the UX on startup or while the device is running? | 15:20 |
| T4 | <akaWolf> but I want to specify which home to start | 15:20 |
| r0kk3rz | systemd can do that, just have two services | 15:21 |
| T4 | <akaWolf> @Leif_Erikson [Is the intention to switch the UX on startup o …], you can do that by different solutions: stop/start systemd services or reload some functions in lipstick | 15:22 |
| T4 | <akaWolf> we can first make simple solution based at restarting systemd service | 15:23 |
| T4 | <akaWolf> it can be done even from UI application | 15:23 |
| ol | Or you can several conflicting packages that provide the same binary file. You'll be able to install just one of them. | 15:23 |
| T4 | <akaWolf> like now, yeah | 15:23 |
| ol | That sounds like a viable solution. | 15:24 |
| T4 | <akaWolf> not in production with need to change UX | 15:24 |
| ol | No need to have configuration or a symlink in "/etc/alternatives". Just install a package that you need. | 15:24 |
| T4 | <akaWolf> That not user friendly | 15:25 |
| ol | Production? Change UX? Don't you find contradictory clauses here? | 15:25 |
| ol | User-friendly way will be to supply just one package in your distribution that just works. | 15:26 |
| T4 | <akaWolf> I just think this is the right direction to work on | 15:29 |
| r0kk3rz | so do it | 15:30 |
| T4 | <neochapay> Okay I buy Nexus 7 and will start work on tablet mode :))) | 15:30 |
| ol | Alternatively, you can have different packages providing different binaries and different systemd service files. You enable just one of these service files. Like gdm, kdm and sddm. | 15:32 |
| Leif_Erikson | For a poc for the technical feasibility of a convergence use case an app to switch the UX would be fine. For a productive system, the device should respond to a connected accessory. We need this poc, before we sign an official partnership with Jolla, because this is an invest. | 15:33 |
| r0kk3rz | lol | 15:34 |
| ol | Leif_Erikson: You don't need to switch compositing managers on the fly. Just make one compositing manager that can act both ways. | 15:34 |
| Leif_Erikson | ol: Sounds good | 15:35 |
| T4 | <neochapay> Oh...so much bla bla | 15:35 |
| *** ChanServ sets mode: +v T4 | 17:15 | |
| T4 | <meierrom> @akaWolf [we can abstract from systemd unit: one service …], Sounds reasonable to me. Discuss this with eg. @neochapay and @samzn. 👍 | 19:07 |
| T4 | <meierrom> @neochapay [Oh...so much bla bla], Please have patience. Not everybody has reached your level yet. 😁 😄 😄 | 19:15 |
| T4 | <akaWolf> devine level? :) | 19:18 |
| T4 | <akaWolf> [Edit] divine level? :) | 19:18 |
| T4 | <meierrom> @akaWolf [okay.. can I have both UX at a time?], Yes, you can. The best start is probably to get fully working sfos device. You can then install a few additional packages, which will switch the device from sfos ui to nemo/glacier. 😁 | 19:21 |
| T4 | <meierrom> @akaWolf [starting Jolla UX?], Many things are not documented yet. I suggest you play around with the device on your own as well. Learning by doing. 😁 | 19:31 |
| r0kk3rz | having fun? | 19:32 |
| T4 | <akaWolf> Yeah, I have Xperia X running under SFOS | 19:33 |
| T4 | <meierrom> @locusf [yeah why thats needed?], I think @akaWolf is looking for some kind of switcher between sfos ui and nemo/glacier. I must admit that this sounds rather cool. 😁 | 19:37 |
| T4 | <meierrom> @locusf [right now glacier is the only alternative home …], There is glacier manhattan, which looks better, IMHO. 😁 | 19:40 |
| T4 | <meierrom> @akaWolf [it would be handy to test Glacier UX], ... without breaking anything... 👍 | 19:41 |
| T4 | <meierrom> @akaWolf [that's doesn't look too handy], IMHO, handyness is not that important. More important is to know the steps to reverse the switch from sfos to nemo/glacier without being forced to flash the device. | 19:46 |
| T4 | <meierrom> @akaWolf [so we can make wrapper, contribute it to Mer, …], 'Jolla is mer' and it's not likely this will change anytime soon. Forcing something on Jolla isn't realistic nor does it make sense. Jolla is currently holding everything together. Not having Jolla anymore will result in: no mer, no sfos, no nemo, no glacier. 😕 | 19:55 |
| T4 | <meierrom> @akaWolf [is he from Jolla?], Yes, he's working for Jolla since they started. He's also a strong supporter of the open source community. 😁 | 20:01 |
| T4 | <meierrom> @akaWolf [I'm not sure if I can name Mer truly open sour …], Mer is truly OSS. There's no doubt about that. 👍 | 20:03 |
| T4 | <meierrom> @akaWolf [no, I mean if they will against home screen ma …], Their focus is on sfos ui. Why should they invest resources on something that is of no use to them? That's where you can come in and develop a patch to switch from one ui to another. 😁 | 20:09 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
