Hi list,

The setup dialog that appears when you start Lazarus with e.g. the compiler set to a non-existent file and the options dialog cover the same settings and overlap a lot.

Maybe it's a good idea to think about merging them into one for future Lazarus versions:
- show the options dialog
- use the setup error detection, red icons and descriptive texts to visually indicate settings are not good
- use setup's functionality of navigating the settings treeview to the first problem if there are problems

Ludo was kind enough to do a quick mock up of this. Though not polished, it gives an idea of how this could work.

While it would be some work to merge the 2, it would allow:
- easier implementation of checking for many more things in the settings that are essential or nice to have (detection for the latter could be skipped when running lazarus --setup)
- cutting down on maintenance for the GUI as the setup GUI can disappear
- allow feedback on incorrect settings when editing options, giving users more direct feedback on things that are wrong

Please see screenshot attached for an idea of how this could look.

Thanks,
Reinier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewOptions.png
Type: image/png
Size: 48159 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120819/51a10349/attachment-0001.png>

On Sun, Aug 19, 2012 at 2:58 PM, Reinier Olislagers <

wrote: Please see screenshot attached for an idea of how this could look.

Your basic idea of merging the dialogs MAY be good (?) but I don't like your way of implementing it. Sorry.

The dialogs should merge in a more clever way, reusing the existing GUI controls.
Now everything is just copy-pasted into one big form with partly duplicate information, making the result look messy.
What a new user will think when he opens Lazarus for the first time and gets a form like that? Uhh!
The options dialog is already very crowded even for experienced users. I don't see why it should get a new pane with confusing and duplicate texts.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120819/66838e13/attachment.html>

Hi Juha,

Thanks for your quick comments.

Your basic idea of merging the dialogs MAY be good (?) but I don't like your way of implementing it. Sorry.

No need to apologize. I didn't say the screenshot is the way it should be done: I did say "an idea"..."could work"... ;)
I did want to send a screenshot so it is immediately clear what concepts we're talking about.

The dialogs should merge in a more clever way, reusing the existing GUI controls. Now everything is just copy-pasted into one big form with partly duplicate information, making the result look messy.

Totally agreed.

What a new user will think when he opens Lazarus for the first time and gets a form like that? Uhh! The options dialog is already very crowded even for experienced users. I don't see why it should get a new pane with confusing and duplicate texts.

Yes.

What about something like:
- don't add the setup part to the left; bascially keep the existing options dialog
- use the red icon (next to Lazarus top leftin the shot), put it next to the relevant item in the treeview (would be Environment/Files), and expand the treeview so it shows the (first) problem area
- use that same icon to the left of the "Lazarus directory (default for all projects)"
- draw the background colour of that control red instead of white, with yellow letters instead of black
- Move the error/status message ("Error: directory not found", on the bottom left now) to top right, next to the filter control, and make it wide and as high as the filter control.
Move the other controls ("max recent files etc") down and separate the two sections by a line or whatever.

19.08.2012 15:58, Reinier Olislagers ?????:

This "overlapping" is made on purpose. The idea behind Initial Setup is exactly to emphasize the most important options to unexperienced users, because Options dialog has heaps of options which can cause confusion.

The setup dialog, is meant to have only a very few settings. I do not think we should display the full option dialog.
By showing only selected settings, it is much easier for the user to see what needs to be fixed.

At the moment the only thing, that I think should still be added is the language.

So I do thing, they will need to stay 2 individual forms.

---

Still maybe some code may be shared. If so it must be moved to a new unit that can be used in both places.
The option does have error checking. But the setup error checking for the paths may be more user friendly...

About the automatic search. I would not want the search for possible locations be started each time I run the options (On my system - having many installations - it takes 30 seconds)

---

So there are intentional differences, and they should be kept.

If you want to indicate pages with errors in the options, then do so in the tree.

Either highlight/color the tree nodes. Or add a top-level node "Faulty Settings" (only shown, if child-nodes)
I am for the highlight/color.

Also, a better Idea is to have setting-modes: Normal / Advanced Then in normal, there would be less settings.

It may also be an option, to call the setup dlg, from the menu ...

