jeffhoogland / moksha Goto Github PK

Hi, another small issue that is solved by a commit on latest E, but not here.

Here's the link of the ticket
https://phab.enlightenment.org/T1155

I've checked the sources of moksha and seems that haven't take the changes from the commit that had solved that issue.

It seems all the icons under /usr/share/icons directories and possibly some under /home are not being loaded. Is Moksha looking for these at all?

All of the ones under /usr/share/pixmaps are being loaded it seems.

So by default desktop is giving a warning dialog about missing modules, but these seems to not be installed with the base desktop. Since I had no sound by default, I've packaged epulse from moksha-pulsemixer project, but I can't find where these other modules comes from. Are those necessary at all?

When you select the "switch user" option in Chrome the desktop segfaults as the window that pops up opens.

It segfaults again instantly when you restart / hit F1. If you drop to a TTY and kill Chrome you can then restart the desktop without issue.

Something in how Moksha is handling the Chrome sub window that is created must be causing the segfault.

http://i.imgur.com/zi77hBg.png

Hi, me again that open tickets. :)

While I'm theming on Moksha (from Bodhi Repos) I've found that issue on EFM and default dark theme (not theme related) when the pathbar goes too long for its window and arrow buttons appear to scroll its content.

User can scroll the content with mouse wheel, but clicking the arrow gets no effect.
From a theme side, there's two program that gets launched when user click the arrow button: the changing of pixmap state and the signal_emit "e,action,prev" (or "e,action,next").
Pixmap state is correctly changed(arrow goes blue), but the scroll doesn't appear.

I suppose it is not a big dealt, but it's something that doesn't work.

Launching Run Everything efl 1.20.7 throws lots of errors:

CRI<>lib/eina/eina_share_common.c:555 *** Eina Magic Check Failed at 0xb5328b12 !!!
    Input handle is wrong type
    Expected: 98761254 - Eina Stringshare Node
    Supplied: 74786574 - (unknown)
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!

Seems like po files were omitted on places module import. It would be nice to have translation if possible.

CCLD enlightenment
enlightenment-e_int_menus.o: In function _e_int_menus_clients_title_abbrv': /home/baggypants/rpmbuild/BUILD/moksha-0.1.0/src/bin/e_int_menus.c:1460: undefined reference toeina_unicode_utf8_next_get'
collect2: error: ld returned 1 exit status

May be an unmet dependency. Not sure.

Hi,

I've been trying to build Moksha on my Sabayon machine. I have installed all dependencies with Entropy and Portage and then I managed to install Moksha with ./configure && make && sudo make install. The problem is the following:

