[Package] PEFactory
#1
Posted 04 June 2010 - 02:21 PM
The current stage looks like:
and it works well for nativeEx_Win7 and nativeEx_barebone.
Maybe there are opinions, suggestions etc. before a publish of the package.
Peter
EDIT 2010-JUN-16: Added latest GUI
#2
Posted 04 June 2010 - 02:31 PM
#3
Posted 04 June 2010 - 02:53 PM
The previous "Finish", " Finalize", "Emulate" etc. scripts will become obsolete and can be deleted.I don't quit understand, will this replace the previous scripts or is this a script to operate the other scripts in a more user friendly way?
(Maybe you have a special script "E-mail the PE to the moon". I am sure there is a way to include that).
In the picture you see, that all current sub-scripts are not selectable to be processed.
Here you only once define your personal settings (usually once).
The unselectable scripts are processed from PEFactory, if applicable.
Peter
#4
Posted 04 June 2010 - 08:03 PM
Sorry, didn't pay attention to the other scripts. Didn't understand, that this was a whole package and not a single script.
Very nice effort!
#5
Posted 04 June 2010 - 09:13 PM
Hi Peter,Maybe there are opinions, suggestions etc. before a publish of the package
Thanks for this. I do have two suggestions. First, it'd be great if PEFactory was compatible with WimPack. Second, it'd be great if it were compatible with RegFactory.
Also, since we can't test yet, I'm not sure if this suggestion has already been implemented. But it'd be great if the grub4dos option supported the current mechanism of adding and replacing items like with the DefineBootsector script.
Thanks,
Galapo.
#6
Posted 05 June 2010 - 10:30 AM
I'l do some test what is possible.Thanks for this. I do have two suggestions. First, it'd be great if PEFactory was compatible with WimPack. Second, it'd be great if it were compatible with RegFactory.
Maybe we have to find a compatibility in the middle.
I'm sure that the functionality of DefineBootsector.Script is fully or 99% contained in the PEFactory package.Also, since we can't test yet, I'm not sure if this suggestion has already been implemented. But it'd be great if the grub4dos option supported the current mechanism of adding and replacing items like with the DefineBootsector script.
Some functionality is decided "Automagically", some functionality like grub4dos skins, can be changed by the user.
Due Test: I think that tonight I'll publish a beta.
Peter
#7
Posted 05 June 2010 - 10:38 AM
Current functionality is:I'm sure that the functionality of DefineBootsector.Script is fully or 99% contained in the PEFactory package.
MenuAdd_GRUB,grub4dos_entry,Prepend|Append|RemoveDefault
Supplied menu.lst entry can be prepended or appended to menu.lst. Alternatively, the default option can be overwritten by the one supplied if that is desirable.
Regards,
Galapo.
#8
Posted 05 June 2010 - 11:24 AM
The current solution provides a custom grub4dos configuration. Sample here:Current functionality is:
MenuAdd_GRUB,grub4dos_entry,Prepend|Append|RemoveDefault
Supplied menu.lst entry can be prepended or appended to menu.lst. Alternatively, the default option can be overwritten by the one supplied if that is desirable.
Regards,
Galapo.
It is activated in the main grub4dos script:
The custom grub4dos script of LiveXP could contain:
[Process] //use the already built menu.lst FileCopy,<myMenu>,%MenuFile%
Peter
#9
Posted 05 June 2010 - 11:42 AM
What about the file grldr? Would Grub4DosStandard.script overwrite one already supplied earlier in build?
Thanks,
Galapo.
#10
Posted 05 June 2010 - 12:33 PM
Currently grldr is written in grub4dos.script, and overwrites already existing loaders.What about the file grldr? Would Grub4DosStandard.script overwrite one already supplied earlier in build?
If,EXISTDIR,%GrubDir%,ExtractFile,%ScriptFile%,Grub,grldr,%GrubDir% Else,ExtractFile,%ScriptFile%,Grub,grldr,%PESourceDir%If necessary, that can be changed, but I think that the current solution will give no issues.
Peter
#11
Posted 05 June 2010 - 12:42 PM
Regards,
Galapo.
#12
Posted 05 June 2010 - 01:20 PM
The PEFactory is intended to be simple and fullfill 9x% of all cases without any "expert knowledge" of the user.I think it gives an issue if someone wants to use a particular version. For example, I prefer a chenall build as it provides progress indication when ram-booting.
Regards,
Galapo.
I do not want to create any GUI with tens of options.
In your case the project must maintain the attachement of grub4dos.script and change dynamically depending on some project options, like:
If,%CrazyOption%,EQUAL,TRUE,FileCopy,<loader_crazy>,%TempFolder%\grldr Else,FileCopy,<loader_standard>,%TempFolder%\grldr Encode,%Grub4DOSScript%,grub,%TempFolder%\grldr
Maybe it does not make PEFactory too complicated to add:
If,%ExistVar%,%MyGrubLoader%,<use this one>
Else,<Use the attached>
Peter
#13
Posted 05 June 2010 - 01:28 PM
Ok, I was just providing this feedback because in the link you provided you've written: "PEFactory package is a solution to have ONE final PE build / test for ALL projects." I assumed "all" meant all, so was providing feedback from a LiveXP perspective. Currently I'm not sure PEFactory will work as it doesn't provide compatibility with currently implemented grub4dos options.The PEFactory is intended to be simple and fullfill 9x% of all cases without any "expert knowledge" of the user.
Regards,
Galapo.
#14
Posted 05 June 2010 - 02:19 PM
#15
Posted 05 June 2010 - 02:23 PM
Well, you could stop complaining and do some script updating yourself.I sure hope PEFactory will not turn into a LiveXP kinda script, where millions of options are thrown at the user.
Regards,
Galapo.
#16
Posted 05 June 2010 - 02:54 PM
PeterTo avoid misunderstandings:
PEFactory does not claim to put ALL existing projects into a "Run Basket".
Existing projects have to qualify themselves for beeing enlosed in the "Run Basket" and maybe do some changes to make this possible.
When they do not want to be included into the "Run Basket", there is no restriction that the projects remain like they are.
They just have not to use the PEFactory package.
#17
Posted 05 June 2010 - 06:48 PM
I'm not complaining, i just happen to disagree with the LiveXP philosophy.Well, you could stop complaining and do some script updating yourself.
Some people like, if they can tweak everything. I like easy to use.
#18
Posted 07 June 2010 - 11:39 PM
#19
Posted 08 June 2010 - 11:23 AM
#20
Posted 08 June 2010 - 05:02 PM
I simultaniously agree and disagree
GUI options which some members call "Useful", confuse other members.
It is not so easy to find a suited compromise between the two sides.
Peter
#21
Posted 10 June 2010 - 08:30 PM
After a fairly long break (playing with Android and new Nexus One)...seems like a good idea, but not sure implementation fits well since it is after the fact, and I would like to see more of this split into two parts...To explain more, please read here.
Maybe there are opinions, suggestions etc. before a publish of the package.
Peter
Some of this needs to happen up front in the configuration of the project, and some of it happens at the end when you test the project or build the project into an ISO/USB, etc. This always seemed poorly implemented to me in the past on many projects, since some of the settings on grub (or even syslinux/isolinux or other boot managers) needs to happen at the start to set up the intial files that other things might write to.
Yes, from a programming point of view, they go together and probably need to be in a single "package" (i.e. a script file). But in terms of a "flow" presented to the user, there are things that happen at the start, and other things that happen at the end.
This is just another "issue" with Winbuilder in general - the conflict between presenting choices to the user and the organization of the code to implement things so you don't duplicate or complicate things.
I saw a similar issue when I was playing around with the code to bypass the WAIK and cache the images, etc. There were calls from one script into another - while that is a good thing to allow to prevent duplication - it made it a bit more difficult to manage (i.e. for me to follow what was going on), and in the end, I figured out it was so that the up front processing happened at the start, and the writing of the images happened at the end.
Not sure the above "rambling" makes sense or if there is a clear message of don't do A, but instead do B, just that making a single "package" to build the physical instantiation of the PE and to allow it to easily combine with other things is a good thing to do, just not sure ONE package will "rule them all" (or even 9x%)...
But, it's worth a shot...
#22
Posted 10 June 2010 - 09:16 PM
Similar concerns and ideas caused me to develop this package.
The "package" should really be totally independent from the project. The project author only has to do one thing: Thell the package some fundamental values:
(current "state of art"
[codebox]Run,%BootManagerScript%,%ProjectTitle% [nativeEx_barebone] Set,%x8664%,%SourceArch%,PERMANENT Set,%ProjectType%,1,PERMANENT Set,%BootTMP%,NIL,PERMANENT Set,%WimApp%,NIL,PERMANENT [nativeEx_Win7] Set,%x8664%,x86,PERMANENT Set,%ProjectType%,4,PERMANENT Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT Set,%WimApp%,NIL,PERMANENT [VistaPE_CAPI_v.12_(RC1b_common_API)] Set,%x8664%,x86,PERMANENT Set,%ProjectType%,2,PERMANENT Set,%BootTMP%,%ProjectTemp%\boot.tmp,PERMANENT IniRead,%ProjectInfo%,VistaInfo,Imagex,%WimApp%[/codebox] Because this is still in beta stage, maybe some other variable definitions may become necessary.
Tomorrow I'll publish a redesigned nativeEx_Win7 using the package.
BTW: It is already on the server and can be downloaded. But please allow me not to give a "preface of explanations, how to use" right now.
Peter
BTW2: e.g. the "Grub" issue is respected by adding a predefined / built menu.lst
#23
Posted 10 June 2010 - 09:35 PM
Given our discussion above, I fail to see how this could possibly be the "one thing" that a project maintainer has to do. For LiveXP, I've already explained how PEFactory in its current implementation is fundamentally incompatible. As explained, that's not necessarily a problem with LiveXP, just that PEFactory can't cover all the options without additional development on PEFactory.The project author only has to do one thing: Thell the package some fundamental values:
Regards,
Galapo.
#24
Posted 11 June 2010 - 10:26 AM
After the nativeEx_barebone theme is closed for me (The 'Main Customer' LiveXP is not able or refuses to update to WB 081 RC1 / 082):As explained, that's not necessarily a problem with LiveXP, just that PEFactory can't cover all the options without additional development on PEFactory.
What do you think is my goal for the next time?
Currently I'm in the last tests to let "Vista PE Capi" project (by JonF) work with PEFactory.
Peter
#25
Posted 11 June 2010 - 10:44 AM
As previously stated, this should be the practice:
Now, I know you disagree. But the reality is that not doing this just gets people offside. I hope this isn't your underlying intention -- I really do hope that you desire a WB that works with other projects and actually supports other developers. At the moment, I don't feel that's the case.In my opinion, we should be able to drop the new WB into our projects and have them work. The only exception to this would be in the case of an actual script bug, or if there is agreement among WB development and project maintainers that a crucial syntax change necessitates not supporting backwards compatibility.
Thanks,
Galapo.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users