While I see your point, now the user gets 2 different visualisations of the same settings. I'd prefer a single layout so the user starts to recognize things. The user will probably see the complicated options menu sooner or later anyway - keeping him away from hit by providing a pseudo options screen may increase the total confusion...

I think Martin's idea about highlighting errors or a "faulty settings" filter will not take away that complexity completely, but help steer the user to fixing serious problems first.

Yep. It shows the user a single view of the options, and helps him learn to navigate the options hierarchy.

Also, a better Idea is to have setting-modes: Normal / Advanced Then in normal, there would be less settings.

Agreed.

Martin wrote

On 19/08/2012 12:58, Reinier Olislagers wrote: About the automatic search. I would not want the search for possible locations be started each time I run the options (On my system - having many installations - it takes 30 seconds)

It could be called just before closing the form in a validation routine. If your settings are correct, this search will immediately hit an existing file and stop, right? Then it won't take much essential settings are wrong, I'd rather know this before they can do harm...

So there are intentional differences, and they should be kept.

See my comments in the other part of the thread about why I don't agree ;)

For a new user lazarus is now showing a form that is definitely much easier to understand than the full options window but he has no way to get back to that easy form when he has second thoughts (an old compiler selected for example). Perhaps merge the 2 forms into one options form with a basic and an expert setting?

It could be run when in basic mode only. For those users it can be useful.

Ludo

The 2 dialogs are different things.
- The setup is a wizard-like dialog
- The options is a normal direct access to all options dialog

There are other applications, with have a wizard and and option page.

Often though the wizard is part of the installer. But that makes no difference, it still holds that the wizard gathers the same info, that is also in the option dialog.

I am very much in favour of keeping both. And each with the layout it currently has.

Then the option dialog, could offer a way of running the wizard again.

I do see your point; with reference to my earlier arguments I just think the wizard-like functionality should be implemented in a different way (e.g. your basic - versus advanced - options dialog with highlighting incorrect settings).

Let's agree to disagree ;)

Exactly. And if your option screen has a simply basic/expert toggle you don't have to look for a "run install wizard" button somewhere in an overly complex options screen.
Having the same dialog with 2 "faces" makes sharing code also easier.

Ludo

Maybe, but maybe not so fast. WE need at least to agree, what we disagree about.

If the setup is kept as it. That does not mean that the options can not be improved. They very much still should be improved.

Only merging the setup into the options is not the way to go. Not even as afirst step.
- Adding normal/advanced to the options is a good way.
- Highlighting pages with errors is also a way (and not limited to the setup part)

Adding a way (either in the menu, or button in the options) to re-run the setup is also an idea.

Also the installer should create a start-menu entry to start Lazarus in setup mode. That will come, if language is added to setup. It allows to recover a screwed up config.
For this one could also add, to reset al window positions to default, or reset the keymapping... though care must be taken not to add to many things

Ludo Brands wrote

Having the same dialog with 2 "faces" makes sharing code also easier.

The "faces" (GUI layout) and the sharing of code are to entirely independent issues. And one should not influence the other.

Code can be shared by extracting it into a GUI independent unit.

So the sharing of code is no argument, when it comes to the design of setup and options.

That's always handy.. ;)

If the setup is kept as it. That does not mean that the options can not be improved. They very much still should be improved. Only merging the setup into the options is not the way to go.

Disagreed ;)

- Adding normal/advanced to the options is a good way.

Yes, that could be done.

- Highlighting pages with errors is also a way (and not limited to the setup part)

Agreed.

Adding a way (either in the menu, or button in the options) to re-run the setup is also an idea.

I'm neutral about this one.

Also the installer should create a start-menu entry to start Lazarus in setup mode. That will come, if language is added to setup. It allows to recover a screwed up config.

Yep, we talked about that. Agreed.

For this one could also add, to reset al window positions to default, or reset the keymapping... though care must be taken not to add to many things

Do you mean via command line options? Or as a GUI option inside the setup dialog?

In the setup dialog.

But maybe only if used with a recovery option.. Not sure yet. Just an unfinished thought...

Yes, but visual consistency for the user is an argument. The setup dialog presents the setup settings differently versus the options dialogs: different category names, different use of tabs versus, actually AFAIR the screen layout is very different.

This difference means that the user won't be able to apply his knowledge about where the options are, how they/their categories are named, to the options dialog.

