19 replies to this topic

[TheHive]

If you can think of a better name for the Topic name let me know.

I was thinking why dont we have a guide of somekind early on so that it can mature as things grow. It will make it easier to maintain in the future. And others that need somekind of guide might gain some wisdom.

I will take Notepad and Notepad++ as an example of a good starting point for comparison.

Notepad


Notepad++


Both notepad and Notepad++ have similar Interfaces and they have options for the end user to build to some of his needs. They both allow the use of File assossiation so that the end user decides what files each program should take care off. In this way the Programmer is not the one to dictate to the end user what app should associate with what file and thus mess up the work of another programmer.

Both apps also have the ability to let the user choose where they would like to put the Shortcuts to. This could use some improvements and hope to see some in the future as more things are being added to the Shell. So both application have a good foundation from where to grow.

Another thing I really like is that the user gets to actually name the apps Shortcut name to what they choose.

Once the Quicklaunch is refined both Applications mentioned will hopefully be able to grow and add the ability to put a shortcuts to the Quicklaunch toolbar also.

----------------------------------------------------------------------------------------
Things that can be added and would like to see in future updates to these apps Script gui interface and to others that might come in the future or are available now.

What I see missing is the option to create subfolders. Im not sure if that can be implemented yet. I havent seen any one releasing an app that adds such an option for the end user.

For example allowing the user to create a shortcut as follows:

1. Start - Create shorcut here

2. Start - Programs - User is given a way to input the name of the Sub Folder that is going to hold the programs shortcut

3. Quicklaunch - Create shorcut here [Smiley said he will update in the future for this option]

4. Quicklaunch - User is given a way to input the name of the Sub Folder that is going to hold the programs shortcut

5. Desktop - User is given a way to input the name of the Sub Folder that is going to hold the programs shortcut

6. A selection box that will allow the user to use whatever icon they want to use with the shortcut.


If any one has any more ideas that might help others make the Scritps end user Gui experience as userfrienly as possible, please post here.

[Yorn]

How about this:
A script that runs just before imaging or whatever that maybe shows the user what their start menu is going to look like ahead of time and lets them select a program and redesign the location? Or wait, I think that's what you're asking for, right?

I think you're right in that we should probably consider this type of a change *now* as opposed to later, when everyone is making their own statically-coded applications and such. Someone might want to put 7zip in a "Utilities" folder, and others would want to call it "Tools" and even more might want to have 7zip, WinRAR, UHARC, etc in a "Compression" folder.

[smiley]

I have a good idea.It is not easy for many scripts to have so big interface.

The scripts that can have this interface , will write in the project.ini their exe files.Then a script will read these entries and execute a program that will ask the user what shortcuts to create for each exe .Then it will create a new script that will aply these settings. I think that can be named AutoShortcuts

[Brito]

I have a good idea.It is not easy for many scripts to have so big interface.

The scripts that can have this interface , will write in the project.ini their exe files.Then a script will read these entries and execute a program that will ask the user what shortcuts to create for each exe .Then it will create a new script that will aply these settings. I think that can be named AutoShortcuts

That is a really good idea!

Since the needed shortcuts would likely be created in last - this would be a perfect way of having a single way of making shortcuts for different shells like explorer, xoblite/bblean and geoshell.

At this moment it is needed to add entries for one sort of shell. With the method you proposed things could be definitively easier.

This would even allow to to use separate shells within the same CD with similar shortcut entries..


Keep it up!

[TheHive]

How about this:
A script that runs just before imaging or whatever that maybe shows the user what their start menu is going to look like ahead of time and lets them select a program and redesign the location? Or wait, I think that's what you're asking for, right?

I think you're right in that we should probably consider this type of a change *now* as opposed to later, when everyone is making their own statically-coded applications and such. Someone might want to put 7zip in a "Utilities" folder, and others would want to call it "Tools" and even more might want to have 7zip, WinRAR, UHARC, etc in a "Compression" folder.

YES!

I have a good idea.It is not easy for many scripts to have so big interface.

The scripts that can have this interface , will write in the project.ini their exe files.Then a script will read these entries and execute a program that will ask the user what shortcuts to create for each exe .Then it will create a new script that will aply these settings. I think that can be named AutoShortcuts