• Firstly, I can't seem to change the desktop background. I just have a black background (here's a screenshot).
• Secondly, as soon as I log out Moksha seems to forget any changes I made (like new shelves I added, gadgets I added to said shelves, modules I've laoded, etc.)
• Thirdly, whenever I try to change the theme, Moksha crashes and gives me this error message
  

Thanks for your time,
Brenton

Testing new dev branch commit c380c30, I am getting the following error when building the package.

make[2]: Entering directory '/builddir/build/BUILD/moksha/data/backgrounds'
make[3]: Entering directory '/builddir/build/BUILD/moksha/data/backgrounds'
make[3]: Nothing to be done for 'install-exec-am'.
/usr/bin/mkdir -p /usr/share/enlightenment/data/backgrounds
/usr/bin/mkdir: cannot create directory '/usr/share/enlightenment': Permission denied

The build fails on command
/usr/bin/make install DESTDIR=/builddir/build/BUILDROOT/moksha-desktop-0.3.0-0.1.20180510dev.c380c30.fc25.x86_64

It looks like install target wants to install backgrounds to root, despise DESTDIR is being used.

Hello Jeff,

I use Bodhi Linux with actual Moksha desktop (0.1.0.).
When I start Chromium browser (which is maximized) the background image is jumping on the right screen side for about 20px (seems exactli the same witdh as the scrollbars from chromium)...
Maybe you find solution...

Regards

Andreas

Hi,

I have attempted to build and install Moksha 0.1.0 from the source code contained in this GitHub repo and while the build appears to have succeeded (i.e., I received no error message from running ./configure && make && sudo make install) I cannot run /usr/local/bin/enlightenment_start and hence I cannot start a Moksha session. For further details please see this question on Ask Ubuntu. Naturally you may wonder why I don't just install Bodhi and use it instead of trying to install Moksha on Xubuntu, well I am running Xubuntu on a virtual machine and I have installed several programs on it (including SageMath from source code which took several hours) and I don't want to start from scratch on Bodhi.

Thanks for your time,
Brenton

I've noticed there was many version bumps over the last year of moksha if I understand correctly, but the latest git tag is stuck on version 0.2.1. What are the plans for that, should we just use commit tarballs to point to a new version or new release is not ready yet?

Hello.
Anybody have any ideas how to build it in ArchLinux distro ?

When adding a new personal application launcher, the dialog does not update to reflect the newly created app launcher. In order to get it to appear you have to restart the Moksha session.

evas mokshavas
ecore mokshacore
mokshacore-mvas

etc thus if up-stream causes breakage you can port over some features etc. , but as the libs are more Moksha specific mate did. freezing libs as moksa libs would keep it viable for some time , avoiding any up-stream SNAFU's , code can be back-ported or just sync/renamed , extended , features added onto , etc that would make it unique , as well if you use multiple window managers ,
ie i still at times roll up good YE OLDEN , windowmaker , IE chroot's and doing multiple compile jobs
but still some window managers offer a good experiance , other like gnome3 i don't know what b@#& they been smoking at times lol

* Long Term Packaging support* this would reduce breakages , and with rolling distro's like Gentoo
Sabayon , Arch etc make it far eassier to package from sources , libs having differing names from e17 wont collided if user/s installs say E19 20 etc down the line. though you can have prefixes etc like /opt/bin/moksa/moksa </usr/bin/moksa> etc , if the libs have same name its a recipe for hell. later down the line.

however pruning enlightenment artifacts.
with a few odd commands (Gentoo can spit out rpm's from source emerge jobs, alien > slack,deb etc. ) for now with a few hacks unpacker.eclass allows for debs/rpms/etc to be installed. however this isn't as kosher . I'm an astute user however not a gentoo-dev.
I've learned enough how to make my own overlay/s.

As the title says, the install-data-local target ignores the $DESTDIR variable and alsways tries to install into /usr/share/enlightenment/data/backgrounds, which is obviously an issue, if the destination should be somewhere else.

configure: WARNING: EFM requirements : ecore >= 1.7.10 ecore-file >= 1.7.10 ecore-ipc >= 1.7.10 eet >= 1.7.10 efreet >= 1.7.10 edbus >= 1.7.10 eina >= 1.7.10 dbus-1 checking for E_FM... no configure: error: Package requirements (ecore >= 1.7.10 ecore-file >= 1.7.10 ecore-ipc >= 1.7.10 eet >= 1.7.10 efreet >= 1.7.10 edbus >= 1.7.1 0 eina >= 1.7.10 dbus-1 ) were not met:

No package 'edbus' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables E_FM_CFLAGS
and E_FM_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

What to do?

Dialog window on E17 keeps a fixed size even if the contents are bigger than the window.

An example is the dialog window displayed before kill an application:

Now I'll set a smaller size and another line will be displayed

on the default situation (showed above), the "Siete sicuri di voler uccidere questa finestra?" line (on english: "Are you sure to want to kill that window?" or something similar) is cropped because the dialog window has a fixed size, I suppose.

I've seen this issue, as pictured, with the default theme, so it is not theme-related.

To produce:

Attach a second screen to a laptop and disable the laptop's screen while leaving the secondary screen on.

If you shut the system down in this setup the next time you turn the system on the laptop's primary disable will still be blank even if the secondary screen is now removed.

Seems like moksha-modules-extra are no longer compatible with current Moksha master branch since modules use different directories changed by following patch: eb1594e

Extra modules gets installed to /usr/lib64/enlightenment/modules/<modulename>/linux-gnu-x86_64-0.2.1/, but current Moksha is looking for module in /usr/lib64/enlightenment/modules/<modulename>/linux-gnu-x86_64/.

Hey,

While I'm not 100% about the decision to fork (though I get it, and agree with most of your thoughts). I think you should have kept (you can still do it, rewrite history) the git history.

1. It's very useful when debugging/tracing issues.
2. Pay some respect to the 20 years of hard work you're basing this fork on.
3. Why not?

I can offer my help if you need it.

I am getting log filled mostly with messages like:
Sep 18 00:04:08 host /usr/libexec/gdm-x-session[1694]: ERR<eo>lib/eo/eo.c:573 in lib/edje/edje_object.eo.c:134: func 'edje_obj_signal_emit' (983) could not be resolved for class 'Efl.Canvas.Group'.

Sometimes group of these slightly different messages appears:
Sep 18 00:04:05 host /usr/libexec/gdm-x-session[1694]: ERR<eo>lib/eo/eo.c:573 in lib/edje/edje_object.eo.c:134: func 'edje_obj_signal_emit' (983) could not be resolved for class 'Efl.Canvas.Rectangle'.

Sample from command: journalctl --since "2017-09-18 00:04:05" --until "2017-09-18 00:04:09"
output.txt

I noticed when debugging an app not functioning well with Moksha that the environmental variable $DESKTOP is currently set to Moksha-0.17.0. This is a minor issue but shouldn't we have the version number set to Moksha version and not an enlightenment version number? Is this set by Moksha or something else?

Guys, again, regarding #1, what's wrong with you?!?!
You can't just steal credit, when you backport, maintain authorship!!! (Why not just cherry-pick the commit? Easier anyway).

One example of many similar commits:
14da9fb

The Pulse mixer added to MOksha 3,2 throws the following errors in stdout:

ERR<eo>lib/eo/eo_base_class.c:296 Eo ID 0x8001dd6e is not a valid object. Current thread: main. This ID has probably been deleted or this was never a valid object ID. (domain=0, current_domain=0, local_domain=0, available_domains=[0 1    ], generation=6e, id=3b8, ref=1)
ERR<ecore>lib/ecore/ecore_timer.c:254 You are trying to destroy a timer which seems dead already.
ERR<eo>lib/eo/eo.c:1798 Eo ID 0x8001dd6e is not a valid object. Current thread: main. This ID has probably been deleted or this was never a valid object ID. (domain=0, current_domain=0, local_domain=0, available_domains=[0 1    ], generation=6e, id=3b8, ref=1)

Štefan noted yesterday that loading and unloading the places module segfaults moksha. The obligatory backtrace (Only relevant parts):

Thread 1 "enlightenment" received signal SIGABRT, Aborted.
0xb7fdac31 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fdac31 in __kernel_vsyscall ()
#1  0xb729dea9 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#2  0xb729f407 in __GI_abort () at abort.c:89
#3  0xb72d937c in __libc_message (do_abort=2, 
    fmt=0xb73d1e54 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#4  0xb72df2f7 in malloc_printerr (action=<optimized out>, 
    str=0xb73d1f0c "double free or corruption (out)", ptr=<optimized out>, 
    ar_ptr=0xb7424780 <main_arena>) at malloc.c:5006
#5  0xb72dfc31 in _int_free (av=0xb7424780 <main_arena>, p=<optimized out>, 
    have_lock=0) at malloc.c:3867
