a cmg in a .desktop file(alpha release)!

[bfree]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.