New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate away from openbox and compton #1011

Open
agaida opened this Issue Apr 3, 2016 · 143 comments

Comments

Projects
@agaida
Member

agaida commented Apr 3, 2016

hi, i would like to suggest to move/migrate away from openbox/compton to xfwm4 as our recommend WM. Reasons: openbox as lowest common nominator don't make sense anymore, xfwm4 is available for all major linux and bsd distributions. compton is stalled and out of date in the most distributions. i would go a step further and say it is dead. Both are not ready for wayland. I know that xfwm4 isn't too but there are more chances that xfwm4 will be ready for Wayland. For the time beeing xfwm4 is the far more capable WM without the need for packages like obconf-qt and compton-conf, so it would ease our development.

@jleclanche

This comment has been minimized.

Contributor

jleclanche commented Apr 3, 2016

What are the advantages of xfwm4 over openbox?

@Esclapion

This comment has been minimized.

Esclapion commented Apr 3, 2016

xfwm4 depends on gtk2 and gtk3, not qt5 ?

@tsujan

This comment has been minimized.

Member

tsujan commented Apr 3, 2016

openbox as lowest common nominator don't make sense anymore

In which sense doesn't it make sense when it's so configurable?

compton is stalled and out of date in the most distributions

That may be true but it still works without problem here.

@Vladimir-csp

This comment has been minimized.

Vladimir-csp commented Apr 3, 2016

Openbox is feature-complete, stable, lightweight, does not depend on whole giant toolkit. There is just nothing more to develop in it, but it is mainained. And it also has some killer features like the way it handles keyboard shortcuts and advanced window management actions, window rules (would be nice to support it via GUI akin obapps btw). Compton is now pretty stable. Both are extremely lightweight.
If not this whole Wayland thing, they could go on forever. Until anything remotely comparable emerges, Openbox is the best choice on X.
Xfwm4 depends on GTK2 and xfce components like xfconf - an ananlog of GNOME's gconf/dconf, which is an analog of you-know-whose registry. I don't think it is worth to depend on such horrors. :)

@ghost

This comment has been minimized.

ghost commented Apr 3, 2016

What are the advantages of xfwm4 over openbox?

probably wayland support also with a possible gtk3 port comes scaling/hidpi support since openbox has some great disadvantages on hidpi(max button size is ~14px? wich is ~7px on hidpi)

there are some alternatives:

@Vladimir-csp

This comment has been minimized.

Vladimir-csp commented Apr 3, 2016

I would suggest creating LXQt module that would work similar to wmctrl - interact with a EWMH/NetWM compatible X Window Manager (or use wmctrl itself) for governing windows in response to events or keyboard shortcuts.
This would decouple LXQt from specific WM, so that any compatible WM with blanked out shortcut configuration would fit right in with minimal tweaks.

@manjarqo

This comment has been minimized.

manjarqo commented May 4, 2016

It is good idea, as for me, i have removed openbox and obconf and install xfwm4 it lightweight too, my system eating 250 Mb memory, and looks great

@agaida

This comment has been minimized.

Member

agaida commented May 4, 2016

@Vladimir-csp: sounds good
@ALL: one could consider the project compton dead - no release for few years and the last commit end of 2015. The bugtracker is not about solving bugs but about how great compton is - not the best base to build a modern desktop environment.

I mentioned xfwm4 because it simply work and is available in nearly all distributions including *bsd, it provides edge snapping, a compositor and other nice features. It would be not the best possible solution, but a good lowest common denominator.

@jleclanche

This comment has been minimized.

Contributor

jleclanche commented May 4, 2016

The plan honestly has always been to move to kwin long term, with the goal in mind to make kwin more lightweight, less kde-dependent etc (a situation which has improved greatly since we started the project).

Keep in mind we want to be compatible with wayland and there's not many WMs that offer that right now. Kwin and Sway are the only two reliable ones (and as nice as sway is, it's not what I would recommend as a default WM).

@tsujan

This comment has been minimized.

Member

tsujan commented May 21, 2016

Although I like Openbox+Compton, yesterday I felt nostalgic for Compiz and hopelessly tried to compile it with Arch patches under Debian Testing. Much to my surprise, not only the compilation finished successfully but also Compiz worked smoothly with LXQt -- almost like old days with Gnome2! Viva Arch community!