#6  0xb7f4bc27 in ?? () from /usr/lib/i386-linux-gnu/libedbus.so.1
#7  0xb301c4e8 in places_udisks_shutdown () at places/e_mod_udisks.c:99
#8  0xb301a5cb in places_shutdown () at places/e_mod_places.c:61
#9  0xb3018975 in e_modapi_shutdown (m=0x8370c20) at places/e_mod_main.c:145
#10 0x080ff09d in e_module_disable (m=0x8370c20) at e_module.c:395
#11 0x080ffa7d in e_module_disable (m=0x8370c20) at e_module.c:415

Hello Jeff,

your I like Bodhi with Moksha very much, the only Thing I'm missing seriously is the possibility to place Starter Icons for Applications directly on desktop an arrange / group it to my needs.
For now I work around with an IBar, placed on Desktop, but this solution is difficult do get it done and you can't place the icons depending to your personal needs on desktop, only vertical or horizontal.

Maybe you can add the functionality under "add to favourites":
right-click on application bar --> application name --> "add to desktop"

This functionality whould be a great pleasure for all the windows to linux switcher...

Regards

Andreas

To brand Moksha in a Display Manager like LightDM an xsessions .desktop file is required (preferrably /usr/share/xsessions/moksha.desktop). As far as I can see, this is not the case either in Bodhi 3.0 with Moksha installed from apt-get or from source. I don't really know if the file should be provided by the package manager or the installation scripts, but here's how one might look:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Moksha
Comment=Log in using Moksha (Version x.y.z)
Icon=/usr/share/enlightenment/data/images/enlightenment.png
TryExec=/usr/bin/enlightenment_start
Exec=/usr/bin/enlightenment_start

(the Icon, TryExec, and Exec values being dependent on where Moksha was installed to, the example above assumes the current default.)

Examples:

• Popup from a window being "urgent" with the pager module
• Popup from displaying window geometry when enabled

Some debugging information here.

Issue:
Moksha will freeze the desktop when an application is moved from one monitor to another if the monitors are not the same size.

Description:
When an application is dragged from one monitor to another of different size, Moksha will enter a state where

• all application windows are locked in place on the desktop
• keyboard entry is ignored except for within open applications windows
• CPU usage on at least one core is maxed out
• mouse clicks are ignored outside of application windows