YES!

That is a really good idea!

Since the needed shortcuts would likely be created in last - this would be a perfect way of having a single way of making shortcuts for different shells like explorer, xoblite/bblean and geoshell.

At this moment it is needed to add entries for one sort of shell. With the method you proposed things could be definitively easier.

This would even allow to to use separate shells within the same CD with similar shortcut entries..
Keep it up!

YES!

[Draugen]

For this to be practical to code, #include's and macros will help a great deal . This allows us to create semi-functions (IE: gen-shortcut(bblean, %APPNAME%,\Location\of\exe) functionality.

Or something. Else, we get a lot of repeated code, since every app script would need their own [addshortcut-{bb4win|explorer|geoshell|whathaveyou}]-sections. This is the way ModPE currently works btw, wich is NOT such a good thing, seeing as if i change one app_ script, i need to change them all...

In summary: Code reuse FTW!

//martin (who realizes that this is NOT what smiley had in mind. Both ideas are valid )

[Brito]

Well.. one line should be enough to define a icon or menu entry, but the goal would be not to limit a common menu to a specific shell.

Since we have a lot of shells to choose from and even more are likely to appear, perhaps it would make more sense to define a common way wich could/should be applied to every shell.

This way we would be able to define wich shortcut/menu type should be used in accordance to the prefered shell - it would not be needed to change or edit any individual script to use a new shell or an alternative one.

To avoid long syntax, two or more commands could define icons/menu entries/quicklaunch icons..

Something like:

Iniwrite,%menu%,icons,MyTest,c:\test\test.txt
Iniwrite,%menu%,menu,Tests\MyTest,c:\test\test.txt
Iniwrite,%menu%,quick,MyTest,c:\test\test.txt

Giving this result on %menu% (a text file - the one used by processinfo is a good option)

[Main]
shell=xoblite,explorer

[icons]
MyTest,c:\test\test.txt

[menu]
Tests\MyTest=c:\test\test.txt

[quick]
MyTest,c:\test\test.txt

This example would show MyTest on the desktop, quicklaunch and as a menu entry. If one also selected xoblite then you also provide a menu with the compatible settings - in this case every entry on [menu], the rest could be ignored.

[Draugen]

Storing the menu entries in a file is a good option.. ithink i'll add some simlar behavior to modpe. This allows me to call a 'genmenu' script at the end of apps.script.

But i think i'll go for a junk file - one that's recreated every run. IMO, this is not information that is needed in a log file.

//martin

[Alexei]

I'd prefer to have all user-definable options in separate ini file common to all projects.
As I remember, there are about 10 entries about visial effects. There are many other settings that may be tuned. It would be logical to collect them all in one INI file, with some most useful options/sets accessable from GUI. Same with shortcuts, especially for additional software from "Common" folder.
I'm going to make a script to do "TweakUI"-things. With INI I can write it fast. Then, eventually, GUI may be developed (do we really need it for kinda permanent settings? ).
I don't think WinBuilder.INI (WinBuilder options) is a good place for "target" options. Does Target.INI sounds OK?

Options may be something like:
[options]
name=on/off
projname.name=on/off - override for the project

Though shortcuts need more complex definitions, maybe something like this:
[shortcuts]
start=command, workdir,...
start.programs=....
projname.start.programs=...

To do overrides for the shell it can be [options.shellname], [shortcuts.shellname]

In fact, I would agree on any format, I just want user options to be global and standard.
And, of course, user parameters should not be reset by uploading new version of WinBuilder or scripts.

Alexei

[Brito]

Good ideas!

As for tweakUI - it would be wise to use a separate file as you've stated. At this point there are several ways of approaching this question but it would be easier to see them working on the program to check where things can be improved/adapted to work better..

[pscEx]

This thread reminds me on an idea I have had some weeks ago, but never published because I thought that it is to difficult to implement.

Now outing to the rest of the world:

What about to have ONE Interface object like
[attachment=298:attachment]
?

Peter

[smiley]

This thread reminds me on an idea I have had some weeks ago, but never published because I thought that it is to difficult to implement.

