icurafu
The Hallucinogenic Elf
If xml is done right, you will be able to drag it along. That's why it is extensible.
Pxml File Format Defintion
- Thread starter EvilDragon
- Start date
burito
Still Fresh
The XML guru's among us know, the tool for editing XMl is Altova's XMLSpy. I know I can't afford the US$750 for a copy of it.
Having wrangled xml for some years professionally, I must side with the Django developers, Making humans edit XML is sadistic..
The last thing I want to do while hammering out some code on the train, is to be checking for well formed xml or that spot where I was drunk and forgot the semicolon on one of the 20 something or &'s laying around the file. Or that this particular menu doesn't support self-closing elements, but this one freaks out with empty elements. Or the more likely scenario, this XML parser requires linebreaks and/or whitespace, or vice-versa.
There are 2 reasons for using XML, large hierarchical data and using Document Object Model/XPath to manipulate that data.
This community wants to put icons, names and categories to binaries. This is not a document that needs separation of content and layout, this is a couple of tiny bits of information that we want to staple onto the end of a directory that contains some files.
Another major concern is the europeans/asians. A lot of good homebrew comes out of non-english countries, and english for them is an afterthought. Whatever format you pick it should have i8n support from day one, or it will splinter the scene on silly language barriers.
Oh hey .desktop meets all those requirements, and is already done by a group of individuals with two decades experience dealing with exactly these issues.
edit: my & wasn't escaped by the forum software, manually escaped.
Having wrangled xml for some years professionally, I must side with the Django developers, Making humans edit XML is sadistic..
The last thing I want to do while hammering out some code on the train, is to be checking for well formed xml or that spot where I was drunk and forgot the semicolon on one of the 20 something or &'s laying around the file. Or that this particular menu doesn't support self-closing elements, but this one freaks out with empty elements. Or the more likely scenario, this XML parser requires linebreaks and/or whitespace, or vice-versa.
There are 2 reasons for using XML, large hierarchical data and using Document Object Model/XPath to manipulate that data.
This community wants to put icons, names and categories to binaries. This is not a document that needs separation of content and layout, this is a couple of tiny bits of information that we want to staple onto the end of a directory that contains some files.
Another major concern is the europeans/asians. A lot of good homebrew comes out of non-english countries, and english for them is an afterthought. Whatever format you pick it should have i8n support from day one, or it will splinter the scene on silly language barriers.
Oh hey .desktop meets all those requirements, and is already done by a group of individuals with two decades experience dealing with exactly these issues.
edit: my & wasn't escaped by the forum software, manually escaped.
Correct me if I'm wrong, but I believe the point of PXML is to have software in movable directories. Unfortunately, .desktop only support absolute paths (or executables in a directory in the PATH variable).
The .desktop format is designed around the classic UNIX way of doing things where software is in a fixed place. For the Pandora, it'd be much better if users could just drag-and-drop a directory onto their SD cards and move it around later, without having to worry about adding the directory to their PATH.
It seems to me if you want software in movable directories, there's no way to make this compatible with the .desktop standard as it currently exists.
The .desktop format is designed around the classic UNIX way of doing things where software is in a fixed place. For the Pandora, it'd be much better if users could just drag-and-drop a directory onto their SD cards and move it around later, without having to worry about adding the directory to their PATH.
It seems to me if you want software in movable directories, there's no way to make this compatible with the .desktop standard as it currently exists.
burito
Still Fresh
"The Exec key must contain a command line."
[Desktop Entry]
Type=Application
Name=Foo
Exec=`find /home -name "foo.py"`
Sounds evil yes, but the kernel will cache large portions of the allocation table, and this is actually very quick.
but back in the real world...
Regardless of the meta data format... when media is inserted, a something will scan the media for "packages", and store the list somewhere on the system. It's very easy to write a shell script that modifies the relative paths to include the location that they were found in, as part of the copying them to said location (location being ram, filesystem, whatever).
This will have to be done regardless of the format used.
Hmm now that I think about it, a relatively simple find + awk + sed command will do the whole lot in one go. I'm meeting the local unix group tonight, I'll post back with the command.
[Desktop Entry]
Type=Application
Name=Foo
Exec=`find /home -name "foo.py"`
Sounds evil yes, but the kernel will cache large portions of the allocation table, and this is actually very quick.
but back in the real world...
Regardless of the meta data format... when media is inserted, a something will scan the media for "packages", and store the list somewhere on the system. It's very easy to write a shell script that modifies the relative paths to include the location that they were found in, as part of the copying them to said location (location being ram, filesystem, whatever).
This will have to be done regardless of the format used.
Hmm now that I think about it, a relatively simple find + awk + sed command will do the whole lot in one go. I'm meeting the local unix group tonight, I'll post back with the command.
Squidge
Certified Guru
It seems that some of us are trying to hackup a pre-existing standard for desktop systems with fixed directory structures into another system where the directory structure can change from one second to the next (inserting a different sd card).
Package managers such as rpm and apt don't handle installation and database files being on removable media very well, and from what I've read about .desktop files, neither do they.
Instead of hacking up something to make it "kind of work, but hey, it's a pre-existing standard.", we are trying to do something from the ground up that is *designed* to work for a portable device with removable media, where applications (and entire directory structures) can go missing and reappear from one second to the next.
Of course, if someone wants to use the Pandora the same as a desktop PC, then they can of course do that, and the menu (or other utilities) will allow them to do that and create any .desktop files necessary, assuming they know the consequences of doing so. However, I don't think this should be the default.
Package managers such as rpm and apt don't handle installation and database files being on removable media very well, and from what I've read about .desktop files, neither do they.
Instead of hacking up something to make it "kind of work, but hey, it's a pre-existing standard.", we are trying to do something from the ground up that is *designed* to work for a portable device with removable media, where applications (and entire directory structures) can go missing and reappear from one second to the next.
Of course, if someone wants to use the Pandora the same as a desktop PC, then they can of course do that, and the menu (or other utilities) will allow them to do that and create any .desktop files necessary, assuming they know the consequences of doing so. However, I don't think this should be the default.
Pleng
Well-Known Member
- Joined
- Dec 28, 2006
- Messages
- 3,030
peca said:
I agree. And when you select an icon to edit, it should bring up a list the categories (all of them) and allow you to unselect the defaults and re-assign which will alter the contents of the PXML file. For instance, say somebody ports SNES9X and decides that it belongs in both the 'Emulator' and 'Game' Categories, I want to be able to select the icon, edit its properties, and deselect the 'Game' category.
Last edited by a moderator:
yosh64
Member
hey
I'm confused? I see some bias here.
From what I understand, it sounds awefully misleading to say you would need to hack up the .desktop standard?wouldn't it just take a new entry, such as "directory" that conforms to the .desktop standards? (and request it be part of the standard) (already part of standard to specify the fullpath within Exec key, see below).
Also, if people are going to be putting stuff in any old directory (and maybe they shouldn't), then how does PXML solve this? and what would be the use of specifying an absolute directory, when it can be put anywhere? Hmm, I guess people would have to manually edit the specified absolute directory if they wanted to place it where they wanted.
Anyhows I got a possible solution
.
Why not make it standard/requirement to name the application directory the same as the name of the executable (where all the contents of the software is placed), and then place all software into a specific directory? then an absolute directory will not be needed.
Hmm, and also have the option of specifying other software directories, it would allow people to place/organise things how they like without having to modify the aboslute directory of every software package they try.
edit: You could just add these "software directories" into the $PATH environement variable, and specify the relative path of the Exec key in the .desktop file. For example, you could add your games "software directory" of "/mnt/sdhc1/games" or whatever to the $PATH environment variable, and then for your game .desktop have "Exec=bob/bob" or whatever, I think this should work fine.
edit: In a way I think it would be better to not have anything specific to make things more flexible and so it's easier to port things. But yea, what I've mentioned above is something anyone could do themself wtihout anything needing to be done or standardised for the Pandora, if I make any sense.
Also, if you care to read the .desktop standards ^_^ (sorry, just wanted to catch your attention), it's actually okay to specify the fullpath within the Exec key.
QUOTE
The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH used by the desktop environment.
BTW, sorry if you already knew this, and read the .desktop standards.
edit
One thing I particularly like about the PXML idea is the possibility to have packages as ZIP or maybe TAR.GZ???, so how is this going to be achieved? (also, I think this should be optional, to make it easier for developers to test their progs).
Hmm, maybe I should look into these .debs someone already mentioned.
cyas
I'm confused? I see some bias here.
From what I understand, it sounds awefully misleading to say you would need to hack up the .desktop standard?
Also, if people are going to be putting stuff in any old directory (and maybe they shouldn't), then how does PXML solve this? and what would be the use of specifying an absolute directory, when it can be put anywhere? Hmm, I guess people would have to manually edit the specified absolute directory if they wanted to place it where they wanted.
Anyhows I got a possible solution
.Why not make it standard/requirement to name the application directory the same as the name of the executable (where all the contents of the software is placed), and then place all software into a specific directory? then an absolute directory will not be needed.
Hmm, and also have the option of specifying other software directories, it would allow people to place/organise things how they like without having to modify the aboslute directory of every software package they try
.edit: You could just add these "software directories" into the $PATH environement variable, and specify the relative path of the Exec key in the .desktop file. For example, you could add your games "software directory" of "/mnt/sdhc1/games" or whatever to the $PATH environment variable, and then for your game .desktop have "Exec=bob/bob" or whatever, I think this should work fine
.edit: In a way I think it would be better to not have anything specific to make things more flexible and so it's easier to port things. But yea, what I've mentioned above is something anyone could do themself wtihout anything needing to be done or standardised for the Pandora, if I make any sense.
Also, if you care to read the .desktop standards ^_^ (sorry, just wanted to catch your attention), it's actually okay to specify the fullpath within the Exec key.
QUOTE
The Exec key must contain a command line. A command line consists of an executable program optionally followed by one or more arguments. The executable program can either be specified with its full path or with the name of the executable only. If no full path is provided the executable is looked up in the $PATH used by the desktop environment.
BTW, sorry if you already knew this, and read the .desktop standards
.edit
One thing I particularly like about the PXML idea is the possibility to have packages as ZIP or maybe TAR.GZ???, so how is this going to be achieved? (also, I think this should be optional, to make it easier for developers to test their progs).
Hmm, maybe I should look into these .debs someone already mentioned.
cyas
Last edited by a moderator:
Squidge
Certified Guru
yosh64 said:
Last edited by a moderator:
yosh64
Member
hey
Sorry, I can't see the specs cause the link is broken. (edit:, Just found them in my browser cache)
I'm confused...
So are all the PXML files stored in some standard directory? or are these included with the software packages? and if they are included with the software packages then are they stored within the ZIP archive also? Hmm, I would think not, but I dunno.
Hmm, so I guess the program that builds the menus has to search for all packages on the sdcard to build a menu.
I dunno, but once I find out I think it might be possible todo the same with .desktop, I will try and think of something anyhows.
Anyhows I don't see what Dutch_Cap is on about, it seems the PXML files must be gathered by the GUI program, so why not gather .desktop files instead? when they are gathered the path to them would be stored, so there is no issue, and you can still specify a relative path from the Exec key of the .desktop file if you really wanted, but really it's not neccessary.
I hope I make some sense here.
edit
Decided to move this edit to a new post, cause I took so long and another post was made.
cyas
Sorry, I can't see the specs cause the link is broken. (edit:, Just found them in my browser cache
)So are all the PXML files stored in some standard directory? or are these included with the software packages? and if they are included with the software packages then are they stored within the ZIP archive also? Hmm, I would think not, but I dunno.
Hmm, so I guess the program that builds the menus has to search for all packages on the sdcard to build a menu.
I dunno, but once I find out I think it might be possible todo the same with .desktop, I will try and think of something anyhows.
Anyhows I don't see what Dutch_Cap is on about, it seems the PXML files must be gathered by the GUI program, so why not gather .desktop files instead? when they are gathered the path to them would be stored, so there is no issue, and you can still specify a relative path from the Exec key of the .desktop file if you really wanted, but really it's not neccessary.
I hope I make some sense here
.edit
Decided to move this edit to a new post, cause I took so long and another post was made.
cyas
sebt3
homebrew player (P. & C.)
Wow, when I spoke about .desktop file in the first place, I didn't envision that such a war will came from both camp. But at least this is not going to be a point-less flamewar. Sorry to have started such a war.
Back to the topic.
First, udev/hald use the filesystem name to provide a single (default) mount point for a given device regardless where it have been connected. TO be clear, an example : I have an USB key which is FAT32 formated which is labelled l-key. So when I plug it in my desktop the UI (gnome, kde etc) open a popup that mean do you want to mount it. if I say yes, my key is always mounted in /media/l-key. even if I use the front or rear usb port.
So technically, even if the sd-card is not always there, the path *will* (or should) be absolute. But sure the developper wont know that path. Anyway, if you (we ???) are going to use compressed archive as an app, you'll still have to uncompress it somewhere temporarly : the kernel wont launch .pzip file on it's own (or you'll have to patch it = ugly hack).
I know that klik try to find a way to bundle apps in a single file that is movable. I remember reading about a v2 of it but I'm not able to find it right now.
Maybe there is some idea there that could help us finding a solution to our problem.
For me pxml or .desktop file is a no brainer. I'll create bash/awk script to convert from one to the other if the pxml is used.
I hope to help the process.
And by the way, I'm not planning to use gmenu as my pandora won't be only for game but also to replace my damn old T|T3 (looking for PIM and note taking stuff) so for me it will be GPE or QT extended or OPIE. don't know yet. If i'm still not satisfied with these, then I'll go for a more heavy desktop : enlightement/kde4. But then no games or dual boot mandatory
Back to the topic.
First, udev/hald use the filesystem name to provide a single (default) mount point for a given device regardless where it have been connected. TO be clear, an example : I have an USB key which is FAT32 formated which is labelled l-key. So when I plug it in my desktop the UI (gnome, kde etc) open a popup that mean do you want to mount it. if I say yes, my key is always mounted in /media/l-key. even if I use the front or rear usb port.
So technically, even if the sd-card is not always there, the path *will* (or should) be absolute. But sure the developper wont know that path. Anyway, if you (we ???) are going to use compressed archive as an app, you'll still have to uncompress it somewhere temporarly : the kernel wont launch .pzip file on it's own (or you'll have to patch it = ugly hack).
I know that klik try to find a way to bundle apps in a single file that is movable. I remember reading about a v2 of it but I'm not able to find it right now.
Maybe there is some idea there that could help us finding a solution to our problem.
For me pxml or .desktop file is a no brainer. I'll create bash/awk script to convert from one to the other if the pxml is used.
I hope to help the process.
And by the way, I'm not planning to use gmenu as my pandora won't be only for game but also to replace my damn old T|T3 (looking for PIM and note taking stuff) so for me it will be GPE or QT extended or OPIE. don't know yet. If i'm still not satisfied with these, then I'll go for a more heavy desktop : enlightement/kde4. But then no games or dual boot mandatory
yosh64
Member
hey
One interesting thing of the PXML format is the clockspeed tag, if .desktop files alone were used maybe a new standard could be introduced, such as having optional .clockspeed files, but nevermind.
Here are my recommendations
Maybe the .desktop file alone isn't the solution. Maybe we should do alike what is done on Archlinux, that is have a .PKGINFO (hidden file, has no prefix) that is included with a package (those being tar.gz archives on Archlinux), this information is used by pacman (the Archlinux package manager) to manage the packages. Obviously when it comes to the Pandora, as it uses SDCard(s), it seems to me that you yourself are the package manager, and that this package information is not used by the package manager, but rather any given GUI application. Now this is the tricky part, it's unlike any other package information format, as it's not only used by a single package manager, but any number of GUI applications. So I suggest not only should there be this package information format, but also a program or library to interface with it that can be used by any given GUI application for the Pandora.
Obviously this package information is very specific to the Pandora (the clockspeed entry for example), it's not trying to be some general standard, it is much like a package information format for any given Linux distribution. Any GUI programs that use this package information is specific to the Pandora.
The key point I wanted to make about this suggested .PKGINFO (again, hidden file and has no prefix) that is to be included with a package archive, is that it should be provided along side a .desktop file, as these already exist for many applications, and support different languages and seem to do the job well. So the .PKGINFO (really, you could use anything, it doesn't matter) might just contain parameters such as version, clockspeed, and preview, and you wouldn't even need to specify the .desktop file from here.
I do not think XML should be used, but I think this is up to whoever bothers to develop the thing, in the end I don't think it makes that much of a difference. Personally I would prefer text alike seen in the .PKGINFO of Archlinux, and most (if not every?) other config file on linux, well those found in the /etc directory anyhows, hehe.
So again, to restate my main points...
1. Still have a package information format, and use .desktop for what it does.
2. Make an interface to this package information, as it can be used by any number of GUI programs specific to the Pandora.
edit
Actually, after further thought I think the use of PXML alone is fine.
It is obvious to me that the use of .desktop alone is not enough, and although there are already lots of .desktop files out there for many apps I think it might lead to further hassles in the sense that it's another thing folks will need to know.
EvilDragon, I hope you haven't been discouraged and go through with it, I think you have made an excellent design.
But yea, my only recommendation would be that you implement an interface to make it easy for other applications to interface with the information, although this might be the reason why you choose XML, as there are already libraries to easily interface with such information.
cyas
One interesting thing of the PXML format is the clockspeed tag, if .desktop files alone were used maybe a new standard could be introduced, such as having optional .clockspeed files, but nevermind.
Here are my recommendations
Maybe the .desktop file alone isn't the solution. Maybe we should do alike what is done on Archlinux, that is have a .PKGINFO (hidden file, has no prefix) that is included with a package (those being tar.gz archives on Archlinux), this information is used by pacman (the Archlinux package manager) to manage the packages. Obviously when it comes to the Pandora, as it uses SDCard(s), it seems to me that you yourself are the package manager, and that this package information is not used by the package manager, but rather any given GUI application. Now this is the tricky part, it's unlike any other package information format, as it's not only used by a single package manager, but any number of GUI applications. So I suggest not only should there be this package information format, but also a program or library to interface with it that can be used by any given GUI application for the Pandora.
Obviously this package information is very specific to the Pandora (the clockspeed entry for example), it's not trying to be some general standard, it is much like a package information format for any given Linux distribution. Any GUI programs that use this package information is specific to the Pandora.
The key point I wanted to make about this suggested .PKGINFO (again, hidden file and has no prefix) that is to be included with a package archive, is that it should be provided along side a .desktop file, as these already exist for many applications, and support different languages and seem to do the job well. So the .PKGINFO (really, you could use anything, it doesn't matter) might just contain parameters such as version, clockspeed, and preview, and you wouldn't even need to specify the .desktop file from here
.I do not think XML should be used, but I think this is up to whoever bothers to develop the thing, in the end I don't think it makes that much of a difference. Personally I would prefer text alike seen in the .PKGINFO of Archlinux, and most (if not every?) other config file on linux
, well those found in the /etc directory anyhows, hehe.So again, to restate my main points...
1. Still have a package information format, and use .desktop for what it does.
2. Make an interface to this package information, as it can be used by any number of GUI programs specific to the Pandora.
edit
Actually, after further thought I think the use of PXML alone is fine
.It is obvious to me that the use of .desktop alone is not enough, and although there are already lots of .desktop files out there for many apps I think it might lead to further hassles in the sense that it's another thing folks will need to know.
EvilDragon, I hope you haven't been discouraged and go through with it, I think you have made an excellent design.
But yea, my only recommendation would be that you implement an interface to make it easy for other applications to interface with the information, although this might be the reason why you choose XML, as there are already libraries to easily interface with such information.
cyas
Trip
Sorry, but I suck at explaining stuff :P
I'm all for standards, but what most people seem to be saying in this thread is that they want to modify an existing standard (.desktop) and change it to do something that it wasn't ever designed to do. What's the point in that?? by changing the standard it's no longer the same thing anyway and will probably either loose it's original compatibility, or it will add a load of useless crap to the original standard making it worse for systems other than the Pandora.
The Pandora shouldn't be expected to be 100% compatible with desktop Linux distributions. It's an open source gaming handheld for crying out loud and not a desktop computer. Although a lot of things will be best kept compatible with existing distributions, there is enough differences in use to warrant creating new standards when needed.
We can either take an old standard and mutilate it until it does what we want and risk problems with speed or compatibility later on, or we can start from scratch and end up with something that does exactly what we want from the word go.
+1 for PXML - I'll follow the dragon on this one
The Pandora shouldn't be expected to be 100% compatible with desktop Linux distributions. It's an open source gaming handheld for crying out loud and not a desktop computer. Although a lot of things will be best kept compatible with existing distributions, there is enough differences in use to warrant creating new standards when needed.
We can either take an old standard and mutilate it until it does what we want and risk problems with speed or compatibility later on, or we can start from scratch and end up with something that does exactly what we want from the word go.
+1 for PXML - I'll follow the dragon on this one
CyruzDraxs
Member
- Joined
- May 9, 2008
- Messages
- 241
- Age
- 37
Expanding on the .desktop standard would not break compatibility with anything--just like XML; unused parts will be ignored. Personally though, I prefer the PXML idea though because it's just more flexible and would promote people supporting the FULL spec of it, rather than some apps not being categorized in the same way as others or other awkward things like that.
CyruzDraxs: If we modified .desktop for our purposes, the new format would be virtually useless for programs that use the old format.
Ok, let's see if I can explain this in a more accessible way: There's two kinds of paths: relative paths and absolute paths. Paths point to stuff, files and directories to be more precise. Absolute paths are the whole path, starting at the root directory. For example the absolute path to the Gimp executable (file you run to start the program) on my Linux system is:
CODE
/usr/bin/gimp
The relative path is the path relative to the current directory. For example if you're currently in the directory /usr, the relative path to that gimp executable would be:
CODE
bin/gimp
The primary goal of both PXML and .desktop is to point to stuff. They point to the file that should be run to start a program, the executable. They do a few other things, but that's their primary goal.
.desktop files point to executables with an absolute path. There's a good reason for this. It needs to be possible to move .desktop files around, so that I can put them in /home/Dutch_Cap/Desktop and get a nice icon on my desktop. .desktop files can use an absolute path because on most Linux systems programs don't move around much.
The design goals for PXML are slightly different, though. The directory that contains both the PXML file and the executable needs to be movable and it might disappear when you remove your SD card. However, the PXML file should not move relative to the executable. That's why PXML uses relative paths.
This way, I can just drag and drop a directory that contains the application to my SD-card. When I insert the SD into my Pandora, the application is automagically detected with a little help from the PXML file. The system finds the PXML file and then it knows where the executable is because it knows where the PXML file is. If I remove the SD-card and put it in the other SD-slot, or if I move the program (including the PXML file) to another directory, the sytem still detects where the program is, and I can access it through my menu of choice.
Long story short, PXML needs relative paths, but .desktop uses absolute paths. Both for good reasons. Luckily It would be easy to generate .desktop files from PXML files.
Ok, let's see if I can explain this in a more accessible way: There's two kinds of paths: relative paths and absolute paths. Paths point to stuff, files and directories to be more precise. Absolute paths are the whole path, starting at the root directory. For example the absolute path to the Gimp executable (file you run to start the program) on my Linux system is:
CODE
/usr/bin/gimp
The relative path is the path relative to the current directory. For example if you're currently in the directory /usr, the relative path to that gimp executable would be:
CODE
bin/gimp
The primary goal of both PXML and .desktop is to point to stuff. They point to the file that should be run to start a program, the executable. They do a few other things, but that's their primary goal.
.desktop files point to executables with an absolute path. There's a good reason for this. It needs to be possible to move .desktop files around, so that I can put them in /home/Dutch_Cap/Desktop and get a nice icon on my desktop. .desktop files can use an absolute path because on most Linux systems programs don't move around much.
The design goals for PXML are slightly different, though. The directory that contains both the PXML file and the executable needs to be movable and it might disappear when you remove your SD card. However, the PXML file should not move relative to the executable. That's why PXML uses relative paths.
This way, I can just drag and drop a directory that contains the application to my SD-card. When I insert the SD into my Pandora, the application is automagically detected with a little help from the PXML file. The system finds the PXML file and then it knows where the executable is because it knows where the PXML file is. If I remove the SD-card and put it in the other SD-slot, or if I move the program (including the PXML file) to another directory, the sytem still detects where the program is, and I can access it through my menu of choice.
Long story short, PXML needs relative paths, but .desktop uses absolute paths. Both for good reasons. Luckily It would be easy to generate .desktop files from PXML files.
CyruzDraxs
Member
- Joined
- May 9, 2008
- Messages
- 241
- Age
- 37
Hmm...hadn't thought of that. >.>
Another reason why I feel XML is a more valid choice for this particular use. Another idea I would suggest is an AppData folder of sorts that can be present in the same folder as the executable to store cover art/screenshots and any other relevant binary data to pair with the PXML file.
One thing that could make the Pandora a little more idiot proof is to have it scan folder contents for the PXML file. When one is found, it's containing folder could appear as a direct link to the executable contained inside it (sort of like the applciations folder on a mac).
Another reason why I feel XML is a more valid choice for this particular use. Another idea I would suggest is an AppData folder of sorts that can be present in the same folder as the executable to store cover art/screenshots and any other relevant binary data to pair with the PXML file.
One thing that could make the Pandora a little more idiot proof is to have it scan folder contents for the PXML file. When one is found, it's containing folder could appear as a direct link to the executable contained inside it (sort of like the applciations folder on a mac).
Dutch_Cap, as have been said, .desktop files can also specify just the relative command name, in which case the executable and the icon is searched for on the path and in the standard icon folders, respectively.
I believe that you would only need to use a 'non-standard' search path in your implementation, and that this would allow you to use an unmodified .desktop file in your package, though you'd probably want to add some of the pandora-specific options. You'd probably have to have the executable and the icon in the same folder as the .desktop file.
As I mentioned a bit earlier in the thread, if applications were to follow the XDG base directory specification, and the launcher set some environment variables per app when launching from an application directory, I also think that you could use the same executable for a traditional package installation, and a self-contained application directory. That could mean, you could take any XDG-conforming app from say, a Debian package, reorder the files a bit, and voila, a movable plug-and-play application directory. And opposite, if you had a list of what files go where, you could very easily build a traditional package in some format directly from the application directory.
I don't expect application developers to care enough about this to make it work reliably, though.
Anyway, both formats could hold the necessary info and fulfill the same role. Splitting it into a .desktop file and another file with more package-related stuff like author info, version and preview might make sense. What goes where isn't entirely clear cut, though. Stuff like clocking would go in the .desktop, and in general I'd say everything required for a simple launcher should go in the .desktop file.
Then the other file could hold stuff you might want to show in a detail view when selecting the file in a launcher or package repository.
Edit: Wot, no [em] tags?
I believe that you would only need to use a 'non-standard' search path in your implementation, and that this would allow you to use an unmodified .desktop file in your package, though you'd probably want to add some of the pandora-specific options. You'd probably have to have the executable and the icon in the same folder as the .desktop file.
As I mentioned a bit earlier in the thread, if applications were to follow the XDG base directory specification, and the launcher set some environment variables per app when launching from an application directory, I also think that you could use the same executable for a traditional package installation, and a self-contained application directory. That could mean, you could take any XDG-conforming app from say, a Debian package, reorder the files a bit, and voila, a movable plug-and-play application directory. And opposite, if you had a list of what files go where, you could very easily build a traditional package in some format directly from the application directory.
I don't expect application developers to care enough about this to make it work reliably, though.
Anyway, both formats could hold the necessary info and fulfill the same role. Splitting it into a .desktop file and another file with more package-related stuff like author info, version and preview might make sense. What goes where isn't entirely clear cut, though. Stuff like clocking would go in the .desktop, and in general I'd say everything required for a simple launcher should go in the .desktop file.
Then the other file could hold stuff you might want to show in a detail view when selecting the file in a launcher or package repository.
Edit: Wot, no [em] tags?
Similar threads
