MUI2 and nsDialogs - The reason for it?

Speed78
25th February 2008 19:45 UTC

MUI2 and nsDialogs - The reason for it?
Hi,

since the latest release I try to use MUI2. IÂ´ve some questions about it:

1. What is the reason for using MUI2?
2. Is there a list of new features compared to the old version (MUI1)
3. Will MUI1 be supported in the future, too?

Then I tried to upgrade to nsDialogs, but I really donÂ´t know how to upgrade my current custom installpages to the new nsDialogs. A few questions about it:

1. Is there an editor to create own custom pages with nsDialogs?
2. How can I set some data (some text or activate a checkbox or a radio button) to a control in my custom page? Should I use SetUserData? How should I use it? Is there an example for doing this?
3. Will InstallOptions be supported in the future?

At the moment I donÂ´t see the big advantage to use MUI2 and nsDialogs. IÂ´ve used in my software several custom pages and with some real time notifcation in the dialogs without any problems. Maybe someone can give me a hint why I should use this and how to upgrade it?

Best regards

Rainer

Joost Verburg
25th February 2008 20:47 UTC

nsDialogs is faster and provides more features as compared to InstallOptions. The main features of MUI2 are similar to MUI1, but it is easier to customize or extend. For example, the Multi-User header files provides a MUI2 page. And of course MUI2 uses nsDialogs so the performance is also better.

New features will only be added to MUI2/nsDialogs, but MUI1/InstallOptions will continue to be included in NSIS 2.x. So you don't need to hurry to upgrade existing scripts with custom pages. For new projects MUI2 is recommended.

Anders
25th February 2008 21:51 UTC

How can you say its easier to extend? With MUI1 you can move controls around on the welcome/finish page just by editing the .ini @ runtime, with MUI2 you would have to call SetWindowPos and GetWindowRect etc, no?

Speed78
26th February 2008 08:32 UTC

Hi,

is it possible to use a graphical editor to create custom pages with nsDialogs?

Best regards

Rainer

Afrow UK
26th February 2008 13:05 UTC

Not yet that I know of.

Stu

bazzauk2002
26th February 2008 13:41 UTC

I agree about this graphical editor when using nsdoalogs, i dont think i shall be using it until such a tool comes out.
Mind you i aint getting very far with the previous way of doing it either. lol

regards bazzauk2002

iceman_k
26th February 2008 14:33 UTC

I think it is fairly unlikely that there will ever be a visual designer for nsDialogs for the following reasons:[list=1][*]nsDialogs can be used for any windows control and can therefore be different from OS to OS. e.g., there may be some controls which are supported on Windows XP and not on Windows 95, etc. It will be extremely difficult and time-consuming to develop such a versatile GUI designer.
[*]nsDialogs commands are interspersed with regular NSIS commands (and can indeed be split over multiple functions and/or macros). Any GUI designer will have to perform advanced parsing of NSIS scripts to even have a hope of handling this.
[*]nsDialogs commands can accept variables which can be modified at runtime. It is not possible for a design-time GUI to predict what can happen at runtime.[/list=1]

A workaround would be to use the existing InstallOptions designers to visually design your dialog, and then use existing macros to convert them to nsDialogs commands. Unfortunately, however, this is a one-way process, since any modifications made to the generated nsDialogs commands will not be reflected in the original INI file.

If you are not terribly affected by the performance gains of nsDialogs over InstallOptions (have these ever been quantified, by the way?), and are happy with the limited subset of control types supported by InstallOptions, then perhaps you may have no need to switch from InstallOptions at all.

Speed78
26th February 2008 18:15 UTC

IÂ´ve created several setups with NSIS and every setup contains several at least one custom page. Some setup contains more custom pages than the default pages. At the moment IÂ´ve no need to use some other controls like the default controls.

I think the InstallOptions are very beautiful for beginners to create custom pages, because it is very easy using the graphical editor. Without a graphical editor I canÂ´t imagine to create custom pages without it and I think a professional setup creator must contain an editor (by itself or by a third party vendor) to create custom page. I also donÂ´t want to create my HTML site with notepad!

This is really a reason for me not to use nsDialogs, except when I must use it (NSIS > 2.x).

