13 replies to this topic

[Brito]

How about a variable added inside script.project to help identify the project type?

I wanted to create a new script for a program wich works well enough under nativeEx and VistaPE - but a question appeared - Is it really needed to create two scripts, one specific for each project?

If both projects added a variable called %project% (for example) - it would be possible to determinate if my script is running under a nativeEx based project or a VistaPE based project and this way be confortably able to add support regarding shortcut creation routines, file copy, registry keys, etc..


This could also become a flexible way for newer projects that come in time and have less work to adapt them.

Of course this is not a solution for every project (especially regarding drivers), but there are a lot of nifty programs and tools that could be shared this way.

Just trying to create a common script ground, what do others think?

[MedEvil]

I don't like it.
You try to patch in the apps scripts, shortcomings in the core design of the projects.
Application level scripts shouldn't have to care, about what project they are used in. It's the job of the project cores to deliver a standardized interface for the scripts to use.

[Brito]

I don't like it.
You try to patch in the apps scripts, shortcomings in the core design of the projects.
Application level scripts shouldn't have to care, about what project they are used in. It's the job of the project cores to deliver a standardized interface for the scripts to use.

Yes, I see your point and agree with it - but we continue without a common solution to create these scripts - both cores of nativeEx and VistaPE are different enough when comparing target platforms, folders and methods of construction.

The script interface is standard with question boxes to add shortcuts and the attached files for these application level scripts.

Having a %project% variable common to both projects would allow to simply merge two scripts on this case into a single one - and then it would become a flexible script - not binded to single project type.

Imagine that I also want do add support for the ReactOS core - or even for a project based on Win9x.

Of course that our projects here seem to change quite quickly - but at the same time, application scripts would start to grow modular, replacing only the section wich needs to be updated but still using common variables.

nativeEx has an API of it's own - and so does VistaPE - changes on application scripts when updating cores should have little impact on scripts and also allow to have separate behaviors for even more projects.

Lots of potential here, let's try it?

[phox]

The strategic goal should be WinBuilder portability across
different OS’s and application scripts portability across projects.
That will bring back common application “Archive”.

[pscEx]

If somebody needs this %project% inside an app, he may create his own one:

IniRead,%ProjectDir%\script.project,Main,Title,%project%

Peter

[Brito]

The strategic goal should be WinBuilder portability across
different OS’s and application scripts portability across projects.

Then we should also start a new topic discussing common API - one wich all projects adopt and I will agree with you then, but unfortunatelly this is not the case. We have projects with very different concepts so this seems a working method to make scripts that support these two projects at the very least..

That will bring back common application “Archive”.

It would only bring back the Archive folder and linked files if needed - wich I doubt.

If somebody needs this %project% inside an app, he may create his own one:

IniRead,%ProjectDir%\script.project,Main,Title,%project%

Peter

I meant a project type - how would this apply to LiveXP and NativePE wich have different tags but are both based on nativeEx?



Should we start discussing a common API?


Really want to create more scripts to give some good use to the download center..

[pscEx]

I meant a project type - how would this apply to LiveXP and NativePE wich have different tags but are both based on nativeEx?

Peter

[Brito]

Just a simple:

%project%=nativeEx

inside script.project for nativeEx and LiveXP

and

%project%=vistape

on the respective vistaPE script.project..


Guess I'll have to show this proposal as a working script or maybe I should write around 100 good reasons to use this method until I can actually convince someone - let me know wich one you'd prefer..

[pscEx]

Just a simple:

%project%=nativeEx

inside script.project for nativeEx and LiveXP

and

%project%=vistape

on the respective vistaPE script.project..


Guess I'll have to show this proposal as a working script or maybe I should write around 100 good reasons to use this method until I can actually convince someone - let me know wich one you'd prefer..

#1: My meant that I worry not have understood your back idea in detail.
#2: You know that I'm a friend of presenting solutions rather than make long discussions ...
... And if somebody does not use the new variable?
... I do not remember that I use all variables WinBuilder offers!

Peter

[Brito]

Yes - you're right!

Will work on it and show the results..

[MedEvil]

@Nuno
- Merging two different 'scripts' into one script has nothing to do with modularity.
- When i said Interface, i didn't ment the script interface where people can choose settings, but an interface between the application script and the Project core, an API.
(The apps script should just say, where it would like to have shortcuts and the project cores job is it to know how to create them, the same will probably be true for file associations.)
btw. We already had this discussion once with regard to the use of differnt shells.

Should we start discussing a common API?

Yes!
A little planning on the general future, would also not be bad.
I keep reading, how surprised people are how far the projects have come, but we could be much further, if we wouldn't have to constantly rewrite old code.

It would only bring back the Archive folder and linked files if needed - wich I doubt.

Common Archive - yes.
Linked files - no.
We have now the ability to load, store and save profiles.
One could load the LiveXp, nativeEx, nativePe or his very own profile and WB would look as if just the LiveXp, nativeEx, nativePe or his very own project were downloaded/installed.



PS A little planning never hurt anyone!

[Brito]

Ok - strong and valid arguments!

Let the API talk begin then..

[pscEx]

@Nuno
- Merging two different 'scripts' into one script has nothing to do with modularity.
- When i said Interface, i didn't ment the script interface where people can choose settings, but an interface between the application script and the Project core, an API.
(The apps script should just say, where it would like to have shortcuts and the project cores job is it to know how to create them, the same will probably be true for file associations.)
btw. We already had this discussion once with regard to the use of differnt shells.


Yes!
A little planning on the general future, would also not be bad.
I keep reading, how surprised people are how far the projects have come, but we could be much further, if we wouldn't have to constantly rewrite old code.


Common Archive - yes.
Linked files - no.
We have now the ability to load, store and save profiles.
One could load the LiveXp, nativeEx, nativePe or his very own profile and WB would look as if just the LiveXp, nativeEx, nativePe or his very own project were downloaded/installed.



PS A little planning never hurt anyone!

@Medevil!
Your post sounds good and shows a rather high level of software ingeneering.

But in the actual case I think the level is TOO high!

Exaggerated but simply said:
WinBuilder is not (yet?) an IDE to create platform independent bootable environments.
WinBuilder is an 'Enhanced DOS cmd replacement' (Remember the grand parent name 'Batcher') to create bootable environments.
And every additional functionality is welcome to create platform independent bootable environments.

So the %ProjectType% is welcome. Nobody is forced to use it.

Peter

[MedEvil]

@Medevil!
Your post sounds good and shows a rather high level of software ingeneering.

But in the actual case I think the level is TOO high!

Well i guess that's possible, i work in the business all my life. Never dawned on me, that experience could be a handicap.

It just pains me to see how valuable resources are wasted.
Instead of first deciding what house we want and then start bulding it, starting from the foundation all the way to the tip of the roof.
We first build a little house, if that is halfway through, we tear it down to replace it by a bigger one, is that halfway through, we tear it down to build a bigger one ....

That's of course a way to do things too, but one that wastes countless hours of work for nothing.