PDA

View Full Version : a cmg in a .desktop file(alpha release)!



urielka
05-21-2005, 04:09 AM
i made few script that are able to take a cmg(a directory with a cmg and zAppRun script) and make it to a .desktop(just like every icon on kde).

so the made .desktop file is all the cmg+.desktop info and it can work by dobule click the icon(the icon is the program and it`s a .desktop file).

so for the end-user he can drag the icon(like every .desktop file it has a icon which can be set at creation of the .desktop(when you run my script it let you choose a icon) to his hard drive from the internet and then run it just like cmg but it has a icon and it doesn`t need zAppRun(coz it`s included in the .desktop file,but the fstab is needed to be with klik paths).

the problem is that i don`t have any web space to host the scripts? does some one have space for it?(i will place a .desktop example of vlc and the scripts).

probono
05-21-2005, 06:50 PM
Sure, you can do that. But this approach violates klik's idea of "1 application = 1 file" (which is useful, e.g., for e-mailing.

You can post your scripts here in this thread if you want.

Greetings,
probono

urielka
05-23-2005, 02:47 AM
you didn`t understood my.
it`s just one file,just one that have all the icon+the cmg and the .desktop info.
the script are a bit long so i preffer to get some webspace to post them and i want to put an example app or maybe a short video that show how is it.
do you know where can i get a free webspace to put files(any files)?

bfree
05-23-2005, 05:19 AM
you didn`t understood my.
it`s just one file,just one that have all the icon+the cmg and the .desktop info.
Another possible problem, does this make your new file depend even more on kde/gnome/some .desktop compatible software? At the moment you can use command line programs like qemu (for example) with klik, would your method handle this?

Are the scripts really to long to post in here (I've posted some long scripts in forums before myself)?

probono
05-24-2005, 08:43 PM
it`s just one file,just one that have all the icon+the cmg and the .desktop info.

All in one single file? Cool!

I'm really curious, perhaps you can upload a zip file with the scripts on
a free hosting site like http://www.savefile.com/filehost/ (no signup required)

Greetings
probono

urielka
05-25-2005, 01:51 PM
i will upload it soon.

spandit
05-25-2005, 09:05 PM
iam looking forward to this release

probono
05-27-2005, 06:37 PM
me too ;-)

bfree
05-27-2005, 07:12 PM
You didn't like the idea too much when I suggested just putting the AppRun into the cmg (to make it self contained, you need klik to create/get them but nothing to use them) ... add a .desktop and all of a sudden your happy :lol:

I have my guesses as to what's going on here, the .desktop file knows to use an offset for both the AppRun and image to mount? My question is, could it also embed menu information in the cmg, so the first time it is run it adds a menu entry (could be one program, could be a whole menu system depending what's in the cmg), and if you attempt to run a non-present menu item it should prompt to delete it, find it or download it again. Basic idea being klik effectively maintains a second copy of the debian menu which just has the klik'd apps in it (the user can of course edit the menus to arrange at will).

A final thought (as I'm rabbitting on about ideas I've had) is that instead of any programs using the real etc and var, should they not create a ~/klik/data/$MD5 , where $MD5 is the MD% of the content, filesize and modification time of the cmg being run, and within this folder the app can have it's own etc and var. End result is that a nw cmg will get a new area (so no cross contamination) and if it also holds a text file of the cmg name/path -> MD5, it would be quite easy for someone to copy their setups across if they wanted (or to create a script to delete unneeded data). Or they can even wipe the whole ~/klik folder and start again! Alternatives would include embedding a second loopback filesystem within the cmg but using it to write to (downsides include sending your data with the app if you copy it and space limitations), storing a second loopback file in parrallel to the app which stores it's data (still space problems and both also would use extra loopback devices), the current method (downside of losing files into your system or not having full control) or some other trick like using unionfs to overlay a directory for each running cmg over the required directories (possible problems and confusion if multiple packages are running which include some of the same packages that require this).

Just floating the ideas more then anything (but as I've done before I'm happy to help coding/testing).

urielka
05-28-2005, 03:45 AM
yes it can!!!
because when the "magic" .desktop untar itself(it`s an uncompressed tar+script) and then run the zAppRun script that the tar contains(plus the cmg of course!).
now i manage to make a .desktop of firefox cmg(the one that probono post few days ago) and more impotant, i manage to find a place to host it so here is it:
http://us.f2.yahoofs.com/bc/4297c203_a67b/bc/My+Documents/xaa?bfFt8lCBRLbeTDlz
http://us.f2.yahoofs.com/bc/4297c203_a67b/bc/My+Documents/xab?bfFt8lCBZJgpeDF5

it`s one zipped file splited into two files using split command.
just wget the two files,join them ,uncommpress them to the Desktop(or any other place on */home),Move Run.sh to /usr/bin and chmod +x him.
and then you need to click the .desktop file and firefox should appear!!!

the script need some work so they can be useful so i will release them later

*Note: the path where the .desktop file can be is set in Run.sh script(for example / include /usr /bin /home ..., /home include /home/user1 /home/user2 ...).
Note2:don`t select properties of the "magic" .desktop file coz it will make the file corrupted(it will resize the file to 4.4MB).
EDIT: there is a problem with the hosting.
so if someone know a good place to host a 9MB file please post here(savefile.com doesn`t work!). :twisted:

probono
05-28-2005, 05:23 PM
Unfortunately, I get the error: Unknown host bcvrf.yahoo.com

Perhaps you can use a smaller application, let's say klik://xvier for demonstration (it's only a few KB in size)

I probably still don't fully understand how you do it, but one thing would be of extreme importance to me: that you can freely move the "1 file" to whatever location you want, and that it does not need to unpack itself before the application can run.

Greetings,
probono

urielka
05-28-2005, 05:58 PM
it can be place any where.
because every time you click the .desktop file it runs the Run.sh script that search for the file(it send to the Run.sh script the name and the rNum(a random number created at creation of .desktop file).
this is the Run.sh script:


#/bin/sh
#get the random number $1=filename $2=random number fPATH is the searching path
fPATH="/home"
files=$(find $fPATH | grep $1)
for filex in $files
do
rNum=$(head -n 2 $filex | tail -n 1 | cut -d" " -f2)
if [ $rNum = $2 ]
then
$filex
fi

done


Question: why this forum doesn`t have attachments?

urielka
05-28-2005, 06:27 PM
i made a .desktop file of xvier here:

http://easy.savefile.com/urielka/xvier.zip

just unzip copy the Run.sh script to /usr/bin and chmod +x him
and then click the xvier.desktop file!

Note:Don`t change the name of the file changing it will make the file unrunable
Note2:Don`t enter Properties of the files it will make it corrupt
Note3: the file must be in the path of /home(including all the subdirectorys) if you want it to be any where set the fPATH in the Run.sh to /(i don`t recommend it coz it will take alot of time).
Note4: the Run.sh is not finished,when i finaly finish it ,it will have multiplie path and index searching for more speed.

More to come!!! :D

probono
05-28-2005, 06:47 PM
Looks like a clever idea, but I would change it a bit:

- The logic for mounting should still be outside of the cmg, e.g., in ~/.zAppRun, because it's not really stable code yet and should be easy to upgrade anytime w/o having to rebuild all cmg files

- Why the GUIDs? That looks "Windowsy" to me. What do you think about the following, it basically calls "itself":


#!/bin/sh
Do_Nothing ()
{
[Desktop Entry]
# for the specs
# see http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
Exec= sh -x %k # tail +9 %k | sh # skips the first 9 lines but removes $0
Icon=info
Name=Self-contained test application
Name[de]=Selbstablaufendes Testprogramm
Type=Application
Terminal=true
}

#
# How to insert icon data into this file?
#

#
# here a shell script can be inserted
#

#
# below this, the cramfs image could be appended
# to be mounted from ~/.zAppRun with loop offset
#

urielka
05-28-2005, 06:55 PM
about the :


sh -x %k # tail +9 %k | sh

did you tested it?
because as far as i know the $0 when running a .desktop is kdesktop(because kdesktop run it).

about using ~/.zAppRun it`s ok but it should contain at least a simple script that will run the ~/.zAppRun like this:


#!/bin/bash
~/.zAppRun * #this script runs on the cmg directory by default!


EDIT: i readed the specs now and i understood how it work and i must say : how the hell did you find this?! i looked at the specs about two hours and i didn`t saw this little (but very important) info.
i will update the scripts and post them very soon.
but for the time i will post a updated xvier using the code that you gave!.(uning sh -x %k and ~/.zApprun instead of using the zApprun inside the .deksktop)
here is it:


http://easy.savefile.com/urielka/xvier1.zip

probono
05-28-2005, 07:04 PM
Exec=sh -x %k
works *perfectly* for me :-)

Do you know a way to calculate the neccessary offset= value for loop?

Btw, would be great to see you on #klik on irc.freenode.net

probono
05-28-2005, 07:13 PM
This works:
(Only .zAppRun has to be changed so that it calculates and uses the correct offset= parameter when loop-mounting)


#!/bin/sh
Do_Nothing ()
{
[Desktop Entry]
# for the specs see
# http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
Exec= sh -x %k
Icon=info
Name=Self-contained test application
Name[de]=Selbstablaufendes Testprogramm
Type=Application
Terminal=true
}

#
# How to insert icon data into this file?
#

~/.zAppRun "$0"
# we need to have .zAppRun calculate and use offset=

#
# below this, the cramfs image is appended
#

urielka
05-28-2005, 07:15 PM
look at this updated file:

http://easy.savefile.com/urielka/xvier1.zip

probono
05-28-2005, 07:36 PM
Now this is a bit of "cheating" because it unpacks the application before it runs it (requires disk space ram, and slows down the start of large apps considerably). So we should really try to use ~/.zAppRun and cramfs/zisofs - what do you think?

Greetings,
probono

urielka
05-28-2005, 07:57 PM
it`s uncommpresd tar so it doesn`t take so long(i think a 0.01 secs) but using the ~/.zAppRun and cramfs should be faster but you can`t have both the icon and the cmg.
with my "cheating" you can tar the cmg+script+icon and then in the script check if the icon exsist on(let say) ~/.kde/share/icons/klik/icon1.png and if it doesn`t exsist it will copy the icon to ~/.kde/share/icons and the run the cmg.(of course the Icon= will be Icon=~/.kde/share/icons/klik/name_of_app.png)

probono
05-29-2005, 09:52 AM
You can do the same but still use cramfs/zisofs - just need to figure out the offset= paramenter of loop-mount

For cramfs, you can get the offset with

grep Compressed filename -ab | cut -d: -f1

For zisofs, you can get the offset with

grep CDROM filename -ab | cut -d: -f1

For both, you can get the offset with

grep -e '\ \ \ CDROM\ \ \ \ \|Compressed\ ROMFS' /home/knoppix/Desktop/xvier.cmg -ab | cut -d: -f1

Greetings,
probono

probono
05-29-2005, 11:05 AM
Ok, here is a new .zAppRun that can handle cmg files embedded into desktop files:


#!/bin/sh

#
# by probono at myrealbox dot com
# GPL
#
# This script mounts and executes CMG files
#

#
# This version does NOT need fstab entries
# but it DOES need sudo rights for mounting and unmounting CMG files
# (these are available in Knoppix/Kanotix Live CDs by default)
#

# rewrite cmdline to use absolute instead of relative paths, thanks bfree
NEWCMD=$(perl -e '$newcmd=shift(@ARGV);foreach $arg (@ARGV){ @part=split(/\=/,$arg); foreach $part (@part){ (-e "$ENV{PWD}/$part") && ($part="$ENV{PWD}/$part");}$newcmd.=" ".join ("=",@part);} print "$newcmd";' $@)
set -- $NEWCMD

# if no arguments are passed and
# there is a .cmg in the same directory as this
# script, then use the .cmg
DIRNAME=$(dirname $0)
if [ -z $1 ]
then
CMG=$(find "$DIRNAME" -iname '*.cmg'|head -n 1) || exit 1
echo "Found $CMG, using it"
else
CMG="$1"
shift
fi

# make path to CMG absolute, thanks bfree
case $CMG in
/*) ;;
*) CMG=$(pwd)/$CMG ;;
esac

#
# Find out the offset where cramgfs/zisofs data begins
# (this allows embedding the cmg into a .desktop file)
#

OFFSET=$(grep -e '\ \ \ CDROM\ \ \ \ \|Compressed\ ROMFS' $CMG -ab | cut -d: -f1)
echo "CMG detected, Offset = $OFFSET"

if [ -n "$OFFSET" ]
then
NUMBERS="7 6 5 4 3 2 1"
for NUMBER in $NUMBERS
do
[ -e "/mnt/app/$NUMBER" ] || MNTNUM=$NUMBER
done

MOUNT=/mnt/app/$MNTNUM

mkdir -p $MOUNT || exit 1

sudo mount $CMG $MOUNT -o offset=$OFFSET -t cramfs,iso9660 || echo "Unable to mount $MOUNT" >&2
else
# NOTE: exit now cause our cmg isn't mounted
echo "$CMG does not appear to be a valid CMG file" >&2
exit 1
fi

#
# execute the wrapper
# the wrapper should take care to keep running until its app closes
#

# we need this so that on the cmdline, pipes etc work
CMDLINE="yes"
( tty | grep ^/dev/tty >/dev/null ) && CMDLINE=""
( tty | grep ^/dev/pts >/dev/null ) && CMDLINE=""
if [ "$CMDLINE" = "yes" ] ; then
RESULT=$($MOUNT/wrapper $@ 2>&1) || echo "$RESULT" >&2
else
$MOUNT/wrapper $@
fi

# kill all child processes
kill $(pidof -x -o %PPID) 2>/dev/null

# unmount and clean up
sudo umount $MOUNT
rm -rf $MOUNT/


Note that this requires sudo rights for mounting and unmounting. Does anyone know how a corresponding entry to the sudoers file has to look?

urielka
05-29-2005, 12:53 PM
yes i got the same problem,we need sudo but using sudo is like using root and we need to make more adjusments as root to make klik work.
i think we need to find a better way not using sudo.

urielka
06-02-2005, 01:30 AM
So when you will put it on the site(i mean instead of cmg or with cmgs and .desktop as option)?

probono
06-02-2005, 07:41 PM
When we have found a way w/o sudo... ;-)

Greetings,
probono

urielka
06-04-2005, 10:11 PM
so you agree with me? ok!
maybe without a cmg and with fast uncomppresing (uncomppresd tar or something)(just getting rid of mount).

urielka
06-04-2005, 10:45 PM
or using FUSE?
it don`t need suid.

probono
06-05-2005, 12:26 AM
Fuse sounds interesting, can you tell me how to do it?

Greetings,
probono

urielka
06-05-2005, 09:41 PM
don`t know i am looking for it but i think it needs a kernel module look at this web page:
http://fuse.sourceforge.net/

bfree
06-08-2005, 12:32 AM
Ok, I have an alternative approach which eliminates the need to sudo ... but it doesn't overcome the problem of viewing the properties of the .desktop corrupting it. I've simplified the approach right down on the way, and basically use a fixed offset (1024 bytes) which is then set in fstab (so first step, fstabs need to be updated). e.g.

/mnt/app/1/image /mnt/app/1 cramfs,iso9660 offset=1024,user,noauto,ro,loop,exec 0 0
Next you need to modify ~/.zAppRun, this is the patch to Kanotix's latest version ...


--- /home/knoppix/.zAppRun.safe 2005-06-07 22:01:48.630717768 +0100
+++ /home/knoppix/.zAppRun 2005-06-07 22:58:12.242330616 +0100
@@ -4,6 +4,8 @@
# thanks to bfree
# GPL

+OFFSET=1024
+
# ok we need dialogs now
if [ -z "$DIALOG" ] ; then
# Determine which dialog to use in which situation:
@@ -111,9 +113,11 @@
esac

# determine which filesystem is used as .cmg
-file $CMG | grep ": data" >/dev/null && FS=squashfs # who knows a better way to recognize it?
-file $CMG | grep "Compressed ROM" >/dev/null && FS=cramfs
-file $CMG | grep "ISO 9660" >/dev/null && FS=iso9660
+# BUG :: FIX :: TODO
+# Add some math so these don't have to be handupdated it offset changes
+head -c 1028 $CMG | tail -c 4| grep "hsqs" >/dev/null && FS=squashfs
+head -c 1056 $CMG | tail -c 16 | grep "Compressed ROMFS" >/dev/null && FS=cramfs
+head -c 33798 $CMG | tail -n 5 | grep "CD001" >/dev/null && FS=iso9660

if [ -n "$FS" ]
then
@@ -154,7 +158,7 @@
fi
SUCMD="$SUCMD echo \"#Added by klik (klik.atekon.de)\" >> /etc/fstab "
for i in 1 2 3 4 5 6 7; do
- SUCMD="$SUCMD ; echo \"/mnt/app/$i/image /mnt/app/$i cramfs,iso9660 user,noauto,ro,loop,exec 0 0\" >> /etc/fstab";
+ SUCMD="$SUCMD ; echo \"/mnt/app/$i/image /mnt/app/$i cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0\" >> /etc/fstab";
done
fi

@@ -192,13 +196,13 @@
As root, please make /mnt/app writeable and add the following lines:

################################################## #####################
-/mnt/app/1/image /mnt/app/1 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/2/image /mnt/app/2 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/3/image /mnt/app/3 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/4/image /mnt/app/4 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/5/image /mnt/app/5 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/6/image /mnt/app/6 cramfs,iso9660 user,noauto,ro,loop,exec 0 0
-/mnt/app/7/image /mnt/app/7 cramfs,iso960 user,noauto,ro,loop,exec 0 0
+/mnt/app/1/image /mnt/app/1 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/2/image /mnt/app/2 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/3/image /mnt/app/3 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/4/image /mnt/app/4 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/5/image /mnt/app/5 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/6/image /mnt/app/6 cramfs,iso9660 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
+/mnt/app/7/image /mnt/app/7 cramfs,iso960 offset=$OFFSET,user,noauto,ro,loop,exec 0 0
################################################## #####################"
exit 1
fi

Right, now all you have to do is get yourself the right sort of cmg/.desktop hybrid. What I did was created a basic .desktop called xvier.desktop (and I put it on the Desktop) to start with which looks like:


[Desktop Entry]
Terminal=false
Icon=package_games
Type=Application
Exec=~/.zAppRun %k

Then I got the xvier.cmg from klik as normal. Now I used the following script (named pad.pl also on Desktop) as:

./pad.pl xvier.desktop xvier.cmg
The script being (I shouldn't let anyone see this as I'm sure it can be rewritten in one line of sed/awk/???, but it's just what I did):


#!/usr/bin/perl
# takes the desktop file as the first argument
$deskname=shift(@ARGV);
# and the cmg as the second
$cmgname=shift(@ARGV);
# opens the desktop file to read it in
open(IN,"$deskname")||die "failed to open $deskname for reading : $!";
# read in the desktop file line by line
while(<IN>){
# count the length of the file
$length+=length($_);
# check if this line is a single newline
if (/^\n$/){
$blank=1;
} else {
$blank=0;
}
}
close(IN);
# start what we will append to the desktop with a newline
# if it didn't end with one
if ($blank=0){
$out.="\n";
$length++;
}
# pad what we will append to the file with '#'
for($i=$length;$i<=1021;$i++){
$out.="#";
}
# finish the padding with 2 newlines
$out.="\n\n";
# open the desktop file for appending
open(OUT,">>$deskname")||die "failed to open $deskname for writing : $!";
print OUT $out;
close(OUT);
# append the cmg to the desktop
system("cat $cmgname >> $deskname");


End result you know have a xvier.desktop on your desktop which you can click on to run. You still need to have the ~/.zAppRun externally, but it can be wrapped back into a dummy shell script and then have the zAppRun as part of the .desktop also. If it was to be done this way the offset would need to be a lot higher (I set it to 1024 on the basis their may be language dependent strings we might want to add in there)! This is just the minimal changes approach for now.

I told you I'd write long posts :-D Congrats to all still with me!

The only problem is ... viewing the properties and clicking ok corrupts the file, choosing cancel doesn't. I don't know if there is a way around this but I'm not too hopeful, perhaps the purveyors of the .desktop spec can be confinced to accomodate us somehow? Maybe there's something there already (going to look now).

In the meantime consider this a barely tested proof of concept.

bfree
06-08-2005, 02:26 AM
Well having read the .desktop spec I can't find anything, so for now all I can come up with is chmod ugo-w xvier.desktop. I haven't tried doing any other sorts of corrupting to the .desktop file (like inserting an extra eof before the cmg, if anyone finds anything that works though ...

urielka
06-08-2005, 08:18 PM
the problem which make the curoption is that kde edit the .desktop file as it was a text file and not as a binary file.
open .desktop file in kate/kwrite(the one including cmg) and then change one arg of the .desktop and save it,it will be corrupt.
so what we can do is to disable writting to the .desktop/cmg(we don`t need it).

bfree
06-09-2005, 05:15 AM
so what we can do is to disable writting to the .desktop/cmg(we don`t need it).
I was going to say we do need it ... but we don't! As long as the user has permission to write to the directory they can delete the file (or move or rename it) at will. So while it's a little ugly that you can't change the permissions/edit the properties of the file, it doesn't obstruct in it's use. Next step is to decide what information to carry in the desktop description, where to source it, do we try and accomadate translations and hence what do we set the offset at (how much of a payload and overhead do we carry). This all assumes of course the probono likes this approach, which is an assumption I'm not making!

probono
06-09-2005, 12:44 PM
bfree, thank you for your working implementation - I would like to know what people think about this approach.

My personal opinion is that we are coming to a point now at which it would really make sense to implement our goal in a "clean" way, and the only real clean way I can think of at the moment would be a cmg kioslave.

We would need to define a cmg format that contains
- the icon picture
- the .dektop information
- the compressed image that becomes mounted or otherwise made accessible

All of this should be possible without fstab, and without sudo. And it should be backward compatible for non-KDE users.

Writing a kioslave clearly is something that I cannot do, so we would need someone who does it for us. Who wants to volunteer?

Greetings,
probono

urielka
06-09-2005, 03:27 PM
a better way of implenting cmg is to add to the .desktop specs a new type named Bundle(or whatever you want) and then when the next realse of KDE/Gnome will be realsed they will support the new spec(this is the long way,using kioslave will be faster but using this way we make cmg to work on every De/WM that support freedesktop`s .desktop files)

bfree
06-10-2005, 03:04 PM
a better way of implenting cmg is to add to the .desktop specs a new type named Bundle(or whatever you want) and then when the next realse of KDE/Gnome will be realsed they will support the new spec(this is the long way,using kioslave will be faster but using this way we make cmg to work on every De/WM that support freedesktop`s .desktop files)


Now probono at least can probably guess what I am going to say ... don't add another kde dependency :-) I don't see any reason why an icon image could not be added as another payload in our heavy cmg file so that zAppRun can extract it (perhaps to .klik/icons/) if it's not present when the cmg is first run? Why overcomplicate things?</p>


Realistically I think we have to wait until some user mounting method becomes available and easy to support before klik goes beyond using a sudo or fstab based method. What's the problem with using fstab (with or without a su/sudo/sux/kdesu backup)? It's tried and trusted, would some kioslave/fuse access be as reliable now? Maybe I'm over conservative? Maybe I don't understand kioslaves well enough?</p>

urielka
06-10-2005, 07:18 PM
i think we should use AppDirs that cannot opened as directory and when you click on them they run the Warraper inside them.
this way you don`t need mounting,compressing the icon is always inside the AppDir(so the path is always $APPDIR/icon.png) and for the end user it`s like a file and not a directory(just like in MacOSX).
but using this way, we need to add AppDirs to KdeLibs/KdeBase code so it could open AppDirs as Programs.
every AppDir will be like this:
/usr /var /tmp .....
icon.png
warraper
AppDir.desktop

when the AppDir.desktop will contain all the "misc" information like : Name,Exec,Descrition and so on.
beside , if we write a kioslave it doesn`t support for having a diffrent icon for every .cmg file it will be the same as with normal .cmg files.
so we have three options:
1.using what we acomplished now(the hacker way ,the fastest way)
2.sending an email to freedesktop asking for adding a Bundle(we need to give them a good discription of the Bundle idea) type to the .desktop specs, and if they will accept it , you can exepcet it to be working on later Kde/Gnome realese(i hope soon and not on KDE4 and Gnome3)(the easy and very long way).
3.adding AppDir support to KDE(and if we want we can add to Gnome via VFS) and posting the patch at kde`s development mail lists.(the hard way , faster way , and the way we need to code Kde/Gnome support)

bfree
06-10-2005, 10:38 PM
so we have three options:
1.using what we acomplished now(the hacker way ,the fastest way)
2.sending an email to freedesktop asking for adding a Bundle(we need to give them a good discription of the Bundle idea) type to the .desktop specs, and if they will accept it , you can exepcet it to be working on later Kde/Gnome realese(i hope soon and not on KDE4 and Gnome3)(the easy and very long way).
3.adding AppDir support to KDE(and if we want we can add to Gnome via VFS) and posting the patch at kde`s development mail lists.(the hard way , faster way , and the way we need to code Kde/Gnome support)
There's a number of issues. First up, you're suggesting going back from cmg to AppDirs losing all the benefits in the process. Second, how do you propose we can magically add support for AppDirs to KDE, or gnome? By installing our own code? As of right now I don't see anyone jumping on the bandwagon to write such code (perhaps you are) let alone maintain it, I see this as as possibly as lengthy a process as trying to get fdo to accomadate us?

I'm not dismissing these ideas at all, I just wonder what benefits this all brings us? What are you trying to achieve? Are you not just going to confuse people by telling them "this is a file but if you go to a command line or use a non-magic kde/gnome app it may be a folder"? Perhaps we could add an AppRun option (maybe right-clickable action) to explode a klikd.desktop back into an appdir as you describe for those who want it that way? I know someone used to always use klik with rox for AppDir support so they could klik an AppDir to run it. I think the compressed single file however is more useful then a corruptable AppDir.

I guess it all depends what you see klik as, I have my own view but know most people see it differently! Maybe i'm just missing something, if you know what it is, or have anything else to say, hit reply or see if I'm lurking in #klik.

probono
06-11-2005, 01:22 PM
Imho AppDirs are great, but AppImages (cmg files) are even better... ;-)

Since both AppDirs and AppImages would have to be implemented in KDE/Gnome first, why not do it with AppImages?

As for AppDirs: you can unpack any cmg and you have an AppDir (that ROX klik://rox-filer recognizes, which has AppDir functionality built in).

Greetings,
probono

urielka
06-11-2005, 05:15 PM
ok , but writting a KIOSLAVE will not make the cmgs to work with icons.
so , what we can do is mail to freedesktop asking to add a Bundle type to .desktop specs.

probono
06-12-2005, 01:08 AM
And it needs to read the actual icon data from that same file.

Greetings,
probono

urielka
06-12-2005, 02:54 AM
i don`t think that a kioslave can do that it only work after you click the icon if not we need to create a klik:/(or something else) that will be like media:/ for applications(the problem is that using this way we must put all the klik`s in on folder)

urielka
06-13-2005, 07:13 AM
so what we going to do?