Note to extension buildersForum: Extension Development Topic: Note to extension builders started by: roberts Posted by roberts on Dec. 30 2006,21:07
Some errors are showing up in extensions.Please note the following... 1. Do not include base directories. 2. Do not include empty directories, unless application specific and absolutely required. 3. Do not use capitalize the lnk file name. 4. Do not use Status Anchor within the lnk file. Posted by humpty on April 24 2007,00:44
In some uci's, I have seen links put it in e.g usr/local/bin/ and they stay there when unmounted.is this allowed? Posted by roberts on April 24 2007,02:20
No. Should be self-contained. It's directory is removed upon unmounting should be it.. Posted by ^thehatsrule^ on April 24 2007,04:28
I believe the designated place for those links was decided to be in /opt/bin ?
Posted by roberts on April 24 2007,22:51
Yes, /opt/binAnd /opt/bin/ should not be in your backup. Posted by Juanito on April 26 2007,11:04
If I've understood this correctly, extension builders should aim (if possible) to put everything in /opt/myextension.In the case of a dsl extension, does it still make sense to put the desktop icon and link in user.tar.gz in /opt/myextension as per a unc extension? Posted by mikshaw on April 26 2007,16:21
If you're still talking about uci, yes. The user.tar.gz file is useable in all mydsl extensions. It is essentially a *.tar.gz type of mydsl package within the main package, and contains any files needed to be installed in /home/dsl or /opt/something_other_than_myextension (an icon, for example). As with other *.tar.gz mydsl packages, user.tar.gz should not write to parts of the system that are not initially in /ramdisk
Posted by chaostic on May 04 2007,02:58
What if its a single file binary? Should I still put in in /opt and a symlink in /opt/bin or can I just put the binary in /opt/bin?
Posted by mikshaw on May 04 2007,05:13
That would not be possible with uci packages, since they are mounted into /opt/package_name. A tar.gz package can do that, but I couldn't say whether or not it's an "impolite" way to install (perhaps not keeping a consistent package structure could be seen by some people as impolite?). I think it's something worth getting more feedback about. The only drawback I can see, though, is the user having a slightly tougher time removing the application if it's not found in the standard /opt/mypackage directory.As far as I can tell, a single-file application should be able to be placed *anywhere* within the filesystem and still work, as long as the user has permission to enter that directory. Posted by MakodFilu on May 04 2007,13:28
I'll try to fix nasm then. Only two binarys, but not placed under /nasm/ and symlinked as those should.
Posted by chaostic on May 04 2007,21:02
I'll do the same and submit my dtach.uci and dtach.tar.gz.One last question, whats the policy on using "stripe" to bring down the package size? I was thinking of packing both the full binary and the stripped down binary, atleast while the package is in testing. Normally, its 69kb, striped is 12kb. I'm testing it and I don't see much of a difference, same quirks in either binary. And as a quick note, how do I make an iso for uci of more then one directory? I want to make my dtach.tar.gz a uci, but with the symlink in /opt/bin and the binaries in /opt/dtach, the given command in the wiki seems to not work. Posted by jpeters on June 04 2007,18:35
I noticed that unc apps (e.g., gnumeric) have their apps both in /usr/bin and /opt/program/usr/bin. I noticed that the icon and menu entries are placed in /opt/program/usr.tar.gz). Is there another script necessary to remove the desktop icons on termination, or is this file sufficient? Thanks Posted by mikshaw on June 04 2007,19:09
chaostic: I think most, if not all, ELF binaries in DSL are stripped. I usually strip the executables and libraries in mydsl packages I build. Occasionally I've found that the binary was corrupted by stripping...whether because it wasn't ELF or for some other reason I couldn't say. I tend to make a copy of the application, strip the copy, and test it before deciding whether to stick with the stripped version. If it works stripped I see no reason to include both in the package.jpeters: The files in /usr/bin are not really in /usr/bin. The unc package type uses unionfs to bind (there's probably a better word) the mounted file system to /usr/bin. To be honest I don't understand how it works, but it seems to "trick" the operating system into thinking that /opt/program/usr is part of /usr. As far as I know, the desktop icons installed from unc packages are removed during a proper shutdown of the system. The user.tar.gz file found in unc and uci packages is loaded into DSL in the same way that any other *.tar.gz mydsl package is installed, using mydsl-install. Posted by jpeters on June 04 2007,20:43
Icons and links are installed to .xtdesktop, which gets saved; I'm assuming there's a standard procedure for deleting them when the app shuts down? Posted by roberts on June 05 2007,01:48
The removal of icons for extensions is based on the lack of the Status: anchor field in its .lnk file. Only base DSL applications should have such field. If you find an extension with such a field it needs to be corrected.Extension menu items should all be in ~/.fluxbox/mydsl.menu This file is in the .xfiletool.lst and therefore is not in the backup. Posted by jpeters on June 05 2007,04:26
Ah, that solves the mystery. Thanks!
Posted by jpeters on June 09 2007,06:20
I'm trying to create a UCI, but seem to be missing something, and keep getting ioct1: LOOP_SET_FD errors when I mydsl-load it. I've tried following Roberts procedure in the WIKI :1. The app is installed and runs properly from the /opt/your_app directory. 2. become root 3. cd /opt 4. mkisofs -R -hide-rr your_app | create_compressed_fs - 65536 > /mnt/somedrive/your_app.uci What am I missing?? note: I tried something simple, one file (e.g. /opt/calc) EDIT: OK....just got it working..... Posted by roberts on Oct. 17 2007,04:29
Note 32x32 xpm style icons are being supported with DSLv4.x. Place your xpm icon in the /tmp/mydsl.icons/ directory. Naming convention is consistent with that current used for menu items.
Posted by roberts on Nov. 15 2007,04:41
This note is for extensions builders and only dealing with additional window managers.This Tech Note is only for DSL v4.1 and later. I am supporting window manager mydsl menus all under /opt. This way it supports legacy mode. This provides a common single simple name of the scripts that code in the core DSL will look for and process. /opt/.mydsl_menu/jwm/ directory contains: make - the code to make the mydsl menu include restart - the code needed to restart/refresh to make the menu updates visible menu_template - the "empty" or starting menu usually has a placeholder used as the target of insertion for the make script. I did not use any extension (.lua, .sh, .pl) on the script names so that you can write your scripts in any supported language. To remain backward compatible the default menu structure remains the fluxbox menu specification. /opt/.mydsl_menu/fluxbox directory contains the same three named files but with content specific to fluxbox. This way a .tar.gz (legacy able) extension can write to /opt/.mydsl_menu and the dynamic mydsl menu creation, update, and cleanup will all work. For the main system menu ((static)) I am now using a bash include to there is a fluxbox.inc and a jwm.inc. This include file is the code snippet that would have been needed inside the .xinitrc case statement which is no longer needed. What would be in an .inc file is pagers, mouse pointers, and wallpapers (backgrounds). With 4.0 it was confusing as there are three system competing for background control. And, if one partakes in adding new window manager, the completion would only increase. With the new window manager structure in 4.1, I am using a netural corner for background independence. That being the {wm}.inc file. I have taken away the background control from dfm and .xinitrc. I am using, as in 3.x versions, xsri which is quite capable of many image formats (jpg, gif, tif, etc). This would allow for far more background choices without having to convert to xpm as dfm required. The xsri command is specified in the window manager include file. By doing so, wallpaper.lua program can set the background via the .inc file. Any additional window managers using the new structure of the .inc would then also be supported. We would have a common known location to manually change backgrouds if so desired. Each window manager could easily have its own background. Example: .jwm.inc xsri --scale-width=100 --scale-height=100 /opt/.backgrounds/lance-blue.xpm .fluxbox.inc fluxter -w &>/dev/null & xsri --scale-width=100 --scale-height=100 /opt/.backgrounds/envane.tif The .inc file is optional. The window manager used is still controlled by the .desktop file. Be sure that your new window manager is in the user's PATH. Use link to /opt/bin is needed. Posted by mikshaw on Nov. 15 2007,12:42
It sounds like you've put a lot of work into this.I don't really understand the system, though. You have three scripts that could be any language, but the intent is to use them to create a bash script? I must have totally misunderstood you. Could you please explain more about the purpose of the scripts? I don't see what a menu has to do with starting a window manager. It seems to me that all that's needed is the *.inc file ...unless you are incorporating this into the switch app? Posted by roberts on Nov. 15 2007,14:09
MyDSL is dynamic. MyDSL extensions use the Fluxbox menu specifiation. The menu entry of a MyDSL extensions are snipetts of menu code. They get loaded into /tmp/mydsl.menu during boot time or upon demand. Other window managers would not know about MyDSL menu items, neither their location or the format. Other window managers use their own menu specifications, e.g., jwm uses xml. To this end I have created a naming convention and structure to enable processing of MyDSL extensions without change the many core DSL MyDSL processes including dsl-config, mydsl-load, mountci, desktop.lua, desktop.sh, etc.make Therefore a program needs to be created to convert from flux format to xml or whatever the new window manager uses as its menu specification. The make program is called during the boot process as well as the upon demand. It is also called when switching to a new window manager. The fact that actual output of make is in a known location by window manager makes it possible. Also the removal of the menu item upon an umount of a uci or upon shutdown/reboot. All core DSL MyDSL processing uses the new more flexible structure. restart The code needed by the window manager to redraw its menu. Examples are of course included for both jwm and fluxbox. Having a separate code file makes it extremely flexible. menu_template Some window managers require special headers to demark an include. Example is jwm. Also is used as a target place holder for the make program for the desire insertion point. So by using the above naming convention and location for your custom scripts, to process your window manager's handling of MyDSL extensions, no changes need to be done to any core DSL program. Not even .xinitrc Posted by mikshaw on Nov. 15 2007,17:03
Oh...duh. The mydsl menu for an arbitrary window manager. I get it now, mostly, thanks.I assume that a window manager with no applications menu would simply not need these scripts? I think I might need to look at an example (and the scripts in 4.1) to get the full picture. I'm guessing the location of the main menu for a submitted window manager extension would need to be specified in make, or maybe menu_template. Posted by roberts on Nov. 15 2007,20:34
Only part of the new structure is in 4.1RC1, the rest and final structure will be 4.1RC2. I just finished it today.FYI the biggest and most difficult work was to implement user=name option. It affects more files than the new mydsl processing structure. 4.1 really has a different base structure than all prior versions of DSL. It is the last of the major restructuring that I wanted to accomplish. Posted by WDef on Nov. 15 2007,22:45
Robert:(Shamelessly skipping to the end of the thread here and shamefully out of date with recent dsl developments - will catch up soon though) At the risk of having not read something important above, am I correct in thinking that, icon size aside, we extension builders can just go building our extensions with /tmp/mydsl.menu files exactly as we always have? Posted by roberts on Nov. 15 2007,23:00
Yes, you can go on building extensions as usual. I did this to be backward compatible to the existing repository. And to continue to fully support DSL 3.4.x as well as 4.x The only thing that is new (additional) is that I ask is to also make or convert the icon image in home/dsl/.xtdesk and store it as a 32x32 icon in /tm/mydsl.icons/ext_name.xpm Example: /tmp/mydsl.icons/abiword.xpm /tmp/mydsl.icons/imagemagick.xpm /tmp/mydsl.icons/samba.xpm /tmp/mydsl.icons/xchat.xpm You can use imagemagick's convert program or xv, to convert gif,jpg,png,tif icons to xpm. Or better yet design a new icon using mikshaw's iconView.lua program. Posted by WDef on Nov. 16 2007,13:22
That sounds painless.xnview.uci can also convert to xpm ("save as") Posted by kuky on Dec. 02 2007,12:55
Can be useful to make a single how to for beguiners to make a uci..to share in a dsl format.we can easily do a uci file with the 4 steps of the wiki (create a uci extension) but have serious problems to create the user.tar.gz.file.(in my case..) In the official damn small linux book there is a 4 steps to create a uci but its depend on the understanding of the others dsl formats ... can help to make a user.tar.gz... 1) I have the app installed into /opt in the app directory. and works ok . example /opt/firefox.es 2) I have made a menu and icon to access. and works ok 3) how i can do a list of user files ? 4) how i can add dsl files to list 5) how i can do the user.tar.gz 6) how i can make a executable file to copy icons and menus (its necesary?) 7) how to make the uci ? with the line command of the wiki or the official damn small linux book.. thanks.. edited its the same procedure to ver 3.x and 4.x ? Posted by Juanito on Dec. 02 2007,13:16
After putting the full path and names of the files you need for user.tar.gz in a file named "files", this works for me:
Posted by kuky on Dec. 02 2007,16:19
thanks juanitoin official damn small linux book in successive the bible to make the file list is made with pag 204 in root cd / find opt/myapp -not -type d > /tmp/app.list but done a expresion error and path and after is added lines to app.list of .lnk and menu and at end its made as you said the user.tar.gz in opt/myapp. help to make the correct line find /opt bla bla Posted by WDef on Dec. 03 2007,03:59
Install gnuutils.dsl first, then "find opt/myapp -not -type d >list" should work. The "-not" syntax doesn't work with Busybox find. Posted by stupid_idiot on Dec. 04 2007,06:23
Wow, thanks for the tip:
Posted by ^thehatsrule^ on Dec. 04 2007,07:32
Typically I do something like (written out nicely)
Posted by humpty on Dec. 04 2007,16:02
wow, and i've been merging two files all this time,one with find -type f and the other with find -type l . nice tip. Posted by kuky on Dec. 06 2007,23:44
i was confused with apps.dsl and apps.uci, its seems that the user.tar.gz in app.uci only needs the path to menu and to desktop files but i have a question : how its made a user.tar.gz polyvalent to ver dsl 3.x and 4.x ?the only point in common its the mydsl.menu the location of icons and desk files are different...how i can add lines to user.tar.gz to copy icons to desk folders... how i can see user.tar.gz of other apps.uci for benchmarking intention... thanks. pd. the thunderbird2009.es.uci its running in dsl ver 4.1 but with snubs icons and boxes Posted by stupid_idiot on Dec. 07 2007,11:37
You can: 1. Load uci: 'mydsl-load foo.uci' 2. 'user.tar.gz' is found at '/opt/foo/user.tar.gz'. Or: 1. 'extract_compressed_fs foo.uci > xxx.iso' 2. 'mount -o loop xxx.iso <dir>' 3. 'user.tar.gz' is found at '<dir>/user.tar.gz'. Posted by kuky on Dec. 07 2007,19:12
thanks stidbut my problem is to read the user.tar.gz, i have done a user.tar.gz for a firefox uci in spanish in ver 2010 and i have a 240 bytes the same in ff uci ver 2.0 in uci apps have 8.800 bytes...that means that i do no have made the correct user.tar... Posted by stupid_idiot on Dec. 08 2007,08:11
240 bytes is a normal size for a 'user.tar.gz' file.I think you should extract and compare the contents of both 'user.tar.gz' files. The 8,800-byte file probably has more things inside. You could use 'ls -aR' to list the contents recursively. Posted by kuky on Dec. 09 2007,11:34
Stid(use 'ls -aR' to list the contents recursively.) how ? steep by steep thanks Posted by roberts on Feb. 04 2008,20:16
Note to extension builders:I am in the process of creating an Sqlite databse for all the extensions. This will allow quite extensive search capabilities. In doing this project I have noticed and thusly has to cleanup many extension .info files. Please adhere to the standard template. Do not drop field names. Please do not add additional field names. Instead embed in the comments section. Many extensions were missing or had unlabeled comments section. Many were noeol files. Please make sure your .info files are plain ASCII text with end-of-line. Having a good searchable SQL database of all extension will help in moving forward. This will be especially true if the new version of DSL is indeed a tiny core. Thanks, Robert Posted by ^thehatsrule^ on Feb. 04 2008,23:42
Posted by roberts on Feb. 05 2008,16:19
n/a would be best as it indicates a response and not ignored.
|