Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
Hi, Terry.
AFAIK the desktop files are used from different WM like KDE and others that prefer to have their own generate menu method different from debian one. I guess you are right the desktop files are placed inside from the package developers.
It will be nice to have same method to convert IceWM menu.
The corresponding jwm.main file for IceWM is /etc/X11/icewm/programs or $HOME/.icewm/programs if we move it separate for each user.
Corresponding Jwm.head file for Icewm is $HOME/.icewm/menu
We can't use something similar to jwm.tail in IceWM. I think this part of the menu is auto-generated by $HOME/.icewm/preferences At least we can hide the shutdown menu from this file.
Toni
AFAIK the desktop files are used from different WM like KDE and others that prefer to have their own generate menu method different from debian one. I guess you are right the desktop files are placed inside from the package developers.
It will be nice to have same method to convert IceWM menu.
The corresponding jwm.main file for IceWM is /etc/X11/icewm/programs or $HOME/.icewm/programs if we move it separate for each user.
Corresponding Jwm.head file for Icewm is $HOME/.icewm/menu
We can't use something similar to jwm.tail in IceWM. I think this part of the menu is auto-generated by $HOME/.icewm/preferences At least we can hide the shutdown menu from this file.
Toni
apt2sfs+loadmodule_debiandog
Thank you Fred.
'apt2sfs+loadmodule_debiandog' -wonderful addition to the system as a whole.
In my opinion a compact system that can design their own versions of the new, is one of the main advantages of DebianDog (Debian and Porteus).
The user has another effective tool for experimentation and improvement of the system in the right (to him - user) direction.
Unmet dependencies inherent in almost all implementations of Linux, this is the reality. Methods of dealing with this phenomenon known to us.
Sergey.
'apt2sfs+loadmodule_debiandog' -wonderful addition to the system as a whole.
In my opinion a compact system that can design their own versions of the new, is one of the main advantages of DebianDog (Debian and Porteus).
The user has another effective tool for experimentation and improvement of the system in the right (to him - user) direction.
Unmet dependencies inherent in almost all implementations of Linux, this is the reality. Methods of dealing with this phenomenon known to us.
Sergey.
Hi Toni
Fred
Aahh, of course, I should have known, noticed already you did that with some applications.For example after creating sfs module with Gtkam it does not appear in debian menu with this content:
Code:
?package(gtkam):needs="X11" \
section="Applications/Viewers" \
title="gtkam" \
But changing package name to registered one this way makes it appear in the menu.
Code:
?package(epdfview):needs="X11" \
section="Applications/Viewers" \
title="gtkam" \
Fred
Terry,
I'm thinking to make desktop files for all missing apps.
It is better to have them this way instead of hardcoded jwm.head. it will be easier to remove desktop and menu file than editing $home/.jwm/jwm.head and /etc/skel/.jwm/jwm.head and the corresponding IceWm menu files if you make the same menu method for IceWM.
Toni
I'm thinking to make desktop files for all missing apps.
It is better to have them this way instead of hardcoded jwm.head. it will be easier to remove desktop and menu file than editing $home/.jwm/jwm.head and /etc/skel/.jwm/jwm.head and the corresponding IceWm menu files if you make the same menu method for IceWM.
Toni
# You guys have used Debian packages more than me I think.
### Do most all Debian packages have the menu files in them.? ( You`d think so...)
# This is critical... If many packages lack menu files, then they`re no better than desktop files.
Toni; To make the top & bottom menu items from desktop/menu files. how do we order them.?
The best way I can think of is to use the menu-root.lst file.
In the menu-root.lst file, have a key word ( App ) and the menu file name.
# Like this:
App xterm
App dillo
The menu file name refers to desktop files or Deb. menu files, which ever is being used.
Fairly easy to add the needed mk-menu code to do this.
# But... The top menu items use default_ links. Perhaps a way to still use them.?
.
### Do most all Debian packages have the menu files in them.? ( You`d think so...)
# This is critical... If many packages lack menu files, then they`re no better than desktop files.
Toni; To make the top & bottom menu items from desktop/menu files. how do we order them.?
The best way I can think of is to use the menu-root.lst file.
In the menu-root.lst file, have a key word ( App ) and the menu file name.
# Like this:
App xterm
App dillo
The menu file name refers to desktop files or Deb. menu files, which ever is being used.
Fairly easy to add the needed mk-menu code to do this.
# But... The top menu items use default_ links. Perhaps a way to still use them.?
.
Hi, Terry.
All deb packages from debain based distros will have /usr/share/applications desktop files. Most likely will not have at all /usr/share/menu file.
We use mostly official debian repository and we can be sure all packages we use have /usr/share/menu file
Menu-root.list makes the top categories only at the moment.
Toni
All deb packages in debian squeezy, wheezy, jessie, sid repository have /usr/share/menu files. Some of them do not have /usr/share/applications desktop files.### Do most all Debian packages have the menu files in them.? ( You`d think so...)
# This is critical... If many packages lack menu files, then they`re no better than desktop files.
All deb packages from debain based distros will have /usr/share/applications desktop files. Most likely will not have at all /usr/share/menu file.
We use mostly official debian repository and we can be sure all packages we use have /usr/share/menu file
I'm not sure what you try to order. I like alphabetical order as it is now in 01-v7.squashfs Why do you want to change it and to have more complicated root-menu.listToni; To make the top & bottom menu items from desktop/menu files. how do we order them.?
The best way I can think of is to use the menu-root.lst file.
In the menu-root.lst file, have a key word ( App ) and the menu file name.
# Like this:
App xterm
App dillo
The menu file name refers to desktop files or Deb. menu files, which ever is being used.
Fairly easy to add the needed mk-menu code to do this.
# But... The top menu items use default_ links. Perhaps a way to still use them.?
.
Menu-root.list makes the top categories only at the moment.
Toni
Terry, the top and bootom if I understand right are lwm.head and lwm.tail?
I already have bottom Shutdown items in one menu category.
The top items from jwm.head will be placed in system and utility folders mostly. Manual changing the section inside the desktop file will do it.
Only Default terminal and Default Web-browser will stay on top of the menu.
Toni
I already have bottom Shutdown items in one menu category.
The top items from jwm.head will be placed in system and utility folders mostly. Manual changing the section inside the desktop file will do it.
Only Default terminal and Default Web-browser will stay on top of the menu.
Toni
Terry.
Download the attached archive with current configuration I have and extract the zip. It includes your latest mk-jwm.main + all desktop and menu files.
Load it with SFS-Loader or place 02-menu-test.squashfs in /live with 10-v7.squashfs and reboot. make sure not to have save file in use.
Run menu-debian and menu-puppy to see the changes. The top terminal and browser will not have icons but i forgot to add the changes in the squashfs for them.
I know much more has to be edited and sorted.
Write what you think about this.
Toni
Download the attached archive with current configuration I have and extract the zip. It includes your latest mk-jwm.main + all desktop and menu files.
Load it with SFS-Loader or place 02-menu-test.squashfs in /live with 10-v7.squashfs and reboot. make sure not to have save file in use.
Run menu-debian and menu-puppy to see the changes. The top terminal and browser will not have icons but i forgot to add the changes in the squashfs for them.
I know much more has to be edited and sorted.
Write what you think about this.
Toni
- Attachments
-
- 02-menu-test.squashfs.zip
- (46.62 KiB) Downloaded 186 times
Hi Toni
Also made it do some "zerosizing" to save some space.
I edited my post on previous page and new version uploaded there.
Fred
Yes, good idea, I made a checkbox for it.Just a thought for extra option.
It needs apt-get update to be run before starting apt2sfs. Maybe running apt-get update at program start up as default?
Also made it do some "zerosizing" to save some space.
I edited my post on previous page and new version uploaded there.
Fred
I absolutely agree with this last comment. Making menu from desktop files is the way to go. I would be surprised if Debian developers didn't in the future move to a menu based on desktop files also. In the meantime shouldn't be too difficult to make a few desktop files for any packages that didn't supply one by default. Terry's menu looking good.saintless wrote: 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.
github mcewanw
Hi Toni, William
Here's IMO an important addition to DebianDog-Porteus:
It will give an option (in case boot parameter changes=EXIT:/) to save changes or not when shutdown/reboot from terminal or console instead of only when X is running.
It works also when pressing Ctrl+Alt+Del from some tty.
It gives a simple question on the console, but when you install the 'dialog' package, then there will be a nicer "dialog".
See below for: snapexit_0.1.1-1_i386.deb (remove dummy .tar extension)
Toni, I wanted to add this to the 021-apps-porteus.xzm module but AFAIK it isn't reliable because of changes in the shutdown order (changed symbolic links in e.g. /etc/rc6).
So the best thing I can think of is to include it in the main module.
I made sure it doesn't run when using the live-boot DebianDog version.
Fred
Here's IMO an important addition to DebianDog-Porteus:
It will give an option (in case boot parameter changes=EXIT:/) to save changes or not when shutdown/reboot from terminal or console instead of only when X is running.
It works also when pressing Ctrl+Alt+Del from some tty.
It gives a simple question on the console, but when you install the 'dialog' package, then there will be a nicer "dialog".
See below for: snapexit_0.1.1-1_i386.deb (remove dummy .tar extension)
Toni, I wanted to add this to the 021-apps-porteus.xzm module but AFAIK it isn't reliable because of changes in the shutdown order (changed symbolic links in e.g. /etc/rc6).
So the best thing I can think of is to include it in the main module.
I made sure it doesn't run when using the live-boot DebianDog version.
Fred
- Attachments
-
- snapexit_0.1.1-1_i386.deb.tar
- (3.12 KiB) Downloaded 227 times
Thank you, Fred!
I'm working on 021-apps-porteus.xzm now. There are some troubles I can not fugure out yet. Ktsus creates issues for user account for obshutdown for example. It does not give password window to reboot and shutdown Old gsu works.
Obshutdown Exit button also does not work for user from icewm and jwm.
There other small issues like loadmodule included in apt2sfs and loadmodule in 021-apps-porteus.xzm - they are different I think. I will overlay the last on top of the first one.
I will create new deb-porteus-dog-test.iso in the next days and very possible I will need your help for some issues.
Toni
I'm working on 021-apps-porteus.xzm now. There are some troubles I can not fugure out yet. Ktsus creates issues for user account for obshutdown for example. It does not give password window to reboot and shutdown Old gsu works.
Obshutdown Exit button also does not work for user from icewm and jwm.
There other small issues like loadmodule included in apt2sfs and loadmodule in 021-apps-porteus.xzm - they are different I think. I will overlay the last on top of the first one.
I will create new deb-porteus-dog-test.iso in the next days and very possible I will need your help for some issues.
Toni
Hi Toni
Is the "gsu" line there in e.g. /usr/bin/wmpoweroff ?
A workaround I can think of is to NOT use obshutdown for JWM and have like this in ~/.jwmrc (instead of the Logout line I added for porteus-boot):
And for icewm use obshutdown and in ~/.obshutdownrc instead of 'pkill X', then 'pkill icewm' (don't know, maybe is to much forcing)
(isn't there something like 'icewm -exit' ?, just couldn't find)
Hope this helps.
btw, now that my new loadmodule supports full path, maybe right-click option for (de)activate?
EDIT:
Q; What are you using as boot options for changes= ?
I suspect there there's a difference in how things behave according to what's used.
Fred
Strange, just tried, I don't have this problem.Ktsus creates issues for user account for obshutdown for example. It does not give password window to reboot and shutdown
Is the "gsu" line there in e.g. /usr/bin/wmpoweroff ?
Yes, got that also, appearently 'pkill X' or 'killall X' is not permitted for user.Obshutdown Exit button also does not work for user from icewm and jwm.
A workaround I can think of is to NOT use obshutdown for JWM and have like this in ~/.jwmrc (instead of the Logout line I added for porteus-boot):
Code: Select all
<Program label="Reboot" confirm="false" icon="restart.png">wmreboot</Program>
<Program label="Shutdown" confirm="false" icon="shutdown.png">wmpoweroff</Program>
(isn't there something like 'icewm -exit' ?, just couldn't find)
Hope this helps.
Yes, the one in /usr/bin is old.There other small issues like loadmodule included in apt2sfs and loadmodule in 021-apps-porteus.xzm - they are different I think. I will overlay the last on top of the first one.
btw, now that my new loadmodule supports full path, maybe right-click option for (de)activate?
EDIT:
Q; What are you using as boot options for changes= ?
I suspect there there's a difference in how things behave according to what's used.
Fred
Hi, Fred
snapexit_0.1.1-1_i386.deb + dialog.deb added in the main module. I tested changes=EXIT:/ and it works for user and root.
It creates folder /changes and I guess it adds more there after every reboot if we choose save?
I like DebianDog-PorteusDog shutting down logo
Editing /home/puppy/.obshutdown.rc this way fixes all. No other changes needed:
We can add more WM names later if we need.
We have your latest apt2sfs + loadmodule in /opt/apps/apt2sfs symlinked in /opt/bin
We have also /opt/bin/load-modules.sh used from SFS-Load
And now we have in 02-apps-porteus.xzm /usr/bin/loadmodules
Do you think we can use only the last one working for apt-2sfs and SFS-Loader?
Added also makepfile to replace /opt/bin/mk-save.gtkdialog in 02-apps-porteus.xzm
Tomorrow more testing and remastering
Toni
snapexit_0.1.1-1_i386.deb + dialog.deb added in the main module. I tested changes=EXIT:/ and it works for user and root.
It creates folder /changes and I guess it adds more there after every reboot if we choose save?
I like DebianDog-PorteusDog shutting down logo
Yes, the gsu line is there. I will check this again tomorrow. I use newer module than 01-v7.squashfs. It might be something I did.Strange, just tried, I don't have this problem.
Is the "gsu" line there in e.g. /usr/bin/wmpoweroff ?
Editing /home/puppy/.obshutdown.rc this way fixes all. No other changes needed:
Code: Select all
killall icewm jwm
I think DebianDog does not have /usr/bin/loadmoduleYes, the one in /usr/bin is old.There other small issues like loadmodule included in apt2sfs and loadmodule in 021-apps-porteus.xzm - they are different I think. I will overlay the last on top of the first one.
We have your latest apt2sfs + loadmodule in /opt/apps/apt2sfs symlinked in /opt/bin
We have also /opt/bin/load-modules.sh used from SFS-Load
And now we have in 02-apps-porteus.xzm /usr/bin/loadmodules
Do you think we can use only the last one working for apt-2sfs and SFS-Loader?
I will try. Not sure how to do it for XFE yet but for Rox it should be easy.btw, now that my new loadmodule supports full path, maybe right-click option for (de)activate?
I use it without option changes= mostly. Also tested changes.dat for user working.Q; What are you using as boot options for changes= ?
I suspect there there's a difference in how things behave according to what's used.
Added also makepfile to replace /opt/bin/mk-save.gtkdialog in 02-apps-porteus.xzm
Tomorrow more testing and remastering
Toni
Hi Toni
It's exactly like the graphical question to save or not, you get at shutdown from X.
EDIT: Maybe better use "changes=EXIT:/debian" to have it in same folder as where the 'base' folder is.
They all work but the one included with apt2sfs is best IMHO, support full path to module, give message when error.
EDIT2: Sorry, wrong, the loadmodule script included with apt2sfs works ONLY for live-boot DebianDog.
So I'll make one for DebianDog-porteus later.
Good night Toni!
Fred
Eh, if you made any changes, yes.It creates folder /changes and I guess it adds more there after every reboot if we choose save?
It's exactly like the graphical question to save or not, you get at shutdown from X.
EDIT: Maybe better use "changes=EXIT:/debian" to have it in same folder as where the 'base' folder is.
It's the original porteus logo (that shows on console) I stole and combined with simple debian logo.I like DebianDog-PorteusDog shutting down logo Smile
Good find, simplicity above all!killall icewm jwm
"02-apps-porteus.xzm /usr/bin/loadmodule" I did mean that's old one.And now we have in 02-apps-porteus.xzm /usr/bin/loadmodules
Do you think we can use only the last one working for apt-2sfs and SFS-Loader?
They all work but the one included with apt2sfs is best IMHO, support full path to module, give message when error.
EDIT2: Sorry, wrong, the loadmodule script included with apt2sfs works ONLY for live-boot DebianDog.
So I'll make one for DebianDog-porteus later.
Good night Toni!
Fred
Wow... Too many posts to follow, I just noticed Toni`s about the menu.
# Script: debmenu-convert that converts debmenu files to a JWM menu file ( jwm.main ).
And a new caregories file to go with it: categories_debmenu.lst
# I can`t see why it errors about a missing double quote, but it makes a good menu file.
# Fred and all; All of my menu files go in $HOME/.jwm , except the script and exec. files.
This will change when I make it generate menus for IceWM as well.
EXPERIMENTAL... So the script writes no file, just xterm output.
To write a file use redirect: debmenu-convert > $HOME/.jwm/jwm.main
# It writes JWM menu entries for all apps listed the in debmenu files. 5 for XFE suite.
### I noticed that many debmenu files have no icon. So lots of editing is needed.
So lots of the menu items show the default icon.
### I also noticed the debmenu files have crappy categories. So more editing is needed.
Like Xhippo and Xrecorder both have Sound category, but this is for system sound settings.
So I`m slowly adding new and custom categories to: categories_debmenu.lst
# It shows the menu using the existing jwm.tail and .jwmrc, so it made a good file: jwm.main
# Script: debmenu-convert that converts debmenu files to a JWM menu file ( jwm.main ).
And a new caregories file to go with it: categories_debmenu.lst
# I can`t see why it errors about a missing double quote, but it makes a good menu file.
# Fred and all; All of my menu files go in $HOME/.jwm , except the script and exec. files.
This will change when I make it generate menus for IceWM as well.
EXPERIMENTAL... So the script writes no file, just xterm output.
To write a file use redirect: debmenu-convert > $HOME/.jwm/jwm.main
# It writes JWM menu entries for all apps listed the in debmenu files. 5 for XFE suite.
### I noticed that many debmenu files have no icon. So lots of editing is needed.
So lots of the menu items show the default icon.
### I also noticed the debmenu files have crappy categories. So more editing is needed.
Like Xhippo and Xrecorder both have Sound category, but this is for system sound settings.
So I`m slowly adding new and custom categories to: categories_debmenu.lst
# It shows the menu using the existing jwm.tail and .jwmrc, so it made a good file: jwm.main
- Attachments
-
- NEW_2-Items.zip
- ### /path/file
/opt/bin/debmenu-convert
$HOME/.jwm/categories_debmenu.lst - (2.06 KiB) Downloaded 174 times
Hi, Terry.
One more time what I and William wrote:
We need your mk-jwm.menu to create menu from /usr/share/applications desktop files. This is the future menu method and most likely next debian stable will also create menus form desktop files. We need to fix and improve this menu method.
Creating Jwm and IceWm menu from /usr/share/menu files is working fine with the current official debian menu way. It has update-menus and install-menus scripts that check for new installed packages on several places inside .pid files. The process is stable and approved in the years. The categories are not the same as mk-jwm.menu makes but all debian packages in wheezy repository are created for this debian categories. Translating the categories in /usr/share/menu files will bring much more troubles in the future if we use mk-jwm.menu to create menu from /usr/share/menu files.
This is pure debian menu way and we need to keep it untouched in DebianDog. It is 100% working and tested in the years.
If we use mk-jwm.menu as default and it creates menu from /usr/share/menu files we gain nothing than different menu structure with very possible later issues with menu entry in wrong category.
If we use mk-jwm.menu to make menu from /usr/share/applications desktop files and try to improve this method, we will have separate working replacement for debian menu process. All linux goes this way - creating menu from desktop files. This is the future and this is the way DebianDog also should go.
If you insist to use /usr/share/menu files for mk-jwm.menu files for some reason then OK, but you will work on a menu method that will be history in a few years. And I think it will involve much more manual editing than the desktop files will need. Why we try to include Open Source Software Standards in DebianDog if mk-jwm.menu will not follow those standards?
Toni
I know the posts are too many. I and William wrote a few times you are taking the wrong way if you try to use /usr/share/menu files for mk-jwm.menu.# Script: debmenu-convert that converts debmenu files to a JWM menu file ( jwm.main ).
One more time what I and William wrote:
We need your mk-jwm.menu to create menu from /usr/share/applications desktop files. This is the future menu method and most likely next debian stable will also create menus form desktop files. We need to fix and improve this menu method.
Creating Jwm and IceWm menu from /usr/share/menu files is working fine with the current official debian menu way. It has update-menus and install-menus scripts that check for new installed packages on several places inside .pid files. The process is stable and approved in the years. The categories are not the same as mk-jwm.menu makes but all debian packages in wheezy repository are created for this debian categories. Translating the categories in /usr/share/menu files will bring much more troubles in the future if we use mk-jwm.menu to create menu from /usr/share/menu files.
This is pure debian menu way and we need to keep it untouched in DebianDog. It is 100% working and tested in the years.
If we use mk-jwm.menu as default and it creates menu from /usr/share/menu files we gain nothing than different menu structure with very possible later issues with menu entry in wrong category.
If we use mk-jwm.menu to make menu from /usr/share/applications desktop files and try to improve this method, we will have separate working replacement for debian menu process. All linux goes this way - creating menu from desktop files. This is the future and this is the way DebianDog also should go.
If you insist to use /usr/share/menu files for mk-jwm.menu files for some reason then OK, but you will work on a menu method that will be history in a few years. And I think it will involve much more manual editing than the desktop files will need. Why we try to include Open Source Software Standards in DebianDog if mk-jwm.menu will not follow those standards?
Toni