While kwin created coredump on logging out, there's no Compiz coredump here! I just disabled Compton, put compiz --replace in Session Settings → Window Manager and logged out and in :)

I may even stay with it until Wayland comes.

@physkets

This comment has been minimized.

physkets commented May 29, 2016

Has anyone looked at Orbital as an option? How does it compare to Kwin?

@palinek

This comment has been minimized.

Contributor

palinek commented May 30, 2016

Has anyone looked at Orbital

I've just tried to build/test it.... but I wasn't able to go further than the "splash screen" :(

screenshot

@paulolieuthier

This comment has been minimized.

Contributor

paulolieuthier commented May 30, 2016

Orbital looks like a nice project to keep an eye on.

@tsujan

This comment has been minimized.

Member

tsujan commented May 30, 2016

@palinek Is Wayland stable on Debian?

@palinek

This comment has been minimized.

Contributor

palinek commented May 30, 2016

Is Wayland stable on Debian?

I'm not using wayland :)... I just built orbital and gave it a try under the X.

@f2404

This comment has been minimized.

f2404 commented May 30, 2016

@palinek Hmm, should it run under X?

Orbital is a Wayland compositor and shell

@palinek

This comment has been minimized.

Contributor

palinek commented May 30, 2016

Hmm, should it run under X?

Based on it's readme, it should:

Running Orbital

Now you can just run orbital, to run it if you are inside an X or a Wayland session. To start its own dedicated session run orbital-launch from a tty.

...the same way as wayland itself can be run inside X

@tsujan

This comment has been minimized.

Member

tsujan commented May 30, 2016

After re-experiencing Compiz, I won't be satisfied by less than it anymore. The best Wayland-based candidate will be KWin if it keeps its effects. Current (and even a bit older) graphics cards are wasted by simple WMs, IMO.

@agaida

This comment has been minimized.

Member

agaida commented May 30, 2016

wayland stable :) - there is no such thing right now. But one could test it in debian sid i think - runs more or less fine with gnome and kde, but still have glitches.

@giucam

This comment has been minimized.

giucam commented Jun 2, 2016

@palinek The console output likely has a clue as to why it stops at the splash screen.

@jubalh

This comment has been minimized.

Contributor

jubalh commented Jun 2, 2016

The Lumina Desktop guys plan to (already started?) developing a new WM. Just throwing this into the discussion ans maybe joining forces there would be an option.

@palinek

This comment has been minimized.

Contributor

palinek commented Jun 3, 2016

The console output likely has a clue as to why it stops at the splash screen.

@giucam Here is the output:

$ ~/opt/weston/bin/orbital
Loading module '/home/palco/opt/weston/lib/libweston-0/x11-backend.so'
Loading module '/home/palco/opt/weston/lib/libweston-0/gl-renderer.so'
EGL client extensions: EGL_EXT_client_extensions EGL_EXT_platform_base
               EGL_EXT_platform_wayland EGL_EXT_platform_x11
               EGL_KHR_client_get_all_proc_addresses EGL_MESA_platform_gbm
warning: EGL_EXT_buffer_age not supported. Performance could be affected.
warning: EGL_EXT_swap_buffers_with_damage not supported. Performance could be affected.
Using gl renderer
EGL version: 1.4 (DRI2)
EGL vendor: Mesa Project
EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3 
EGL extensions: EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness
               EGL_EXT_image_dma_buf_import EGL_KHR_create_context
               EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses
               EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image
               EGL_KHR_gl_texture_cubemap_image EGL_KHR_image
               EGL_KHR_image_base EGL_KHR_image_pixmap
               EGL_KHR_surfaceless_context EGL_KHR_wait_sync
               EGL_MESA_configless_context EGL_MESA_drm_image
               EGL_MESA_image_dma_buf_export EGL_NOK_swap_region
               EGL_NOK_texture_from_pixmap EGL_NV_post_sub_buffer
               EGL_WL_bind_wayland_display
