I only thought of the folder structure briefly.
I think it is something that's not going to be standardized too soon. In fact I don't even see the point for this to happen (diversity is a good thing
Standardized folder structure offers ( at least
) 2 advantages:
- Users' convenience. When user wants to find some files, it's easier to navigate in a known structure.
- Allows for making tools that relay on it. Example: PortableApps.com backup.
I prefer applications sitting each in its place so if i want to get rid of one, i only have to select that one folder and press delete. I don't have the time to think what i have to select and where from.
Me too. None of standards proposed to date interferes with it. 2 allow for breaking it if users wishes too (which has advantages as well).
The truth is that anyone could change the folder structure to their liking in 2 minutes: just create the necessary folders and edit the .ini file - only 3-4 lines/paths have to be modified.
Yes, but remember that you have to do it with every app and every update of the launcher. In the end it's cumbersome.
What for? To save a few kilobytes?
To save 464 KB if the user choose to
With your way one has one more directory to pass to get to the files which slows access to them whenever it has to do something manually.
IMO it's unnecessary complication.
Then you are also suggest that what redllar had set in 12 Step Program and JPE Quickie standard that use JPE\ProgramFiles\Appname is is slow and unnecessary. I really cant comment about this coz i dont know how it really affecting the performance
I meant situation when user has to access the files directly. That's another directory to pass. When it's automated there's practically no difference.
Also, you achieve do the same in a few seconds by editing the .ini and changing JPERuntime setting to point to some common directory like ..\JPE\jauntePE.dll
IMO, new user will be afraid to edit the .ini, plus they need to know how to use relative path. We should ask other person opinion which one is far more easier, merging 2 package or editing the runtime ini?
IMO, new user won't experiment with merging apps. I'm pretty sure about it.
Question: Does JPE allow for environmental variables in paths in the [Launch] section?
I think yes. redllar use the term tokens. See readme.html>Launch Ini
Yes, it seems it does. So it is possible to make my approach work with shared dlls (and settings) too. W/out increasing tree deph.
What i dont understand is how the secondary launcher (if i'm right (appname).exe) get it setting to point to data\jpe_(appname).exe?
There's a handful of ways to do it, the simplest being reading own file name.
I want to correct that my suggestion folder structure for JPE does not need to have its own application folder (...)
I don't get this part.
(...) thus we can have similar setting for file system that is create in JPE Quickie and redllar 12 Step Program. So we have two app-specific condition potentially to occur
1. JPE App-specific that is set using 12-Step Program and JPE Quickie that use installation procedure
2. JPE App-specific that is design for app that doesnt have setup, unable to JPE-Setup for example msi installer so we can use Universal Extractor. The application can be put in App\appname folder
Both condition will use same dll which will be in JPE\jauntePE.dll and both using the same File System setting which will be in JPE folder. The most important is that it is sync with redllar 12 Step Program and JPE Quickie folder structure.
Yes, things should be as similar to what redllar set as possible, to make it easy for the developers.
I'll have to look at JPE defaults more closely, I'm yet to Jauntize my first app! Well, I tried once before, but it seems that Quickie doesn't work on XP x64. Will investigate another day.
Yes i admit the it will complicated when we do the update and that is why i said it is only an option
Directory structure is not an option.
Developer sets it and users live with it (or change it, if they are advanced enough and find it worthwhile).
To end this long post, I want to update my structure proposal: add optional "doc" directory in the root. Containing things like sources and..well..docs.