The counter argument is of course that it is a wizard, designed to simplify things for the user.
Well, as a thought experiment, try cutting down the options dialog until you only have the settings currently in the setup dialog.

Then apply the visual indicators (red icon etc) as discussed.

What do you get? Setup dialog functionality with (mostly) the visual layout of the options dialog.
Users can quickly fix their problems, and they get used to the relative positions/feel of the options dialog.

To clarify my point. I only speak about the visual/GUI design part.

If functionality from the setup (such as searching for alternative locations (probably on user request only)) can be merged and used within the current option dialog, then that is not an issue. Same for improvements on the error detection.

---------
AS for the GUI design.
Just selecting examples, similar for other elements......

The setup brings options (like fpc and gdb path) closer together. It does that by hiding all other related options.

In the option dialog, there are more settings, and the gdb path should be with the other debug settings.

That makes it (to me) impossible to have a setup-like access to it.

If we tried to merge the setup to the option, I can not see how that would work, without having the gdb path in 2 different locations. And I can not see how that would help.

Yes, understood.

AS for the GUI design. Just selecting examples, similar for other elements......

<snip>

That makes it (to me) impossible to have a setup-like access to it.

Then why not use the basic (vs advanced) options screen. Presumably the basic screen would group those elements anyway?

Well its wizard versus option. This is not uncommon...

However, if the actual name of an option, does differ, then maybe the name should be corrected. That is independent of merging the two.

This difference means that the user won't be able to apply his knowledge about where the options are, how they/their categories are named, to the options dialog.

As for the option categories.

If they can be named better in either of the 2 forms, then make suggestions.

Still yes there will be a difference. The setup has only a few selected settings, so it can group them different. That can not be done in the options, because the options should show ALL settings.

The proposed merge (picture) added a 2nd set of categories (copied from the setup) to the option.
That means, that in the option, one and the same setting will then be accessible via 2 different ways. That is the most confusing concept of them all.

Then the setup has a tree like this

Environment
Files
Debugger
General

instead of one page for each setting. I doubt that is helpful.

The idea of cutting them down, includes the ability to be able to display them in a less compact (and therefore different) way.

In the option dialog the amount of settings does not allow for that. In the setup, it is possible.

And IMHO by making this change in setup, the setup becomes easier to use.

Since the change can not be applied to the options, I see 3 ways only:
- current / difference
- setup will be putting more on each page, become harder to use, but looks more like options
- we try to change the option to be like the setup, less settings per page (1 or 2 maximum) . This will mean to have 10 or more times as many pages/entries in the tree.

------------------------

As I said already, for people who can't find the settings, havwe a "run wizard" button (next to the help button, so always available)

That solves the issue too.

Because it hasn't been implemented

The basic would probably not put fpc and make on different pages though (which the setup does).

The easiest way to implement it (without duplicating everything) is to filter out certain options (visible := false), and, or hide some pages completly.

I am not sure, if re-grouping options into new pages, will be a good idea.
- hard to implement, unless by copy and paste
- not helping users, if they go from one to the other, and nothing is where it was.

Note: the basic/advanced must then also be supported by packages (e.g. Jedi)

Then we can stop the entire discussion right now as it's all about changes that haven't been implemented.

Yes, or disable (gray out) those controls so they won't be editable but will be visible.
Although this does clutter up the GUI, it does show the user where everything is.

I am not sure, if re-grouping options into new pages, will be a good idea. - hard to implement, unless by copy and paste

Could be.
Surely maintenance of basic+advanced must be easier than maintaining setup+options?

- not helping users, if they go from one to the other, and nothing is where it was.

Well yes. How do you think users feel now between setupoptions? The difference between basicadvanced will be less due to identical layout f screen.
Also see my gray out idea.

Note: the basic/advanced must then also be supported by packages (e.g. Jedi)

Or packages that don't implement basic won't be showed in the basic options screen.

NO. That was a quick MOCKUP, an IDEA of how things COULD look like, not my idea of how they MUST look like. Please read my initial post again, and especially my response to Juha.

After that, we got Ludo & your idea of a basic versus advanced options dialog, which would fit in very well as well.

Since the change can not be applied to the options, I see 3 ways only: - current / difference