So, please donÂ´t beat me ;). I partly agree with you and I understand the reasons to implement it, but IÂ´m not really convinced of the new implementations. I think it is a big break and at the moment (or nearly in the future) I can only see new work for me :(.

Best regards

Rainer

{_trueparuex^}
27th February 2008 00:50 UTC

Well creating / and using pages with nsDialogs is actually very similiar to creating windows with Windows api. The whole CreateControl call is just kind of wrap around the CreateWindowEx function.

With this design developers that has ever created applications with windows or dialog boxes (what kind of makes sense if you are already creating an installer for your application) should feel right at home when using nsDialogs. And I think this is definitely the right direction to go.

And what comes to graphical designer... There never might be a such complete designer as iceman_k describe, but I am quite confident that nsDialogs designer(s) to create the basic layout for pages will appear at some point.

Cheers :)

AaronLS
6th March 2008 17:30 UTC

I was kind of wondering about the differences as well. As far as I can tell, the benefits offered with nsDialogs in my case isn't worth the additional complexity.

I know that the documentation says to only use nsDialogs in the MUI2 welcome and finish pages, but can I still use install options with other custom pages and have them share the mui2 look, like the HEADERBMP ?

I am doing my first custom dialog and am confused about which direction to go. My one custom dialog will be very simple for the most part. I'm not a big fan of win32 programming. I'd rather not have to read through two sets of documentation to determine which is right for me.

If I have to use MUI 1 with install options, then do you tihnk I would regret using MUI 1 if my custom dialog is very simple?

kichik
6th March 2008 17:59 UTC

It is faster. Way faster. INI files were holding InstallOptions back for far too long. nsDialogs could easily handle a large number of controls where InstallOptions would have chocked.
It's actually so much faster than InstallOptions that it can finally handle notification of changes in edit controls.
It offers direct access from the dialogs to the script. There's no need to read slow INI files in the leave callback function in order to get information. nsDialogs will call functions in your script for you.
It is far more capable and less limited. You can create any type of control with nsDialogs so there's no need for additional plug-ins such as InstallOptionsEx with a lot of logic in them for every type of new control.
As controls are created by code, it's much easier to dynamically create pages.
Simple "add this style" feature requests can now be easily scripted vy the user.

As for MUI1 integration and IO+MUI2 integration - it just works. There's no magic to it. Different plug-ins have created different pages in the same installer for a long time. Even MUI1 installers still use both IO and StartMenu.

AaronLS
6th March 2008 18:10 UTC

Thanks for the prompt reply. I'm glad to hear the install options will work with MUI2. I'm not trying to knock nsDialogs, as I can see the power of it when that is needed.

Speed78
6th March 2008 20:03 UTC

Originally posted by kichik
It is faster. Way faster. INI files were holding InstallOptions back for far too long. nsDialogs could easily handle a large number of controls where InstallOptions would have chocked.

My install pages have 30 Controls and I think this is a large number of controls and donÂ´t saw any performance problems. I donÂ´t know how much controls other developers needed on a custom page but I think the performance are good enough for the most developers.

It's actually so much faster than InstallOptions that it can finally handle notification of changes in edit controls.

IÂ´m using notifications of changes in my custom page too e.g. with radio buttons - (On a click some textboxes will be disabled) without any problems.

It offers direct access from the dialogs to the script. There's no need to read slow INI files in the leave callback function in order to get information. nsDialogs will call functions in your script for you.

Ok. I partly agree with you. I think reading an Ini-File is not so beautiful.

It is far more capable and less limited. You can create any type of control with nsDialogs so there's no need for additional plug-ins such as InstallOptionsEx with a lot of logic in them for every type of new control.

I partly agree with you. But for me I donÂ´t need other controls like the default controls. Probably, this is an interesting feature for other developers .

As controls are created by code, it's much easier to dynamically create pages.

Creating controls by code is the most disadvantage. I really prefer a gui editor.

Nevertheless I prefer MUI2 + IO and I avoid using the nsDialogs. I really donÂ´t want to upgrade my setups to nsDialogs because this takes so much time.

Best regards

Rainer

kichik
6th March 2008 21:21 UTC

IÂ´m using notifications of changes in my custom page too e.g. with radio buttons - (On a click some textboxes will be disabled) without any problems.

I was talking of specifically edit (TEXT) controls.

Creating controls by code is the most disadvantage. I really prefer a gui editor.

Controls created by code don't interfere with a GUI editor. Swing has a GUI editor and so can nsDialogs. It doesn't have to support everything the user later does with the code it generated. It can even save the dialog as an intermediate format and only generate the code when really needed.

Joost Verburg
6th March 2008 23:12 UTC

I think the best option for a dialog editor would be to store the dialog in some generic format and allow it to be exported to InstallOptions INI or nsDialogs script code.

iceman_k
7th March 2008 01:01 UTC

