[Porteus-LXDE] UI-Productivity-SuperPack.Updated May 13,2014

Here is a place for your projects which are not officially supported by the Porteus Team. For example: your own kernel patched with extra features; desktops not included in the standard ISO like Gnome; base modules that are different than the standard ISO, etc...
User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#31 by dimx » 17 Jan 2014, 12:13

At login screen choose openbox session. Now by right-clicking you can open pcmanfm (file manager).
Deactivate the modules from pack that you have previously activated (and remove them from /modules).
then at terminal

Code: Select all

rm -rf /mnt/live/memory/changes/root/.config/lxsession/LXDE/desktop.conf
or if you login as guest:

Code: Select all

rm -rf /mnt/live/memory/changes/home/guest/.config/lxsession/LXDE/desktop.conf
this should reset lxde session settings (themes/icons etc) to defaults.
Relogin.
(or reboot if it doesnt work - im not sure if layered filesystem would immediately replace the desktop.conf file from previous layer without rebooting)

User avatar
phhpro
Full of knowledge
Full of knowledge
Posts: 545
Joined: 10 Nov 2013, 20:35
Distribution: .

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#32 by phhpro » 18 Jan 2014, 01:22

...
Last edited by phhpro on 03 Feb 2016, 23:49, edited 1 time in total.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#33 by dimx » 20 Jan 2014, 11:57

phhpro wrote:theme switching shouldn't require any handy work on the user's end.
Completely agree. Themes from this pack work exactly this way. You just need to activate everything from themes folder on Porteus LXDE 3rc1 amd64.
It would take more than that on other Porteus versions/architectures/DE's.
(Still very easy to do, if you have a basic background on how Porteus/Slackware/linux works)

User avatar
phhpro
Full of knowledge
Full of knowledge
Posts: 545
Joined: 10 Nov 2013, 20:35
Distribution: .

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#34 by phhpro » 22 Jan 2014, 01:18

...
Last edited by phhpro on 03 Feb 2016, 23:50, edited 1 time in total.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#35 by brokenman » 21 Mar 2014, 13:21

Are we gonna see a v3.0 of this useful desktop? I think it rocked.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#36 by dimx » 29 Mar 2014, 18:35

brokenman wrote:Are we gonna see a v3.0 of this useful desktop? I think it rocked.
Heya there! Of course! :)
(My apologies for the late response)
Im currently testing various builds of Compiz on Porteus LXDE, git/bzr etc, because the (very old) stable 0.8.8 version doesnt integrate as well as I would like with new mesa/gtk3 packages, causing random small delays on gtk3 menus. This is a very minor issue, but I would like to make my package as perfect and as smooth as possible.
I have literally tested about 8-9 compiz builds so far, up to the latest bzr branch. Most likely I will stick with 0.9.10.x version.
Also, the Cairo-dock will be bumped to v3.3.2, which runs great on the new Porteus. Some other small fixes will be posted with the release.
Stay tuned!

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#37 by dimx » 02 Apr 2014, 21:57

