Yes, it is important to have the pure Debian version by default. Very nice to have all these options though. Well thought out scheme.saintless wrote:Hi, William.
DebianDog is pure Debian and it will use debian initrd by default
Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Hi, Terry.sunburnt wrote:Toni; For help, run: /root/0_BaCon/debmenu2desktop
This command filled /tmp/0 with only 66 ready to go desktop files ( not sure why not 70 ).Code: Select all
# /root/0_BaCon/debmenu2desktop /usr/share/menu /tmp/0 ##### Total Files: 70 #
debmenu2desktop is setup to use /mnt/sq/usr/share/menu which makes it not to work on DebianDog. I guess you use it from puppy?
I had to make some changes but works fine now. We will include it as menu entry option.
Added this in the beginning of /opt/bin/debmenu2desktop (otherwise gives error there is no /tmp/0 folder):
Code: Select all
mkdir /tmp/0
echo "***All converted desktop files are in /tmp/0 folder.***"
Code: Select all
Fs=`find /mnt/sq/usr/share/menu -maxdepth 1 -type f |grep -v README`
to to this:
Code: Select all
Fs=`find /usr/share/menu -maxdepth 1 -type f |grep -v README`
Code: Select all
root@debian:~# debmenu2desktop /usr/share/menu /tmp/0
***All converted desktop files are in /tmp/0 folder.***
##### Total Files: 70
root@debian:~#
Hi, all.
After installing w3m and links2 I get in /usr/share/menu files for links2 (GUI), Links2 (CLI), w3m (CLI) and I can start them all from start menu.
In /usr/share/applications I get desktop file only for Links2 (GUI).
If this is the case for most text based programs that means the user have to convert desktop files for them all the time to make them appear in the menu.
It seems desktop files are not well supported in debian package repository. I think we need a way to automate the process of converting menu to desktop files and move them in /usr/share/applications to make them appear in the mk-jwm.menu after installing every new package.
Toni
After installing w3m and links2 I get in /usr/share/menu files for links2 (GUI), Links2 (CLI), w3m (CLI) and I can start them all from start menu.
In /usr/share/applications I get desktop file only for Links2 (GUI).
If this is the case for most text based programs that means the user have to convert desktop files for them all the time to make them appear in the menu.
It seems desktop files are not well supported in debian package repository. I think we need a way to automate the process of converting menu to desktop files and move them in /usr/share/applications to make them appear in the mk-jwm.menu after installing every new package.
Toni
William, here's a new 021-apps-porteus.xzm updated for JWM.
Just replace with this one in the 'base' folder.
changes=EXIT:/ and choice to save or not should work then.
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Toni,
Just for info: I edited /root/jwm/jwm.tail and /etc/jwm/system.jwmrc.
Removed the "shutdown" and "reboot" entries and added "Logout" pointing to obshutdown.
Terry, I'll test your new menu-maker later today.
Fred
Just replace with this one in the 'base' folder.
changes=EXIT:/ and choice to save or not should work then.
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Toni,
Just for info: I edited /root/jwm/jwm.tail and /etc/jwm/system.jwmrc.
Removed the "shutdown" and "reboot" entries and added "Logout" pointing to obshutdown.
Terry, I'll test your new menu-maker later today.
Fred
You are welcome Toni!saintless wrote:Thank you, Fred!fredx181 wrote:William, here's a new 021-apps-porteus.xzm updated for JWM.
Just replace with this one in the 'base' folder.
Downloading and saving this for the new iso build.
Toni
I hope I did it right, also for puppy user and /etc/skel.
Please test a little.
Fred
Hi William, Toni
New revision of 021-apps-porteus.xzm:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Forgot in previous version to update a few scripts to use 'gsu' (Graphical su) for multiuser support.
Toni, what I didn't add is a menu entry for creating porteus savefile (anyway question will appear at shutdown to create savefile in case booting without one)
It would be nice if you can add, but if it's very complicated just leave it like it is.
Fred
New revision of 021-apps-porteus.xzm:
https://drive.google.com/file/d/0ByBgCD ... sp=sharing
Forgot in previous version to update a few scripts to use 'gsu' (Graphical su) for multiuser support.
Toni, what I didn't add is a menu entry for creating porteus savefile (anyway question will appear at shutdown to create savefile in case booting without one)
It would be nice if you can add, but if it's very complicated just leave it like it is.
Fred
Thank you, Fred!fredx181 wrote:Toni, what I didn't add is a menu entry for creating porteus savefile (anyway question will appear at shutdown to create savefile in case booting without one)
It would be nice if you can add, but if it's very complicated just leave it like it is.
I will add porteus save file option with sure.
I'm removing the second pae kernel now and I will start working on the separate kernel modules.
The base will be one module with kernel 486 included. This way only one module will be loaded on boot for Debian boot and 2 modules for Porteus boot. It should not take more ram usage this way.
The modules for 686-pae and Porteus-kernel + more extra modules later will be available for download and remastering the main module after purging 486 kernel.
Toni
Everyone;
For root user having the Shutdown, Reboot, etc... is a good thing. Right.?
# We need to define root & user menu differences.
Toni; Yes... I keep forgetting to remove PRINT statements and other code patches.
# Instead of /tmp/0 , probably better to use something like: /tmp/desktop
# How about mk-jwm.menu checking for changes in: /usr/share/menu
This can be done by file creation or a tracking list.
If there`s a change, then run ( on all new files found ):
### New mk-jwm.main file. Complete rewrite of the icon search.
Finds icon anywhere in /usr/share/icons, and it made a good menu.
# Icon search method:
1) If no Icon= , then default icon
2) If is good: /path/icon.ext
3) If is good: $HOME/.icons/icon.ext
4) If is good: /usr/share/pixmaps/icon.ext
5) Search icon no ext. in: $HOME/.icons
6) Search icon no ext. in: /usr/share/pixmaps
7) "find" icon in: /usr/share/icons
I think that this jwm.tail file should be the one for normal users. Correct.?Just for info: I edited /root/jwm/jwm.tail and /etc/jwm/system.jwmrc.
Removed the "shutdown" and "reboot" entries and added "Logout" pointing to obshutdown.
For root user having the Shutdown, Reboot, etc... is a good thing. Right.?
# We need to define root & user menu differences.
Toni; Yes... I keep forgetting to remove PRINT statements and other code patches.
# Instead of /tmp/0 , probably better to use something like: /tmp/desktop
# How about mk-jwm.menu checking for changes in: /usr/share/menu
This can be done by file creation or a tracking list.
If there`s a change, then run ( on all new files found ):
Code: Select all
debmenu2desktop /usr/share/menu/(NewFile) /usr/share/applications
Finds icon anywhere in /usr/share/icons, and it made a good menu.
# Icon search method:
1) If no Icon= , then default icon
2) If is good: /path/icon.ext
3) If is good: $HOME/.icons/icon.ext
4) If is good: /usr/share/pixmaps/icon.ext
5) Search icon no ext. in: $HOME/.icons
6) Search icon no ext. in: /usr/share/pixmaps
7) "find" icon in: /usr/share/icons
- Attachments
-
- mk-jwm.main.zip
- (19.33 KiB) Downloaded 199 times
Hi, Terry.
Root and user will get the same jwm.tail with shutdown submenu.
Toni
No, this is something needed for Porteus boot option to make save changes work. The changes will be in very small separate module used only for Porteus boot.sunburnt wrote:I think that this jwm.tail file should be the one for normal users. Correct.?Just for info: I edited /root/jwm/jwm.tail and /etc/jwm/system.jwmrc.
Removed the "shutdown" and "reboot" entries and added "Logout" pointing to obshutdown.
For root user having the Shutdown, Reboot, etc... is a good thing. Right.?
Root and user will get the same jwm.tail with shutdown submenu.
Sounds good to me.# How about mk-jwm.menu checking for changes in: /usr/share/menu
This can be done by file creation or a tracking list.
If there`s a change, then run ( on all new files found ):Code: Select all
debmenu2desktop /usr/share/menu/(NewFile) /usr/share/applications
Thank you, Terry! I will test it and report back.### New mk-jwm.main file. Complete rewrite, finds icon anywhere in /usr/share/icons
It does "find" on: /usr/share/icons , it did find an icon file there and made a good menu.
Toni
Toni; Joe was right about the Firefox navigation keys.
They`re probably the same for other Mozilla browsers too.
Comment out these lines at the bottom of the jwm.tail file:
### I`ll look at doing a new file find in /usr/share/menu
# Fred; Maybe you have an idea as to how to find new menu files.?
I didn`t catch that the menu change was a "Proteus thing".
### But still... We want to sandbox the user menu, right.?
.
They`re probably the same for other Mozilla browsers too.
Comment out these lines at the bottom of the jwm.tail file:
Code: Select all
<--
<Key mask="A" key="Left">ldesktop</Key>
<Key mask="A" key="Right">rdesktop</Key>
-->
# Fred; Maybe you have an idea as to how to find new menu files.?
I didn`t catch that the menu change was a "Proteus thing".
### But still... We want to sandbox the user menu, right.?
.
Last edited by sunburnt on Fri 21 Mar 2014, 16:36, edited 2 times in total.
Thank you, Terry!sunburnt wrote:### New mk-jwm.main file. Complete rewrite of the icon search.
Finds icon anywhere in /usr/share/icons, and it made a good menu.
# Icon search method:
1) If no Icon= , then default icon
2) If is good: /path/icon.ext
3) If is good: $HOME/.icons/icon.ext
4) If is good: /usr/share/pixmaps/icon.ext
5) Search icon no ext. in: $HOME/.icons
6) Search icon no ext. in: /usr/share/pixmaps
7) "find" icon in: /usr/share/icons
Seems working fine. I get icon for audacious without changing anything else than your new mk-jwm.main
I will test it more in the next days to see if I can find any problems.
Toni
Terry,
You should try it once, then you know what we're talking about and you might like it!
It brings a lot of options more than the regular debian live-boot and the debian system itself is exactly the same.
Toni, still struggling with multiuser support with 021-apps-porteus.xzm.
It's the exact thing as some time ago:
Because of the copying when changes=EXIT:/ option is used /home/puppy is owned by root.
I thought I had solved it but can't remember how
So probably again new update will come later.
Fred
It's "Porteus"I didn`t catch that the menu change was a "Proteus thing".
You should try it once, then you know what we're talking about and you might like it!
It brings a lot of options more than the regular debian live-boot and the debian system itself is exactly the same.
Toni, still struggling with multiuser support with 021-apps-porteus.xzm.
It's the exact thing as some time ago:
Because of the copying when changes=EXIT:/ option is used /home/puppy is owned by root.
I thought I had solved it but can't remember how
So probably again new update will come later.
Fred
Fred, I'm not sure if this is what you are looking for but check out in 01-v7.squashfs in /opt/bin/new/changes-EXIT-filesfredx181 wrote:Because of the copying when changes=EXIT:/ option is used /home/puppy is owned by root.
I thought I had solved it but can't remember how
So probably again new update will come later.
I keep there to be added later the latest files from you uploaded after creating DebianDog-PorteusDog-test.iso
Toni
I'm thinking to keep root only applications to be executed from command line (like xdm-start and xdm-stop). This will save as the troubles creating separate jwm menu for user. User and root will have the same JWM menu unless we do not find good reason to keep them different.sunburnt wrote:### But still... We want to sandbox the user menu, right.?
.
What I don't like is after installing xdm the path in /etc/profile does not work and we have path exported from /etc/environment
Unfortunately it exports the secure bin paths for user also. I will try to fix this but for now we keep this problem.
Toni
Hi Toni
Fortunally didn't have to reinvent the wheel
New revision of 021-apps-porteus.xzm: use link in one of my previous posts.
Fred
Yes, thanks!, it was in the snapmergepuppy script.Fred, I'm not sure if this is what you are looking for but check out in 01-v7.squashfs in /opt/bin/new/changes-EXIT-files
Fortunally didn't have to reinvent the wheel
New revision of 021-apps-porteus.xzm: use link in one of my previous posts.
Fred
Toni; If Debian uses /menu files reliably, then mk-menu should use them.
I like Free standards, but we`re using Debian, so lets do it the Debian way.
# It only makes sense to use what Debian supports...
I can rewrite mk-menu to read menu files, and keep desktop files as option.
Then debmenu2desktop would not be needed so much.
# Need to check that most .deb packages have menu files ( I`d think so...).
### This could possibly solve our menu problems completely.!
.
I like Free standards, but we`re using Debian, so lets do it the Debian way.
# It only makes sense to use what Debian supports...
I can rewrite mk-menu to read menu files, and keep desktop files as option.
Then debmenu2desktop would not be needed so much.
# Need to check that most .deb packages have menu files ( I`d think so...).
### This could possibly solve our menu problems completely.!
.
Terry, I'm sure Debian uses much more reliable /usr/share/menu files since they are the structure of debian update-menus system.
Unfortunately some package developers do not make menu files for debian menu system and have only desktop packages included. This is the future package management behaviour. This means debian packages outside debian wheezy repository may not have menu files included. Debian developers maybe will follow this method for the next stable debian or try to adapt current debian menu to use desktop files.
If we change the menu method it is better to use desktop files. This way we will have separate working replacement for debian menu system.
I think there is no point to try to replace debian menus system using the same menu files just to get different menu structure.
Edit: Terry, it is better to test a few days mk-jwm.menu before starting work to convert and copy new menu -> desktop files after every new installed package. Maybe the missing desktop files will not be too many and we can use manual convert as option.
Toni
Unfortunately some package developers do not make menu files for debian menu system and have only desktop packages included. This is the future package management behaviour. This means debian packages outside debian wheezy repository may not have menu files included. Debian developers maybe will follow this method for the next stable debian or try to adapt current debian menu to use desktop files.
If we change the menu method it is better to use desktop files. This way we will have separate working replacement for debian menu system.
I think there is no point to try to replace debian menus system using the same menu files just to get different menu structure.
Edit: Terry, it is better to test a few days mk-jwm.menu before starting work to convert and copy new menu -> desktop files after every new installed package. Maybe the missing desktop files will not be too many and we can use manual convert as option.
Toni
Last edited by saintless on Fri 21 Mar 2014, 18:19, edited 1 time in total.