Posted: Sun Mar 02, 2008 4:13 pm
hey redlar,
where can I download the new version?
where can I download the new version?
TPFC Forums
https://www.portablefreeware.com/forums/
https://www.portablefreeware.com/forums/viewtopic.php?t=2904
Yes, it makes more sense to me now. Still one functional nitpick, I would like to be able to keep a base storage dll for building/upgrading most launchers, but also to be able to override that dll for some specific builds. In the current GUI this isn't possible, I think. Perhaps it could be addressed in the dynamic build flow, by showing a confirmation dialog by prompting "use \path\to\storage\dll?" with possible answers yes=build, no=browse for replacement then build.redllar wrote:I might have confused things re: the dll, so I split the two JPE dll locations into two separate entries: one for where the dll is always stored (where it will be copied from when setting up/building the launcher) and one for where the dll needs to be when the to-be-built launcher is run. The storage location is intended to be a set-once entry while the runtime entry is something you would change as necessary per-launcher. Please take a look at the new screencaps below to see if this makes more sense now.
Hello thibeaz,thibeaz wrote:To borrow a quote from John T Haller "its done when its done" and welcome to the forums (as it seems to me that i forgot to do so when you first joined)
thanks for your work again..redllar wrote:
I like your previous idea on the way preventing the non-portable app from being accidentally executed, that is renaming the application.exe into application.jpe. Maybe you could bring it as an option in the "Launcher Settings"redllar wrote: Please post if you have any more thoughts on functional requirements
Override with an older version? That won't work. The launcher and jpe dll must be of the same version. So an 030 launcher won't work with an 016 jpe dll, for instance. After the dll is injected and starts up it'll complain and then kill the launched app.sgp wrote:I would like to be able to keep a base storage dll for building/upgrading most launchers, but also to be able to override that dll for some specific builds.
I would think your confusion would disappear by placing a big OR overlaying the split between the sections for the 2 different uses, which is what I did in the help text.crownixx wrote:Then after viewing several time i could guess that in the tab, we could do two different things..build new launcher OR modify old launcher,i'm right?
I personally always strive for a modeless design whenever possible. At first glance your idea sounds reasonable, but it raises several questions related to the splitting of the work and data between the two build tabs and forcing the user into a mode of operation (build or rebuild), which is rarely a good thing in a dialog that is essentially free flowing. Actually, if I were to go the 2 mode route, I think one Build tab with a toggle to switch between build and rebuild modes would be preferrable, since the only real difference between the two modes is in how the data is identified - either from the selection of a launcher or from the selection of an app + a launcher folder. Everything else could be treated the same after that.crownixx wrote:Maybe separate those tasks into two tabs could make the GUI more friendly and avoid confusion. The gui could have the "Build" tab and "Modify" tab. In the "Modify" tab, you could have more space for the "Launcher Info" and instead of "Build Portable" use "Rebuild Launcher" button make more sense for the modifying task
Thanks for noting that. I'd forgotten about that capability. Mainly because it's now possible to put the launcher in a different folder than the app, and to give the launcher the same name as the app, but I suppose some will want to keep everything in one folder.crownixx wrote:I like your previous idea on the way preventing the non-portable app from being accidentally executed, that is renaming the application.exe into application.jpe. Maybe you could bring it as an option in the "Launcher Settings"
well it proof some users learn through gui first before reading the help text/readme. .i am did miss the big "OR" in the help tab.Sorry bout that.redllar wrote: I would think your confusion would disappear by placing a big OR overlaying the split between the sections for the 2 different uses, which is what I did in the help text.
yes, that's also great idea. Using radio button for switching, then hide/disable the unnecessary input..redllar wrote: ..I think one Build tab with a toggle to switch between build and rebuild modes would be preferrable, since the only real difference between the two modes is in how the data is identified - either from the selection of a launcher or from the selection of an app + a launcher folder
Nothing to be sorry about. I've added an OR to the gui as well. It should have been in there in the first place.well it proof some users learn through gui first before reading the help text/readme. i am did miss the big "OR" in the help tab.Sorry bout that.
I mocked one up and will probably offer it as an option. I like its looks better but I can see where some will be confused by it so it won't be the default.yes, that's also great idea. Using radio button for switching, then hide/disable the unnecessary input..
It was there for the built launchers iirc. It wasn't there with the JauntePE command line exe, but it is now. So now it's there for everything. And you can override it if you want with a built launcher ini setting, and the launcher ini can be stored in the launcher.i remember sgp request an ability launcher accepting command-line argument. Will it be there in the new version?
Or mybe extend the function a little: the command-line argument is stored inside the launcher so that users doesnt need 3rd party program(example pstart) just to lunch the launcher with parameter.Hope it is not too much >.<