Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: jls on March 24, 2010, 09:40:27 PM
-
I only see the 3 icons from the base even I have extensions in onboot.lst that normally creates icons in wbar .
-
Read the .info file. The extension maker did not create the necessary interface files for Tiny Core. It is the first line of the comments.
-
Read the .info file. The extension maker did not create the necessary interface files for Tiny Core. It is the first line of the comments.
That being said, there is nothing in e17 that should affect wbar's ability to function correctly, and indeed on (all three) of my test systems, appropriate wbar icons are visible for onboot applications when I let wbar start. I tend to find wbar is not necessary for enlightenment however, as there is a gadget on the shelf which serves the same purpose.
-
but wbar works also using other wm, if I load an xtension having an icon entry when the system is running, wbar gets updated, the only problem, I'm repeeting, is for tcz loaded during boot.
I understand u like flwm as I do I, but since (rarely) happens that I install tc/mc to friends' computer, flwm is not always well seen.
I agree wbar isn't needed in E(nlightenment) but wbar is auto populated by this distro despite the one in E
-
So it works with all other window managers, except enlightenment.
I guess I will have to get involved with this extension then,
-
I only tred enlightenment, using the boot code
desktop=enghlitenment_startor something like that, but I feel the problem occours with any other wm
-
jwm OK, icewm OK, hackedbox OK.
the desktop= is really not very useful anymore, unless you have multiple window managers listed onboot, and then wish to specify which one to actually use via the bootcode.
desktop=icewm
BTW, enlightenment errors out for me with
ERROR: UNABLE TO ASSUME ROOT PRIVILIDEGES.
So unable to test it.
-
BTW, enlightenment errors out for me with
ERROR: UNABLE TO ASSUME ROOT PRIVILIDEGES.
So unable to test it.
Hmm. I'd noticed those messages too, but since I'd also seen them on a Ubuntu session, and they've never seemed to interfere with e17 being able to run, nor seemed to interfere with it's operation, I'd dismissed them as not being relevant.
If it's actually preventing e17 from starting, then I'll look into finding out the problem there. Is there anything specific in your setup that would force e to stop after those errors?
-
With enlightenment, I get what appears to be a language select screen, except it is totally blank. Nothing to select. The cursor is very blurred. I tried to click on the wbar terminal and nothing worked. I don't know this window manger, so it is likely me. When exiting the window manager, I see the error messages. Reading the .info file did not help.
-
Is the cursor blurry, or does the drop shadow just make it look blurry? E17 has the attitude of "We can be a lightweight desktop environment fast enough for embedded devices, AND be fancier than gnome!", but it does make the default cursor a little hard on the eyes.
On first run, it's usually best to boot with "noicons". There's actually a "Next" button hidden under wbar, and whatever e17 does on that first boot interferes with wbar's behaviour. After you get through the config screen, add /home/tc/.e to your backup and then you can turn wbar back on - I have previously promised to update the info file to include this information, but simply haven't had the time to do it properly yet.
-
Ah, see, the noicons is the trick.
However, this window manager is very difficult for low vision users, such as myself. There is still much of which I am unable to read. After a reboot, sans noicons, wbar seems to still be incompatible.
With implementing freedesktop.org for core menu should help this window manager. I have started such.
-
I updated the .info with
Best to use 'noicons' boot option.
-
if u don't see well u can customize E.
if u start wbar with -above-desk then when u install an extension which adds an entry in wbar, wbar doesn't crash
-
Ah, see, the noicons is the trick.
However, this window manager is very difficult for low vision users, such as myself. There is still much of which I am unable to read. After a reboot, sans noicons, wbar seems to still be incompatible.
E is highly customisable, and I'm sure it would be trivial to adjust things for low vision users (Just don't ask me how, as it's not a problem I've needed to solve yet)
With implementing freedesktop.org for core menu should help this window manager. I have started such.
I will be interested in seeing the progress to see how this affects freedesktop DE's.
-
Another issue with Enlightenment, I see that the freedesktop.org .desktop specification of
Terminal=true
does not work with this extension. I have the other Tiny Core menu items working.
I also have no issue with LXDE extension in using the Terminal=true specification.
Is it just this build or a general issue with Enlightenment?
-
Another issue with Enlightenment, I see that the freedesktop.org .desktop specification of
Terminal=true
does not work with this extension. I have the other Tiny Core menu items working.
I also have no issue with LXDE extension in using the Terminal=true specification.
Is it just this build or a general issue with Enlightenment?
It doesn't work in Xfce4 with the default Aterm from the base but works fine with the optional vte based 'Terminal' extension. BTW, both LXDE and Xfce4 terminals are using the vte library.
-
Another issue with Enlightenment, I see that the freedesktop.org .desktop specification of
Terminal=true
does not work with this extension. I have the other Tiny Core menu items working.
I also have no issue with LXDE extension in using the Terminal=true specification.
Is it just this build or a general issue with Enlightenment?
More than likely it's a general e17 issue. I'll bring it up with the devs, see what they think.
-
bmarkus, could you ask the Xfce devs about that? IIRC we also have a symlink xterm -> aterm, so it should be detecting at least xterm.
-
bmarkus, could you ask the Xfce devs about that? IIRC we also have a symlink xterm -> aterm, so it should be detecting at least xterm.
No need to ask, it is a local issue with Xfce4 default setup on TC. Changing it from 'aterm' to 'X Terminal' it works as expected. Will fix it.
-
Another issue with Enlightenment, I see that the freedesktop.org .desktop specification of
Terminal=true
does not work with this extension. I have the other Tiny Core menu items working.
I also have no issue with LXDE extension in using the Terminal=true specification.
Is it just this build or a general issue with Enlightenment?
Actually, it's more likely a configuration issue.
The following desktop entry correctly launches Vim in a terminal:
[Desktop Entry]
Name[C]=Vim
Hidden=false
Exec=vim
Icon=/usr/local/tce.icons/gvim.png
NoDisplay=false
Comment[C]=Vim Editor
Type=Application
Version=1.0
StartupNotify=false
Comment=Vim Editor
Terminal=true
Icon[C]=/usr/local/tce.icons/gvim.png
Name=Vim
I've been doing some heavy experimentation with my e17 configuration, learning all the ins and outs, so if I have time today, I'll set up a default tc + e and work out what I've changed exactly that made it work.
(It could also be that my version is slightly newer than the version in the repo. Just need to find some time to finish putting together new info and dep files before I submit the new version)
-
If the libs have their own versions, could you use those in the info files instead of the e snapshot version? I think at least eet is a formal 1.2.x release..
-
bmarkus, could you ask the Xfce devs about that? IIRC we also have a symlink xterm -> aterm, so it should be detecting at least xterm.
No need to ask, it is a local issue with Xfce4 default setup on TC. Changing it from 'aterm' to 'X Terminal' it works as expected. Will fix it.
Bug fixed Xfce4base.tcz is in the repo.
-
Would you share on how it was fixed (and where the bug was in the first place)?
-
Would you share on how it was fixed (and where the bug was in the first place)?
Simple configuration mismatch, my fault. Terminal emulator is specified in
/home/tc/.config/xfce4/helpers.rc
Now default is:
TerminalEmulator=aterm
while previously it was
TerminalEmulator=custom
Of course custom doesn't exist and can't be executed, error message was correct.
TerminalEmulator=xterm
works too.
-
Another issue with Enlightenment, I see that the freedesktop.org .desktop specification of
Terminal=true
does not work with this extension. I have the other Tiny Core menu items working.
I also have no issue with LXDE extension in using the Terminal=true specification.
Is it just this build or a general issue with Enlightenment?
Actually, it's more likely a configuration issue.
The following desktop entry correctly launches Vim in a terminal:
[Desktop Entry]
Name[C]=Vim
Hidden=false
Exec=vim
Icon=/usr/local/tce.icons/gvim.png
NoDisplay=false
Comment[C]=Vim Editor
Type=Application
Version=1.0
StartupNotify=false
Comment=Vim Editor
Terminal=true
Icon[C]=/usr/local/tce.icons/gvim.png
Name=Vim
I've been doing some heavy experimentation with my e17 configuration, learning all the ins and outs, so if I have time today, I'll set up a default tc + e and work out what I've changed exactly that made it work.
(It could also be that my version is slightly newer than the version in the repo. Just need to find some time to finish putting together new info and dep files before I submit the new version)
This does not work with the version of enlightenment in the repository.
-
Would you share on how it was fixed (and where the bug was in the first place)?
Simple configuration mismatch, my fault. Terminal emulator is specified in
/home/tc/.config/xfce4/helpers.rc
Now default is:
TerminalEmulator=aterm
while previously it was
TerminalEmulator=custom
Of course custom doesn't exist and can't be executed, error message was correct.
TerminalEmulator=xterm
works too.
Upgraded the base. Checking the Settings Preferred Applications Utilities I do now see aterm. Still simply using the run command from xfce menu fails when trying to run vi or top with the run in terminal option checked.
Checking the Settings Preferred Applications Utilities I do now see aterm.
-
Upgraded the base. Checking the Settings Preferred Applications Utilities I do now see aterm. Still simply using the run command from xfce menu fails when trying to run vi or top with the run in terminal option checked.
Checking the Settings Preferred Applications Utilities I do now see aterm.
It works here. Enter 'top' and tick checkbox 'Run in terminal':
(http://tc.hasix.org/scrcap/xfceterm2.jpg)
Top runs fine in a terminal window:
(http://tc.hasix.org/scrcap/xfceterm3.jpg)
Same with vi.
-
reinstalling all of xfce now works to the point of simple run in terminal.
However, I see a wide variation of how freedesktop items are handled.
LXDE works the way I would think it should, i.e., within a .desktop item using both
Exec=sudo usbinstall and Terminal=true, works as expected. XFCE does not. Even back to the run command prefixing with sudo fails, but of course, not checking run in terminal, and using
aterm -e sudo usbinstall does.
-
I will evaluate Xfce in few days.
-
Hm... On a fresh 2.10 placing this USB_Installl.desktop into /home/tc/Desktop it works as expected:
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=USB Installer
Categories=Application;
Exec=sudo usbinstall
Icon=dialog-warning
Terminal=true
StartupNotify=false
but doesn't work in /usr/local/share/applications :( I do not know why it behaves differently. When usbinstall terminates with an error message terminal window is closed immediately :(
-
(It could also be that my version is slightly newer than the version in the repo. Just need to find some time to finish putting together new info and dep files before I submit the new version)
This does not work with the version of enlightenment in the repository.
I should have enough free time after work tonight to get the new version finished up and send it off to the extensions gmail account. I believe that should resolve this issue.
If the libs have their own versions, could you use those in the info files instead of the e snapshot version? I think at least eet is a formal 1.2.x release..
Not sure I follow, but e is generally developed against the latest versions of the libs from the repo. Relying on a snapshot two or three months old for the libraries whilst providing the latest e would be silly and cause problems.
-
Hm... On a fresh 2.10 placing this USB_Installl.desktop into /home/tc/Desktop it works as expected:
[Desktop Entry]
Version=1.0
Encoding=UTF-8
Type=Application
Name=USB Installer
Categories=Application;
Exec=sudo usbinstall
Icon=dialog-warning
Terminal=true
StartupNotify=false
but doesn't work in /usr/local/share/applications :( I do not know why it behaves differently. When usbinstall terminates with an error message terminal window is closed immediately :(
1. Not really helpful to only work in home.
2. Should work in either /usr/share/applications or /usr/local/share/applications.
As I said, LXDE does and is the most compliant. XFCE less so, Englightenment, I am waiting.
The .desktop items are not that difficult. I am looking consistency in support of a standard, otherwise much effort will not result in good experience.
-
2. Should work in either /usr/share/applications or /usr/local/share/applications.
For sure. And must work starting with the run command too in the menu. Trying to fix, work in progress.
The .desktop items are not that difficult. I am looking consistency in support of a standard, otherwise much effort will not result in good experience.
Using .desktop definition files is a good idea. BTW, it brings in a new attribute, category.