GL version: OpenGL ES 3.1 Mesa 11.2.2
GLSL version: OpenGL ES GLSL ES 3.10
GL vendor: Intel Open Source Technology Center
GL renderer: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 
GL extensions: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays
               GL_EXT_texture_filter_anisotropic
               GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8888
               GL_OES_compressed_ETC1_RGB8_texture GL_OES_depth24
               GL_OES_element_index_uint GL_OES_fbo_render_mipmap
               GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives
               GL_OES_stencil8 GL_OES_texture_3D 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_EGL_image GL_OES_depth_texture
               GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV
               GL_OES_get_program_binary GL_APPLE_texture_max_level
               GL_EXT_discard_framebuffer GL_EXT_read_format_bgra
               GL_NV_fbo_color_attachments GL_OES_EGL_image_external
               GL_OES_EGL_sync GL_OES_vertex_array_object
               GL_ANGLE_texture_compression_dxt3
               GL_ANGLE_texture_compression_dxt5 GL_EXT_texture_rg
               GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer
               GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil
               GL_EXT_draw_buffers GL_EXT_map_buffer_range GL_KHR_debug
               GL_OES_depth_texture_cube_map GL_OES_surfaceless_context
               GL_EXT_color_buffer_float GL_EXT_separate_shader_objects
               GL_EXT_shader_integer_mix GL_EXT_draw_elements_base_vertex
               GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex
               GL_OES_texture_storage_multisample_2d_array
               GL_EXT_blend_func_extended GL_EXT_buffer_storage
               GL_EXT_shader_samples_identical
GL ES 2 renderer features:
               read-back format: BGRA
               wl_shm sub-image to texture: yes
               EGL Wayland extension: yes
Chosen EGL config details:
               RGBA bits: 8 8 8 0
               swap interval range: 0 - 1000
x11 output 800x400, window id 75497477
Using 'wayland-0'
Launching '/home/palco/opt/weston/libexec/orbital-authorizer-helper'...
xserver listening on display :1
Launching '/home/palco/opt/weston/libexec/orbital-splash'...
Launching '/home/palco/opt/weston/libexec/startorbital'...
autostart!!
populate /home/palco/.config/autostart
Autostarting /home/palco/.config/autostart/set_mouse_precision.desktop: 'mouse_precision.sh'
Autostarting /home/palco/.config/autostart/set_video.desktop: 'video.sh'
forked X server, pid 6459
glamor: EGL version 1.4 (DRI2):
[D orbital-client - /home/palco/work/oss/orbital/src/client/client.cpp:108] == Wayland display socket: 48
[D orbital-splash - unknown:0] == Using Wayland-EGL
[W orbital-client - /home/palco/work/oss/orbital/src/client/style.cpp:51] == Could not find the style "chiaro"
[D orbital-client - /home/palco/work/oss/orbital/src/client/shellui.cpp:150] == screen "X1"
[W orbital-client - /home/palco/work/oss/orbital/src/client/element.cpp:387] == "Could not find the element 'background'. Check your configuration or your setup."
[W orbital-client - /home/palco/work/oss/orbital/src/client/element.cpp:387] == "Could not find the element 'panel'. Check your configuration or your setup."
[W orbital-client - /home/palco/work/oss/orbital/src/client/element.cpp:387] == "Could not find the element 'overlay'. Check your configuration or your setup."
[W orbital-client - /home/palco/work/oss/orbital/src/client/element.cpp:387] == "Could not find the element 'lockscreen'. Check your configuration or your setup."
[D orbital-client - /home/palco/work/oss/orbital/src/client/client.cpp:235] == Elements for screen "X1" loaded after 0 ms
xfixes version: 5.0
created wm, root 624

... and after closing the window

[D Orbital - /home/palco/work/oss/orbital/src/compositor/compositor.cpp:545] == Orbital exiting...
xserver exited, code 9
[W Orbital - unknown:0] == QProcess: Destroyed while process ("mouse_precision.sh") is still running.
[W Orbital - unknown:0] == QProcess: Destroyed while process ("video.sh") is still running.
Segmentation fault
[W orbital-client - unknown:0] == The Wayland connection broke. Did the Wayland compositor die?
[W orbital-splash - unknown:0] == The Wayland connection broke. Did the Wayland compositor die?

Note: the video.sh/mouse_precision.sh are simple bash scripts (with xinput/xrandr)

@giucam

This comment has been minimized.

giucam commented Jun 3, 2016

@palinek Well, it says there: "Could not find the element 'background'. Check your configuration or your setup."
Judging by the path, did you run make install with DESTDIR? That won't work, set the right prefix to cmake if you want to install it in your home.