Small update on my progress.
After spending hours upon hours on testing, compiz proved to be a real b*tch.
./rant-mode on
Fist of all, I was going for the 0.8.8/0.8.9 stable which proved excellent (for the functions I needed), stable and bug-free under Porteus 2.1. Seriously, never had an issue so far, even with tricky stuff like coming out of suspended state.
Moving to Porteus 3 (Slackware 14.1 base) the same package compiled fine, but there was an annoying bug introduced: there were random 0.5-1s delays on menus of apps that were using gtk3. Now this issue is very hard to track and almost impossible for me to resolve, since its most likely caused by updated xcb/mesa packages from Slackware. Same behavior I have confirmed on Arch too. Hacking into xcb/mesa related compiz code is not an option for me.
So, moving on, I went for the latest "ubuntu-stable" package 0.9.10, and later 0.9.11-bzr, 0.9.7, 0.9.6.
Now the previous bug is gone and gtk3 menus are snappy again. But welcome to the new bug:
Compiz would clip shadows of the menus that would overlap with the invisible part of Cairo-dock. (Cairo-dock draws ~50px box extending upon its visible part). The clipping is actually compiz drawing menu shadows below the invisible box and its a known bug (https://bugs.launchpad.net/compiz/+bug/979252), affecting AWN as well. So I submitted to the bug thread, subbed to it to up its "heat meter" on launchpad and just hope that they fix it someday.
Now, why would i be concerned about some shadow issues on menus, while I could just disable them and be off with them? Because my main GTK2/3 theme (Boje) is so much better with heavy shadows, because menus and windows do not blend together into one single-continuous-grey-thing and are easily distinguished. The theme is far from unusable, but once u get hooked on a well-polished GUI, its so hard to give it up.
./rant-mode off
Next things on my todo list will be:
* Examine the alternative compositing WMs (kwin standalone, elementaryOS's gala) and see if can get the desired behavior out of them, as well as adequate resource consumption and performance.
* If they prove unsatisfactory (and there is a good chance they will), I will build the next pack with compiz 0.9.11, disable all menu shadows and change my default theme to the dark theme from this series:http://gnome-look.org/content/show.php?content=156782
* Do an overhaul of my pack for Porteus 2.1 and also build an amd64 version of it. This will probably become my main system again until compiz's menu shadow issue is fixed.
RIP compiz 0.8.8.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#38 by dimx » 18 Apr 2014, 16:40

ok, another update. This time a (relatively) positive one.
Compiz 0.8 is not dead yet!
On another machine with a fresh Manjaro/Arch installed I have got compiz 0.8 installed and have not observed any submenu delays on gtk3 apps. And that was with all the latest stuff:
gtk3-3.12
xorg-server 1.15
mesa 10.1.0
and kernel 3.13.6

Now while i have compiled the same packages on porteus3, and even passed the same arguments to the compiler (and applied same patches too), it didnt solve the issue.
Its still a breakthrough though, as I was about to release the pack with the annoying compiz 0.9.11.
I even have hacked into the latest compiz branch's code to fix 2 bugs that annoyed me - one in which compiz scale plugin would not work, and a workaround for clipping shadow of menus. If not too lazy will provide those to upstream.
Now my fist priority is to find out which package causes the strange random submenus delays with compiz 0.8 under Porteus3.
And then release the pack with compiz 0.8 which has proved to be very stable.
RIP compiz 0.9.11!
Welcome back, compiz 0.8! You are still the best compositing window manager.
As a side note on other compositing wm's:
- gala is too fresh and uses gconf, not configurable enough. Yeah and GConf sucks (big surprise..).
- kwin uses Qt code for compositing, so an extra dep, plus egde triggers are a bit slow. Also bigger memory footprint.
- Compton, while fast and very lightweight, doesnt offer any scale (aka Expose) effects and completely lacks animations.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4566
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#39 by fanthom » 19 Apr 2014, 08:41

hello dimx,

i could provide mesa slackbuild as it was compiled with different ./configure flags than slackware version. xorg-server is the same except for higher version. will to it this evening.

in the mean time you could just uninstall my packages and install original slackware ones (removepkg $x, installpkg $y). please let me know if that helps and i'll see what we can do about it for the next release.

thanks
Please add [Solved] to your thread title if the solution was found.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#40 by dimx » 19 Apr 2014, 12:46

I have actually built compiz and all other apps on vanilla Slackware 14.1, with same results...
(Almost vanilla, since I built 3.13.6 kernel for it, keeping the same config options).
I'm not sure reinstalling packages from Slackware would solve my problem. I will do another vanilla Slackware install on a different machine very soon (default kernel this time), and test again. I'm almost sure this problem comes from Slackware base, not Porteus. But still I would like to check the slackbuilds, just so I'm not guessing the options Porteus packages were built with.
Oh, and thank you!

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#41 by dimx » 20 Apr 2014, 16:26

ok another update.
real progress this time.
I was able to locate the culprit of "submenu delay" bug. Its gtk3... Not sure how I missed it before, since it was my no1 suspect since the beginning, and the first thing I did was test versions >3.8.2. After rebuilding and downgrading to 3.4.4 (which was in Slackware 14.0) I'm finally convinced its gtk's fault. Also confirming in latest gtk 3.12 the bug wasnt there. It seems it was fixed along the way, since there were some major structural changes, since 3.10. That also somewhat explains why version 3.10 was working ok on Manjaro - even though 3.10 on Slackware still had the bug, it could be due to not playing well with earlier versions of glib and gobject-introspection.
TODO:
- bisect gtk versions 3.4.4 through 3.8.2 to find offending commit(s)
- generate a patch for v.3.8.2 and possibly provide it to Slackware
- rebuild/overhaul the UI pack -- rebuild caches of icon themes and update gtk-immodules too (should have done it since the beginning)
- release.

P.S. @Fanthom: if u r reading this, no need to post mesa slackbuilds, since the bug is in gtk. Sorry for the inconvenience.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#42 by dimx » 22 Apr 2014, 20:29

Image
I've finally resolved the GTK3 bug above!
Having performed regression testing (git bisect) as well as reverse regression testing, I was left with 2 options. Either:
A. Revert the commit:
[645b5f398d2d50c361600f4f8a089488a66eed99] Reimplement _NET_WM_SYNC_REQUEST inside X11 backend
B. Backport the commit:
[ed447eba08afc13103c4f269c47bddfaecfe528d] widget: emit synthesized crossing event with correct device position
I chose B, as its very straight forward, as opposed to A. The only change I made was is to use the methods for getting position in int instead of double, since the latter aren't implemented until GTK 3.10.
The change to the patch was gdk_device_get_position_double ----> gdk_device_get_position.
Should not make any difference, since method signatures are basically the same and glib2 should handle conversion (I bet it even wont be happening here, but in the (gdouble) methods introduced in 3.10).
Resulting patch derived from this:

Code: Select all

backport to gtk+3.8 of commit ed447eba08afc13103c4f269c47bddfaecfe528d
Author: dimx
Date:   Tue Apr 22 23:11:33 2014 +0100

    widget: emit synthesized crossing event with correct device position
    
    https://bugzilla.gnome.org/show_bug.cgi?id=704456

diff --git a/gtk/gtkwidget.c b/gtk/gtkwidget.c
index f4246ac..0b2aac3 100644
--- a/gtk/gtkwidget.c
+++ b/gtk/gtkwidget.c
@@ -11893,8 +11893,15 @@ synth_crossing (GtkWidget       *widget,
   event->crossing.send_event = TRUE;
   event->crossing.subwindow = g_object_ref (window);
   event->crossing.time = GDK_CURRENT_TIME;
-  event->crossing.x = event->crossing.y = 0;
-  event->crossing.x_root = event->crossing.y_root = 0;
+  gdk_device_get_position (device,
+                                  NULL,
+                                  &event->crossing.x_root,
+                                  &event->crossing.y_root);
+  gdk_window_get_device_position (window,
+                                         device,
+                                         &event->crossing.x,
+                                         &event->crossing.y,
+                                         NULL);
   event->crossing.mode = mode;
   event->crossing.detail = detail;
   event->crossing.focus = FALSE;

Worked like a charm!
Now I need to kindly ask Ahau to provide his gtk+3 slackbuild, so I wont need to include the whole gtk+3 to override his package, but only the file(s) that will differ due to the patch.

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#43 by brokenman » 23 Apr 2014, 03:44

Nice job. Anything special about Ahau's gtk3 slackbuild? Did he modify it somehow?

I havn't heard from Ahau for some time. He got very busy at work and hasn't been around lately.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
dimx
Contributor
Contributor
Posts: 42
Joined: 02 Dec 2013, 08:10
Distribution: porteus-LXDE,Slackware,Arch
Location: Greece

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#44 by dimx » 23 Apr 2014, 17:37

brokenman wrote:Nice job. Anything special about Ahau's gtk3 slackbuild? Did he modify it somehow?

I havn't heard from Ahau for some time. He got very busy at work and hasn't been around lately.
If I dont have the exact same build options as Ahau, chances are there will be lots of differences between compiled libs. This is cause the linker will link different sets of objects, depending on build configuration. And that, assuming that gcc flags are the same (its more probable that they are). In case they differ, then *all* so's will different.
I saw in package log that list of installed files was different (smaller) from default Slackware.
That being said, the weight of my gtk3 xzm is 10mb, unpacked it's 57mb. I dont mind including the whole gtk3 module in the pack, and just override everything from Ahau, but it just feels kinda silly to have same package twice.
Any advice appreciated. Cheers!

User avatar
brokenman
Site Admin
Site Admin
Posts: 5456
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v3.2rcX all desktops
Location: Brazil
Contact:

Re: [Porteus-LXDE] UI-Productivity-SuperPack.Updated Jan 11,

Post#45 by brokenman » 23 Apr 2014, 20:59

I can't think of any build options that would change for gtk3. Ahau would have built it on top of a basic LXDE. After creating the lxde module we have cleanup scripts that remove unrequired files (some test files for example) that take up space. In any case you can wait for him to reply to be sure.
How do i become super user?
Wear your underpants on the outside and put on a cape.

Post Reply