Observations:
-The only way found to recover is to reboot the system.

• The speed at which one move the application from one monitor to the other does seem to have an impact. Moving/dragging more slowly sometimes prevents the freeze.
• This issue is believed to be exacerbated by the fact that 'windows raise on focus' settings do not seem to work in Moksha 0.2.1.

Notes on attached files:

• xsession_error has been trimmed to include only the applicable error.

xrandr_to_report.txt
lsb_release.txt
xsession_error_to_report.txt

Hi, another bug that I've seen on E17 and it won't be fixed.
https://phab.enlightenment.org/T122

I report here the description:
If I set a text object on edje with outlined effect, like OUTLINE_SHADOW and I link to a color_class editable by Settings -> Look -> Colors , I have a strange behaviour when I'm changing the color by Settings -> Look -> Colors.

example:

On a theme with a part like this:

part { name: "my_text"; type: TEXT;
       effect: OUTLINE
       description { state: "default" 0.0;
         color_class: "border_title";
         color: 255 255 255 255;
         color2: 255 255 255 255;
         color3: 255 255 255 255;
         text { blah blah }
         }
     }

When I set as color2 of border title, on Settings -> Look -> Color , the Blue and the Green value are inverted.
Eg: I set color2 as 0 255 0 255 (the green) and I see 0 0 255 255 (the blue) and if I set 0 0 255 255 (the blu), I see 0 255 0 255 (the green).

The same things happens with yellow and fucsia:
If I set 255 0 255 255 (the fucsia) I'll see 255 255 0 255 (the yellow) and If I set 255 255 0 255 (the yellow) I'll see 255 0 255 255 (the fucsia)

Hope I am clear. The issue is visible only if I edit color2 and color3 by Settings -> Look -> Color Dialog, not if I set the color with the code.

While building the package, I am getting errors like these:

extracting debug info from /builddir/build/BUILDROOT/moksha-desktop-0.2.1-1.fc26.x86_64/usr/lib64/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.2.1/freqset
objcopy: unable to copy file '/builddir/build/BUILDROOT/moksha-desktop-0.2.1-1.fc26.x86_64/usr/lib64/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.2.1/freqset'; reason: Permission denied

Through the build system files I've noticed that permissions a=rx,u+xs are being set, any reason why user is not being given writable permission? e.g. a=rx,u+wxs

Probably there's a lot of places to edit, but I've found on src/bin/e_actions.c , line 2150 the config dialog

 e_dialog_text_set(exit_dialog, _("Are you sure you want to exit Enlightenment?"));

Maybe we have to replace Enlightenment with Moksha, isn't it?
And, of course, on all the translations file.
For example, on po/it.po on line 90

#: src/bin/e_actions.c:2124
msgid "Are you sure you want to exit Enlightenment?"
msgstr "Siete sicuri di voler uscire da Enlightement?"

When i go to "About Operating System" -> "Reset Moksha", i get a black and blank screen. The enlightenment process uses then 100% of one cpu-core.

I need to completly stop enlightenment (including enlightenment_start) and start enilghtenment again to get a working desktop back.

Currently, git head of moksha doesnt seem to have its own applications menu. Using the oldmenu module usually works fine. But doing a moksha reset causes the application menu to vanish, so maybe the oldmenu module doesnt load correctly during a moksha reset?

If a Moksha menu contains more entries than could be displayed by a vertical resolution, it shows nothing.

Way to reproduce the bug:

1. Set a computer to a low vertical setting, say, 800x600 or 1024x600.
2. Install a package that installs a lot of entries in a menu category. For example, a good option could be 'kdegames', which installs a lot of apps for the "Games" menu category.
3. As kdegames package installs a lot of programs, their menu entries cannot be shown all at once in a 600 vertical resolution (not even in my machine, at 1440x900). As a result, the "Games" menu does not show anything at all, as if Games were an empty category with no programs installed.

The same issue described with kdegames as an example, could happen in any category menu in which the user could install more programs than the vertical resolution available in his/her computer and not be able to display all the programs in a category at once.

If the test computer has the possibility to be set to a higher vertical resolution (say, 1600x1200), restart Moksha, and all the menu entries in the Games category are going to be visible. Of course, this workaround is not possible in every computer, and in others would be straining to the eye the need to have high resolutions merely to be able to see all the items in a menu category.

This seems to be a variant of the bug described for E17 in http://forums.bodhilinux.com/index.php?/topic/8271-not-all-programs-are-displayed-in-bodhi-menu/?hl=%2Bmenu+%2Bitems#entry69762