Now outing to the rest of the world:

What about to have ONE Interface object like
[attachment=298:attachment]
?

Peter

The idea seems good but i can't count how many ideas Nuno have to achieve

[Brito]

The idea seems good but i can't count how many ideas Nuno have to achieve

At this moment I'm mostly busy with some server/intranet issues at my work - once it's solved I'll be able to focus all my daytime on programming as before..

The more ideas the merrier!

[Alexei]

The idea seems good but i can't count how many ideas Nuno have to achieve

Agree, but what Peter's idea would be easy to implement with already proposed "Call" command that supposed to ivoke script in its own context dynamically.
It would be like: "INI-support script" scans INI, forms work-script for each entry, and calls it. Each work script asks user about shortcut (or global setting) and writes back to INI.

No work from Nuno, but to implement "Call"-command, though it may be not easy

Generally, the more "powerful" scripting features, the less future workload on Nuno


Alexei

[Alexei]

Correction to my previous post:

...already proposed "Call" command that supposed to ivoke script in its own context dynamically.

Ccurrently "Call"-command does not execute complete script, but its processing section.
So, we may need something else to do that, sorry

Alexei

[Brito]

Correction to my previous post:

Currently "Call" command does not execute complete script, but its processing section.
So, we may need something else to do that, sorry

Alexei,

Call will completely execute a script if you wish, use the [process] section and it will run like any other script..

At this moment I'm debugging your test project - I find it a really good tool to stress winbuilder and check where things can be improved, have you made/found anything new?

[Alexei]

Alexei,

Call will completely execute a script if you wish, use the [process] section and it will run like any other script..

At this moment I'm debugging your test project - I find it a really good tool to stress winbuilder and check where things can be improved, have you made/found anything new?

Actually, yes I didn't verify it completely, but it looks like "Message" with incorrect syntax may hang WinBuilder (it was something like Message,txt - without ""). BTW, I used one trick once and still love it: when wm_syscommand,sys_close comes 5th time I terminate the program harshly

About "Call", it's gonna be "execute" in the next betta, correct? - it's OK with me Initially, I was thinking about execution of the whole script meaning its [vars] and [process]-sections. While reading this thread it just popped up that dynamic call of [interface] could be an interesting feature. That actually means each script would be able to create and call another script (with it's own dialog) at runtime (in the middle of the building)! However, runtime dialog may be excessive feature ... may be not

Alexei

[Brito]

Actually, yes I didn't verify it completely, but it looks like "Message" with incorrect syntax may hang WinBuilder (it was something like Message,txt - without ""). BTW, I used one trick once and still love it: when wm_syscommand,sys_close comes 5th time I terminate the program harshly

I'll check it!

However, runtime dialog may be excessive feature ... may be not

Actually it works since no variables get mixed in anywhere. Once you call the other script a new process is launched - the equivalent of selecting to run only one script from the main window.

This is very helpfull for adding components on a script.project file and then use them as variables..

What do you think?

[Draugen]

This is very helpfull for adding components on a script.project file and then use them as variables..

this sounds.... interesting now to figure out something to do with it

[Alexei]

I'll check it!
Actually it works since no variables get mixed in anywhere. Once you call the other script a new process is launched - the equivalent of selecting to run only one script from the main window.

This is very helpfull for adding components on a script.project file and then use them as variables..

What do you think?

Please take a look at this topic I created Though I'd prefer to have some button to run "Global Parameters" script (same way I decribed). How about making "script.project" to run as fully-featured script? (same for the .link files). Such features has to be thought carefully. Maybe just allow project to add its own buttons to WinBuilder's window and link them with scripts (easy, powerful, but does not provoke "tricks")
Though there is no limit to improvements , so just don't let me go too far In fact, having too many features may create more problem then solve

Alexei,
Call will completely execute a script if you wish, use the [process] section and it will run like any other script..

Wow, I have to play with it

Alexei,
At this moment I'm debugging your test project - I find it a really good tool to stress winbuilder and check where things can be improved, have you made/found anything new?

Not yet, just "refresh button"-fix mentioned in the topic above


Alexei