And again, Hi!
I've spotted some dumbness and errors in my load modules script.
I still don't understand how it was working ;) Fixed.
If somebody still interested in this, it should be like this:
# modules load part
MODULES="alarm clock cpu deskshow dropshadow forecasts ibar ibox
language mail mem net news pager screenshot slideshow start taskbar
tclock mixer uptime weather moon winselector"
TMPF=/tmp/e_mod_load
$ER -module-list|grep "ENABLED" > $TMPF
for m in $MODULES; do
[ ! -z "`grep $m $TMPF`" ] || $ER -module-load $m
[ `grep $m $TMPF|grep -c "ENABLED 1"` -gt 0 ] || $ER -module-enable $m
done
rm -f $TMPF
Thanks,
Dan
Carsten Haitzler (The Rasterman) wrote:
> On Thu, 31 May 2007 14:16:50 +0300 "Ag. System Administrator"
> <[EMAIL PROTECTED]> babbled:
>
> no screenshots attached.
>
>> Hi!
>>
>> Sorry for huge mail.
>>
>> Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 30 May 2007 21:22:14 +0300 "Ag. System Administrator"
>>> <[EMAIL PROTECTED]> babbled:
>>>
>>> i have yet to see anything like this... ? :/
>> See attached screenshots.
>>
>> e_before_rest.png - as it looks when E loaded first time.
>> e_after_rest.png - as it looks after restart (from menu)
>> e_after_restart_module_load.png - as it looks after load and enabling
>> missing modules.
>>
>> This is the script i use to load and enable them again:
>>
>> #!/bin/bash
>> ER="enlightenment_remote"
>>
>> # some removed: bling
>> MODULES="alarm clock cpu deskshow dropshadow forecasts ibar ibox
>> language mail mem net news pager screenshot slideshow start taskbar
>> tclock mixer uptime weather moon winselector"
>> mreply=`$ER -module-list|grep -c "ENABLED"`
>>
>> for m in $MODULES; do
>> [ ! -z `echo $mreply|grep $m` ] || $ER -module-load $m
>> [ `echo $mreply|grep $m|grep -c "ENABLED 1"` -gt 0 ] || $ER
>> -module-enable $m
>> done
>>
>>
>> also, look at language module screenshot - no languages at all :(((
>>
>>
>>>> Also, not related to this issue, another crazy thing. Imagine situation,
>>>> when you have couple of terminal windows open, and E crashed (for reason
>>>> or not). On restart, E_IPC_SOCKET will get new value, but on opened
>>>> terminals it will stay with old value (thus making them unusable for
>>>> enlightenment_remote utility). Might be we should find another way to
>>>> pass socket name and location to enlightenment_remote?
>>> this can't be. the socket name is the display (doesn't change) and pid. pid
>>> also does not change, if e is catching its crash (white box of death). are
>>> you
>> E_IPC_SOCKET does not change in case if E catch his crash. And in case
>> of "glibc detected bla-bla-bla" this is the case. Ok, i got it ;)
>>
>>> launching e via some other mechanism that restarts e instead of e handling
>>> it?
>> I running E this way:
>>
>> $ xinit
>>
>> then, in teminal window opened, i run ~/e
>>
>> --- ~/e ---
>>
>> #!/bin/bash
>>
>> export PATH=/opt/e17/bin:/opt/e17/sbin:$PATH
>>
>> #this is needed for apps that use fake transparency
>> #Esetroot -scale /usr/share/backgrounds/images/space/marsglobe1.jpg &
>> #and finally start E17
>> /opt/e17/bin/enlightenment_start
>>
>> --------------------
>>
>> Well, i guess, that i should use entrance(d) and Co.
>>
>>
>> Thanks,
>> Dan
>>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