I would like to change the default theme to something lighter / more neutral. Started working on editing the "Radiance" E17 theme to something that might be a reasonable default -> https://github.com/JeffHoogland/MokshaRadiance

This messages appears when adjusting volume with a mouse scroll wheel. Using development branch commit 90e5ccb .

May 13 09:01:10 machine /usr/libexec/gdm-x-session[6320]: ERR<eo>lib/eo/eo.c:611 in lib/edje/edje_object.eo.c:134: func 'edje_obj_signal_emit': obj_id=0x555f915eb270 is an invalid ref.
May 13 09:01:10 machine /usr/libexec/gdm-x-session[6320]: ERR<edje>lib/edje/edje_util.c:3968 file /usr/share/enlightenment/data/themes/default.edj, group e/modules/notification/main has a non-fixed part 'notification.swallow.app_icon'. Adding 'fixed: 1 1;' to source EDC may help. Continuing discarding faulty part.

As long as I have been using bodhi It has always thrown DANGLING SUBMENU warnings in stderr or stdout. Now on the dev branch for moksha 3.0 we have:

WRN<e>e_menu.c:1346 DANGLING SUBMENU FOR Places: REF(1)||MENU(0xa13b4e8)
WRN<e>e_menu.c:1346 DANGLING SUBMENU FOR Desktop: REF(1)||MENU(0xa03bb38)
WRN<e>e_menu.c:1346 DANGLING SUBMENU FOR About Operating System: REF(1)||MENU(0xa1604c0)

I am noting it here as I would like to find the cause of this warning and fix it.

When I click the File Manager icon on the bottom gadget bar it produces an error without opening the File Manger. The File Manager works properly from the desktop left click application starter.

BTW: very nice system. Good job!

This issue has been reported to me by chauhankiran:

I am not sure if this is the place of creating an issue of Moksha desktop environment. If this is not, then please guide me on the where to write the issue.

If I open more than five program in my laptop, it put a open tab upto space between menu icon and first opened tab - https://prnt.sc/jnfli9

Selecting About Bodhi from menu and the window pops up blank. No scrolling text until you resize window. This was tested using default theme and MoskhaArcDark theme.

This functionality worked with efl 1.18.4 but upgrading efl to 1.19.1 breaks it. Also Stefan and/or I tested efl 1.20.5, efl 1.20.6, and efl 1.20.7. The latter two tested on lubuntu 16.04 with nicos enlightenment ppa and moksha compiled. For my testing all other test were done using bodhi 4.2 with all packages up to date.
All efl versions greater or equal to efl 1.19 have inconsistent results, Sometimes About Bodhi menu item works and sometimes it doesn't. Sometimes the same thing applies to the About Moksha menu item. Using nicos enlightenment ppa and efl 1.20.7 About Moksha works every time in multiple testing but About Bodhi works intermittently. In bodhi 4.5 both can fail intermittently.

In latest master tree, mixer allows to increase volume beyond 100% with a mouse scroll wheel.

This leads to issues in some applications when restarting Moksha like (he)xchat as mentioned here -> http://forums.bodhilinux.com/index.php?/topic/12514-gtk-theme-bug-when-restarting-moksha/

When I get around to rewriting the configuration panel we want to make sure this is done.

As far as i can see, pulseaudio is only used together with the mixer module. But the configure check for the pulseaudio libraries are not conditionally based on enabled mixer module.

So even if the mixer module is disabled and there is no need for pulseaudio, current git head of moksha requires pulseaudio to be installed. Please make this configure.ac check conditional based on the check, if mixer module is enabled or not.

Tried Badhi with Moksha 1st time..

1.Terminal is too deeply hidden in menu, hard to find
1b. Terminal not called with CtrlAltT (as i use on Ubuntu)
1c. Why name "Terminology", i must guess that it is terminal..

2.Main prob I cannot install CudaText via deb-file: i run it and installer ok, but Sudo asks a pass, i dont know the pass.

This is an upstream reported bug best described by stefan_schmidt:

Interesting bug. I was able to reproduce it. Having two folders called Übungsblätter and Ubungsblätter I can type u and it still lists Ubungsblätter while it does not list Übungsblätter when I type ü.

Like on E19, I report a super-simple change to do on Moksha:

I've noticed that the color_classes "Border Frame" and "Border Frame Active" should be displayed as Space, not like Text, so it is necessary to edit on /src/modules/conf_theme/e_int_config_color_classes.c .

Here the phab task for details: https://phab.enlightenment.org/T1637

This was working on E17.6, so I assume this is another issue with the border backports. When I have two chrome windows open I should be able to drag tabs between them. This is no longer possible with the current Moksha git code.