Jump to content











Photo
- - - - -

%project% variable


  • Please log in to reply
13 replies to this topic

#1 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 04 May 2007 - 11:03 PM

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? :confused1:

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? :confused1:

#2 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 05 May 2007 - 12:12 AM

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.

:confused1:

#3 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 May 2007 - 12:47 AM

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.

:confused1:


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?

:confused1:

#4 phox

phox

    Silver Member

  • .script developer
  • 764 posts

Posted 05 May 2007 - 03:33 AM

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

#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 05 May 2007 - 07:16 AM

If somebody needs this %project% inside an app, he may create his own one:
IniRead,%ProjectDir%\script.project,Main,Title,%project%
Peter

#6 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 May 2007 - 10:14 AM

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? :confused1:



Should we start discussing a common API?


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

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 05 May 2007 - 10:33 AM

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


:confused1:

Peter

#8 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 May 2007 - 10:43 AM

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

#9 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 05 May 2007 - 10:50 AM

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


#1: My :confused1: 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 :confused1:

#10 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 May 2007 - 10:58 AM

Yes - you're right! :confused1:

Will work on it and show the results.. :confused1:

#11 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 05 May 2007 - 01:28 PM

@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. :confused1:
(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. :confused1:

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.

:confused1:

PS A little planning never hurt anyone! :confused1:

#12 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 05 May 2007 - 01:59 PM

Ok - strong and valid arguments!

Let the API talk begin then.. :confused1:

#13 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 05 May 2007 - 02:02 PM

@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. :confused1:
(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. :confused1:


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.

:confused1:

PS A little planning never hurt anyone! :confused1:

@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

#14 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 05 May 2007 - 09:26 PM

@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. :confused1:

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.

:confused1:




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users