Originally posted by kichik
Swing has a GUI editor and so can nsDialogs. It doesn't have to support everything the user later does with the code it generated. It can even save the dialog as an intermediate format and only generate the code when really needed.

Java is a much easier language to parse than NSIS, as far as creating a AST model goes. It has a very well defined grammar , which NSIS does not. Java is also very structured while NSIS is more free-form.
Doing a one time parse to generate the installer is reasonably easy. However, creating and maintaining a model in memory which is synchronized with text editors is very complex.
I have made an attempt to create such a parser, but I simply don't have the time- it is a full time effort.
Creating an intermediate format in which dialogs can be stored is trivial. However, the true power of a GUI builder lies in its round-tripping capability- and that will get lost if the GUI representation is not synchronized with the textual representation.

Just my 2 cents.

Joost Verburg
7th March 2008 11:46 UTC

I agree that round-tripping can be useful, but using an intermediate format is better than having no support at all.

For InstallOptions you had to manually write the code to set texts based on variables / language strings. That should now be possible with a GUI builder.

kichik
7th March 2008 13:29 UTC

Even if you want round-tripping, you can decide that you only support built-in macros in nsDialogs.nsh. That's not much worse than other available solutions. Even with a proper AST, you can't handle loops or functions. Actually, you always can, but it'd be harder and harder to represent, no matter which language you choose.

iceman_k
7th March 2008 13:45 UTC

Originally posted by kichik
Even if you want round-tripping, you can decide that you only support built-in macros in nsDialogs.nsh. That's not much worse than other available solutions. Even with a proper AST, you can't handle loops or functions. Actually, you always can, but it'd be harder and harder to represent, no matter which language you choose.

All good points. I had briefly considered adding a plugin to EclipseNSIS for creating and editing nsDialogs GUIs, but there were too many pitfalls I found and it I rapidly became aware that I would have to impose too many restrictions for it to be more than a useful toy. e.g.,

1) Only predefined nsDialogs macros will be supported.
2) All nsDialogs calls will have to be in a single NSH file.
3) nsDialogs calls for a specific dialog cannot be spread over multiple functions or wrapped in other macros.
4) No use of variables. If a variable is specified for an (x,y) location or control setting, there is no way a GUI editor can represent it correctly.
etc.

Given these issues, I abandoned the idea of an nsDialogs GUI builder.

kichik
7th March 2008 18:20 UTC

Those restrictions are not much different than those of any other GUI editors I've seen, including VEP (though that was a long time ago, so they may have advanced).

Even with all of these restrictions and more, the editor will still be at least as good and feature-complete as any of the old InstallOptions editors.

iceman_k
7th March 2008 22:35 UTC

One of the advantages VE has is the JDT editor with its associated AST model which it gets for free with Eclipse. Also, from what I remember, VEP was not very happy if you messed around too much with the generated code- it would tolerate only a certain level of manual modification. However, like you said, it may have improved a lot now.

The way VE works is quite interesting- from what I remember, it actually fires up a separate java VM in which the SWT or Swing widgets are instantiated and it then uses reflection and the Java beans mechanism to interact with the widgets.
Because these are objects which it can interact with in real time, runtime behavior can be emulated reasonably easily.
e.g., it can use the AST to determine variable values, etc., at runtime and use those to interact with the widget classes and determine how they react to variable inputs.

I am not sure how other Swing GUI editors work and how flexible they are.

nsnb
26th September 2010 01:23 UTC

Originally posted by Afrow UK
Not yet that I know of.

Any good news since then? :)

redxii
26th September 2010 08:45 UTC

GUI editors are mentioned. You can use a program called ResEdit, kinda like ResHacker, but it's much better than ResHacker. Set the size to 140 high and 300 wide and no border, and design away. Once you have what you want then grab the x y w h values and use those. It only lists dialog units, when using other languages or DPI settings I recommend staying away from using pixels. So much better than guessing and repeat compiling and hoping your nsDialogs page will turn out how you want it.

I also used ResEdit when customizing the included UIs.

http://www.resedit.net/ (You don't need the Platform SDK.)

ResEdit is still being updated, ResHacker was last updated in 2002. As a warning though, save your form often because ResEdit tends to crash.

Also when creating a new page I create a mini script, very small and fast to compile. So if your program is large you don't have to wait long to see how your page turns out, and using DetailPrint or MessageBox to see if the variables you use return the desired values.

nsnb
26th September 2010 14:05 UTC

Originally posted by redxii
http://www.resedit.net/

Thanks, I'll give it a try.