@palinek

This comment has been minimized.

Contributor

palinek commented Jun 3, 2016

Judging by the path, did you run make install with DESTDIR? That won't work, set the right prefix to cmake if you want to install it in your home.

Nope, I built it with `cmake -DCMAKE_PREFIX_PATH=$HOME/opt/weston -DCMAKE_INSTALL_PREFIX=$HOME/opt/weston ..'

... oh I almost forgot, I also made changes in the sources for the ETC dirs:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 32e9792..882a5cb 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -31,4 +31,4 @@ add_custom_target(uninstall
 add_subdirectory(scripts)
 add_subdirectory(data)

-install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/orbital-launcher.desktop DESTINATION /etc/xdg/autostart)
+install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/orbital-launcher.desktop DESTINATION etc/xdg/autostart)
diff --git a/data/CMakeLists.txt b/data/CMakeLists.txt
index b7585e0..8df1063 100644
--- a/data/CMakeLists.txt
+++ b/data/CMakeLists.txt
@@ -1,2 +1,2 @@
 configure_file(restricted_interfaces.conf.in ${CMAKE_CURRENT_BINARY_DIR}/restricted_interfaces.conf @ONLY)
-install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/restricted_interfaces.conf DESTINATION /etc/orbital)
+install(PROGRAMS ${CMAKE_CURRENT_BINARY_DIR}/restricted_interfaces.conf DESTINATION etc/orbital)
diff --git a/src/authorizer_helper/main.cpp b/src/authorizer_helper/main.cpp
index fdaeb9e..f8d6aec 100644
--- a/src/authorizer_helper/main.cpp
+++ b/src/authorizer_helper/main.cpp
@@ -88,7 +88,7 @@ public:
         QString path = QStandardPaths::writableLocation(QStandardPaths::ConfigLocation);
         Result res = readFile(path + QLatin1String("/orbital/restricted_interfaces.conf"), global, executable);
         if (res == Result::Unknown) {
-            res = readFile(QStringLiteral("/etc/orbital/restricted_interfaces.conf"), global, executable);
+            res = readFile(QStringLiteral("/home/palco/opt/weston/etc/orbital/restricted_interfaces.conf"), global, executable);
         }
         return res == Result::Allow;
     }
diff --git a/src/compositor/shell.cpp b/src/compositor/shell.cpp
index 4cbd98c..7aedabe 100644
--- a/src/compositor/shell.cpp
+++ b/src/compositor/shell.cpp
@@ -305,7 +305,7 @@ fmt::print(stderr, "autostart!!\n");
             return false;
         });
     } else {
-        populateAutostartList(files, "/etc/xdg/autostart");
+        populateAutostartList(files, "/home/palco/opt/weston/etc/xdg/autostart");
     }

     QDir outputDir = QDir::temp();
@giucam

This comment has been minimized.

giucam commented Jun 3, 2016

Right, it looks in the dirs returned by QStandardPaths for DataLocation, as defined here: http://doc.qt.io/qt-5/qstandardpaths.html#StandardLocation-enum
So that won't include your custom path. In the meanwhile you can move share/orbital/ in ~/.local/share, that shoule make it work.

@palinek

This comment has been minimized.

Contributor

palinek commented Jun 3, 2016

@giucam thanks... with some tweaking in ~/.local/share it is running now

@paulolieuthier

This comment has been minimized.

Contributor

paulolieuthier commented Jun 3, 2016

@palinek what do you think of it?

@palinek

This comment has been minimized.

Contributor

palinek commented Jun 3, 2016

what do you think of it?

Just tested it and tried to run the lxqt-panel in there -> issues discovered right away:

  • panel does not place itself correctly
  • taskbar doesn't show anything

Here are some glues from @mgraesslin (thanks again):

(13:16:01) palinek: Hi. A (simple) question: please, what do I need make kwnidowsystem usable under wayland? Is there some needed plugin package?
(13:16:18) palinek: mgraesslin: ^
(13:16:25) bshah: I believe so
(13:16:36) bshah: https://quickgit.kde.org/?p=kwayland-integration.git have kwindowsystem plugin
(13:16:52) mgraesslin: palinek: depends on what you define as "usable" there is a dummy implementation
(13:17:53) palinek: with dummy implementation you mean a "noop" methods (i think i've seen something like that a while ago)?
(13:18:23) mgraesslin: palinek: it's an implementation which matches what Wayland standard protocols allow to use
(13:18:42) mgraesslin: palinek: most of KWindowSystem just doesn't match Wayland - e.g. there are no window ids
(13:22:25) mgraesslin: palinek: so what do you actually need from KWindowSystem on Wayland?
(13:23:03) palinek: looking into the sources... (windowsystem.cpp) WindowSystem::setExtendedStrut
(13:23:03) palinek: mgraesslin: can you give me a clue how do it in wayland
(13:23:19) mgraesslin: not at all, there is nothing like that in the protocol
(13:23:29) palinek: mgraesslin: asking because of LXQt
(13:23:57) mgraesslin: palinek: what we have for that in KWayland is PlasmaShell: you can mark a surface as a panel than struts are applied automatically
(13:24:50) mgraesslin: palinek: see https://api.kde.org/frameworks/kwayland/html/classKWayland_1_1Client_1_1PlasmaShellSurface.html
(13:25:04) palinek: hm... do I need something wayland specific or is that covered by any framework (kwindowsystem, qt)?
(13:25:23) mgraesslin: palinek: but that only works with Compositors which support that protocol which at the moment is probably only KWin
(13:25:33) palinek: :)
(13:25:59) mgraesslin: I think you would need to use KWayland directly
(13:26:05) mgraesslin: let me look for code example
(13:26:57) mgraesslin: palinek: the name Plasma in that doesn't mean that it's only meant for Plasma, we had LXQt in mind when we designed the protcols
(13:27:10) palinek: the KWAYLAND is a tier 1 framework?
(13:27:42) palinek: ...found... good
(13:28:11) mgraesslin: yes
(13:28:14) mgraesslin: https://quickgit.kde.org/?p=plasma-workspace.git&a=blob&h=3910aabe9a8317aa371fc9138821147cf4ca4d99&hb=0d0c4f4a2247e8213deb232d2d80f12480dc05aa&f=shell%2Fpanelview.cpp
(13:28:33) mgraesslin: PanelView shows how to make it a "Panel"
(13:28:45) mgraesslin: the interesting code is in the event handler for QPlatformSurfaceEvent
(13:29:04) mgraesslin: and in PanelView::integrateScreen
(13:29:17) palinek: looking on that
(13:29:19) mgraesslin: what's nice about PlasmaSurface is that it allows to set an absolute position
(13:29:26) mgraesslin: which is something a panel rather wants
(13:29:42) mgraesslin: KWin fully trusts a PlasmaSurface to do the right things
(13:29:54) mgraesslin: and we destroyed the complete security thoughts of Wayland for it ;-)
(13:30:49) mgraesslin: palinek: and for task managers you want to have a look at PlasmaWindow and PlasmaWindowModel
(13:31:07) mgraesslin: (or just use the new libtaskmanager just being under development by Sho_)

=> so right now, we have only the kwin as an option for wayland (if we want still stick with kwindowsystem)

@simoniz0r

This comment has been minimized.

simoniz0r commented May 16, 2018

How is it not? A user is going to want to, for example, be able to change the hotkey of how to close windows. I could not find a way to do that without systemsettings5 for kwin.

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

Can't, theoretically speaking, LXQt's current shortcut manager (or one design for that effect) detect if one is using kwin and in that case work the way kwin needs?

@simoniz0r

This comment has been minimized.

simoniz0r commented May 16, 2018

I don't really think that's how it works. I'm pretty sure that's one of those things that uses QML as I don't see any files to configure it in my config directory.

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

Added a test with mutter - @tsujan - what about gnome-shell and mutter as default for wayland ...

/me runs away screeming

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

@simoniz0r - i still see not any problem. Yes, some glue is needed - and if it's not there thats not nice - but that says nothing about how some WMs work with LXQt - all these things are FOSS and if one is really interested and there is really no glue - one sit down and will write the needed glue if dedicated enough. Thats how FOSS works.

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

Completely amazed with Mutter!!! I never thought it would beat kwin!!! Amazing!!!
@agaida what do you mean with:

did i mention the great Qt sharing of ressources?

can you clarify?

@simoniz0r

This comment has been minimized.

simoniz0r commented May 16, 2018

@agaida I would be fine with kwin if there were a way to set hotkeys such as closing windows without needing systemsettings5. In my tests, if I disabled kwin's compositor and used compton instead, kwin was actually pretty light on RAM use. It was using ~20MBs of RAM without compositing and ~70MBs with.

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

@maverick74 - the most qt things come with a relative hight memory footprint at the beginning - notable more than in GTK envionments. But if you really use the system the memory usage don't grow so much as one would expect without the knowledge needed - so if you have a look at LXQt, we use kwindowsystem (Tier 1 KF5 component), kidletime (Tier 1), solid (Tier 1) and what ever i forget - so lxqt load the needed parts into memory and with the base set of LXQt components the very most basic Qt libs a Qt application will need is already loaded and can be re-used. That means - the goal is not to save memory at any price - the goal should be to use the available memory wise. And in case even a "fat" thing like kwin don't add much to the overall memory footprint. And thats really cool.

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

@agaida I didn't know about that. That's a very clever approach, imo!!!
Thanks for bringing some light on the subject :)

@tsujan

This comment has been minimized.

Member

tsujan commented May 16, 2018

Added a test with mutter - @tsujan - what about gnome-shell and mutter as default for wayland ...

I'm working under it now, with pcmanfm-qt, qterminal, featherpad,... and without Gnome apps. Everything is fine.

@simoniz0r

As for KDE shortcuts under LXQt, they shouldn't work, of course, unless KGlobalAccel is running, which isn't a good idea outside KDE. I used KWin with LXQt without any problem for a long time and changed kwin themes with systemsettings5. Whenever I ran systemsettings5, some KDE processes started and I stopped those which were irrelevant.

@tsujan

This comment has been minimized.

Member

tsujan commented May 16, 2018

Of course, I was working under gnome-shell just to test Qt 5.11 -- which was a a bad experience. Returning to LXQt.....

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

@maverick74 - and i'm not exactly sure that i'm 100% right about the usage thing - but if not someone will step up and corret me :D

@tsujan

This comment has been minimized.

Member

tsujan commented May 16, 2018

And in case even a "fat" thing like kwin don't add much to the overall memory footprint. And thats really cool.

I've seen that part on a very old computer with 4 GiB of ram and a duo.

@Vladimir-csp

This comment has been minimized.

Vladimir-csp commented May 16, 2018

what about gnome-shell and mutter as default for wayland

I would suspect it uses gnome's windows-registry-wannabe for configuration, is it not?

@tsujan

This comment has been minimized.

Member

tsujan commented May 16, 2018

I would suspect it uses gnome's windows-registry-wannabe for configuration, is it not?

In case you asked me, I think gnome should use gnome stuff, of course. Qt apps use xwayland under it. I didn't encounter a single problem regarding window management with gnome-shell+wayland+Intel.

@Vladimir-csp

This comment has been minimized.

Vladimir-csp commented May 16, 2018

I mean dconf or gsettings or whatever iteration of this monstrosity they have now.

@tsujan

This comment has been minimized.

Member

tsujan commented May 16, 2018

It should be dconf.

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

So... all in all, from what i can understand, if one has at least 1G of ram one can use whatever wm he wants because the differences are not really that significant. (except for others details like most stable/complete/advanced).

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

yes, that was the plan right from the beginning

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

yes, i believe it was! But i wasn't really expecting such good results to be honest!!!
I was expecting big differences from wm to wm

@maverick74

This comment has been minimized.

maverick74 commented May 16, 2018

A suggestion: Picking up @PCMan 's blog post as an example, i think this too would give a very interesting article!!!
I bet other users would also like to know about this experiments (that, at the same time would also put an end to some myths/fears/misconceptions )

@agaida

This comment has been minimized.

Member

agaida commented May 16, 2018

we should do such things more often - right. But it's hard for me as not natural english speaker to put together such an article - so if one will stand up and do this ...

But: "It just works"™ is only one side of the coin - the second side is also important - as seen in the discussion. How to integrate the WM (or any other external application) into LXQt - fortunately not every LXQt-User is also a LXQt-Developer, that would be a bit boring and frustrating :D

@tsujan

This comment has been minimized.

Member

tsujan commented May 17, 2018

I've seen this in other places but have no idea whether it's because of Linux kernel, C++ or Qt: A Qt program may take, let's say, 100 MiB of RAM when the total RAM is 16 GiB but the same program may take only 20 MiB with a 4 GiB RAM (the numbers are totally hypothetical). Until now, I haven't been so curious (or have been too lazy) to search the Internet for it.

@maverick74

This comment has been minimized.

maverick74 commented May 18, 2018

@agaida I would gladly step up! But English is not my native language either...

I think the capacity of integrating various WM (or any other external application) is a plus! Even if it is not for the faint of heart, it's still a plus.
In the article, i believe we would not need to get into the technical side of it, but mostly share the results so that a reader could know of the actual state and capacities of LXQt regarding the use of different WM's

@agaida agaida added this to Needs triage in Issues Jul 14, 2018

@agaida agaida moved this from Needs triage to Wishlist in Issues Jul 15, 2018

@chimak111

This comment has been minimized.

chimak111 commented Aug 10, 2018

@agaida , @maverick74
I think many English speakers and readers aren't native. Even the "natives" are quite understanding and forgiving. So please don't hesitate!

@tsujan

This comment has been minimized.

Member

tsujan commented Oct 1, 2018

I played with the code of KWin's Breeze titlebar -- starting from BreezeBlur because it didn't have a different config file -- and saw that the font can be configured outside KDE. This is after heavy and, sometimes, dirty hacks (mac-like titlbar buttons grow on mouse-over):

screenshot

Of course, it depends on KDE but is completely configurable under LXQt.

No upload yet because it needs a lot of cleanup and I should see whether KDE breaks the Breeze code once in a while (I don't think so).

EDIT: Done under the title BreezeEnhanced.

@shirishag75

This comment has been minimized.

shirishag75 commented Oct 18, 2018

Here are my numbers -

$ inxi -SICGxxx
System:    Host: debian Kernel: 4.18.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: LXQt 0.13.0 tk: Qt 5.11.1 
           info: lxqt-panel wm: xfwm4 dm: LightDM 1.26.0 Distro: Debian GNU/Linux buster/sid 
CPU:       Topology: Quad Core model: Intel Core i5-7400 bits: 64 type: MCP arch: Kaby Lake rev: 9 L2 cache: 6144 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 24000 
           Speed: 800 MHz min/max: 800/3300 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 
Graphics:  Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 
           Display: x11 server: X.Org 1.20.1 driver: modesetting unloaded: fbdev,vesa resolution: 1600x900~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.1.7 compat-v: 3.0 
           direct render: Yes 
Info:      Processes: 181 Uptime: 9m Memory: 7.66 GiB used: 1.01 GiB (13.2%) Init: systemd v: 239 runlevel: 5 Compilers: 
           gcc: 8.2.0 alt: 8 Shell: bash v: 4.4.23 running in: qterminal inxi: 3.0.27

and on Debian MATE -


$ inxi -SICGxxx
System:    Host: debian Kernel: 4.18.0-2-amd64 x86_64 bits: 64 compiler: gcc v: 7.3.0 Desktop: MATE 1.20.3 info: mate-panel 
           wm: marco 1.20.2 dm: LightDM 1.26.0 Distro: Debian GNU/Linux buster/sid 
CPU:       Topology: Quad Core model: Intel Core i5-7400 bits: 64 type: MCP arch: Kaby Lake rev: 9 L2 cache: 6144 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 24000 
           Speed: 800 MHz min/max: 800/3300 MHz Core speeds (MHz): 1: 800 2: 800 3: 800 4: 800 
Graphics:  Device-1: Intel HD Graphics 630 vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:5912 
           Display: x11 server: X.Org 1.20.1 driver: modesetting unloaded: fbdev,vesa compositor: marco v: 1.20.2 
           resolution: 1600x900~60Hz 
           OpenGL: renderer: Mesa DRI Intel HD Graphics 630 (Kaby Lake GT2) v: 4.5 Mesa 18.1.7 compat-v: 3.0 
           direct render: Yes 
Info:      Processes: 177 Uptime: 15m Memory: 7.66 GiB used: 1.09 GiB (14.2%) Init: systemd v: 239 runlevel: 5 Compilers: 
           gcc: 8.2.0 alt: 8 Shell: bash v: 4.4.23 running in: qterminal inxi: 3.0.27 

I didn't see much difference between the numbers as far as I can see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment