Feedback needed for new JauntePE 0.5.0 GUI
Re: Feedback needed for new JauntePE 0.5.0 GUI
hm, the prelim ini settings, I'd imagine something like JPE Config Modifier's window to appear with similar options?
This way it doesn't need a set of .ini like it does now with normal1-3, greener 1-3 etc...
This way it doesn't need a set of .ini like it does now with normal1-3, greener 1-3 etc...
Re: Feedback needed for new JauntePE 0.5.0 GUI
Yup, i'm with you too on this one. The set of .ini selection could lead the beginner user at frustrated point which one should be use. Currently IMO, _Normal3.ini should be enough.
So why not we eliminate that step. Just simply load the _Normal3.ini first in into GUI like JPE Config Modifier or a Wizard GUI style. Then the GUI will provide the user to change some of the basic settings. The outcome will be the prelim ini settings.
So why not we eliminate that step. Just simply load the _Normal3.ini first in into GUI like JPE Config Modifier or a Wizard GUI style. Then the GUI will provide the user to change some of the basic settings. The outcome will be the prelim ini settings.
- Andrew Lee
- Posts: 3074
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
Re: Feedback needed for new JauntePE 0.5.0 GUI
I think Normal3.ini is a good start for the prelim settings.Andrew Lee, right now i'm trying to figure out how to fit your idea into my process flow if possible. Just one question. Your're idea is focusing on creating the prelim ini settings. So the application's files are already in placed before or after creating the prelim ini settings?
When creating a new project, I am assuming the app files are already there.
Same if you are creating a new project using two-phase discovery.
When creating a new project using the "from installer" wizard, the wizard will help extract the app files and create some sensible initial settings based on the discovery results from running the installer.
Re: Feedback needed for new JauntePE 0.5.0 GUI
Andrew Lee, thanks for staying interested and discuss about this matter.
![Image](http://www.freeimagehosting.net/uploads/a74d2cac6d.jpg)
There is way to create a Project using either redirect installer or 2 phase analysis for an application that distribute using zip package.
If we use redirect installer method, which mean an exe is asked. The workaround is simply replace the exe which suppose to be installer to an archive manager, eg: 7zM.exe. Your 7zM.exe will be run under redirection. Open the VirtualDub zip file and extract it to C:\Program Files
If we use 2 phase analysis. Simply take first snapshot, extract VirtualDub zip file to C:\Program Files, and take 2nd snapshot.
Just to give redllar clear road on your idea, is the third method is to provide option for novice/advanced user(i suppose) for creating a Project that have its own directory structure? For example, one folder called APP and another folder called DATA?
Currently the method of redirecting installer, 2 phase analysis and the workarounds above are simply just using portable filesystem directory structure
LOL, i already made it for you. Is it close to your idea in mind?Andrew Lee wrote:Hope I have made myself clear, otherwise I may have to start resorting to diagrams.
All your comments from above are taken to create the process flow below. For example, currrently i use the term "Capturing Application's Files", to represent more general method of the process that can be redirect installer method, 2 phase analysis method, and another method for manually create project dir structure(?) and then extract the zip file. "and assuming I know what I am doing" can be say as your knowledge about the application behavior. The knowledge could be obtain from the reading or from experience or from the other discovering tools. This knowledge i can represent it in the process flow as "Analysis Result". There are sub-process flow for "Capturing Application's files" but i want to present them laterAndrew Lee wrote:Why I am proposing this is because it makes simple tasks simple. Say I want to portablize VirtualDub, which comes in a ZIP file. I am not forced to take unnecessary steps. I just create the project, point to the EXE, choose a profile, and assuming I know what I am doing, I can go straight to building the portable package without configuration.
![Image](http://www.freeimagehosting.net/uploads/a74d2cac6d.jpg)
There is way to create a Project using either redirect installer or 2 phase analysis for an application that distribute using zip package.
If we use redirect installer method, which mean an exe is asked. The workaround is simply replace the exe which suppose to be installer to an archive manager, eg: 7zM.exe. Your 7zM.exe will be run under redirection. Open the VirtualDub zip file and extract it to C:\Program Files
If we use 2 phase analysis. Simply take first snapshot, extract VirtualDub zip file to C:\Program Files, and take 2nd snapshot.
Just to give redllar clear road on your idea, is the third method is to provide option for novice/advanced user(i suppose) for creating a Project that have its own directory structure? For example, one folder called APP and another folder called DATA?
Currently the method of redirecting installer, 2 phase analysis and the workarounds above are simply just using portable filesystem directory structure
- Andrew Lee
- Posts: 3074
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
Re: Feedback needed for new JauntePE 0.5.0 GUI
The updated flowchart still doesn't quite capture what I have in mind, and since I am terrible with flowcharts, I have created a mockup to show you what I mean.
http://localhostr.com/files/mWArIBx/jau ... 0101129.7z
I think the main problem I have is with the capture app files -> analysis portion. IMHO, these two should be optional in "Create Project" and should be classified under the "Configure Project" part instead.
If you look at my mockup, one can conceivably click Project -> New, specify the EXE, then click Build -> Create portable package. There is no capture app files, and no analysis. You can do that under Analysis -> Exercise, but that part is optional.
Hope the mockup makes my thoughts clearer to you. Your feedback is most welcome!
http://localhostr.com/files/mWArIBx/jau ... 0101129.7z
I think the main problem I have is with the capture app files -> analysis portion. IMHO, these two should be optional in "Create Project" and should be classified under the "Configure Project" part instead.
If you look at my mockup, one can conceivably click Project -> New, specify the EXE, then click Build -> Create portable package. There is no capture app files, and no analysis. You can do that under Analysis -> Exercise, but that part is optional.
Hope the mockup makes my thoughts clearer to you. Your feedback is most welcome!
Re: Feedback needed for new JauntePE 0.5.0 GUI
Yes, your idea is very clear to me. There are several points that i concern if we using this method. First is the directory structure of the project. I assuming users might manually creating their own directory structure for example APP folder: all application's files will be place here, and DATA folder: portable registry maybe be place here. There is no wrong to design the portable app dir structure like that but this practice might not work for all apps. We would never know if the app write an absolute path in the file or in the registry. As a result, users will face more problems to troubleshot the error. The best practice which increase the chance of getting native application running portable to work is by running the app completely virtualized. i.e, by fooling the app to think it was running in the Program Files folder. This is what is being practice by application virtualization. That is why i try to ask you how the dir structure is created in previous post.Andrew Lee wrote:If you look at my mockup, one can conceivably click Project -> New, specify the EXE, then click Build -> Create portable package. There is no capture app files, and no analysis. You can do that under Analysis -> Exercise, but that part is optional.
If we read JPE Quickie tutorial or thinapp tutorial, exercising the app after installation/ extraction is highly recommended in order to discover any potential of registry creation or other file creation in the system so that they can be included into redirection. I prefer JPE GUI to set Exercise as part of the important process to be done before creating the final portable package. It is also can be considered as the best practice to do. It could be better if the JPE GUI try to recommend the best practice within its GUI, wizard or settings so that there will be higher success rate of portablizing either from beginner or novice user. Do you agree?
Your mockup is nice. Simple and neat. Here's my mockup for the wizard part that use method of redirect installer. It is not a real wizard but actually using the tab gui, because it is far more easy for me to write the script.
http://www.mediafire.com/?eq5ueh63b2hjzob
Any comment?
Re: Feedback needed for new JauntePE 0.5.0 GUI
Just a quick note: Even though i'm familiar with thinapp, i would have no idea what "exercise application" means (now i know - i usually do this during capture already).
I'd recommend a (hideable) permanent infopane at the bottom, that gives a short quick summary about what it is that one currently is doing. I don't just mean for "exercise application" but for anything.
One advantage of this would also be, that you keep the areas of the GUI where settings are made, mostly clutter free: Without such an infopane, any *general* descriptions about the current step, would need to be embedded inside the area where settings are made - which would be distracting, when you know already how stuff works. With such an infopane instead, general descriptions about the current step, could go into the (hideable) infopane, and the settings-area would only need to contain descriptions/warnings about individual settings.
I'd recommend a (hideable) permanent infopane at the bottom, that gives a short quick summary about what it is that one currently is doing. I don't just mean for "exercise application" but for anything.
One advantage of this would also be, that you keep the areas of the GUI where settings are made, mostly clutter free: Without such an infopane, any *general* descriptions about the current step, would need to be embedded inside the area where settings are made - which would be distracting, when you know already how stuff works. With such an infopane instead, general descriptions about the current step, could go into the (hideable) infopane, and the settings-area would only need to contain descriptions/warnings about individual settings.
Re: Feedback needed for new JauntePE 0.5.0 GUI
In my perspective, the "exercise application" in the thinapp is at step 3 and 4 as described in the thinapp manual here.lyx wrote:Just a quick note: Even though i'm familiar with thinapp, i would have no idea what "exercise application" means (now i know - i usually do this during capture already).
thanks for the suggestion. I can assure you all of the suggestions throwing here are being listened by redllar. So, please keep posting your ideas. We are welcoming any other suggestion.lyx wrote:I'd recommend a (hideable) permanent infopane at the bottom, that gives a short quick summary about what it is that one currently is doing. I don't just mean for "exercise application" but for anything.
One advantage of this would also be, that you keep the areas of the GUI where settings are made, mostly clutter free: Without such an infopane, any *general* descriptions about the current step, would need to be embedded inside the area where settings are made - which would be distracting, when you know already how stuff works. With such an infopane instead, general descriptions about the current step, could go into the (hideable) infopane, and the settings-area would only need to contain descriptions/warnings about individual settings.
Andrew, i think redllar is considering your idea about just having the simple method of creating the project. I have made an article about choosing the portable directory structure. It is just to give awareness to user with the potential problem that could occur to them.
Re: Feedback needed for new JauntePE 0.5.0 GUI
Now back to discuss about the prelim settings idea. But we might use several different set of config settings before we reach the prelim settings. So i would like to discuss about the config in sequence using my Wizard Mock GUI as an example.
Assuming we are using the method of redirecting installer, so the next GUI idea maybe like this
![Image](http://www.freeimagehosting.net/uploads/9bc1440c09.jpg)
In the GUI, user can select the installer that is intend to be redirected. Then a run button to start the installer. The idea is like this; if the first installation is done and there might be a second installation to be included in the same Project, user can just simply browse the next installer. This process can be done many times until the user is decided to go for the next wizard GUI.
Now the selection of the default config for the redirection is a bit tough. Normally i built my portable app in my virtual machine. In the virtual machine, i don't have to worry about installer cluttered my system because i can always reset it back my clean state. So I always use _Normal config at this phase. But after considering user might not have the same situation like mine, it could be good selection for the installer to use _Greener(?) config for the redirection. I'm not sure about it and opinion from the developer is needed here.
Putting all the configs selection in the wizard may cluttered the GUI so the idea is to hide them in another pop-up GUI. Advanced users can access the GUI using the "Advanced Config Selection..." button if they want to change the default config for redirection. In JPE Quickie, there is idea where user might have the specific config to be used for the installer redirection. This specific config might be obtained and shared by other jpe user in the forum. An example is the redllar's Firefox Setup 3.0_Hands Off.ini. This idea on specific config sharing is great and should be available in the JPE 0.5.0 GUI. So this feature too can be access in the "Advanced Config Selection..." button(?)
Assuming we are using the method of redirecting installer, so the next GUI idea maybe like this
![Image](http://www.freeimagehosting.net/uploads/9bc1440c09.jpg)
In the GUI, user can select the installer that is intend to be redirected. Then a run button to start the installer. The idea is like this; if the first installation is done and there might be a second installation to be included in the same Project, user can just simply browse the next installer. This process can be done many times until the user is decided to go for the next wizard GUI.
Now the selection of the default config for the redirection is a bit tough. Normally i built my portable app in my virtual machine. In the virtual machine, i don't have to worry about installer cluttered my system because i can always reset it back my clean state. So I always use _Normal config at this phase. But after considering user might not have the same situation like mine, it could be good selection for the installer to use _Greener(?) config for the redirection. I'm not sure about it and opinion from the developer is needed here.
Putting all the configs selection in the wizard may cluttered the GUI so the idea is to hide them in another pop-up GUI. Advanced users can access the GUI using the "Advanced Config Selection..." button if they want to change the default config for redirection. In JPE Quickie, there is idea where user might have the specific config to be used for the installer redirection. This specific config might be obtained and shared by other jpe user in the forum. An example is the redllar's Firefox Setup 3.0_Hands Off.ini. This idea on specific config sharing is great and should be available in the JPE 0.5.0 GUI. So this feature too can be access in the "Advanced Config Selection..." button(?)
Re: Feedback needed for new JauntePE 0.5.0 GUI
The third wizard GUI is after the installer redirection process is done.
Similar to JPE Quickie, there will be a list of exes.
![Image](http://www.freeimagehosting.net/uploads/3074ba7014.jpg)
User will select an app and click on the run button. Similar idea like the 2nd wizard GUI; if the main executable is done exercising and there might be other several exes in the same Project that need to be exercise too, user can just simply select an exe and run. This process can be done many times until the user is decided to go for the next wizard GUI.
We are not reaching to the prelim settings yet but there should be a config selection used for the purpose of exercise here. Again, i'm not so sure what should be the default config at this phase and developer opinion is needed. It could be _Greener config too (?)
Similar to JPE Quickie, there will be a list of exes.
![Image](http://www.freeimagehosting.net/uploads/3074ba7014.jpg)
User will select an app and click on the run button. Similar idea like the 2nd wizard GUI; if the main executable is done exercising and there might be other several exes in the same Project that need to be exercise too, user can just simply select an exe and run. This process can be done many times until the user is decided to go for the next wizard GUI.
We are not reaching to the prelim settings yet but there should be a config selection used for the purpose of exercise here. Again, i'm not so sure what should be the default config at this phase and developer opinion is needed. It could be _Greener config too (?)
Re: Feedback needed for new JauntePE 0.5.0 GUI
I like the AutoIt Mockup! I think for users who have no or little experience will find this easier to use than before.
Re: Feedback needed for new JauntePE 0.5.0 GUI
Thanks. Feel free to comment if you have any better idea for the AutoIt Mockup gui improvementguinness wrote:I like the AutoIt Mockup! I think for users who have no or little experience will find this easier to use than before.
![Image](http://www.freeimagehosting.net/uploads/2a71efa31c.jpg)
Above is the next gui for the wizard. There will be an input box for user to enter the project name. Then there is also a list box showing the exes available in the project similar to the previous 3rd wizard gui. User can select which exe to be selected as path for the portable launcher. The task similar to JPE Quickie
Future idea.
Currently JPE Quickie can only create a launcher for a portable app package. In future, maybe the list box can be expand to have tick box so that user could create more than one launcher in the portable app package like below
![Image](http://www.freeimagehosting.net/uploads/9ad480469b.jpg)
For this idea, there should be another discussion topic on what is the best way to design our config structure so that it could support the multiple launcher.
Edit: I create topic about config structure in SF forum. Should i created one too in TPFC forum?
- Andrew Lee
- Posts: 3074
- Joined: Sat Feb 04, 2006 9:19 am
- Contact:
Re: Feedback needed for new JauntePE 0.5.0 GUI
Well, not really. That is decided by the build step. If you click on "Build, Create portable package" under my mockup, you see a message "Options for different package layouts may be included here". The user decides which layout to use, with a sensible default. The "Project, New..." lets you point to the EXE of an already installed app, or an app that doesn't have an installer, so the APP/DATA folder shouldn't be there.First is the directory structure of the project. I assuming users might manually creating their own directory structure for example APP folder: all application's files will be place here, and DATA folder: portable registry maybe be place here.
To be frank, multiple launchers didn't really crossed my mind when I was thinking about this. I think multiple launchers are the exceptions to the rule, and easy things should remain easy and not be complicated by rare cases. Frankly, the complexity of representing multiple INIs in the same project with parent/child relationship freaks me out.Currently JPE Quickie can only create a launcher for a portable app package. In future, maybe the list box can be expand to have tick box so that user could create more than one launcher in the portable app package like below
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Re: Feedback needed for new JauntePE 0.5.0 GUI
Glad to see that option is available.Andrew Lee wrote:If you click on "Build, Create portable package" under my mockup, you see a message "Options for different package layouts may be included here". The user decides which layout to use, with a sensible default.
Yeah, it freaks me too when i first try to play with the complexity in the PStart JPE Edition. Log info is our guideline finding out the parent/child/multiple INIs relationship.Andrew Lee wrote:Frankly, the complexity of representing multiple INIs in the same project with parent/child relationship freaks me out.
Re: Feedback needed for new JauntePE 0.5.0 GUI
Finally we arrived at the fifth wizard GUI. This is the point we will talk about the idea of prelim settings. It is a new concept when we talk about “Full write access” and “Restricted write access”. The concept is similar to _Normal and _Greener but with additional enhancement, mostly at filesystem redirection.
![Image](http://www.freeimagehosting.net/uploads/d79cf811fa.jpg)
If Administrator (portable app maker) selects “Full write access” to be as basis for his portable app project, it means the Administrator wants the end users of portable app expecting the save file to appear on the physical system, instead of in the sandbox. In order to do that _Normal config will be selected with additional details below:
If Administrator selects “Restricted write access” to be as basis for his portable app project, it means the Administrator wants JauntePE redirect most of the portable app operations to the sandbox. This mode is useful where the Administrator want to prevent end user of portable app from affecting the local file system. In order to do that _Greener config will be selected with additional details below:
The third option "Let me choose my own config settings" will be similar to JPE Quickie idea on app-specific config sharing. User might already have the app-specific config to be used as prelim settings for the project. Example would be redllar's Firefox_3.0 Basic.ini
![Image](http://www.freeimagehosting.net/uploads/d79cf811fa.jpg)
If Administrator (portable app maker) selects “Full write access” to be as basis for his portable app project, it means the Administrator wants the end users of portable app expecting the save file to appear on the physical system, instead of in the sandbox. In order to do that _Normal config will be selected with additional details below:
- filesystem redirection is set to the minimum. FilesystemExclude (All) and FilesystemInclude to only Appdata (26), Common Appdata (35), Local Appdata (28), %ProgramFiles% (38), ProgramFiles\Common (43), %SystemRoot% (36), %SystemRoot%\system32 (37). These special folders however are still being redirected because they are the most commonly used by app to place files and settings
- registry redirection is set to be similar to _Normal3.ini.
- Using Analysis Result obtained during the discovery of installer redirection and application exercising, any value that app-specific are set to [FilesystemInclude], [FilesystemIgnore], [RegistryInclude] and [RegistryIgnore]. This is similar to partial optimized I guess.
- current User Desktop (16) and current user My Document (5) are always excluded from redirection.
Code: Select all
; top here will be the same settings listed in _Normal3.ini
; then followed with additional details below
[RegistryInclude]
1= HKEY_CURRENT_USER\Software\7-ZIP
[RegistryIgnore]
1= HKEY_CURRENT_USER\Software\7-ZIP
[FilesystemExclude]
1=*
[FilesystemInclude]
1=38
2=43
3=36
4=37
5=35
6=28
7=26
8=%38%\7-Zip
[FilesystemIgnore]
1=%38%\7-Zip
- filesystem redirection is set to the maximum similar to _Greener2.ini
- registry redirection is set to maximum similar to _Greener2.ini.
- Using Analysis Result obtained during the discovery of installer redirection and application exercising, any value that app-specific are set to [FilesystemInclude], [FilesystemIgnore], [RegistryInclude] and [RegistryIgnore]. This is similar to partial optimized I guess.
- current User Desktop (16) and current user My Document (5) are always excluded from redirection. This exclusion is a feature. It is because end users always work their file in these two special folder. If the Administrator change this feature by redirecting My Document for example, it is the the Administrator's responsibility to inform the end user on how the portable app behave when end user working at My Document.
Code: Select all
; top here will be the same settings listed in _Greener2.ini
; then followed with additional details below
[RegistryInclude]
1= HKEY_CURRENT_USER\Software\7-ZIP
[RegistryIgnore]
1= HKEY_CURRENT_USER\Software\7-ZIP
[FilesystemExclude]
1=5
2=16
[FilesystemInclude]
1=%UserProfile%
2=%AllUsersProfile%
3=%UserProfile%\..
4=%Temp%
5=%Temp%\..
6=%38%\7-Zip
[FilesystemIgnore]
1=%38%\7-Zip