You mean leave things a is?

- setup will be putting more on each page, become harder to use, but looks more like options

This is the way things seem to be going...

- we try to change the option to be like the setup, less settings per page (1 or 2 maximum) . This will mean to have 10 or more times as many pages/entries in the tree.

I'd agree that wouldn't help.

Reinier Olislagers wrote

> Because it hasn't been implemented Then we can stop the entire discussion right now as it's all about changes that haven't been implemented.

Yes,

Its discuss first, then implement (If someone volunteers)

Better, than someone writing a lot of code, just to hear, it wont be used...

Of course about the will or wont be used: I am voicing my opinion. If other members of the development team have other opinions, they may accept patches, that do not have my liking. That would be perfectly normal.

No they should be invisible. Or they are misleading

Currently from a maintenance view, there is no issue. It's easy

Normal/ advanced can be based on the same code, that is used to search for keywords. All items, just need a tag, if they are advanced.

So it may be very easy to do. With almost no extra code

<snip>

Yes, I understand and agree, but that was not the point. This:

... just seems a very weird response. Perhaps it's just me.

Apart from that, I think I understand were you stand, and I think I've made my arguments clear. If not, let me know :)

Thanks,
Reinier

Well I do not see, how you want or can solve it?

the option dialog (even in a none advanced mode) will always have more options than the setup. So it needs different grouping.

- The setup is easiest to understand, with the one page per setting.
- The Option just can not do one page per setting.

How to solve that?

Yes, in the context of GUI design setup vs option

This does not block normal, advanced or other improvements

> - setup will be putting more on each page, become harder to use, but > looks more like options This is the way things seem to be going...

Not following.

I always advertised the "one page per setting" in the setup, as the best way.

But I also said, it is only good in the setup, where there are only very few settings. In the options, there must be multiple settings per page.

BTW, independent of this discussion: Some option pages are overloaded, and should be splitted. But the splitted pages still have several settings per page.

Good. One more point on the agreed list.

Just don't do one "page" per setting.

Use visual indicators, such as red text, icons, red background, a descriptive text on the top right that says where the problem is. Use hints/tooltips to indicate what an option is for. Use a "Next error" button on the bottom right if there are errors. On pressing, expand the relevant treeview, move focus to problematic control.

Accept that users will sooner or later see the "big" (advanced or whatever) options screen anyway and let them get used to a similar layout.

Then I understood corretly.

Oh I must have misunderstood. I interpreted it as there becoming more settings to check (now debugger, tomorrow language... etc), not more on each page. Never mind.

+1

The purpose of the setup dialog is to check the most important environment options, to
- warn the user that the installation might be incomplete/wrong
- avoid starting the wrong IDE
- combine several warnings in one dialog

+1

So I do thing, they will need to stay 2 individual forms. So there are intentional differences, and they should be kept.

I would even say, there should be more.

The current setup dialog combines several messagedlg. There are some functions that checks many settings and may show a cascade of messagedlg (e.g. compiling, running, compiling the IDE). Maybe some of these messages can be combined too.

Mattias

...

Accept that users will sooner or later see the "big" (advanced or whatever) options screen anyway and let them get used to a similar layout.

Now we have a point, that we can disagree on.

I believe the "one setting per page" is a big advantage. And I believe it is well worth the difference between option/setup.

One possibility would be to use the same dialogue/form, but to have the bulk of it "greyed out" as not relevant until the full IDE is running.

I particularly like the setup dialogue's feature of displaying candidate Lazarus directories rather than everything. It would be nice if it could be extended to look at what versions of Lazarus were in "peer" directories, and to work out what compiler version each expected- provided this could be done efficiently.

I'm not sure if I understand you right.
The Lazarus directory must fit the currently running IDE. The compiler must fit the FPC source directory.
The compiler does not need to fit the IDE.
The compiler must fit the IDE only when recompiling the IDE and that depends on the installed packages. They contain IFDEFs for that.

Mattias

But in most cases, particularly when considering the less-experienced user who doesn't know his way round the dialogues, the compiler version to select will be either the one that was used to compile the IDE or the poorly-defined "appropriate versoin" (i.e. like 2.6.0 is the appropriate version for 1.0). I think this could be usefully presented as (at least) a hint.