Monday, 2018-09-24

*** ChanServ sets mode: +v T405:23
Leif_EriksonI can build the glacier home and lipstick example project. But I  can’t deploy them, yet.08:29
Leif_EriksonThe 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_EriksonThe error message of the lipstick example project is the following:08:30
Leif_EriksonError on file "/home/deploy/installroot/usr/share/applications/*.desktop": No such file or directory08:30
Leif_EriksonI’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
NeoChapayLeif_Erikson: you can't build master of glacier home in sdk08:30
Leif_Erikson1. What has to be configured in the .desktop file?08:30
Leif_Erikson2. 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_EriksonIf 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_EriksonNeoChapay: Why not? The build engine includes the full platform sdk08:31
NeoChapayLeif_Erikson: it's rpm problem...i fix it in devel branch08:32
Leif_EriksonThe build was successful for the two projects08:32
Leif_EriksonNeoChapay: I will switch to the devel branch then08:33
NeoChapayLeif_Erikson: i move installing desktop and other files from .spec file to pro and all is well08:33
NeoChapayLeif_Erikson: yea...devel branch in developming08:34
r0kk3rznew sdk has new rpm, so it might be ok now08:52
T4<akaWolf> .spec generated by spectacle from .yaml08:55
T4<akaWolf> Btw, @neochapay , correct case is to edit yaml08:57
r0kk3rzcorrect case is to nuke the yaml from orbit :P08:57
T4<akaWolf> Why?08:58
r0kk3rzbecause spectacle is stupid08:58
r0kk3rznot even jolla uses it anymore08:58
r0kk3rznobody maintains it08:58
T4<akaWolf> It have about 1k commits08:59
r0kk3rzim not even sure what problem its supposed to solve09:00
T4<akaWolf> What was purpose of that scheme?09:00
T4<akaWolf> Hmm09:00
r0kk3rzmaybe its a slightly easier to parse version of the spec for some tool09:00
T4<neochapay> @akaWolf [Btw, @neochapay , correct case is to edit yaml], Don't use yaml09:02
T4<akaWolf> spec isnt better09:02
Leif_EriksonUsing a .yaml file is the recommended way for deployment:
r0kk3rzno it isnt :P09:03
T4<neochapay> @akaWolf [spec isnt better], Spec is awesome!09:04
Leif_EriksonUsing a .yaml file is the recommended way for deployment:
T4<neochapay> @Leif_Erikson [Using a .yaml file is the recommended way for …], We. Are not Jolla don't forget it :)))09:05
Leif_EriksonQuote: "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
r0kk3rzfine, ignore people with actual experience, read some outdated document instead09:05
r0kk3rzyou're asking for help and then arguing about what we tell you09:07
T4<faenil> Relax people, relax :)09:08
T4<neochapay> (Sticker, 512x512)
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_Eriksonr0kk3rz: 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 redhat09:10
r0kk3rzused all over the place09:10
r0kk3rzyou dont need terminal commands, you can just deploy it from the qt creator09:12
r0kk3rzyou dont need a .yaml file to do that09:12
Leif_Eriksonr0kk3rz: Good news, but how?09:13
T4<neochapay> mb2 build ?09:13
r0kk3rz'deploy as rpm' dun dun dun09:13
r0kk3rzi wonder what that does09:13
T4<akaWolf> Too many time was spent for that spectacle. I think, should be real reason09:14
Leif_EriksonWe 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_EriksonIs 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 rpm09:17
Leif_EriksonT4: Sure I would be happy to write a tutorial in the Wiki as soon I have the solution.09:17
r0kk3rzLeif_Erikson: everything is deployed as rpm, there is no distinction between 'apps' and everything else09:23
Leif_EriksonT4: 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_EriksonLauncers are defined within the AndroidManifest.xml with the line <category android:name="android.intent.category.HOME" />09:37
Leif_EriksonIs there something similar to Nemo Mobile respectively Sailfish?09:37
Leif_EriksonMaybe is the .desctop file? It's also still an open question for me, how to write this file.09:38
r0kk3rzyep this isnt android, knowledge of it wont help you here09:39
Leif_EriksonFor Android there is also the category <category android:name="android.intent.category.LAUCNHER" />09:39
Leif_Eriksonr0kk3rz: 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_Erikson1. How do I have to configure a lipstick implementation as the system UI (home screen, launcher, etc)?09:42
r0kk3rzdon't try and map android concepts onto things that arent android :P you'll confuse yourself09:42
Leif_Erikson2. Is it possible to deploy a lipstick implementation, that is visible like an app to switch between implementations like in Android?09:43
r0kk3rzall you need to do is deploy lipstick and run it09:44
r0kk3rzlipstick is more analogous to surfaceflinger on android, not merely a homescreen ux09:44
Leif_Eriksonr0kk3rz: 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
r0kk3rzapps are installed into a different place, thats pretty much it09:46
r0kk3rzthe launcher icon is the .desktop file09:46
Leif_EriksonAnd how is it defined in the project, that a lipstick implementation is installed into a different place?09:47
r0kk3rzin the spec09:48
NeoChapayanybody tryed windowed mode patch ?09:54
NeoChapay....okay....anybody trying devel branch ^_^ ?09:54
T4<akaWolf> with which envir?09:58
Leif_Eriksonr0kk3rz: So the OS expects an implementation in a specific directory? This is %{_bindir}/lipstick in the .specc file of Glacier?10:04
r0kk3rznot really10:05
r0kk3rzit gets started by systemd using the .service file10:05
T4<akaWolf> .spec is for building rpm10:07
r0kk3rzit is, but it does define where stuff gets installed10:12
T4<akaWolf> ofc =)10:17
T4<akaWolf> like any other description of the package10: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 services11: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 here11:03
Leif_EriksonSo 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_EriksonIn 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_Eriksonr0kk3rz: The service file defines the location of the installation?11:17
Leif_EriksonAgain: How does the system know, that it use the lipstick implementation? Does the installation modifies a system configuration?11:20
Leif_EriksonIt looks like that way, if I read the following line in the .service file of the Glacier project:11:20
r0kk3rzthe service file tells systemd what to run11:22
r0kk3rzyou only need a .pro and a .spec11:23
r0kk3rzthats not too much overhead11:24
Leif_EriksonDo 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 yaml12:00
r0kk3rzLeif_Erikson: just remove yaml from pro and delete file12:10
T4<akaWolf> r0kk3rz, what did especial in SDK?12:10
T4<akaWolf> I mean what different in SFOS SDK flow from common generic Qt project flow13:01
T4<akaWolf> what is for yaml13:02
r0kk3rzno idea, i cant see any benefit to it13:02
r0kk3rzlearning how to read and write spec files is much more useful13:03
olRPM 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
olThe 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
olA ".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 way14:02
T4<akaWolf> in the internet14:02
T4<akaWolf> no need to describe basics of package management here I guess14: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
T4<akaWolf> so if QT_QUICK_CONTROLS_STYLE is unset, what is happen?14:26
T4<akaWolf> starting Jolla UX?14:26
T4<locusf> no14:27
r0kk3rzprobably not, it would use the qt theme14:27
T4<locusf> its just going to look bad14:27
T4<akaWolf> hmm14:28
T4<akaWolf> but how to start Glacier then?14:28
r0kk3rzwhat do you mean 'start glacier'14:28
r0kk3rzyou mean the homescreen?14:28
T4<akaWolf> right14:29
r0kk3rzfollow the instructions14:29
T4<akaWolf> I want to understand what is happening when I follow14:30
T4<locusf> its /usr/bin/lipstick14:30
T4<akaWolf> okay.. can I have both UX at a time?14:30
T4<locusf> which UX?14:31
T4<locusf> jolla, no14:31
T4<akaWolf> Glacier and Jolla14:31
T4<locusf> because it overwrites the binary14:31
T4<locusf> though you can copy it as backup14:31
T4<akaWolf> hm14:31
T4<locusf> lipstick is just a library to make a homescreen with14:31
T4<akaWolf> okay I see14:31
T4<locusf> and then glacier is just an implementing software for it14:32
T4<locusf> or jolla14:32
T4<akaWolf> why glacier and jolla write binary /usr/bin/lipstick then14:32
T4<akaWolf> if lipstick is just a library14:32
T4<locusf> it doesn't have to be like that :)14:32
T4<locusf> its just easier to have a single systemd user service14:33
T4<akaWolf> we can abstract from systemd unit: one service, which makes decision at config, what to start14:33
T4<locusf> no14:33
T4<locusf> as you can see its baked in to c++14:34
T4<locusf> HomeApplication is what lipstick provides14:34
T4<locusf> glacier helps with the qml portion thats presented as the lipstick compositor14:34
T4<locusf> its responsibility is to manage windows, show notifications etc14: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 sta14:37
T4rt corresponding home14:37
T4<locusf> sure14:37
T4<akaWolf> so?14:37
T4<locusf> yeah why thats needed?14:37
T4<locusf> since you can backup the binary14:38
T4<locusf> and then rename it back if you want to do something else14:38
T4<akaWolf> @locusf [yeah why thats needed?], well I dont want to hurt my device, for example14:38
T4<locusf> restart lipstick service14:38
T4<akaWolf> that's doesn't look too handy14:38
T4<akaWolf> better to have it in such way as I described14:38
T4<akaWolf> it would be handy to test Glacier UX14:39
r0kk3rzyou can do whatever you like, its your device14:39
T4<locusf> yeah14:39
T4<akaWolf> I cant change the name of jolla's home...14:39
r0kk3rzneither can we14:39
T4<akaWolf> but we can change main service units14:40
T4<akaWolf> in such way that Jolla should modify their package14:40
T4<locusf> one can only hope :)14:40
T4<locusf> right now glacier is the only alternative homescreen that I know of14:41
r0kk3rzi suggest you talk to the jolla guys and get them on board14:41
T4<akaWolf> so we can make wrapper, contribute it to Mer, so that Jolla will be forced to use that solution14:41
T4<locusf> so making such a change would really require more than just one14:41
T4<locusf> hahah14: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 no14:42
T4<locusf> and also Jolla isn't the only vendor that uses mer14:42
T4<akaWolf> sounds sadly14:42
r0kk3rzall key mer people are jolla employees though14:42
T4<locusf> welcome to nemo then :)14:43
T4<akaWolf> but if we have no value to make such changes that we want14:43
r0kk3rzits not that sad, they're getting better at allowing non jolla contributions14:43
T4<locusf> indeed14:43
T4<locusf> but this is quite invasive IMO14:44
T4<akaWolf> who have control to Mer's servers?14:44
T4<akaWolf> over*14:45
T4<locusf> afaik lbt14:45
T4<akaWolf> is he from Jolla?14:45
T4<locusf> last I checked, yes14:45
T4<locusf> dunno now though14:45
T4<akaWolf> okay14:45
T4<locusf> he's a proper fine chap though and understands the situation quite well14:46
T4<akaWolf> I'm not sure if I can name Mer truly open source project due to the newly discovered circumstances...14:47
r0kk3rzhes still a jolla person14:47
r0kk3rzhow is it not open source?14:47
T4<locusf> the source is deffo open14:47
T4<akaWolf> like Telegram14:47
T4<akaWolf> it's open14:47
T4<akaWolf> but going it's own way14:47
T4<locusf> its just that the vendor for platform X doesn't want to integrate some changes to Mer to their platform14:48
r0kk3rzall open source projects usually have their own agenda14:48
r0kk3rzotherwise they probably wouldnt exist14:48
T4<akaWolf> well, but if they are going in such way to forbid another UX (in our example)14:49
r0kk3rzthey arent14:49
T4<locusf> yeah14:49
T4<locusf> they aren't at all14:49
r0kk3rzyou can replace their lipstick with your own quite happily14:49
T4<locusf> or installing nemo on j1 or other jolla devices14:49
r0kk3rzor possibly even kwin or phosh14:50
T4<akaWolf> no, I mean if they will against home screen manager14:50
T4<locusf> can be done but could void varranty :)14:50
T4<akaWolf> this will be clearly policit decision14:50
r0kk3rz@akaWolf: you can make one, but you cant force jolla to use it14: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
r0kk3rzit depends how much you plan to butcher lipstick14:52
r0kk3rzreally we could just install glacier homescreen to a different location14:52
r0kk3rzlipstick-glacier or something14:52
T4<akaWolf> not so much: just instead of home screen start something like desktop manager14:53
T4<locusf> ....14:53
T4<locusf> WTF14:53
T4<locusf> this isn't sddm14:53
r0kk3rzlipstick is the compositor14:53
r0kk3rzwithout that you have a blank screen14:54
T4<akaWolf> ofc no, but if you look at Android, there are ability to start different launcher14:54
r0kk3rzyeah, and?14:54
T4<locusf> which is still in the implementation side, in the same compositor14:55
T4<akaWolf> at PC we have desktop manager14:55
r0kk3rzi dont see your point14:55
T4<locusf> aand we have a club14:56
T4<akaWolf> I mean at Mer platform there should be something similar14: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> yes14:56
T4<akaWolf> why?14:56
r0kk3rzyeah, thats going to need major surgery to lipstick14:56
T4<locusf> since its just a shell in android14:56
T4<locusf> you can decide what is displayed on the homescreen14:57
T4<locusf> lipstick isn't that simple14:57
T4<akaWolf> okay, at least we can make a simple manager, which reads text config from /etc14:57
T4<akaWolf> for first iteration14:57
T4<locusf> my forehead is blushing from this virtual facepalmin, gotta eat something14: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 components14: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 any15:00
r0kk3rzyou can do that if you want15: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 architecture15:02
r0kk3rzwhat 'correct decision'?15:04
r0kk3rzthis is open source, its a house of cards :)15:04
T4<akaWolf> what can be a part of Mer15:04
r0kk3rzreplace cards as you like, but the house might fall down15:05
T4<akaWolf> 'correct decision' is making house more strong15:05
r0kk3rzit depends on how you want it to act15:08
r0kk3rzswapping one bin for another might leave you stuck15:08
T4<akaWolf> @locusf said me that this approach isn't correct15:08
T4<akaWolf> ofc it can be, since I did not read sources of lipstich yet15:09
r0kk3rztbh the correct approach is to leave it alone :P15:09
T4<akaWolf> I dont understand why15:09
Leif_EriksonSeems to be similar questions I have to understand the deployment of lipstick.15:10
r0kk3rzif it aint broke, dont fix it15:10
Leif_EriksonThe 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_EriksonSo 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 changes15:10
T4<akaWolf> it's easy to say: you are wrong … but it's hard to explain, why15:12
r0kk3rzi'm not saying you're wrong15:12
T4<akaWolf> locusf said15:12
r0kk3rzi expect it will be a lot of work to get lipstick to hotswap UXs with fallback15:14
T4<akaWolf> why? we can choice, which UX to start before starting lipstick15:15
T4<akaWolf> it will be first step15:15
T4<akaWolf> that sounds logical for me15:15
r0kk3rzthen like, do that?15:15
T4<akaWolf> then start to make changes in lipstick to hotswap15:16
r0kk3rzi wouldnt bother15: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 many15:19
r0kk3rzyou dont need anything in etc15:20
Leif_EriksonIs 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 start15:20
r0kk3rzsystemd can do that, just have two services15: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 lipstick15:22
T4<akaWolf> we can first make simple solution based at restarting systemd service15:23
T4<akaWolf> it can be done even from UI application15:23
olOr 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, yeah15:23
olThat sounds like a viable solution.15:24
T4<akaWolf> not in production with need to change UX15:24
olNo need to have configuration or a symlink in "/etc/alternatives". Just install a package that you need.15:24
T4<akaWolf> That not user friendly15:25
olProduction? Change UX? Don't you find contradictory clauses here?15:25
olUser-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 on15:29
r0kk3rzso do it15:30
T4<neochapay> Okay I buy Nexus 7 and will start work on tablet mode :)))15:30
olAlternatively, 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_EriksonFor 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
olLeif_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_Eriksonol: Sounds good15:35
T4<neochapay> much bla bla15:35
*** ChanServ sets mode: +v T417: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 [ 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
r0kk3rzhaving fun?19:32
T4<akaWolf> Yeah, I have Xperia X running under SFOS19: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 2.14.0 by Marius Gedminas - find it at!