JauntePE 0.3.0 "Build Portable" GUI feedback req

Discuss anything related to JauntePE, the utlimate utility to help you tame non-portable applications. Share your experience about the apps that work with JauntePE, and the apps that don't.
Message
Author
Master of Dice
Posts: 61
Joined: Tue Nov 28, 2006 5:44 am

#16 Post by Master of Dice »

hey redlar,

where can I download the new version?

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Well

#17 Post by Zach Thibeau »

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)

sgp
Posts: 67
Joined: Sat May 12, 2007 1:05 am

#18 Post by sgp »

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.
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.

Re my request to show dll versions, your idea about a launcher info page is fine with me.

Master of Dice
Posts: 61
Joined: Tue Nov 28, 2006 5:44 am

Re: Well

#19 Post by Master of Dice »

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)
Hello thibeaz,

Yeah. I know what John T Haller always says :)
I thought it's ready for testing and for feedback.

User avatar
Kranor
Posts: 120
Joined: Sun Jan 14, 2007 7:15 am
Location: uk

#20 Post by Kranor »

Hi redllar,
Looks like a class app now, can't wait to have a play with it. :lol: :lol: :lol:

crownixx
Posts: 403
Joined: Sat May 12, 2007 6:26 am

#21 Post by crownixx »

redllar wrote: Image
thanks for your work again..
As the first glance i see the new gui, i'm a bit confuse about the required task in the "Build tab". 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?

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
redllar wrote: Please post if you have any more thoughts on functional requirements
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
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#22 Post by redllar »

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.
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.

If you're talking about using an 030 log dll vs an 030 default dll, you'll be able to choose amongst the various builds found in the storage folder. And this will happen automatically if it's a new build and you choose one of the supplied configs.
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 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: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
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.

Regardless, using a mode-based approach would just move the point of confusion from the beginning to after a build takes place. What tab do I use after a build that I goofed up? Does the rebuild tab's data get automatically overwritten after a build? Even if I explicitly set the rebuild data first then went to use the build tab instead? What happens on a failed build - wipe out the rebuild data or leave it alone? So at the very least these questions and others would have to be subjectively answered so that they could at least be documented.

Forcing the user to choose between a build or rebuild would be a good way to start for a wizard though, which I plan to have available for the true novice user.
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"
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
Posts: 403
Joined: Sat May 12, 2007 6:26 am

#23 Post by crownixx »

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.
well it proof some users learn through gui first before reading the help text/readme. :lol: .i am did miss the big "OR" in the help tab.Sorry bout that.
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
yes, that's also great idea. Using radio button for switching, then hide/disable the unnecessary input..

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 >.<

redllar
Posts: 411
Joined: Thu Aug 03, 2006 7:52 pm
Contact:

#24 Post by redllar »

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.
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.
yes, that's also great idea. Using radio button for switching, then hide/disable the unnecessary input..
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.
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 >.<
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.

User avatar
Zach Thibeau
Posts: 251
Joined: Tue Nov 28, 2006 3:26 pm
Contact:

Great

#25 Post by Zach Thibeau »

Great sounds good to me

jordan
Posts: 3
Joined: Wed Mar 19, 2008 12:23 am

#26 Post by jordan »

Remember at the end of the day redllar did not ask for a debate he asked for suggestions to improve an amazing program that saves me and a lot of other people a lot of time.

Post Reply