Re: [SailfishDevel] Flatpak for Sailfish
On Mon, Mar 23, 2020 at 11:51 PM Tone Kastlunger wrote: > Obvious things first: timers are whako? > > Morning, and how would I test that? Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Obvious things first: timers are whako? On Sat, Feb 22, 2020 at 5:11 PM rinigus wrote: > Hi, > > I would like to ask for help regarding animation rendering from hybris/qt > gurus. In Flatpak apps, when running QT animation, such as spinning busy > indicator, I am getting general slow down of the applications. Slowdown can > be felt by trying to pull drawers, slower web pages download, and other > similar effects. This can be remedied by setting QSG_RENDER_LOOP=basic . > > When I asked for help at KDE, originally just suspecting something odd in > BusyIndicator, I was pointed to possibly wrong vsync. According to > QSG_INFO=1, its set to 16.67 ms - 60Hz, as expected for embedded device. > Corresponding data dump is below. > > I haven't noticed any difference between QSG_INFO as reported by SFOS app > or app running from Flatpak. Same slowdown is for Qt 5.12 and 5.14. Any > ideas on how to fix it instead of using QSG_RENDER_LOOP=basic? > > Feel free to suggest fixes ask questions on #sfos-devel - I just thought > its better to write up the issue here than to paste it on IRC. > > Cheers, > > Rinigus > > > > [D] unknown:0 - threaded render loop > [D] unknown:0 - Using sg animation driver > [D] unknown:0 - Animation Driver: using vsync: 16.67 ms > [D] unknown:0 - opengl texture atlas dimensions: 2048x4096 > [D] unknown:0 - R/G/B/A Buffers: 5 6 5 0 > [D] unknown:0 - Depth Buffer: 24 > [D] unknown:0 - Stencil Buffer:8 > [D] unknown:0 - Samples: 0 > [D] unknown:0 - GL_VENDOR: Qualcomm > [D] unknown:0 - GL_RENDERER: Adreno (TM) 630 > [D] unknown:0 - GL_VERSION:OpenGL ES 2.0 (OpenGL ES 3.2 V@324.0 > (GIT@f4471f2, I3387004788) > [D] unknown:0 - GL_EXTENSIONS: GL_AMD_compressed_ATC_texture > GL_ANDROID_extension_pack_es31a > GL_ARM_shader_framebuffer_fetch_depth_stencil GL_EXT_EGL_image_array > GL_EXT_EGL_image_storage GL_EXT_YUV_target GL_EXT_blend_func_extended > GL_EXT_blit_framebuffer_params GL_EXT_buffer_storage GL_EXT_clip_control > GL_EXT_clip_cull_distance GL_EXT_color_buffer_float > GL_EXT_color_buffer_half_float GL_EXT_copy_image GL_EXT_debug_label > GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query > GL_EXT_draw_buffers_indexed GL_EXT_external_buffer GL_EXT_geometry_shader > GL_EXT_gpu_shader5 GL_EXT_memory_object GL_EXT_memory_object_fd > GL_EXT_multisampled_render_to_texture > GL_EXT_multisampled_render_to_texture2 GL_EXT_primitive_bounding_box > GL_EXT_protected_textures GL_EXT_robustness GL_EXT_sRGB > GL_EXT_sRGB_write_control GL_EXT_shader_framebuffer_fetch > GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers > GL_EXT_tessellation_shader GL_EXT_texture_border_clamp > GL_EXT_texture_buffer GL_EXT_texture_cube_map_array > GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA > GL_EXT_texture_format_sRGB_override GL_EXT_texture_norm16 > GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode > GL_EXT_texture_type_2_10_10_10_REV GL_KHR_blend_equation_advanced > GL_KHR_blend_equation_advanced_coherent GL_KHR_debug GL_KHR_no_error > GL_KHR_robust_buffer_access_behavior GL_KHR_texture_compression_astc_hdr > GL_KHR_texture_compression_astc_ldr > GL_NV_shader_noperspective_interpolation GL_OES_EGL_image > GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync > GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth_texture > GL_OES_depth_texture_cube_map GL_OES_element_index_uint > GL_OES_framebuffer_object GL_OES_get_program_binary > GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_sample_shading > GL_OES_sample_variables GL_OES_shader_image_atomic > GL_OES_shader_multisample_interpolation GL_OES_standard_derivatives > GL_OES_surfaceless_context GL_OES_texture_3D > GL_OES_texture_compression_astc GL_OES_texture_float > GL_OES_texture_float_linear GL_OES_texture_half_float > GL_OES_texture_half_float_linear GL_OES_texture_npot > GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array > GL_OES_vertex_array_object GL_OES_vertex_half_float GL_OVR_multiview > GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture > GL_QCOM_alpha_test GL_QCOM_shader_framebuffer_fetch_noncoherent > GL_QCOM_texture_foveated GL_QCOM_tiled_rendering > [D] unknown:0 - Max Texture Size: 16384 > >> ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I would like to ask for help regarding animation rendering from hybris/qt gurus. In Flatpak apps, when running QT animation, such as spinning busy indicator, I am getting general slow down of the applications. Slowdown can be felt by trying to pull drawers, slower web pages download, and other similar effects. This can be remedied by setting QSG_RENDER_LOOP=basic . When I asked for help at KDE, originally just suspecting something odd in BusyIndicator, I was pointed to possibly wrong vsync. According to QSG_INFO=1, its set to 16.67 ms - 60Hz, as expected for embedded device. Corresponding data dump is below. I haven't noticed any difference between QSG_INFO as reported by SFOS app or app running from Flatpak. Same slowdown is for Qt 5.12 and 5.14. Any ideas on how to fix it instead of using QSG_RENDER_LOOP=basic? Feel free to suggest fixes ask questions on #sfos-devel - I just thought its better to write up the issue here than to paste it on IRC. Cheers, Rinigus [D] unknown:0 - threaded render loop [D] unknown:0 - Using sg animation driver [D] unknown:0 - Animation Driver: using vsync: 16.67 ms [D] unknown:0 - opengl texture atlas dimensions: 2048x4096 [D] unknown:0 - R/G/B/A Buffers: 5 6 5 0 [D] unknown:0 - Depth Buffer: 24 [D] unknown:0 - Stencil Buffer:8 [D] unknown:0 - Samples: 0 [D] unknown:0 - GL_VENDOR: Qualcomm [D] unknown:0 - GL_RENDERER: Adreno (TM) 630 [D] unknown:0 - GL_VERSION:OpenGL ES 2.0 (OpenGL ES 3.2 V@324.0 (GIT@f4471f2, I3387004788) [D] unknown:0 - GL_EXTENSIONS: GL_AMD_compressed_ATC_texture GL_ANDROID_extension_pack_es31a GL_ARM_shader_framebuffer_fetch_depth_stencil GL_EXT_EGL_image_array GL_EXT_EGL_image_storage GL_EXT_YUV_target GL_EXT_blend_func_extended GL_EXT_blit_framebuffer_params GL_EXT_buffer_storage GL_EXT_clip_control GL_EXT_clip_cull_distance GL_EXT_color_buffer_float GL_EXT_color_buffer_half_float GL_EXT_copy_image GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_discard_framebuffer GL_EXT_disjoint_timer_query GL_EXT_draw_buffers_indexed GL_EXT_external_buffer GL_EXT_geometry_shader GL_EXT_gpu_shader5 GL_EXT_memory_object GL_EXT_memory_object_fd GL_EXT_multisampled_render_to_texture GL_EXT_multisampled_render_to_texture2 GL_EXT_primitive_bounding_box GL_EXT_protected_textures GL_EXT_robustness GL_EXT_sRGB GL_EXT_sRGB_write_control GL_EXT_shader_framebuffer_fetch GL_EXT_shader_io_blocks GL_EXT_shader_non_constant_global_initializers GL_EXT_tessellation_shader GL_EXT_texture_border_clamp GL_EXT_texture_buffer GL_EXT_texture_cube_map_array GL_EXT_texture_filter_anisotropic GL_EXT_texture_format_BGRA GL_EXT_texture_format_sRGB_override GL_EXT_texture_norm16 GL_EXT_texture_sRGB_R8 GL_EXT_texture_sRGB_decode GL_EXT_texture_type_2_10_10_10_REV GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent GL_KHR_debug GL_KHR_no_error GL_KHR_robust_buffer_access_behavior GL_KHR_texture_compression_astc_hdr GL_KHR_texture_compression_astc_ldr GL_NV_shader_noperspective_interpolation GL_OES_EGL_image GL_OES_EGL_image_external GL_OES_EGL_image_external_essl3 GL_OES_EGL_sync GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_depth_texture GL_OES_depth_texture_cube_map GL_OES_element_index_uint GL_OES_framebuffer_object GL_OES_get_program_binary GL_OES_packed_depth_stencil GL_OES_rgb8_rgba8 GL_OES_sample_shading GL_OES_sample_variables GL_OES_shader_image_atomic GL_OES_shader_multisample_interpolation GL_OES_standard_derivatives GL_OES_surfaceless_context GL_OES_texture_3D GL_OES_texture_compression_astc GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_texture_stencil8 GL_OES_texture_storage_multisample_2d_array GL_OES_vertex_array_object GL_OES_vertex_half_float GL_OVR_multiview GL_OVR_multiview2 GL_OVR_multiview_multisampled_render_to_texture GL_QCOM_alpha_test GL_QCOM_shader_framebuffer_fetch_noncoherent GL_QCOM_texture_foveated GL_QCOM_tiled_rendering [D] unknown:0 - Max Texture Size: 16384 > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, just one more comment - I would expect Lipstick to follow the specified standards. When we have an option to specify `X-Nemo-Single-Instance=no`, it should be respected. Especially, when the fix is known and involves one-liner. Turned out that there is an old issue filed regarding it at https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ (mine is at https://together.jolla.com/question/221851/x-nemo-single-instanceno-is-not-respected/ ). In context of Flatpak runner, that one-liner fix makes it usable. Apps open as expected, with visual animation as it should be. There is responsibility on user not to start multiple copies of the same app (unless it supports it), but that's way better than having limitation on a single app or using some weird hack with unique executable scripts. So, I would like to ask to add the fix to Lipstick as distributed by Jolla. Regarding DBus activation (thanks for suggesting it!): not sure how well would it work. Would have to wrap a head around possible scenarios in launching sequence as well as start reading again 'bout it. Cheers, Rinigus On Tue, Jan 28, 2020 at 5:07 PM rinigus wrote: > Hi, > > sounds a bit like over-engineering, but maybe dbus service will be needed > unless we can utilize Lipstick handling of the windows. > > Cheers, > > Rinigus > > On Tue, Jan 28, 2020 at 3:38 PM Андрей Кожевников > wrote: > >> what if you try to remove Exec from desktop file and will handle launch >> only via dbus service? single dbus service will start applications. >> >> вт, 28 янв. 2020 г. в 01:11, Dietmar Schwertberger < >> maill...@schwertberger.de>: >> >>> Hi! >>> >>> Single instance handling has always been broken for Sailfish OS 3. >>> >>> Not even different .desktop files with different Exec entries like these >>> are working, as they are probably both interpreted as "python3": >>> >>> Exec=python3 /path/to/application/app1.pyExec=python3 >>> /path/to/application/app2.py >>> >>> See >>> https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ >>> >>> >>> (Fortunately for the Python applications there's a workaround: start >>> both apps within a second or so...) >>> >>> Regards, >>> >>> Dietmar >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, sounds a bit like over-engineering, but maybe dbus service will be needed unless we can utilize Lipstick handling of the windows. Cheers, Rinigus On Tue, Jan 28, 2020 at 3:38 PM Андрей Кожевников wrote: > what if you try to remove Exec from desktop file and will handle launch > only via dbus service? single dbus service will start applications. > > вт, 28 янв. 2020 г. в 01:11, Dietmar Schwertberger < > maill...@schwertberger.de>: > >> Hi! >> >> Single instance handling has always been broken for Sailfish OS 3. >> >> Not even different .desktop files with different Exec entries like these >> are working, as they are probably both interpreted as "python3": >> >> Exec=python3 /path/to/application/app1.pyExec=python3 >> /path/to/application/app2.py >> >> See >> https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ >> >> >> (Fortunately for the Python applications there's a workaround: start both >> apps within a second or so...) >> >> Regards, >> >> Dietmar >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
what if you try to remove Exec from desktop file and will handle launch only via dbus service? single dbus service will start applications. вт, 28 янв. 2020 г. в 01:11, Dietmar Schwertberger < maill...@schwertberger.de>: > Hi! > > Single instance handling has always been broken for Sailfish OS 3. > > Not even different .desktop files with different Exec entries like these > are working, as they are probably both interpreted as "python3": > > Exec=python3 /path/to/application/app1.pyExec=python3 > /path/to/application/app2.py > > See > https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ > > > (Fortunately for the Python applications there's a workaround: start both > apps within a second or so...) > > Regards, > > Dietmar > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi! Single instance handling has always been broken for Sailfish OS 3. Not even different .desktop files with different Exec entries like these are working, as they are probably both interpreted as "python3": |Exec=python3 /path/to/application/app1.py | ||Exec=python3 /path/to/application/app2.py| | See https://together.jolla.com/question/193960/problem-with-excec-and-single-instance-in-desktop-files-on-sailfish-os-3/ (Fortunately for the Python applications there's a workaround: start both apps within a second or so...) Regards, Dietmar ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I am currently having issues with running multiple flatpak applications under Lipstick. Flatpak apps are started through a wrapper - flatpak-runner which has multiple functions * provide wayland compositor for flatpak app * set its environment to ensure that libhybris gl is used * forward device orientation and assist with maliit plugin interaction In addition, flatpak-runner is registered as a desktop app as it provides * GUI for adjusting flatpak apps environment * creates / syncs gl extension * generates desktop files for flatpak apps In practice, to run flatpak application, I am using command flatpak-runner flatpak-app-id. And that's where things are getting out of hand. Just using as it is, Lipstick is happy to detect that it already has one instance running (if it has) and switches to that. Which, in practice, limits you to one app in a time as single-instance keyword is not respected ( https://together.jolla.com/question/221851/x-nemo-single-instanceno-is-not-respected/ ). Ideally, though, as pointed by abranson this morning, we would like to have some ID to detect when Flatpak app is started and act accordingly. Something like it is done for Android apps in copyright protected but partially human readable Jolla codes. Each Flatpak desktop file has X-Flatpak carried around to identify its ID, maybe that can be used. Currently, I have ugly workaround by generating unique script, using it as Exec in desktop and starting apps that way. Few issues with this approach - Lipstick still has no clue if the app is already running and shows spinning-disk-small-card on active apps already after the app has been started. In addition, it will happily start a new one if requested. Workaround available at https://github.com/sailfishos-flatpak/flatpak-runner/tree/lipstick-hack . I presume it requires some better support from Lipstick part or somehow getting around it differently. Question is in how interested others and official-sailors are in getting it done and pushing for wider Flatpak support. Cheers, Rinigus On Mon, Jan 13, 2020 at 3:33 PM rinigus wrote: > Hi, > > as the holidays are over, I wonder if someone could look into libhybris > patch https://github.com/libhybris/libhybris/pull/433 . > > As for keyboard support in Flatpak applications, I will ask for adding it > as an extension for KDE runtime. For now, we have ugly solution with Maliit > plugin for Flatpak packaged as RPM (flatpak-maliit-plugin-qt) and mounting > it into the container by flatpak-runner. Good part in this solution is that > the applications can be used as they are - no recompilation and no editing > of their manifests is needed. > > Best wishes, > > Rinigus > >> ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, as the holidays are over, I wonder if someone could look into libhybris patch https://github.com/libhybris/libhybris/pull/433 . As for keyboard support in Flatpak applications, I will ask for adding it as an extension for KDE runtime. For now, we have ugly solution with Maliit plugin for Flatpak packaged as RPM (flatpak-maliit-plugin-qt) and mounting it into the container by flatpak-runner. Good part in this solution is that the applications can be used as they are - no recompilation and no editing of their manifests is needed. Best wishes, Rinigus > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I finished the first version of support for Maliit keyboard in Qt apps inside Flatpak. It required, in the end, separate communication channel via dbus p2p between maliit plugin inside Flatpak container and Sailfish host (flatpak-runner) to assist the plugin by providing info regarding screen rotation and active state of the app. Code is in Github project (maliit-framework and flatpak-runner). I have also added small example on how to package Flatpak app using it under https://github.com/sailfishos-flatpak/example-apps . Now would have to figure out how to avoid the separate packaging and implant maliit plugin into Flatpak container. Cheers, Rinigus On Thu, Jan 9, 2020 at 9:11 AM rinigus wrote: > Morning, > > I've got SFOS keyboard triggered from Flatpak app by planting in Maliit > input context plugin into it. Had to drop compensation for keyboard > rectangle inside Flatpak as it was compensated twice (once in SFOS and once > in Flatpak) leading to large empty area above the keyboard. > > Currently, keyboard is stuck in portrait mode and doesn't know much about > app being minimized. As a result, while app is rotating in response to the > screen rotation, keyboard gets stuck in portrait. In addition, if you open > keyboard in Flatpak, minimize the app, move to some other SFOS app, you'll > get open keyboard with the text prediction still pointing towards Flatpak > app context. This is not surprising as orientation and focus are set by the > plugin and it just doesn't have data to work with. So, I plan to write > small dbus server/client to pass these data from flatpak-runner (host of > flatpak apps) to Maliit plugin. In the end, we will have special version of > the plugin oriented towards running inside Flatpaks, but that should be OK. > > Tried last night to pass orientation by setting Wayland's server > setScreenOrientation ( > https://git.sailfishos.org/mer-core/qtwayland/blob/master/src/compositor/compositor_api/waylandcompositor.h#L96), > but that didn't help and the plugin was not getting any signals from > qGuiApp->primaryScreen. So, that shortcut didn't work... > > All in all, we are getting there. > > Cheers, > > Rinigus > > On Tue, Jan 7, 2020 at 12:03 PM rinigus wrote: > >> Thanks! Let's see how it will work in practice. I'll report back >> after the tests. >> >> Rinigus >> >> On Tue, Jan 7, 2020 at 11:59 AM Pekka Vuorela >> wrote: >> >>> On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote: >>> > Pekka, >>> > >>> > thanks for the swift reply! >>> > >>> > >>> > > > - is SFOS keyboard drawn by Lipstick? >>> > > >>> > > Keyboard running in its own process, maliit-server. >>> > >>> > But something is drawing it on the screen via QML. Is that the server >>> > and Lipstick just making space for it? If it is then that would fit >>> > with such separation perfectly. >>> >>> Maliit-server acts as a host for input plugins, and Jolla-keyboard >>> implements such and has the qml parts. The content is drawn in a >>> separate window, and Lipstick handles the window composition. >>> >>> Maliit passes the used keyboard area to application via the qt input >>> plugin so the app knows which area to avoid for active content, and >>> maliit also sets the window properties so Lipstick knows which area of >>> the window should get mouse events. >>> >>> >>> >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Morning, I've got SFOS keyboard triggered from Flatpak app by planting in Maliit input context plugin into it. Had to drop compensation for keyboard rectangle inside Flatpak as it was compensated twice (once in SFOS and once in Flatpak) leading to large empty area above the keyboard. Currently, keyboard is stuck in portrait mode and doesn't know much about app being minimized. As a result, while app is rotating in response to the screen rotation, keyboard gets stuck in portrait. In addition, if you open keyboard in Flatpak, minimize the app, move to some other SFOS app, you'll get open keyboard with the text prediction still pointing towards Flatpak app context. This is not surprising as orientation and focus are set by the plugin and it just doesn't have data to work with. So, I plan to write small dbus server/client to pass these data from flatpak-runner (host of flatpak apps) to Maliit plugin. In the end, we will have special version of the plugin oriented towards running inside Flatpaks, but that should be OK. Tried last night to pass orientation by setting Wayland's server setScreenOrientation ( https://git.sailfishos.org/mer-core/qtwayland/blob/master/src/compositor/compositor_api/waylandcompositor.h#L96), but that didn't help and the plugin was not getting any signals from qGuiApp->primaryScreen. So, that shortcut didn't work... All in all, we are getting there. Cheers, Rinigus On Tue, Jan 7, 2020 at 12:03 PM rinigus wrote: > Thanks! Let's see how it will work in practice. I'll report back after the > tests. > > Rinigus > > On Tue, Jan 7, 2020 at 11:59 AM Pekka Vuorela > wrote: > >> On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote: >> > Pekka, >> > >> > thanks for the swift reply! >> > >> > >> > > > - is SFOS keyboard drawn by Lipstick? >> > > >> > > Keyboard running in its own process, maliit-server. >> > >> > But something is drawing it on the screen via QML. Is that the server >> > and Lipstick just making space for it? If it is then that would fit >> > with such separation perfectly. >> >> Maliit-server acts as a host for input plugins, and Jolla-keyboard >> implements such and has the qml parts. The content is drawn in a >> separate window, and Lipstick handles the window composition. >> >> Maliit passes the used keyboard area to application via the qt input >> plugin so the app knows which area to avoid for active content, and >> maliit also sets the window properties so Lipstick knows which area of >> the window should get mouse events. >> >> >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Thanks! Let's see how it will work in practice. I'll report back after the tests. Rinigus On Tue, Jan 7, 2020 at 11:59 AM Pekka Vuorela wrote: > On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote: > > Pekka, > > > > thanks for the swift reply! > > > > > > > > - is SFOS keyboard drawn by Lipstick? > > > > > > Keyboard running in its own process, maliit-server. > > > > But something is drawing it on the screen via QML. Is that the server > > and Lipstick just making space for it? If it is then that would fit > > with such separation perfectly. > > Maliit-server acts as a host for input plugins, and Jolla-keyboard > implements such and has the qml parts. The content is drawn in a > separate window, and Lipstick handles the window composition. > > Maliit passes the used keyboard area to application via the qt input > plugin so the app knows which area to avoid for active content, and > maliit also sets the window properties so Lipstick knows which area of > the window should get mouse events. > > > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
On Tue, 2020-01-07 at 11:42 +0200, rinigus wrote: > Pekka, > > thanks for the swift reply! > > > > > - is SFOS keyboard drawn by Lipstick? > > > > Keyboard running in its own process, maliit-server. > > But something is drawing it on the screen via QML. Is that the server > and Lipstick just making space for it? If it is then that would fit > with such separation perfectly. Maliit-server acts as a host for input plugins, and Jolla-keyboard implements such and has the qml parts. The content is drawn in a separate window, and Lipstick handles the window composition. Maliit passes the used keyboard area to application via the qt input plugin so the app knows which area to avoid for active content, and maliit also sets the window properties so Lipstick knows which area of the window should get mouse events. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Pekka, thanks for the swift reply! > > - is SFOS keyboard drawn by Lipstick? > > Keyboard running in its own process, maliit-server. > But something is drawing it on the screen via QML. Is that the server and Lipstick just making space for it? If it is then that would fit with such separation perfectly. > > - does communication between app and the keyboard occur via DBus? > > Yes. Session bus and p2p connection. > Thanks, I hope it will work. > > - which files/plugins are used by the app in respect of communication > > with keyboard? Is it just > > /usr/lib/qt5/plugins/platforminputcontexts/libmaliit* or something in > > addition/else? > > All communication goes through that. > > Also FWIW the qt plugins do have some qt version checks which might > complicate running newer/different qt. > Great! Well, I have to compile it against Flatpak provided Qt and then the plugin should be consistent. Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
On Tue, 2020-01-07 at 09:30 +0200, rinigus wrote: > I am working on adding Maliit into Flatpak sandbox. Idea is to use > Maliit plugin on Flatpak side and via DBus communicate with SFOS > keyboard. However, I make few assumptions and would be like to get > some background info: > > - is SFOS keyboard drawn by Lipstick? Keyboard running in its own process, maliit-server. > - does communication between app and the keyboard occur via DBus? Yes. Session bus and p2p connection. > - which files/plugins are used by the app in respect of communication > with keyboard? Is it just > /usr/lib/qt5/plugins/platforminputcontexts/libmaliit* or something in > addition/else? All communication goes through that. Also FWIW the qt plugins do have some qt version checks which might complicate running newer/different qt. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
I am working on adding Maliit into Flatpak sandbox. Idea is to use Maliit plugin on Flatpak side and via DBus communicate with SFOS keyboard. However, I make few assumptions and would be like to get some background info: - is SFOS keyboard drawn by Lipstick? - does communication between app and the keyboard occur via DBus? - which files/plugins are used by the app in respect of communication with keyboard? Is it just /usr/lib/qt5/plugins/platforminputcontexts/libmaliit* or something in addition/else? Cheers, Rinigus On Mon, Jan 6, 2020 at 1:12 PM rinigus wrote: > Exactly, something like that is needed. Ideally, it would be hooked via > Wayland (input extension?) and trigger the keyboard on focusing on any text > field. But I will be happy with Qt only solution as well. Any tips on how > to make it possible? > > Rinigus > > On Mon, Jan 6, 2020 at 10:51 AM Андрей Кожевников > wrote: > >> Android side is using "remote keyboard" to show sailfish keyboard on top >> of Android >> >> пн, 6 янв. 2020 г., 9:52 rinigus : >> >>> Morning! >>> >>> Re compositor issue: that has been worked around by having >>> compositor-in-compositor. In theory, but I didn't look too much more than a >>> day into it, we could have headless compositor rendered on gles widget >>> which could be rather current, with all protocols supported. I mainly >>> bailed out to keep this project feasible and getting somewhere in >>> reasonable amount of time. >>> >>> Re keyboard: current solution is to incorporate keyboard into the app by >>> adding into main window. I am waiting for Sailfish keyboard gurus to >>> comment on it with the hope that we can use some kind of plugin in flatpaks >>> for communication with SFOS keyboards (dbus is available, for example). >>> >>> Rinigus >>> >>> On Mon, Jan 6, 2020 at 7:55 AM Alexander Akulich < >>> akulichalexan...@gmail.com> wrote: >>> Hi all and thank you for working on this. Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not available anymore because of changes in OBS repos), but the builds were not usable because the of the same issues — wayland and virtual keyboard. As far as I understood, a compositor with newer wayland protocol is needed to support minimize and switching back to full screen (the applications were able to start, but I couldn't open them again after minimize). On Sat, Dec 28, 2019 at 3:54 AM Damien Caliste wrote: > > Thank you Rinigus for all of this. Indeed, the current main blocker seems to be the fact that xdg-shell is not available in Lipstick. This is linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! They already have a 5.9 branch in SailfishOS git ( https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need to wait for Jolla to make the Qt switch. I don't think it's something community can change on device... I hope I can be proven wrong though. > > Damien. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org >>> >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Exactly, something like that is needed. Ideally, it would be hooked via Wayland (input extension?) and trigger the keyboard on focusing on any text field. But I will be happy with Qt only solution as well. Any tips on how to make it possible? Rinigus On Mon, Jan 6, 2020 at 10:51 AM Андрей Кожевников wrote: > Android side is using "remote keyboard" to show sailfish keyboard on top > of Android > > пн, 6 янв. 2020 г., 9:52 rinigus : > >> Morning! >> >> Re compositor issue: that has been worked around by having >> compositor-in-compositor. In theory, but I didn't look too much more than a >> day into it, we could have headless compositor rendered on gles widget >> which could be rather current, with all protocols supported. I mainly >> bailed out to keep this project feasible and getting somewhere in >> reasonable amount of time. >> >> Re keyboard: current solution is to incorporate keyboard into the app by >> adding into main window. I am waiting for Sailfish keyboard gurus to >> comment on it with the hope that we can use some kind of plugin in flatpaks >> for communication with SFOS keyboards (dbus is available, for example). >> >> Rinigus >> >> On Mon, Jan 6, 2020 at 7:55 AM Alexander Akulich < >> akulichalexan...@gmail.com> wrote: >> >>> Hi all and thank you for working on this. >>> >>> Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not >>> available anymore because of changes in OBS repos), but the builds >>> were not usable because the of the same issues — wayland and virtual >>> keyboard. As far as I understood, a compositor with newer wayland >>> protocol is needed to support minimize and switching back to full >>> screen (the applications were able to start, but I couldn't open them >>> again after minimize). >>> >>> On Sat, Dec 28, 2019 at 3:54 AM Damien Caliste wrote: >>> > >>> > Thank you Rinigus for all of this. Indeed, the current main blocker >>> seems to be the fact that xdg-shell is not available in Lipstick. This is >>> linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! >>> They already have a 5.9 branch in SailfishOS git ( >>> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we >>> need to wait for Jolla to make the Qt switch. I don't think it's something >>> community can change on device... I hope I can be proven wrong though. >>> > >>> > Damien. >>> > ___ >>> > SailfishOS.org Devel mailing list >>> > To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Android side is using "remote keyboard" to show sailfish keyboard on top of Android пн, 6 янв. 2020 г., 9:52 rinigus : > Morning! > > Re compositor issue: that has been worked around by having > compositor-in-compositor. In theory, but I didn't look too much more than a > day into it, we could have headless compositor rendered on gles widget > which could be rather current, with all protocols supported. I mainly > bailed out to keep this project feasible and getting somewhere in > reasonable amount of time. > > Re keyboard: current solution is to incorporate keyboard into the app by > adding into main window. I am waiting for Sailfish keyboard gurus to > comment on it with the hope that we can use some kind of plugin in flatpaks > for communication with SFOS keyboards (dbus is available, for example). > > Rinigus > > On Mon, Jan 6, 2020 at 7:55 AM Alexander Akulich < > akulichalexan...@gmail.com> wrote: > >> Hi all and thank you for working on this. >> >> Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not >> available anymore because of changes in OBS repos), but the builds >> were not usable because the of the same issues — wayland and virtual >> keyboard. As far as I understood, a compositor with newer wayland >> protocol is needed to support minimize and switching back to full >> screen (the applications were able to start, but I couldn't open them >> again after minimize). >> >> On Sat, Dec 28, 2019 at 3:54 AM Damien Caliste wrote: >> > >> > Thank you Rinigus for all of this. Indeed, the current main blocker >> seems to be the fact that xdg-shell is not available in Lipstick. This is >> linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! >> They already have a 5.9 branch in SailfishOS git ( >> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need >> to wait for Jolla to make the Qt switch. I don't think it's something >> community can change on device... I hope I can be proven wrong though. >> > >> > Damien. >> > ___ >> > SailfishOS.org Devel mailing list >> > To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Morning! Re compositor issue: that has been worked around by having compositor-in-compositor. In theory, but I didn't look too much more than a day into it, we could have headless compositor rendered on gles widget which could be rather current, with all protocols supported. I mainly bailed out to keep this project feasible and getting somewhere in reasonable amount of time. Re keyboard: current solution is to incorporate keyboard into the app by adding into main window. I am waiting for Sailfish keyboard gurus to comment on it with the hope that we can use some kind of plugin in flatpaks for communication with SFOS keyboards (dbus is available, for example). Rinigus On Mon, Jan 6, 2020 at 7:55 AM Alexander Akulich wrote: > Hi all and thank you for working on this. > > Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not > available anymore because of changes in OBS repos), but the builds > were not usable because the of the same issues — wayland and virtual > keyboard. As far as I understood, a compositor with newer wayland > protocol is needed to support minimize and switching back to full > screen (the applications were able to start, but I couldn't open them > again after minimize). > > On Sat, Dec 28, 2019 at 3:54 AM Damien Caliste wrote: > > > > Thank you Rinigus for all of this. Indeed, the current main blocker > seems to be the fact that xdg-shell is not available in Lipstick. This is > linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! > They already have a 5.9 branch in SailfishOS git ( > https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need > to wait for Jolla to make the Qt switch. I don't think it's something > community can change on device... I hope I can be proven wrong though. > > > > Damien. > > ___ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi all and thank you for working on this. Back in 2018 I had Qt 5.9 and Qt 5.11 builds for SFOS (they are not available anymore because of changes in OBS repos), but the builds were not usable because the of the same issues — wayland and virtual keyboard. As far as I understood, a compositor with newer wayland protocol is needed to support minimize and switching back to full screen (the applications were able to start, but I couldn't open them again after minimize). On Sat, Dec 28, 2019 at 3:54 AM Damien Caliste wrote: > > Thank you Rinigus for all of this. Indeed, the current main blocker seems to > be the fact that xdg-shell is not available in Lipstick. This is linked to > the ancient version of QtWayland, even not 5.6, but still 5.4 ! They already > have a 5.9 branch in SailfishOS git > (https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need to > wait for Jolla to make the Qt switch. I don't think it's something community > can change on device... I hope I can be proven wrong though. > > Damien. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Good part is that this home-cooked libhybris will live separately from the main one in your home folder (see https://github.com/sailfishos-flatpak/flatpak-runner/blob/master/scripts/flatpak-extension-hybris for script generating it). So, you can experiment while keeping system one intact. Rinigus On Mon, Jan 6, 2020 at 12:10 AM wrote: > I'm probably totally wrong, but you can run all kinds of homecooked > libhybris versions on a device without needing kernel recompiled, unless > some specific kernel options are missing? > > On Sunday, 5 January 2020, rinigus wrote: > > Re kernel options: USER_NS is one of them, rest I am not sure as it > worked > > immediately for me on Xperia XZ2. As a result, I never looked too deeply > > into it. > > > > Re libhybris: isn't it compiled against device specific droid-hal? > > > > Rinigus > > > > On Sun, Jan 5, 2020 at 11:37 PM wrote: > > > > > If it's only in libhybris, then it's not device specific? Which exactly > > > kernel options need to be turned on for it? Or I'm totally confused > > > > > > On Sunday, 5 January 2020, rinigus wrote: > > > > Hi, > > > > > > > > I think that the patch suggested for libhybris is a bugfix. So, I > hope it > > > > will be merged and distributed with one of the next SFOS updates. > > > Assuming > > > > that Jolla C is still getting updates, you should get it too. > > > > > > > > Now, libhybris bug is in the linker, as you can see from my PR. I > don't > > > > know how device-specific it is, hopefully knowledgeable porters can > chip > > > in > > > > and comment on it. If its not device specific then we can just > package > > > the > > > > linker and use the rest as it is on device. > > > > > > > > Let's see what the next few days bring. I presume many of developers > are > > > > back from holidays next week which could speed up the response. > > > > > > > > Cheers, > > > > > > > > Rinigus > > > > > > > > > > > > > > > > On Sun, Jan 5, 2020 at 10:52 PM wrote: > > > > > > > > > It's device specific? Shame, doubt jolla C can help then. Still > hopeful > > > > > the eventual cosmo communicator edition will support it. Any hints > what > > > > > needs to be enabled in kernel? > > > > > > > > > > Thanks in advance, > > > > > szopin > > > > > > > > > > On Sunday, 5 January 2020, rinigus wrote: > > > > > > Hi, > > > > > > > > > > > > I have moved all repositories required for Flatpak support to > > > > > > https://github.com/sailfishos-flatpak . Documentation is > available > > > at > > > > > > https://github.com/sailfishos-flatpak/main describing how to > > > install and > > > > > > develop using this environment. Issues are expected to be filed > fixed > > > > > under > > > > > > https://github.com/sailfishos-flatpak/main and, when > appropriate, > > > under > > > > > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to > > > list > > > > > all > > > > > > current issues under those repositories. > > > > > > > > > > > > I have also opened a thread at TMO ( > > > > > > http://talk.maemo.org/showthread.php?p=1564143) for those who > prefer > > > > > that > > > > > > way of communication. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > Rinigus > > > > > > > > > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus > > > wrote: > > > > > > > > > > > > > Excellent! If something in kernel config is missing, I expect > that > > > you > > > > > > > could use Xperia 10 as a base to check the settings or for > Xperia > > > XZ2 > > > > > used > > > > > > > by me at > > > > > > > > > > > > > > > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > > > > > > > > > > > Rinigus > > > > > > > > > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg > > > wrote: > > > > > > > > > > > > > >> Ill build it on mido and try it out, thanks! > > > > > > >> > > > > > > >> On Fri, 3 Jan 2020 at 22:45, rinigus > > > wrote: > > > > > > >> > > > > > > >>> Hi, > > > > > > >>> > > > > > > >>> I have submitted PR to libhybris allowing to use Flatpak on > > > hybris > > > > > > >>> devices with the same version serving its main purpose and > inside > > > > > Flatpak > > > > > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > > > > > > >>> > > > > > > >>> As soon as your device has such libhybris, you could > > > > > > >>> > > > > > > >>> - use > > > https://build.merproject.org/project/show/home:rinigus:flatpak > > > > > to > > > > > > >>> install flatpak, flatpak-runner > > > > > > >>> - run flatpak-extension-hybris to generate Flatpah hybris > > > extension > > > > > at > > > > > > >>> user nemo's home (run as nemo) > > > > > > >>> - install flatpak apps, see instructions at Flathub on how > to do > > > it > > > > > > >>> - run them using flatpak-runner > > > > > > >>> > > > > > > >>> Many things don't work, but would be faster to get it fixed > > > together > > > > > > >>> with other devs. > > > > > > >>> > > > > > > >>> Cheers.
Re: [SailfishDevel] Flatpak for Sailfish
I'm probably totally wrong, but you can run all kinds of homecooked libhybris versions on a device without needing kernel recompiled, unless some specific kernel options are missing? On Sunday, 5 January 2020, rinigus wrote: > Re kernel options: USER_NS is one of them, rest I am not sure as it worked > immediately for me on Xperia XZ2. As a result, I never looked too deeply > into it. > > Re libhybris: isn't it compiled against device specific droid-hal? > > Rinigus > > On Sun, Jan 5, 2020 at 11:37 PM wrote: > > > If it's only in libhybris, then it's not device specific? Which exactly > > kernel options need to be turned on for it? Or I'm totally confused > > > > On Sunday, 5 January 2020, rinigus wrote: > > > Hi, > > > > > > I think that the patch suggested for libhybris is a bugfix. So, I hope it > > > will be merged and distributed with one of the next SFOS updates. > > Assuming > > > that Jolla C is still getting updates, you should get it too. > > > > > > Now, libhybris bug is in the linker, as you can see from my PR. I don't > > > know how device-specific it is, hopefully knowledgeable porters can chip > > in > > > and comment on it. If its not device specific then we can just package > > the > > > linker and use the rest as it is on device. > > > > > > Let's see what the next few days bring. I presume many of developers are > > > back from holidays next week which could speed up the response. > > > > > > Cheers, > > > > > > Rinigus > > > > > > > > > > > > On Sun, Jan 5, 2020 at 10:52 PM wrote: > > > > > > > It's device specific? Shame, doubt jolla C can help then. Still hopeful > > > > the eventual cosmo communicator edition will support it. Any hints what > > > > needs to be enabled in kernel? > > > > > > > > Thanks in advance, > > > > szopin > > > > > > > > On Sunday, 5 January 2020, rinigus wrote: > > > > > Hi, > > > > > > > > > > I have moved all repositories required for Flatpak support to > > > > > https://github.com/sailfishos-flatpak . Documentation is available > > at > > > > > https://github.com/sailfishos-flatpak/main describing how to > > install and > > > > > develop using this environment. Issues are expected to be filed fixed > > > > under > > > > > https://github.com/sailfishos-flatpak/main and, when appropriate, > > under > > > > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to > > list > > > > all > > > > > current issues under those repositories. > > > > > > > > > > I have also opened a thread at TMO ( > > > > > http://talk.maemo.org/showthread.php?p=1564143) for those who prefer > > > > that > > > > > way of communication. > > > > > > > > > > Cheers, > > > > > > > > > > Rinigus > > > > > > > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus > > wrote: > > > > > > > > > > > Excellent! If something in kernel config is missing, I expect that > > you > > > > > > could use Xperia 10 as a base to check the settings or for Xperia > > XZ2 > > > > used > > > > > > by me at > > > > > > > > > > > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > > > > > > > > > Rinigus > > > > > > > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg > > wrote: > > > > > > > > > > > >> Ill build it on mido and try it out, thanks! > > > > > >> > > > > > >> On Fri, 3 Jan 2020 at 22:45, rinigus > > wrote: > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> I have submitted PR to libhybris allowing to use Flatpak on > > hybris > > > > > >>> devices with the same version serving its main purpose and inside > > > > Flatpak > > > > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > > > > > >>> > > > > > >>> As soon as your device has such libhybris, you could > > > > > >>> > > > > > >>> - use > > https://build.merproject.org/project/show/home:rinigus:flatpak > > > > to > > > > > >>> install flatpak, flatpak-runner > > > > > >>> - run flatpak-extension-hybris to generate Flatpah hybris > > extension > > > > at > > > > > >>> user nemo's home (run as nemo) > > > > > >>> - install flatpak apps, see instructions at Flathub on how to do > > it > > > > > >>> - run them using flatpak-runner > > > > > >>> > > > > > >>> Many things don't work, but would be faster to get it fixed > > together > > > > > >>> with other devs. > > > > > >>> > > > > > >>> Cheers. > > > > > >>> > > > > > >>> Rinigus > > > > > >>> > > > > > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus > > > > wrote: > > > > > >>> > > > > > Hi, > > > > > > > > > > just finished the first version of a wrapper for 'flatpak run' > > > > command > > > > > as well, available at https://github.com/rinigus/flatpak-runner > > . > > > > Its > > > > > based on qxcompositor and it opens new Wayland server before > > > > running an > > > > > application, all explained in README. Device rotation is > > supported > > > > and > > > > > should be followed. > > > > > > > > > > So,
Re: [SailfishDevel] Flatpak for Sailfish
Re kernel options: USER_NS is one of them, rest I am not sure as it worked immediately for me on Xperia XZ2. As a result, I never looked too deeply into it. Re libhybris: isn't it compiled against device specific droid-hal? Rinigus On Sun, Jan 5, 2020 at 11:37 PM wrote: > If it's only in libhybris, then it's not device specific? Which exactly > kernel options need to be turned on for it? Or I'm totally confused > > On Sunday, 5 January 2020, rinigus wrote: > > Hi, > > > > I think that the patch suggested for libhybris is a bugfix. So, I hope it > > will be merged and distributed with one of the next SFOS updates. > Assuming > > that Jolla C is still getting updates, you should get it too. > > > > Now, libhybris bug is in the linker, as you can see from my PR. I don't > > know how device-specific it is, hopefully knowledgeable porters can chip > in > > and comment on it. If its not device specific then we can just package > the > > linker and use the rest as it is on device. > > > > Let's see what the next few days bring. I presume many of developers are > > back from holidays next week which could speed up the response. > > > > Cheers, > > > > Rinigus > > > > > > > > On Sun, Jan 5, 2020 at 10:52 PM wrote: > > > > > It's device specific? Shame, doubt jolla C can help then. Still hopeful > > > the eventual cosmo communicator edition will support it. Any hints what > > > needs to be enabled in kernel? > > > > > > Thanks in advance, > > > szopin > > > > > > On Sunday, 5 January 2020, rinigus wrote: > > > > Hi, > > > > > > > > I have moved all repositories required for Flatpak support to > > > > https://github.com/sailfishos-flatpak . Documentation is available > at > > > > https://github.com/sailfishos-flatpak/main describing how to > install and > > > > develop using this environment. Issues are expected to be filed fixed > > > under > > > > https://github.com/sailfishos-flatpak/main and, when appropriate, > under > > > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to > list > > > all > > > > current issues under those repositories. > > > > > > > > I have also opened a thread at TMO ( > > > > http://talk.maemo.org/showthread.php?p=1564143) for those who prefer > > > that > > > > way of communication. > > > > > > > > Cheers, > > > > > > > > Rinigus > > > > > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus > wrote: > > > > > > > > > Excellent! If something in kernel config is missing, I expect that > you > > > > > could use Xperia 10 as a base to check the settings or for Xperia > XZ2 > > > used > > > > > by me at > > > > > > > > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > > > > > > > Rinigus > > > > > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg > wrote: > > > > > > > > > >> Ill build it on mido and try it out, thanks! > > > > >> > > > > >> On Fri, 3 Jan 2020 at 22:45, rinigus > wrote: > > > > >> > > > > >>> Hi, > > > > >>> > > > > >>> I have submitted PR to libhybris allowing to use Flatpak on > hybris > > > > >>> devices with the same version serving its main purpose and inside > > > Flatpak > > > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > > > > >>> > > > > >>> As soon as your device has such libhybris, you could > > > > >>> > > > > >>> - use > https://build.merproject.org/project/show/home:rinigus:flatpak > > > to > > > > >>> install flatpak, flatpak-runner > > > > >>> - run flatpak-extension-hybris to generate Flatpah hybris > extension > > > at > > > > >>> user nemo's home (run as nemo) > > > > >>> - install flatpak apps, see instructions at Flathub on how to do > it > > > > >>> - run them using flatpak-runner > > > > >>> > > > > >>> Many things don't work, but would be faster to get it fixed > together > > > > >>> with other devs. > > > > >>> > > > > >>> Cheers. > > > > >>> > > > > >>> Rinigus > > > > >>> > > > > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus > > > wrote: > > > > >>> > > > > Hi, > > > > > > > > just finished the first version of a wrapper for 'flatpak run' > > > command > > > > as well, available at https://github.com/rinigus/flatpak-runner > . > > > Its > > > > based on qxcompositor and it opens new Wayland server before > > > running an > > > > application, all explained in README. Device rotation is > supported > > > and > > > > should be followed. > > > > > > > > So, as it is: > > > > > > > > - we have to resolve libhybris linker issue to make it possible > to > > > > distribute. > > > > - keyboard is not supported currently. At present, app has to > have > > > > qtvirtualkeyboard support added as in > > > > > > > > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > > > > . > > > > - only single-window apps are working well, such as QML > developed > > > for > > > > mobile > > > > - no
Re: [SailfishDevel] Flatpak for Sailfish
If it's only in libhybris, then it's not device specific? Which exactly kernel options need to be turned on for it? Or I'm totally confused On Sunday, 5 January 2020, rinigus wrote: > Hi, > > I think that the patch suggested for libhybris is a bugfix. So, I hope it > will be merged and distributed with one of the next SFOS updates. Assuming > that Jolla C is still getting updates, you should get it too. > > Now, libhybris bug is in the linker, as you can see from my PR. I don't > know how device-specific it is, hopefully knowledgeable porters can chip in > and comment on it. If its not device specific then we can just package the > linker and use the rest as it is on device. > > Let's see what the next few days bring. I presume many of developers are > back from holidays next week which could speed up the response. > > Cheers, > > Rinigus > > > > On Sun, Jan 5, 2020 at 10:52 PM wrote: > > > It's device specific? Shame, doubt jolla C can help then. Still hopeful > > the eventual cosmo communicator edition will support it. Any hints what > > needs to be enabled in kernel? > > > > Thanks in advance, > > szopin > > > > On Sunday, 5 January 2020, rinigus wrote: > > > Hi, > > > > > > I have moved all repositories required for Flatpak support to > > > https://github.com/sailfishos-flatpak . Documentation is available at > > > https://github.com/sailfishos-flatpak/main describing how to install and > > > develop using this environment. Issues are expected to be filed fixed > > under > > > https://github.com/sailfishos-flatpak/main and, when appropriate, under > > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to list > > all > > > current issues under those repositories. > > > > > > I have also opened a thread at TMO ( > > > http://talk.maemo.org/showthread.php?p=1564143) for those who prefer > > that > > > way of communication. > > > > > > Cheers, > > > > > > Rinigus > > > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus wrote: > > > > > > > Excellent! If something in kernel config is missing, I expect that you > > > > could use Xperia 10 as a base to check the settings or for Xperia XZ2 > > used > > > > by me at > > > > > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > > > > > Rinigus > > > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg wrote: > > > > > > > >> Ill build it on mido and try it out, thanks! > > > >> > > > >> On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> I have submitted PR to libhybris allowing to use Flatpak on hybris > > > >>> devices with the same version serving its main purpose and inside > > Flatpak > > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > > > >>> > > > >>> As soon as your device has such libhybris, you could > > > >>> > > > >>> - use https://build.merproject.org/project/show/home:rinigus:flatpak > > to > > > >>> install flatpak, flatpak-runner > > > >>> - run flatpak-extension-hybris to generate Flatpah hybris extension > > at > > > >>> user nemo's home (run as nemo) > > > >>> - install flatpak apps, see instructions at Flathub on how to do it > > > >>> - run them using flatpak-runner > > > >>> > > > >>> Many things don't work, but would be faster to get it fixed together > > > >>> with other devs. > > > >>> > > > >>> Cheers. > > > >>> > > > >>> Rinigus > > > >>> > > > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus > > wrote: > > > >>> > > > Hi, > > > > > > just finished the first version of a wrapper for 'flatpak run' > > command > > > as well, available at https://github.com/rinigus/flatpak-runner . > > Its > > > based on qxcompositor and it opens new Wayland server before > > running an > > > application, all explained in README. Device rotation is supported > > and > > > should be followed. > > > > > > So, as it is: > > > > > > - we have to resolve libhybris linker issue to make it possible to > > > distribute. > > > - keyboard is not supported currently. At present, app has to have > > > qtvirtualkeyboard support added as in > > > > > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > > > . > > > - only single-window apps are working well, such as QML developed > > for > > > mobile > > > - no sound so far > > > - probably many other things are missing, haven't bumped into them. > > > > > > Essentially, we will have access to the latest Qt, but would have to > > > write apps for this use. Fortunately, it all goes along SFOS > > programming > > > and should be simple to convert later to Silica, when/if it catches > > up with > > > Qt versions. > > > > > > I guess we can get better integration after it will be simple to > > > install on other devices and start using it by others. > > > > > >
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I think that the patch suggested for libhybris is a bugfix. So, I hope it will be merged and distributed with one of the next SFOS updates. Assuming that Jolla C is still getting updates, you should get it too. Now, libhybris bug is in the linker, as you can see from my PR. I don't know how device-specific it is, hopefully knowledgeable porters can chip in and comment on it. If its not device specific then we can just package the linker and use the rest as it is on device. Let's see what the next few days bring. I presume many of developers are back from holidays next week which could speed up the response. Cheers, Rinigus On Sun, Jan 5, 2020 at 10:52 PM wrote: > It's device specific? Shame, doubt jolla C can help then. Still hopeful > the eventual cosmo communicator edition will support it. Any hints what > needs to be enabled in kernel? > > Thanks in advance, > szopin > > On Sunday, 5 January 2020, rinigus wrote: > > Hi, > > > > I have moved all repositories required for Flatpak support to > > https://github.com/sailfishos-flatpak . Documentation is available at > > https://github.com/sailfishos-flatpak/main describing how to install and > > develop using this environment. Issues are expected to be filed fixed > under > > https://github.com/sailfishos-flatpak/main and, when appropriate, under > > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to list > all > > current issues under those repositories. > > > > I have also opened a thread at TMO ( > > http://talk.maemo.org/showthread.php?p=1564143) for those who prefer > that > > way of communication. > > > > Cheers, > > > > Rinigus > > > > On Sat, Jan 4, 2020 at 10:22 AM rinigus wrote: > > > > > Excellent! If something in kernel config is missing, I expect that you > > > could use Xperia 10 as a base to check the settings or for Xperia XZ2 > used > > > by me at > > > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > > > Rinigus > > > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg wrote: > > > > > >> Ill build it on mido and try it out, thanks! > > >> > > >> On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > > >> > > >>> Hi, > > >>> > > >>> I have submitted PR to libhybris allowing to use Flatpak on hybris > > >>> devices with the same version serving its main purpose and inside > Flatpak > > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > > >>> > > >>> As soon as your device has such libhybris, you could > > >>> > > >>> - use https://build.merproject.org/project/show/home:rinigus:flatpak > to > > >>> install flatpak, flatpak-runner > > >>> - run flatpak-extension-hybris to generate Flatpah hybris extension > at > > >>> user nemo's home (run as nemo) > > >>> - install flatpak apps, see instructions at Flathub on how to do it > > >>> - run them using flatpak-runner > > >>> > > >>> Many things don't work, but would be faster to get it fixed together > > >>> with other devs. > > >>> > > >>> Cheers. > > >>> > > >>> Rinigus > > >>> > > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus > wrote: > > >>> > > Hi, > > > > just finished the first version of a wrapper for 'flatpak run' > command > > as well, available at https://github.com/rinigus/flatpak-runner . > Its > > based on qxcompositor and it opens new Wayland server before > running an > > application, all explained in README. Device rotation is supported > and > > should be followed. > > > > So, as it is: > > > > - we have to resolve libhybris linker issue to make it possible to > > distribute. > > - keyboard is not supported currently. At present, app has to have > > qtvirtualkeyboard support added as in > > > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > > . > > - only single-window apps are working well, such as QML developed > for > > mobile > > - no sound so far > > - probably many other things are missing, haven't bumped into them. > > > > Essentially, we will have access to the latest Qt, but would have to > > write apps for this use. Fortunately, it all goes along SFOS > programming > > and should be simple to convert later to Silica, when/if it catches > up with > > Qt versions. > > > > I guess we can get better integration after it will be simple to > > install on other devices and start using it by others. > > > > Cheers, > > > > Rinigus > > > > On Wed, Jan 1, 2020 at 5:25 PM rinigus > wrote: > > > > > Hi, > > > > > > wait a bit, I may have a way to simplify setup. Few days ago, after > > > discussion on IRC, I found a way around disappearance of the > window when > > > wrapped into qxcomposer. So, that blocker is over now. Which means > that we > > > will be able to craft apps using the latest Qt available in >
Re: [SailfishDevel] Flatpak for Sailfish
It's device specific? Shame, doubt jolla C can help then. Still hopeful the eventual cosmo communicator edition will support it. Any hints what needs to be enabled in kernel? Thanks in advance, szopin On Sunday, 5 January 2020, rinigus wrote: > Hi, > > I have moved all repositories required for Flatpak support to > https://github.com/sailfishos-flatpak . Documentation is available at > https://github.com/sailfishos-flatpak/main describing how to install and > develop using this environment. Issues are expected to be filed fixed under > https://github.com/sailfishos-flatpak/main and, when appropriate, under > https://github.com/sailfishos-flatpak/flatpak-runner. I tried to list all > current issues under those repositories. > > I have also opened a thread at TMO ( > http://talk.maemo.org/showthread.php?p=1564143) for those who prefer that > way of communication. > > Cheers, > > Rinigus > > On Sat, Jan 4, 2020 at 10:22 AM rinigus wrote: > > > Excellent! If something in kernel config is missing, I expect that you > > could use Xperia 10 as a base to check the settings or for Xperia XZ2 used > > by me at > > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > > > Rinigus > > > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg wrote: > > > >> Ill build it on mido and try it out, thanks! > >> > >> On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > >> > >>> Hi, > >>> > >>> I have submitted PR to libhybris allowing to use Flatpak on hybris > >>> devices with the same version serving its main purpose and inside Flatpak > >>> sandbox: https://github.com/libhybris/libhybris/pull/433. > >>> > >>> As soon as your device has such libhybris, you could > >>> > >>> - use https://build.merproject.org/project/show/home:rinigus:flatpak to > >>> install flatpak, flatpak-runner > >>> - run flatpak-extension-hybris to generate Flatpah hybris extension at > >>> user nemo's home (run as nemo) > >>> - install flatpak apps, see instructions at Flathub on how to do it > >>> - run them using flatpak-runner > >>> > >>> Many things don't work, but would be faster to get it fixed together > >>> with other devs. > >>> > >>> Cheers. > >>> > >>> Rinigus > >>> > >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: > >>> > Hi, > > just finished the first version of a wrapper for 'flatpak run' command > as well, available at https://github.com/rinigus/flatpak-runner . Its > based on qxcompositor and it opens new Wayland server before running an > application, all explained in README. Device rotation is supported and > should be followed. > > So, as it is: > > - we have to resolve libhybris linker issue to make it possible to > distribute. > - keyboard is not supported currently. At present, app has to have > qtvirtualkeyboard support added as in > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > . > - only single-window apps are working well, such as QML developed for > mobile > - no sound so far > - probably many other things are missing, haven't bumped into them. > > Essentially, we will have access to the latest Qt, but would have to > write apps for this use. Fortunately, it all goes along SFOS programming > and should be simple to convert later to Silica, when/if it catches up > with > Qt versions. > > I guess we can get better integration after it will be simple to > install on other devices and start using it by others. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > > > Hi, > > > > wait a bit, I may have a way to simplify setup. Few days ago, after > > discussion on IRC, I found a way around disappearance of the window when > > wrapped into qxcomposer. So, that blocker is over now. Which means that > > we > > will be able to craft apps using the latest Qt available in Flatpaks. > > > > Currently, I am looking into > > > > - how we can use regular hybris > > - making a wrapper similar to qxcomposer for Flatpaks. > > > > Shouldn't take too long for an update on status. > > > > Cheers, > > > > Rinigus > > > > On Wed, Jan 1, 2020 at 4:55 PM wrote: > > > >> Could you elaborate on: > >> > libhybris compiled with specification of default > >> hybris-ld-library-path, > >> > content of libexec/droid-hybris added with GL extension. > >> Is that libhybris build available (and safe to run on main device, or > >> should I dig out my j1)? > >> Also not sure what added with GL extension means? Having a browser > >> that uses up to date webengine would be awesome. > >> > >> Thanks and happy new year! > >> szopin > >> > >> On Sunday, 29 December 2019, rinigus wrote: >
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I have moved all repositories required for Flatpak support to https://github.com/sailfishos-flatpak . Documentation is available at https://github.com/sailfishos-flatpak/main describing how to install and develop using this environment. Issues are expected to be filed fixed under https://github.com/sailfishos-flatpak/main and, when appropriate, under https://github.com/sailfishos-flatpak/flatpak-runner. I tried to list all current issues under those repositories. I have also opened a thread at TMO ( http://talk.maemo.org/showthread.php?p=1564143) for those who prefer that way of communication. Cheers, Rinigus On Sat, Jan 4, 2020 at 10:22 AM rinigus wrote: > Excellent! If something in kernel config is missing, I expect that you > could use Xperia 10 as a base to check the settings or for Xperia XZ2 used > by me at > https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig > > Rinigus > > On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg wrote: > >> Ill build it on mido and try it out, thanks! >> >> On Fri, 3 Jan 2020 at 22:45, rinigus wrote: >> >>> Hi, >>> >>> I have submitted PR to libhybris allowing to use Flatpak on hybris >>> devices with the same version serving its main purpose and inside Flatpak >>> sandbox: https://github.com/libhybris/libhybris/pull/433. >>> >>> As soon as your device has such libhybris, you could >>> >>> - use https://build.merproject.org/project/show/home:rinigus:flatpak to >>> install flatpak, flatpak-runner >>> - run flatpak-extension-hybris to generate Flatpah hybris extension at >>> user nemo's home (run as nemo) >>> - install flatpak apps, see instructions at Flathub on how to do it >>> - run them using flatpak-runner >>> >>> Many things don't work, but would be faster to get it fixed together >>> with other devs. >>> >>> Cheers. >>> >>> Rinigus >>> >>> On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: >>> Hi, just finished the first version of a wrapper for 'flatpak run' command as well, available at https://github.com/rinigus/flatpak-runner . Its based on qxcompositor and it opens new Wayland server before running an application, all explained in README. Device rotation is supported and should be followed. So, as it is: - we have to resolve libhybris linker issue to make it possible to distribute. - keyboard is not supported currently. At present, app has to have qtvirtualkeyboard support added as in https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel . - only single-window apps are working well, such as QML developed for mobile - no sound so far - probably many other things are missing, haven't bumped into them. Essentially, we will have access to the latest Qt, but would have to write apps for this use. Fortunately, it all goes along SFOS programming and should be simple to convert later to Silica, when/if it catches up with Qt versions. I guess we can get better integration after it will be simple to install on other devices and start using it by others. Cheers, Rinigus On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > Hi, > > wait a bit, I may have a way to simplify setup. Few days ago, after > discussion on IRC, I found a way around disappearance of the window when > wrapped into qxcomposer. So, that blocker is over now. Which means that we > will be able to craft apps using the latest Qt available in Flatpaks. > > Currently, I am looking into > > - how we can use regular hybris > - making a wrapper similar to qxcomposer for Flatpaks. > > Shouldn't take too long for an update on status. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 4:55 PM wrote: > >> Could you elaborate on: >> > libhybris compiled with specification of default >> hybris-ld-library-path, >> > content of libexec/droid-hybris added with GL extension. >> Is that libhybris build available (and safe to run on main device, or >> should I dig out my j1)? >> Also not sure what added with GL extension means? Having a browser >> that uses up to date webengine would be awesome. >> >> Thanks and happy new year! >> szopin >> >> On Sunday, 29 December 2019, rinigus wrote: >> > Hi, >> > >> > I would have preferred to stay away from discussion on why do we >> need/not >> > need Flatpak on SFOS. But I guess I have to take it as the one >> working on >> > making it possible. >> > >> > Native apps rely on the libs allowed in the Store and bundle the >> rest of >> > them. I presume OSM Scout Server and Pure Maps are exceptions, but >> they are >> > built around almost 20 libs bundled with the application and >> compiled with >> >
Re: [SailfishDevel] Flatpak for Sailfish
Excellent! If something in kernel config is missing, I expect that you could use Xperia 10 as a base to check the settings or for Xperia XZ2 used by me at https://github.com/sailfishos-sony-tama/android_kernel_sony_msm/blob/hybris-sony-aosp-9.0.0-4.9-tama-sony/arch/arm64/configs/aosp_tama_akari_defconfig Rinigus On Sat, Jan 4, 2020 at 12:47 AM Adam Pigg wrote: > Ill build it on mido and try it out, thanks! > > On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > >> Hi, >> >> I have submitted PR to libhybris allowing to use Flatpak on hybris >> devices with the same version serving its main purpose and inside Flatpak >> sandbox: https://github.com/libhybris/libhybris/pull/433. >> >> As soon as your device has such libhybris, you could >> >> - use https://build.merproject.org/project/show/home:rinigus:flatpak to >> install flatpak, flatpak-runner >> - run flatpak-extension-hybris to generate Flatpah hybris extension at >> user nemo's home (run as nemo) >> - install flatpak apps, see instructions at Flathub on how to do it >> - run them using flatpak-runner >> >> Many things don't work, but would be faster to get it fixed together with >> other devs. >> >> Cheers. >> >> Rinigus >> >> On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: >> >>> Hi, >>> >>> just finished the first version of a wrapper for 'flatpak run' command >>> as well, available at https://github.com/rinigus/flatpak-runner . Its >>> based on qxcompositor and it opens new Wayland server before running an >>> application, all explained in README. Device rotation is supported and >>> should be followed. >>> >>> So, as it is: >>> >>> - we have to resolve libhybris linker issue to make it possible to >>> distribute. >>> - keyboard is not supported currently. At present, app has to have >>> qtvirtualkeyboard support added as in >>> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel >>> . >>> - only single-window apps are working well, such as QML developed for >>> mobile >>> - no sound so far >>> - probably many other things are missing, haven't bumped into them. >>> >>> Essentially, we will have access to the latest Qt, but would have to >>> write apps for this use. Fortunately, it all goes along SFOS programming >>> and should be simple to convert later to Silica, when/if it catches up with >>> Qt versions. >>> >>> I guess we can get better integration after it will be simple to install >>> on other devices and start using it by others. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: >>> Hi, wait a bit, I may have a way to simplify setup. Few days ago, after discussion on IRC, I found a way around disappearance of the window when wrapped into qxcomposer. So, that blocker is over now. Which means that we will be able to craft apps using the latest Qt available in Flatpaks. Currently, I am looking into - how we can use regular hybris - making a wrapper similar to qxcomposer for Flatpaks. Shouldn't take too long for an update on status. Cheers, Rinigus On Wed, Jan 1, 2020 at 4:55 PM wrote: > Could you elaborate on: > > libhybris compiled with specification of default > hybris-ld-library-path, > > content of libexec/droid-hybris added with GL extension. > Is that libhybris build available (and safe to run on main device, or > should I dig out my j1)? > Also not sure what added with GL extension means? Having a browser > that uses up to date webengine would be awesome. > > Thanks and happy new year! > szopin > > On Sunday, 29 December 2019, rinigus wrote: > > Hi, > > > > I would have preferred to stay away from discussion on why do we > need/not > > need Flatpak on SFOS. But I guess I have to take it as the one > working on > > making it possible. > > > > Native apps rely on the libs allowed in the Store and bundle the > rest of > > them. I presume OSM Scout Server and Pure Maps are exceptions, but > they are > > built around almost 20 libs bundled with the application and > compiled with > > newer gcc than the one on the platform. If I would have continued to > > provide OSM Scout Server via the official Store, I'd have to bundle > > libsystemd as well - something that I found was crossing a line for > me. So, > > any security issue in those bundled libs would be propagated the > same way > > as with the Flatpak. I admit that its way less libs than distributed > via > > Flatpak. However, in the case of Flatpak, apps are provided on the > top of > > "runtimes" with the app including everything which is extending the > runtime > > to make it work. So, in case of OSM Scout Server and Pure Maps, their > > Flatpaks do include some libs as well. Those runtimes are updated. > Now, I > > am not in position to say whether its
Re: [SailfishDevel] Flatpak for Sailfish
Ill build it on mido and try it out, thanks! On Fri, 3 Jan 2020 at 22:45, rinigus wrote: > Hi, > > I have submitted PR to libhybris allowing to use Flatpak on hybris devices > with the same version serving its main purpose and inside Flatpak sandbox: > https://github.com/libhybris/libhybris/pull/433. > > As soon as your device has such libhybris, you could > > - use https://build.merproject.org/project/show/home:rinigus:flatpak to > install flatpak, flatpak-runner > - run flatpak-extension-hybris to generate Flatpah hybris extension at > user nemo's home (run as nemo) > - install flatpak apps, see instructions at Flathub on how to do it > - run them using flatpak-runner > > Many things don't work, but would be faster to get it fixed together with > other devs. > > Cheers. > > Rinigus > > On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: > >> Hi, >> >> just finished the first version of a wrapper for 'flatpak run' command as >> well, available at https://github.com/rinigus/flatpak-runner . Its based >> on qxcompositor and it opens new Wayland server before running an >> application, all explained in README. Device rotation is supported and >> should be followed. >> >> So, as it is: >> >> - we have to resolve libhybris linker issue to make it possible to >> distribute. >> - keyboard is not supported currently. At present, app has to have >> qtvirtualkeyboard support added as in >> https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel >> . >> - only single-window apps are working well, such as QML developed for >> mobile >> - no sound so far >> - probably many other things are missing, haven't bumped into them. >> >> Essentially, we will have access to the latest Qt, but would have to >> write apps for this use. Fortunately, it all goes along SFOS programming >> and should be simple to convert later to Silica, when/if it catches up with >> Qt versions. >> >> I guess we can get better integration after it will be simple to install >> on other devices and start using it by others. >> >> Cheers, >> >> Rinigus >> >> On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: >> >>> Hi, >>> >>> wait a bit, I may have a way to simplify setup. Few days ago, after >>> discussion on IRC, I found a way around disappearance of the window when >>> wrapped into qxcomposer. So, that blocker is over now. Which means that we >>> will be able to craft apps using the latest Qt available in Flatpaks. >>> >>> Currently, I am looking into >>> >>> - how we can use regular hybris >>> - making a wrapper similar to qxcomposer for Flatpaks. >>> >>> Shouldn't take too long for an update on status. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Wed, Jan 1, 2020 at 4:55 PM wrote: >>> Could you elaborate on: > libhybris compiled with specification of default hybris-ld-library-path, > content of libexec/droid-hybris added with GL extension. Is that libhybris build available (and safe to run on main device, or should I dig out my j1)? Also not sure what added with GL extension means? Having a browser that uses up to date webengine would be awesome. Thanks and happy new year! szopin On Sunday, 29 December 2019, rinigus wrote: > Hi, > > I would have preferred to stay away from discussion on why do we need/not > need Flatpak on SFOS. But I guess I have to take it as the one working on > making it possible. > > Native apps rely on the libs allowed in the Store and bundle the rest of > them. I presume OSM Scout Server and Pure Maps are exceptions, but they are > built around almost 20 libs bundled with the application and compiled with > newer gcc than the one on the platform. If I would have continued to > provide OSM Scout Server via the official Store, I'd have to bundle > libsystemd as well - something that I found was crossing a line for me. So, > any security issue in those bundled libs would be propagated the same way > as with the Flatpak. I admit that its way less libs than distributed via > Flatpak. However, in the case of Flatpak, apps are provided on the top of > "runtimes" with the app including everything which is extending the runtime > to make it work. So, in case of OSM Scout Server and Pure Maps, their > Flatpaks do include some libs as well. Those runtimes are updated. Now, I > am not in position to say whether its security updates are as fast as of > distros and have no idea how it compares to SFOS. > > However, I see mainly portability and up-to-date toolbox aspect of Flatpak, > not that much security in terms of sandbox. These are my preferences and > they could differ from yours. > > Looking at the speed of upcoming Qt update, I was considering whether to > make qt5.12 (or later) in /opt (/home/opt) and use it from there to allow
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I have submitted PR to libhybris allowing to use Flatpak on hybris devices with the same version serving its main purpose and inside Flatpak sandbox: https://github.com/libhybris/libhybris/pull/433. As soon as your device has such libhybris, you could - use https://build.merproject.org/project/show/home:rinigus:flatpak to install flatpak, flatpak-runner - run flatpak-extension-hybris to generate Flatpah hybris extension at user nemo's home (run as nemo) - install flatpak apps, see instructions at Flathub on how to do it - run them using flatpak-runner Many things don't work, but would be faster to get it fixed together with other devs. Cheers. Rinigus On Fri, Jan 3, 2020 at 12:18 AM rinigus wrote: > Hi, > > just finished the first version of a wrapper for 'flatpak run' command as > well, available at https://github.com/rinigus/flatpak-runner . Its based > on qxcompositor and it opens new Wayland server before running an > application, all explained in README. Device rotation is supported and > should be followed. > > So, as it is: > > - we have to resolve libhybris linker issue to make it possible to > distribute. > - keyboard is not supported currently. At present, app has to have > qtvirtualkeyboard support added as in > https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel > . > - only single-window apps are working well, such as QML developed for > mobile > - no sound so far > - probably many other things are missing, haven't bumped into them. > > Essentially, we will have access to the latest Qt, but would have to write > apps for this use. Fortunately, it all goes along SFOS programming and > should be simple to convert later to Silica, when/if it catches up with Qt > versions. > > I guess we can get better integration after it will be simple to install > on other devices and start using it by others. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > >> Hi, >> >> wait a bit, I may have a way to simplify setup. Few days ago, after >> discussion on IRC, I found a way around disappearance of the window when >> wrapped into qxcomposer. So, that blocker is over now. Which means that we >> will be able to craft apps using the latest Qt available in Flatpaks. >> >> Currently, I am looking into >> >> - how we can use regular hybris >> - making a wrapper similar to qxcomposer for Flatpaks. >> >> Shouldn't take too long for an update on status. >> >> Cheers, >> >> Rinigus >> >> On Wed, Jan 1, 2020 at 4:55 PM wrote: >> >>> Could you elaborate on: >>> > libhybris compiled with specification of default >>> hybris-ld-library-path, >>> > content of libexec/droid-hybris added with GL extension. >>> Is that libhybris build available (and safe to run on main device, or >>> should I dig out my j1)? >>> Also not sure what added with GL extension means? Having a browser that >>> uses up to date webengine would be awesome. >>> >>> Thanks and happy new year! >>> szopin >>> >>> On Sunday, 29 December 2019, rinigus wrote: >>> > Hi, >>> > >>> > I would have preferred to stay away from discussion on why do we >>> need/not >>> > need Flatpak on SFOS. But I guess I have to take it as the one working >>> on >>> > making it possible. >>> > >>> > Native apps rely on the libs allowed in the Store and bundle the rest >>> of >>> > them. I presume OSM Scout Server and Pure Maps are exceptions, but >>> they are >>> > built around almost 20 libs bundled with the application and compiled >>> with >>> > newer gcc than the one on the platform. If I would have continued to >>> > provide OSM Scout Server via the official Store, I'd have to bundle >>> > libsystemd as well - something that I found was crossing a line for >>> me. So, >>> > any security issue in those bundled libs would be propagated the same >>> way >>> > as with the Flatpak. I admit that its way less libs than distributed >>> via >>> > Flatpak. However, in the case of Flatpak, apps are provided on the top >>> of >>> > "runtimes" with the app including everything which is extending the >>> runtime >>> > to make it work. So, in case of OSM Scout Server and Pure Maps, their >>> > Flatpaks do include some libs as well. Those runtimes are updated. >>> Now, I >>> > am not in position to say whether its security updates are as fast as >>> of >>> > distros and have no idea how it compares to SFOS. >>> > >>> > However, I see mainly portability and up-to-date toolbox aspect of >>> Flatpak, >>> > not that much security in terms of sandbox. These are my preferences >>> and >>> > they could differ from yours. >>> > >>> > Looking at the speed of upcoming Qt update, I was considering whether >>> to >>> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to >>> allow >>> > us to work on newer browser engine or make Flatpak available. The both >>> > solutions would break look-and-feel of SFOS, but allow us to use >>> current >>> > libs, something that we have been missing for too long. And, in many >>> >
Re: [SailfishDevel] Flatpak for Sailfish
Hi, just finished the first version of a wrapper for 'flatpak run' command as well, available at https://github.com/rinigus/flatpak-runner . Its based on qxcompositor and it opens new Wayland server before running an application, all explained in README. Device rotation is supported and should be followed. So, as it is: - we have to resolve libhybris linker issue to make it possible to distribute. - keyboard is not supported currently. At present, app has to have qtvirtualkeyboard support added as in https://doc.qt.io/qt-5/qtvirtualkeyboard-deployment-guide.html#creating-inputpanel . - only single-window apps are working well, such as QML developed for mobile - no sound so far - probably many other things are missing, haven't bumped into them. Essentially, we will have access to the latest Qt, but would have to write apps for this use. Fortunately, it all goes along SFOS programming and should be simple to convert later to Silica, when/if it catches up with Qt versions. I guess we can get better integration after it will be simple to install on other devices and start using it by others. Cheers, Rinigus On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > Hi, > > wait a bit, I may have a way to simplify setup. Few days ago, after > discussion on IRC, I found a way around disappearance of the window when > wrapped into qxcomposer. So, that blocker is over now. Which means that we > will be able to craft apps using the latest Qt available in Flatpaks. > > Currently, I am looking into > > - how we can use regular hybris > - making a wrapper similar to qxcomposer for Flatpaks. > > Shouldn't take too long for an update on status. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 4:55 PM wrote: > >> Could you elaborate on: >> > libhybris compiled with specification of default hybris-ld-library-path, >> > content of libexec/droid-hybris added with GL extension. >> Is that libhybris build available (and safe to run on main device, or >> should I dig out my j1)? >> Also not sure what added with GL extension means? Having a browser that >> uses up to date webengine would be awesome. >> >> Thanks and happy new year! >> szopin >> >> On Sunday, 29 December 2019, rinigus wrote: >> > Hi, >> > >> > I would have preferred to stay away from discussion on why do we >> need/not >> > need Flatpak on SFOS. But I guess I have to take it as the one working >> on >> > making it possible. >> > >> > Native apps rely on the libs allowed in the Store and bundle the rest of >> > them. I presume OSM Scout Server and Pure Maps are exceptions, but they >> are >> > built around almost 20 libs bundled with the application and compiled >> with >> > newer gcc than the one on the platform. If I would have continued to >> > provide OSM Scout Server via the official Store, I'd have to bundle >> > libsystemd as well - something that I found was crossing a line for me. >> So, >> > any security issue in those bundled libs would be propagated the same >> way >> > as with the Flatpak. I admit that its way less libs than distributed via >> > Flatpak. However, in the case of Flatpak, apps are provided on the top >> of >> > "runtimes" with the app including everything which is extending the >> runtime >> > to make it work. So, in case of OSM Scout Server and Pure Maps, their >> > Flatpaks do include some libs as well. Those runtimes are updated. Now, >> I >> > am not in position to say whether its security updates are as fast as of >> > distros and have no idea how it compares to SFOS. >> > >> > However, I see mainly portability and up-to-date toolbox aspect of >> Flatpak, >> > not that much security in terms of sandbox. These are my preferences and >> > they could differ from yours. >> > >> > Looking at the speed of upcoming Qt update, I was considering whether to >> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to >> allow >> > us to work on newer browser engine or make Flatpak available. The both >> > solutions would break look-and-feel of SFOS, but allow us to use current >> > libs, something that we have been missing for too long. And, in many >> > aspects, we, as developers, waste lot of time to fight against. I swayed >> > towards Flatpaks as it has well developed tools around it, provides >> > portability (you can run it on desktop), and will make sense to have >> when >> > other mobile Linux distros will start going as a way to use the same >> app at >> > all of them. >> > >> > Note that is we develop apps immediately with the reservation that we >> could >> > switch to a native version as soon as it is ready to receive it (in >> terms >> > of Qt version, for example), we can start working on things that are >> > impossible right now on SFOS but may become available later (Qt 5.12?). >> I >> > would expect that this much better than using Android browser on SFOS. >> > >> > Please note that it is not to criticize Jolla regarding the update >> speed of >> > Qt. Its probably a complex process and, as we have all built
Re: [SailfishDevel] Flatpak for Sailfish
Re simplification: To get hybris libs supported, we need to give them through host GL extension. Now, we can mount many filesystems readonly, such as /system and /vendor, as needed. However, /usr is blacklisted and provided via Flatpak runtime with host /usr mounted under /var/run/host/usr. So, for the most part, I can just provide symlinks to regular hybris libs. The main issue is with libhybris/linker/o.so. That linker searches only path as given during compilation and cannot be adjusted. Essentially, I need to provide hybris-ld-library-path as an environment variable. Currently, it is ignored as far as I have tested. In my understanding, the offending line is https://github.com/libhybris/libhybris/blob/master/hybris/common/o/linker_main.cpp#L343. It seems to me that `if (ldpath_env)` should be used instead and if/else blocks swapped. Same goes to the other linkers. If we would get that functioning correctly, libhybris from device could be used as it is and Flatpak could be guided via folders using symlinks and environment variables. Cheers, Rinigus On Wed, Jan 1, 2020 at 5:25 PM rinigus wrote: > Hi, > > wait a bit, I may have a way to simplify setup. Few days ago, after > discussion on IRC, I found a way around disappearance of the window when > wrapped into qxcomposer. So, that blocker is over now. Which means that we > will be able to craft apps using the latest Qt available in Flatpaks. > > Currently, I am looking into > > - how we can use regular hybris > - making a wrapper similar to qxcomposer for Flatpaks. > > Shouldn't take too long for an update on status. > > Cheers, > > Rinigus > > On Wed, Jan 1, 2020 at 4:55 PM wrote: > >> Could you elaborate on: >> > libhybris compiled with specification of default hybris-ld-library-path, >> > content of libexec/droid-hybris added with GL extension. >> Is that libhybris build available (and safe to run on main device, or >> should I dig out my j1)? >> Also not sure what added with GL extension means? Having a browser that >> uses up to date webengine would be awesome. >> >> Thanks and happy new year! >> szopin >> >> On Sunday, 29 December 2019, rinigus wrote: >> > Hi, >> > >> > I would have preferred to stay away from discussion on why do we >> need/not >> > need Flatpak on SFOS. But I guess I have to take it as the one working >> on >> > making it possible. >> > >> > Native apps rely on the libs allowed in the Store and bundle the rest of >> > them. I presume OSM Scout Server and Pure Maps are exceptions, but they >> are >> > built around almost 20 libs bundled with the application and compiled >> with >> > newer gcc than the one on the platform. If I would have continued to >> > provide OSM Scout Server via the official Store, I'd have to bundle >> > libsystemd as well - something that I found was crossing a line for me. >> So, >> > any security issue in those bundled libs would be propagated the same >> way >> > as with the Flatpak. I admit that its way less libs than distributed via >> > Flatpak. However, in the case of Flatpak, apps are provided on the top >> of >> > "runtimes" with the app including everything which is extending the >> runtime >> > to make it work. So, in case of OSM Scout Server and Pure Maps, their >> > Flatpaks do include some libs as well. Those runtimes are updated. Now, >> I >> > am not in position to say whether its security updates are as fast as of >> > distros and have no idea how it compares to SFOS. >> > >> > However, I see mainly portability and up-to-date toolbox aspect of >> Flatpak, >> > not that much security in terms of sandbox. These are my preferences and >> > they could differ from yours. >> > >> > Looking at the speed of upcoming Qt update, I was considering whether to >> > make qt5.12 (or later) in /opt (/home/opt) and use it from there to >> allow >> > us to work on newer browser engine or make Flatpak available. The both >> > solutions would break look-and-feel of SFOS, but allow us to use current >> > libs, something that we have been missing for too long. And, in many >> > aspects, we, as developers, waste lot of time to fight against. I swayed >> > towards Flatpaks as it has well developed tools around it, provides >> > portability (you can run it on desktop), and will make sense to have >> when >> > other mobile Linux distros will start going as a way to use the same >> app at >> > all of them. >> > >> > Note that is we develop apps immediately with the reservation that we >> could >> > switch to a native version as soon as it is ready to receive it (in >> terms >> > of Qt version, for example), we can start working on things that are >> > impossible right now on SFOS but may become available later (Qt 5.12?). >> I >> > would expect that this much better than using Android browser on SFOS. >> > >> > Please note that it is not to criticize Jolla regarding the update >> speed of >> > Qt. Its probably a complex process and, as we have all built around it, >> may >> > break few things to put it
Re: [SailfishDevel] Flatpak for Sailfish
Hi, wait a bit, I may have a way to simplify setup. Few days ago, after discussion on IRC, I found a way around disappearance of the window when wrapped into qxcomposer. So, that blocker is over now. Which means that we will be able to craft apps using the latest Qt available in Flatpaks. Currently, I am looking into - how we can use regular hybris - making a wrapper similar to qxcomposer for Flatpaks. Shouldn't take too long for an update on status. Cheers, Rinigus On Wed, Jan 1, 2020 at 4:55 PM wrote: > Could you elaborate on: > > libhybris compiled with specification of default hybris-ld-library-path, > > content of libexec/droid-hybris added with GL extension. > Is that libhybris build available (and safe to run on main device, or > should I dig out my j1)? > Also not sure what added with GL extension means? Having a browser that > uses up to date webengine would be awesome. > > Thanks and happy new year! > szopin > > On Sunday, 29 December 2019, rinigus wrote: > > Hi, > > > > I would have preferred to stay away from discussion on why do we need/not > > need Flatpak on SFOS. But I guess I have to take it as the one working on > > making it possible. > > > > Native apps rely on the libs allowed in the Store and bundle the rest of > > them. I presume OSM Scout Server and Pure Maps are exceptions, but they > are > > built around almost 20 libs bundled with the application and compiled > with > > newer gcc than the one on the platform. If I would have continued to > > provide OSM Scout Server via the official Store, I'd have to bundle > > libsystemd as well - something that I found was crossing a line for me. > So, > > any security issue in those bundled libs would be propagated the same way > > as with the Flatpak. I admit that its way less libs than distributed via > > Flatpak. However, in the case of Flatpak, apps are provided on the top of > > "runtimes" with the app including everything which is extending the > runtime > > to make it work. So, in case of OSM Scout Server and Pure Maps, their > > Flatpaks do include some libs as well. Those runtimes are updated. Now, I > > am not in position to say whether its security updates are as fast as of > > distros and have no idea how it compares to SFOS. > > > > However, I see mainly portability and up-to-date toolbox aspect of > Flatpak, > > not that much security in terms of sandbox. These are my preferences and > > they could differ from yours. > > > > Looking at the speed of upcoming Qt update, I was considering whether to > > make qt5.12 (or later) in /opt (/home/opt) and use it from there to allow > > us to work on newer browser engine or make Flatpak available. The both > > solutions would break look-and-feel of SFOS, but allow us to use current > > libs, something that we have been missing for too long. And, in many > > aspects, we, as developers, waste lot of time to fight against. I swayed > > towards Flatpaks as it has well developed tools around it, provides > > portability (you can run it on desktop), and will make sense to have when > > other mobile Linux distros will start going as a way to use the same app > at > > all of them. > > > > Note that is we develop apps immediately with the reservation that we > could > > switch to a native version as soon as it is ready to receive it (in terms > > of Qt version, for example), we can start working on things that are > > impossible right now on SFOS but may become available later (Qt 5.12?). I > > would expect that this much better than using Android browser on SFOS. > > > > Please note that it is not to criticize Jolla regarding the update speed > of > > Qt. Its probably a complex process and, as we have all built around it, > may > > break few things to put it mildly. But a large part of my work as a > > developer on SFOS is around incompatibilities imposed by old libs and > gcc. > > So, from developer POV, its important to prioritize Qt update as much as > > possible. Not sure how much we can help with it, but that's probably > > separate discussion (please start it if you wish). > > > > Sorry for long post, please see my previous ones on technical issues that > > we currently face. > > > > As for latest state: > > > > Test browser that I can run is executed with: > > > > QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host --device=all > > > --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris > > > --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker > > org.qutebrowser.qutebrowser together.jolla.com > > > > libhybris compiled with specification of default hybris-ld-library-path, > > content of libexec/droid-hybris added with GL extension. > > > > Cheers, > > > > Rinigus > > > > > > > > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg < > > es.rosenberg+sailfishos@gmail.com> wrote: > > > > > Native apps rely on the libs shipped with the OS, thus they don't ship > > > with unsecure libs unless Jolla is shipping them
Re: [SailfishDevel] Flatpak for Sailfish
Could you elaborate on: > libhybris compiled with specification of default hybris-ld-library-path, > content of libexec/droid-hybris added with GL extension. Is that libhybris build available (and safe to run on main device, or should I dig out my j1)? Also not sure what added with GL extension means? Having a browser that uses up to date webengine would be awesome. Thanks and happy new year! szopin On Sunday, 29 December 2019, rinigus wrote: > Hi, > > I would have preferred to stay away from discussion on why do we need/not > need Flatpak on SFOS. But I guess I have to take it as the one working on > making it possible. > > Native apps rely on the libs allowed in the Store and bundle the rest of > them. I presume OSM Scout Server and Pure Maps are exceptions, but they are > built around almost 20 libs bundled with the application and compiled with > newer gcc than the one on the platform. If I would have continued to > provide OSM Scout Server via the official Store, I'd have to bundle > libsystemd as well - something that I found was crossing a line for me. So, > any security issue in those bundled libs would be propagated the same way > as with the Flatpak. I admit that its way less libs than distributed via > Flatpak. However, in the case of Flatpak, apps are provided on the top of > "runtimes" with the app including everything which is extending the runtime > to make it work. So, in case of OSM Scout Server and Pure Maps, their > Flatpaks do include some libs as well. Those runtimes are updated. Now, I > am not in position to say whether its security updates are as fast as of > distros and have no idea how it compares to SFOS. > > However, I see mainly portability and up-to-date toolbox aspect of Flatpak, > not that much security in terms of sandbox. These are my preferences and > they could differ from yours. > > Looking at the speed of upcoming Qt update, I was considering whether to > make qt5.12 (or later) in /opt (/home/opt) and use it from there to allow > us to work on newer browser engine or make Flatpak available. The both > solutions would break look-and-feel of SFOS, but allow us to use current > libs, something that we have been missing for too long. And, in many > aspects, we, as developers, waste lot of time to fight against. I swayed > towards Flatpaks as it has well developed tools around it, provides > portability (you can run it on desktop), and will make sense to have when > other mobile Linux distros will start going as a way to use the same app at > all of them. > > Note that is we develop apps immediately with the reservation that we could > switch to a native version as soon as it is ready to receive it (in terms > of Qt version, for example), we can start working on things that are > impossible right now on SFOS but may become available later (Qt 5.12?). I > would expect that this much better than using Android browser on SFOS. > > Please note that it is not to criticize Jolla regarding the update speed of > Qt. Its probably a complex process and, as we have all built around it, may > break few things to put it mildly. But a large part of my work as a > developer on SFOS is around incompatibilities imposed by old libs and gcc. > So, from developer POV, its important to prioritize Qt update as much as > possible. Not sure how much we can help with it, but that's probably > separate discussion (please start it if you wish). > > Sorry for long post, please see my previous ones on technical issues that > we currently face. > > As for latest state: > > Test browser that I can run is executed with: > > QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host --device=all > --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris > --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker > org.qutebrowser.qutebrowser together.jolla.com > > libhybris compiled with specification of default hybris-ld-library-path, > content of libexec/droid-hybris added with GL extension. > > Cheers, > > Rinigus > > > > On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg < > es.rosenberg+sailfishos@gmail.com> wrote: > > > Native apps rely on the libs shipped with the OS, thus they don't ship > > with unsecure libs unless Jolla is shipping them and they become secure the > > moment Jolla updated the libs (and should the update break binary > > compatibility will require a new release compiled against the new libs). > > Flatpacks and snaps are security nightmares, instead of getting them lets > > work on moving the SFOS platform along. > > > > Op zo 29 dec. 2019 om 20:41 schreef rinigus : > > > >> Hi, > >> > >> If you refer to http://flatkill.org/ , it does have lot of good points. > >> In this respect, its similar to what we have with the native apps, as soon > >> as some security flaws are used. At the moment, I would prefer to get > >> access to the latest Qt and other recent software. But users are still > >> responsible for
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I would have preferred to stay away from discussion on why do we need/not need Flatpak on SFOS. But I guess I have to take it as the one working on making it possible. Native apps rely on the libs allowed in the Store and bundle the rest of them. I presume OSM Scout Server and Pure Maps are exceptions, but they are built around almost 20 libs bundled with the application and compiled with newer gcc than the one on the platform. If I would have continued to provide OSM Scout Server via the official Store, I'd have to bundle libsystemd as well - something that I found was crossing a line for me. So, any security issue in those bundled libs would be propagated the same way as with the Flatpak. I admit that its way less libs than distributed via Flatpak. However, in the case of Flatpak, apps are provided on the top of "runtimes" with the app including everything which is extending the runtime to make it work. So, in case of OSM Scout Server and Pure Maps, their Flatpaks do include some libs as well. Those runtimes are updated. Now, I am not in position to say whether its security updates are as fast as of distros and have no idea how it compares to SFOS. However, I see mainly portability and up-to-date toolbox aspect of Flatpak, not that much security in terms of sandbox. These are my preferences and they could differ from yours. Looking at the speed of upcoming Qt update, I was considering whether to make qt5.12 (or later) in /opt (/home/opt) and use it from there to allow us to work on newer browser engine or make Flatpak available. The both solutions would break look-and-feel of SFOS, but allow us to use current libs, something that we have been missing for too long. And, in many aspects, we, as developers, waste lot of time to fight against. I swayed towards Flatpaks as it has well developed tools around it, provides portability (you can run it on desktop), and will make sense to have when other mobile Linux distros will start going as a way to use the same app at all of them. Note that is we develop apps immediately with the reservation that we could switch to a native version as soon as it is ready to receive it (in terms of Qt version, for example), we can start working on things that are impossible right now on SFOS but may become available later (Qt 5.12?). I would expect that this much better than using Android browser on SFOS. Please note that it is not to criticize Jolla regarding the update speed of Qt. Its probably a complex process and, as we have all built around it, may break few things to put it mildly. But a large part of my work as a developer on SFOS is around incompatibilities imposed by old libs and gcc. So, from developer POV, its important to prioritize Qt update as much as possible. Not sure how much we can help with it, but that's probably separate discussion (please start it if you wish). Sorry for long post, please see my previous ones on technical issues that we currently face. As for latest state: Test browser that I can run is executed with: QT_WAYLAND_FORCE_DPI=physical flatpak run --filesystem=host --device=all --env=HYBRIS_EGLPLATFORM_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris --env=HYBRIS_LINKER_DIR=/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker org.qutebrowser.qutebrowser together.jolla.com libhybris compiled with specification of default hybris-ld-library-path, content of libexec/droid-hybris added with GL extension. Cheers, Rinigus On Sun, Dec 29, 2019 at 9:26 PM E.S. Rosenberg < es.rosenberg+sailfishos@gmail.com> wrote: > Native apps rely on the libs shipped with the OS, thus they don't ship > with unsecure libs unless Jolla is shipping them and they become secure the > moment Jolla updated the libs (and should the update break binary > compatibility will require a new release compiled against the new libs). > Flatpacks and snaps are security nightmares, instead of getting them lets > work on moving the SFOS platform along. > > Op zo 29 dec. 2019 om 20:41 schreef rinigus : > >> Hi, >> >> If you refer to http://flatkill.org/ , it does have lot of good points. >> In this respect, its similar to what we have with the native apps, as soon >> as some security flaws are used. At the moment, I would prefer to get >> access to the latest Qt and other recent software. But users are still >> responsible for thinking before installing, as they are now. Note that in >> many aspects our current packaging together with bundled libs is similar to >> flatpak already. So, why not to make it with the recent libs as well? >> >> Cheers, >> >> Rinigus >> >> >> On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg < >> es.rosenberg+sailfishos@gmail.com> wrote: >> >>> No one is bothered by the serious (bad) security implications of running >>> flatpacks? >>> Though I guess we are all tolerating the claim to "security" on ancient >>> kernels so we have no right to blab about security now 樂 >>> >>> Op za 28 dec. 2019 om 12:04 schreef rinigus :
Re: [SailfishDevel] Flatpak for Sailfish
Native apps rely on the libs shipped with the OS, thus they don't ship with unsecure libs unless Jolla is shipping them and they become secure the moment Jolla updated the libs (and should the update break binary compatibility will require a new release compiled against the new libs). Flatpacks and snaps are security nightmares, instead of getting them lets work on moving the SFOS platform along. Op zo 29 dec. 2019 om 20:41 schreef rinigus : > Hi, > > If you refer to http://flatkill.org/ , it does have lot of good points. > In this respect, its similar to what we have with the native apps, as soon > as some security flaws are used. At the moment, I would prefer to get > access to the latest Qt and other recent software. But users are still > responsible for thinking before installing, as they are now. Note that in > many aspects our current packaging together with bundled libs is similar to > flatpak already. So, why not to make it with the recent libs as well? > > Cheers, > > Rinigus > > > On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg < > es.rosenberg+sailfishos@gmail.com> wrote: > >> No one is bothered by the serious (bad) security implications of running >> flatpacks? >> Though I guess we are all tolerating the claim to "security" on ancient >> kernels so we have no right to blab about security now 樂 >> >> Op za 28 dec. 2019 om 12:04 schreef rinigus : >> >>> Hi, >>> >>> I am not 100% sure whether xdg-shell availability is the blocker. There >>> is something going on which I cannot explain yet - its as if Wayland >>> rendering disappears even when I use qxcomposer. >>> >>> qxcomposer does allow me to minimize and then restore. However, when >>> keeping app minimized and switching to other apps, I do get (with >>> WAYLAND_DEBUG=1) >>> >>> [2294832.935] wl_pointer@8.motion(207667, 0.00, 0.00) >>> [2299966.213] qt_extended_surface@29.onscreen_visibility(1) >>> [2303645.301] qt_extended_surface@29.onscreen_visibility(0) >>> [2303647.486] -> wl_surface@26.destroy() >>> [2303648.296] -> wl_buffer@4278190080.destroy() >>> [2303648.395] -> wl_buffer@4278190082.destroy() >>> [2303648.448] -> wl_buffer@4278190081.destroy() >>> >>> and the app window disappears from qxcomposer. >>> >>> Same happens when running directly using SFOS composer: >>> >>> [2614530.331] qt_extended_surface@29.onscreen_visibility(0) >>> [2614552.802] -> wl_surface@26.destroy() >>> [2614555.653] -> wl_buffer@4278190080.destroy() >>> [2614556.795] -> wl_buffer@4278190082.destroy() >>> [2614557.099] -> wl_buffer@4278190081.destroy() >>> >>> So, looks like the surface gets destroyed, but nothing really restores >>> it. >>> >>> As such, some kind of wrapper, similar to qxcomposer, around Flatpak >>> programs maybe handy. It could take few tasks, such as >>> >>> - follow orientation of the screen >>> - restore app after wl_buffer.destroy() >>> - provide keyboard support >>> >>> I don't know enough about Wayland to be efficient in working on it. So, >>> I wonder if someone would like to step in and help with this part. If there >>> is interest, I will work on packaging libhybris extension and provide an >>> example at OBS for Xperia Tama devices. >>> >>> Cheers, >>> >>> Rinigus >>> >>> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste >>> wrote: >>> Thank you Rinigus for all of this. Indeed, the current main blocker seems to be the fact that xdg-shell is not available in Lipstick. This is linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! They already have a 5.9 branch in SailfishOS git ( https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need to wait for Jolla to make the Qt switch. I don't think it's something community can change on device... I hope I can be proven wrong though. Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org >>> >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, If you refer to http://flatkill.org/ , it does have lot of good points. In this respect, its similar to what we have with the native apps, as soon as some security flaws are used. At the moment, I would prefer to get access to the latest Qt and other recent software. But users are still responsible for thinking before installing, as they are now. Note that in many aspects our current packaging together with bundled libs is similar to flatpak already. So, why not to make it with the recent libs as well? Cheers, Rinigus On Sun, Dec 29, 2019 at 8:26 PM E.S. Rosenberg < es.rosenberg+sailfishos@gmail.com> wrote: > No one is bothered by the serious (bad) security implications of running > flatpacks? > Though I guess we are all tolerating the claim to "security" on ancient > kernels so we have no right to blab about security now 樂 > > Op za 28 dec. 2019 om 12:04 schreef rinigus : > >> Hi, >> >> I am not 100% sure whether xdg-shell availability is the blocker. There >> is something going on which I cannot explain yet - its as if Wayland >> rendering disappears even when I use qxcomposer. >> >> qxcomposer does allow me to minimize and then restore. However, when >> keeping app minimized and switching to other apps, I do get (with >> WAYLAND_DEBUG=1) >> >> [2294832.935] wl_pointer@8.motion(207667, 0.00, 0.00) >> [2299966.213] qt_extended_surface@29.onscreen_visibility(1) >> [2303645.301] qt_extended_surface@29.onscreen_visibility(0) >> [2303647.486] -> wl_surface@26.destroy() >> [2303648.296] -> wl_buffer@4278190080.destroy() >> [2303648.395] -> wl_buffer@4278190082.destroy() >> [2303648.448] -> wl_buffer@4278190081.destroy() >> >> and the app window disappears from qxcomposer. >> >> Same happens when running directly using SFOS composer: >> >> [2614530.331] qt_extended_surface@29.onscreen_visibility(0) >> [2614552.802] -> wl_surface@26.destroy() >> [2614555.653] -> wl_buffer@4278190080.destroy() >> [2614556.795] -> wl_buffer@4278190082.destroy() >> [2614557.099] -> wl_buffer@4278190081.destroy() >> >> So, looks like the surface gets destroyed, but nothing really restores it. >> >> As such, some kind of wrapper, similar to qxcomposer, around Flatpak >> programs maybe handy. It could take few tasks, such as >> >> - follow orientation of the screen >> - restore app after wl_buffer.destroy() >> - provide keyboard support >> >> I don't know enough about Wayland to be efficient in working on it. So, I >> wonder if someone would like to step in and help with this part. If there >> is interest, I will work on packaging libhybris extension and provide an >> example at OBS for Xperia Tama devices. >> >> Cheers, >> >> Rinigus >> >> On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste wrote: >> >>> Thank you Rinigus for all of this. Indeed, the current main blocker >>> seems to be the fact that xdg-shell is not available in Lipstick. This is >>> linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! >>> They already have a 5.9 branch in SailfishOS git ( >>> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we >>> need to wait for Jolla to make the Qt switch. I don't think it's something >>> community can change on device... I hope I can be proven wrong though. >>> >>> Damien. >>> ___ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
No one is bothered by the serious (bad) security implications of running flatpacks? Though I guess we are all tolerating the claim to "security" on ancient kernels so we have no right to blab about security now 樂 Op za 28 dec. 2019 om 12:04 schreef rinigus : > Hi, > > I am not 100% sure whether xdg-shell availability is the blocker. There is > something going on which I cannot explain yet - its as if Wayland rendering > disappears even when I use qxcomposer. > > qxcomposer does allow me to minimize and then restore. However, when > keeping app minimized and switching to other apps, I do get (with > WAYLAND_DEBUG=1) > > [2294832.935] wl_pointer@8.motion(207667, 0.00, 0.00) > [2299966.213] qt_extended_surface@29.onscreen_visibility(1) > [2303645.301] qt_extended_surface@29.onscreen_visibility(0) > [2303647.486] -> wl_surface@26.destroy() > [2303648.296] -> wl_buffer@4278190080.destroy() > [2303648.395] -> wl_buffer@4278190082.destroy() > [2303648.448] -> wl_buffer@4278190081.destroy() > > and the app window disappears from qxcomposer. > > Same happens when running directly using SFOS composer: > > [2614530.331] qt_extended_surface@29.onscreen_visibility(0) > [2614552.802] -> wl_surface@26.destroy() > [2614555.653] -> wl_buffer@4278190080.destroy() > [2614556.795] -> wl_buffer@4278190082.destroy() > [2614557.099] -> wl_buffer@4278190081.destroy() > > So, looks like the surface gets destroyed, but nothing really restores it. > > As such, some kind of wrapper, similar to qxcomposer, around Flatpak > programs maybe handy. It could take few tasks, such as > > - follow orientation of the screen > - restore app after wl_buffer.destroy() > - provide keyboard support > > I don't know enough about Wayland to be efficient in working on it. So, I > wonder if someone would like to step in and help with this part. If there > is interest, I will work on packaging libhybris extension and provide an > example at OBS for Xperia Tama devices. > > Cheers, > > Rinigus > > On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste wrote: > >> Thank you Rinigus for all of this. Indeed, the current main blocker seems >> to be the fact that xdg-shell is not available in Lipstick. This is linked >> to the ancient version of QtWayland, even not 5.6, but still 5.4 ! They >> already have a 5.9 branch in SailfishOS git ( >> https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need >> to wait for Jolla to make the Qt switch. I don't think it's something >> community can change on device... I hope I can be proven wrong though. >> >> Damien. >> ___ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Hi, I am not 100% sure whether xdg-shell availability is the blocker. There is something going on which I cannot explain yet - its as if Wayland rendering disappears even when I use qxcomposer. qxcomposer does allow me to minimize and then restore. However, when keeping app minimized and switching to other apps, I do get (with WAYLAND_DEBUG=1) [2294832.935] wl_pointer@8.motion(207667, 0.00, 0.00) [2299966.213] qt_extended_surface@29.onscreen_visibility(1) [2303645.301] qt_extended_surface@29.onscreen_visibility(0) [2303647.486] -> wl_surface@26.destroy() [2303648.296] -> wl_buffer@4278190080.destroy() [2303648.395] -> wl_buffer@4278190082.destroy() [2303648.448] -> wl_buffer@4278190081.destroy() and the app window disappears from qxcomposer. Same happens when running directly using SFOS composer: [2614530.331] qt_extended_surface@29.onscreen_visibility(0) [2614552.802] -> wl_surface@26.destroy() [2614555.653] -> wl_buffer@4278190080.destroy() [2614556.795] -> wl_buffer@4278190082.destroy() [2614557.099] -> wl_buffer@4278190081.destroy() So, looks like the surface gets destroyed, but nothing really restores it. As such, some kind of wrapper, similar to qxcomposer, around Flatpak programs maybe handy. It could take few tasks, such as - follow orientation of the screen - restore app after wl_buffer.destroy() - provide keyboard support I don't know enough about Wayland to be efficient in working on it. So, I wonder if someone would like to step in and help with this part. If there is interest, I will work on packaging libhybris extension and provide an example at OBS for Xperia Tama devices. Cheers, Rinigus On Sat, Dec 28, 2019 at 12:54 AM Damien Caliste wrote: > Thank you Rinigus for all of this. Indeed, the current main blocker seems > to be the fact that xdg-shell is not available in Lipstick. This is linked > to the ancient version of QtWayland, even not 5.6, but still 5.4 ! They > already have a 5.9 branch in SailfishOS git ( > https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need > to wait for Jolla to make the Qt switch. I don't think it's something > community can change on device... I hope I can be proven wrong though. > > Damien. > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Thank you Rinigus for all of this. Indeed, the current main blocker seems to be the fact that xdg-shell is not available in Lipstick. This is linked to the ancient version of QtWayland, even not 5.6, but still 5.4 ! They already have a 5.9 branch in SailfishOS git (https://git.sailfishos.org/mer-core/qtwayland/tree/mer-5.9), but we need to wait for Jolla to make the Qt switch. I don't think it's something community can change on device... I hope I can be proven wrong though. Damien. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
If you can provide a basic.qml for a portal for x, pretty sure tons of people will be able to help with portals for y (still no idea how that would work with the whole virtualization, but hopefully only you need to do the hard carry and rest can help with the localization/copy pasting stuff) On Friday, 27 December 2019, rinigus wrote: > Yes, pretty much GUI allowing access to files and other sandboxed > functions. See https://github.com/flatpak/flatpak/wiki/Portals > > Rinigus > > On Fri, Dec 27, 2019 at 9:43 PM wrote: > > > 'writing portals' would mean? Like qml files to handle i/o? > > > > > > On Friday, 27 December 2019, rinigus wrote: > > > That was exactly the thought behind it. There will be work to do, such as > > > writing portals, but we need to get compositor issue fixed first. Or use > > > some separate one... > > > > > > Rinigus > > > > > > On Fri, Dec 27, 2019 at 9:17 PM wrote: > > > > > > > This is amazing, if there is something I can do to help please let me > > > > know, not being tied to os version of qt is awesome, we could maybe > > get a > > > > proper browser with this? Hope leszek is on the list > > > > > > > > > > > > > > > -- > > Sent from my Jolla > > ___ > > SailfishOS.org Devel mailing list > > To unsubscribe, please send a mail to > > devel-unsubscr...@lists.sailfishos.org > -- Sent from my Jolla ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
Yes, pretty much GUI allowing access to files and other sandboxed functions. See https://github.com/flatpak/flatpak/wiki/Portals Rinigus On Fri, Dec 27, 2019 at 9:43 PM wrote: > 'writing portals' would mean? Like qml files to handle i/o? > > > On Friday, 27 December 2019, rinigus wrote: > > That was exactly the thought behind it. There will be work to do, such as > > writing portals, but we need to get compositor issue fixed first. Or use > > some separate one... > > > > Rinigus > > > > On Fri, Dec 27, 2019 at 9:17 PM wrote: > > > > > This is amazing, if there is something I can do to help please let me > > > know, not being tied to os version of qt is awesome, we could maybe > get a > > > proper browser with this? Hope leszek is on the list > > > > > > > > > > -- > Sent from my Jolla > ___ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
'writing portals' would mean? Like qml files to handle i/o? On Friday, 27 December 2019, rinigus wrote: > That was exactly the thought behind it. There will be work to do, such as > writing portals, but we need to get compositor issue fixed first. Or use > some separate one... > > Rinigus > > On Fri, Dec 27, 2019 at 9:17 PM wrote: > > > This is amazing, if there is something I can do to help please let me > > know, not being tied to os version of qt is awesome, we could maybe get a > > proper browser with this? Hope leszek is on the list > > > > > -- Sent from my Jolla ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
That was exactly the thought behind it. There will be work to do, such as writing portals, but we need to get compositor issue fixed first. Or use some separate one... Rinigus On Fri, Dec 27, 2019 at 9:17 PM wrote: > This is amazing, if there is something I can do to help please let me > know, not being tied to os version of qt is awesome, we could maybe get a > proper browser with this? Hope leszek is on the list > > ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
This is amazing, if there is something I can do to help please let me know, not being tied to os version of qt is awesome, we could maybe get a proper browser with this? Hope leszek is on the list On Friday, 27 December 2019, rinigus wrote: > I have a breakthrough. Had to compile libhybris with > > --with-default-hybris-ld-library-path=/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris/system/lib:/vendor/lib:/system/lib:/odm/lib > > and enable "--filesystem=host --device=all" in "flatpak run". As a result, > I have some Qt flatpak apps running. While Falkon does crash on init, > qutebrowser > started. > > Few issues: > > Keyboard: > Enabling Qt Virtual Keyboard with QT_IM_MODULE=qtvirtualkeyboard makes it > crash though, with a message > > 19:48:20 WARNING: requestActivate() called for > QtVirtualKeyboard::InputView(0xe9150998) which has > Qt::WindowDoesNotAcceptFocus set. > > and flashing virtual keyboard on screen for a moment. I guess, we will have > to use > QML InputPanel to make it work for now. > > > Minimizing: > When you minimize an application, you get the application minimized into > small live icon and you get a message in terminal > > 20:25:39 WARNING: Minimizing is not supported on wl-shell. Consider using > xdg-shell instead. > 20:25:39 WARNING: Wayland does not support QWindow::requestActivate() > > You can restore application immediately from small representation of it. > However, if you had lockscreen or some other app over it, the icon > disappears and its impossible to get the window back. At the same time, the > application keeps running. qxcompositor does help, as apps are not > minimized when staying on Wayland screen over there. > > So, to summarize: > > 1. Flatpak applications can run on SFOS. > > 2. We need to move away from wl-shell and get to the non-deprecated > composer option (fixing minimizing and restoring applications). That will > enable Gdk apps as well. > > 3. Ideally, libhybris should allow to specify hybris-ld-library-path during > runtime. Otherwise, we have to compile separate versions of hybris - one > for device and one for flatpaks. On device, two copies are needed anyway > (probably hardlinking will work as well). > > 4. Keyboard will need some work. I presume that by moving to supported > composer we could get around it with qt virtual keyboard. There is a > workaround for our apps, if needed. For native look, if possible, someone > will have to comment. > > Looks like #2 is a breaker right now and I don't know if it is possible to > fix anytime soon. > > Cheers, > > Rinigus > -- Sent from my Jolla ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
I have a breakthrough. Had to compile libhybris with --with-default-hybris-ld-library-path=/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris/system/lib:/vendor/lib:/system/lib:/odm/lib and enable "--filesystem=host --device=all" in "flatpak run". As a result, I have some Qt flatpak apps running. While Falkon does crash on init, qutebrowser started. Few issues: Keyboard: Enabling Qt Virtual Keyboard with QT_IM_MODULE=qtvirtualkeyboard makes it crash though, with a message 19:48:20 WARNING: requestActivate() called for QtVirtualKeyboard::InputView(0xe9150998) which has Qt::WindowDoesNotAcceptFocus set. and flashing virtual keyboard on screen for a moment. I guess, we will have to use QML InputPanel to make it work for now. Minimizing: When you minimize an application, you get the application minimized into small live icon and you get a message in terminal 20:25:39 WARNING: Minimizing is not supported on wl-shell. Consider using xdg-shell instead. 20:25:39 WARNING: Wayland does not support QWindow::requestActivate() You can restore application immediately from small representation of it. However, if you had lockscreen or some other app over it, the icon disappears and its impossible to get the window back. At the same time, the application keeps running. qxcompositor does help, as apps are not minimized when staying on Wayland screen over there. So, to summarize: 1. Flatpak applications can run on SFOS. 2. We need to move away from wl-shell and get to the non-deprecated composer option (fixing minimizing and restoring applications). That will enable Gdk apps as well. 3. Ideally, libhybris should allow to specify hybris-ld-library-path during runtime. Otherwise, we have to compile separate versions of hybris - one for device and one for flatpaks. On device, two copies are needed anyway (probably hardlinking will work as well). 4. Keyboard will need some work. I presume that by moving to supported composer we could get around it with qt virtual keyboard. There is a workaround for our apps, if needed. For native look, if possible, someone will have to comment. Looks like #2 is a breaker right now and I don't know if it is possible to fix anytime soon. Cheers, Rinigus ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Flatpak for Sailfish
>From comparing logs of normal apps and the app in Flatpak sasndbox, looks
like sandboxed app does not find /usr/libexec/droid-hybris. Is there a way
to let it search under
>
/usr/lib/arm-linux-gnueabihf/GL/default/libexec/droid-hybris
instead? Any env variable to tune? Seems like HYBRIS_LD_LIBRARY_PATH is
ignored while AT_SECURE is zero.
Corresponding part of strace:
openat(AT_FDCWD,
"/usr/lib/arm-linux-gnueabihf/GL/default/lib/libhybris/linker/o.so",
O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
read(3,
"\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0|\370\0\0004\0\0\0"..., 512)
= 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=221216, ...}) = 0
mmap2(NULL, 306916, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xe2f9f000
mprotect(0xe2fd4000, 61440, PROT_NONE) = 0
mmap2(0xe2fe3000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x34000) = 0xe2fe3000
mmap2(0xe2fe5000, 20196, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xe2fe5000
close(3)= 0
mprotect(0xe2fe3000, 4096, PROT_READ) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) =
0xeae5e000
prctl(PR_SET_VMA, 0, 0xeae5e000, 0x1000, 0xe2fcd60c) = 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/libexec", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/usr/libexec/droid-hybris", 0xfff54d18) = -1 ENOENT (No such file
or directory)
lstat64("/vendor", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64("/vendor/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
Cheers,
Rinigus
PS:
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
