Hi all,

The page in the "Project options / Compiler options / IDE Macro Values" was replaced with a more powerful page "Additions and Overrides".

Things that you can do now, which were not possible before:
- Append compiler options to packages without touching the lpk.
- Changing the output directory of packages without touching the lpk.
- Define IDE macros only for some packages or only for the project.
- Append compiler options for all projects with build mode "debug".
- Change the package(s) output directory of all projects and packages with build mode "release".
- Append compiler options of third party projects and packages without altering their sources.

See here for details and screenshots:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Additions_and_Overrides

Mattias

Amazing!

Marcos Douglas

Very nice :)

A few questions:
- this seems to make "custom options" in "other" redundant. The "show options" button becomes more important than ever to figure out what the options will be. Is "custom options" still needed?
- will the "compiler options" screen ("show options" button) be expanded to show what the resulting compiler options will be for packages?

thank you very much for this addition

Ludo

Nice work!

I have build modes defined as default for new projects. Would this interfere with this update?

On the other hand, it seems that some options apply to all build modes irrespective of their enabled status. With Linux and Win32 build modes defined, compiling an empty project for Linux uses the following options:

-MObjFPC -Scghi -O1 -Tlinux -g -gl -vewnhi -Filib/i386-linux -Fu/home/me/Programs/lazarus/lazarus-svn/lcl/units/i386-linux/win32 -Fu/home/me/Programs/lazarus/lazarus-svn/lcl/units/i386-linux -Fu/home/me/Programs/lazarus/lazarus-svn/components/lazutils/lib/i386-linux -Fu/home/me/Programs/lazarus/lazarus-svn/packager/units/i386-linux -Fu. -FUlib/i386-linux/ -l -dLCL -dLCLwin32

and fails:
win32/win32wsdialogs.pp(32,3) Fatal: Can't find unit Windows used by Win32WSDialogs

Inherited for LCL:
unit path =
/home/supra/Programs/lazarus/lazarus-svn/lcl/units/i386-linux/win32 custom options = -dLCL -dLCLwin32
LCLWidgetType = win32

Inherited for LCLBase, LazUtils, and FCL do not show win32 related stuff.

Stephano

Yes it definitely is.

I really don't share your enthousiasm about this new dialog;

However powerful it may be, the options handling of Lazarus is getting more convoluted by the day. It is KISS reversed. Not to sound entirely negative: The new dialog does look nice and modern.

But I find "Custom options" both simple and effective for daily use, so please do not get rid of it.

Michael.

Looks like a really nice update.

Sorry for my ignorance, but
- what exactly is meant by "target" and how I choose between multiple targets ?
- Why can multiple "target" lines be present at the same time ?
- What is the use of the green vs the white macro activation check box ?
- I suppose, the result of this page can be stored as a "build mode", but I don't find how to create, store or load a "build mode"

Thanks,
-Michael

[...] A few questions: - this seems to make "custom options" in "other" redundant.

The custom options in "other" has a big memo, the new only a short edit. When this is improved in the new view, then the old can be merged.

The "show options" button becomes more important than ever to figure out what the options will be.

... and the inherited page became more important to find out, where the options are coming from.
Maybe the "inherited" content should be moved to the "show options" dialog.

Is "custom options" still needed? - will the "compiler options" screen ("show options" button) be expanded to show what the resulting compiler options will be for packages?

Every package already has its own "show options" button. But maybe a select combobox could be added to the "show options" dialog, so you don't need to switch the modal dialogs.

Mattias

[...] I have build modes defined as default for new projects. Would this interfere with this update?

No.
If you don't use it nothing changes.
It will start interfering, when you add some options to the IDE configs.

What is the host operating system? I guess Linux.
What build mode is active?
What shows Project Options / Compiler Options / right side, top, rightmost edit button '...' / Show differences between modes?

Mattias

Looks like a really nice update. Sorry for my ignorance, but - what exactly is meant by "target"

See here:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Targets_of_build_options

I added a sentence to make it more clear.

and how I choose between multiple targets ? - Why can multiple "target" lines be present at the same time ?

See link above.

- What is the use of the green vs the white macro activation check box ?

See here
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Colors_in_the_matrix

- I suppose, the result of this page can be stored as a "build mode",

Please read the wiki.

but I don't find how to create, store or load a "build mode"

Juha has removed the old build modes page some weeks ago. Its features are now in the header above each page of compiler options. This is not yet documented in the wiki.

Mattias

My default build modes affect only the OS and widgetset, and the widgetset part shows up in the new dialog.

Yes

What build mode is active?

Build mode for Linux

What shows Project Options / Compiler Options / right side, top, rightmost edit button '...' / Show differences between modes?

It seems options are messed up somewhere:

Win32 differences (with Linux as reference):
Code/TargetOS=win32
Has matrix option IDEMacro:LCLWisgetType:=gtk2
Does not have matrix option IDEMacro:LCLWisgetType:=win32
Linux differences (with Win32 as reference):
Code/TargetOS=linux
Does not have matrix option IDEMacro:LCLWisgetType:=gtk2
Has matrix option IDEMacro:LCLWisgetType:=win32

I switched the order of the widgetset options using the up/down arrows, and all compiles well. If I switch the order back, the error shows up!

Stephano

That would change the purpose of the "show options" dialog completely. Currently it shows the complete list of compiler options applied when you build the project with the current configuration. The "were are options coming from" is something completely different IMHO. I use a copy of the content of the options list in the "compiler options" to create build shell scripts for projects that don't need lazarus installed.

BTW, just noticed that "custom options" are not listed in the "inherited" window although they are on the same level as the ones in "Additions and Overrides" which are listed (lpi in my case).

Ludo

P.S.: With "it" I meant the new page.

> It will start interfering, when you add some options to the IDE configs. My default build modes affect only the OS and widgetset, and the widgetset part shows up in the new dialog.

The old IDE macro page was merged into the new page. The internal structure for macros has changed. The loading function converts the old macros to the new format. Maybe there is the bug.
The LCLWidgetType macro with value 'win32' should be under 'stored in project', 'targets:*' and enabled only under the build modes, where they were before.
That means the LCLWidgetType:=gtk2 should only be enabled for build mode 'Linux' and the LCLWidgetType:=win32 should only be enabled for build mode 'Win32'.
What do you see?

It seems the enabled states of the macros are wrong.

I switched the order of the widgetset options using the up/down arrows, and all compiles well. If I switch the order back, the error shows up!

Mattias

Exactly what you described. I attached a snapshot just in case.

Stephano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: options1.jpg
Type: image/jpeg
Size: 47101 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130607/39215d8a/attachment-0001.jpg>

Probably you misunderstood me. I suggest to move the inherited treeview to the show options, so you can see the final options plus where they came from.

[...] BTW, just noticed that "custom options" are not listed in the "inherited" window although they are on the same level as the ones in "Additions and Overrides" which are listed (lpi in my case).

The "inherited" window shows the options inherited by packages ("Usage / Custom options") and all things added by the new "Additions and Overrides". Except for the macros. Maybe the macros should be added too. The first node 'all inherited options' shows only the sum of the packages. Maybe that should be extended by the project additions.

Mattias

Mattias Gaertner wrote

> and how I choose between multiple targets ? > - Why can multiple "target" lines be present at the same time ? See link above.

Great !
Now the packages used in a project can easily be compiled with different options.

> - What is the use of the green vs the white macro activation check box ? See here http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Colors_in_the_matrix

I see now a description a bit above this location: The boxes correspond with the "Default", "Debug", "Release" ... Headers, that denote the available Build Modes (I have "Default" and "Custom Drawn" here)

Juha has removed the old build modes page some weeks ago. Its features are now in the header above each page of compiler options. This is not yet documented in the wiki.

I see.

Thanks,
-Michael

Yes.

Is there something unclear?

Mattias

Mattias Gaertner wrote

Is there something unclear?

Not to me any more.

I just failed to see the strict "matrix" correspondence between the check boxes and the build-Modes which are specific with the user's installation and thus can't match in the Wiki example. So some additional words might be useful, especially as multiple build modes are not exactly commonly known (not yet much used at the moment).

-Michael

Can you give an example, how to phrase such a sentence?

Mattias

Fixed.

Mattias

On 06/07/2013 01:41 PM, Mattias Gaertner wrote:

In fact this is a three dimensional matrix of check-boxes, which of course is flattened in the interface. This is not that clear on the first view for "newcomers".

Can you give an example, how to phrase such a sentence?

E.g.:
Below the picture "The page contains a matrix of build options":

The multiple "custom options", "output directory", and "IDE Macros" setting within any target can be switched on and off separately for each build mode.

Thus, for each target, there is a Matrix of enabling check boxes.

The vertical words in the header show all the Build Modes that are currently defined, and by this they denote the column in the matrices.

At the right side of each row of any matrix, the description of the type (such as "Custom"<Option>, "OutDir", or "IDE Macro" ) and the value of the option to be enabled, is given.

-Michael

Mattias Gaertner wrote

Hi all, The page in the "Project options / Compiler options / IDE Macro Values" was replaced with a more powerful page "Additions and Overrides".

Thanks, looks quite good and fairly intuitive for such a complex featureset!

Confirmed. Thanks!

A suggestion: Since the Additions and Overrides don't apply to a particular build mode, I suggest that the build mode selector at the top be hidden when this page is selected in order to prevent confusion for newcomers.

Now concerning the practical usage:
I have build modes for Linux and Win32 defined as project defaults. At times I even add modes for other platforms. The build modes toolbar button provides a quick way to switch the target platform. Now the obvious way of integrating debug/release additions is to double the build modes so that the quick selector is still used. Is there some better way that allows the debug/release additions to be independent so that the build modes are not doubled while still having a quick switch selector (like an independent debug/release selector)?

Stephano

I have mixed feelings about this new grid GUI because its usage is not obvious or intuitive.

Now build modes can be created in a GUI that is visually above the affected settings pages.
Earlier there was no visual hint of affected pages and one could only guess what happens. Now it is more intuitive.
The plan is to have <All build modes> selection that allows you to edit a setting for all build modes at one go. This is most usefull for the paths. The GUI could disable the settings and pages which don't support editing for all build modes.
Initially maybe paths only will be enabled.

This new grid again screws the logic. It is a page side-by-side with other pages, and below the build mode GUI, yet it affects all build modes.

Solution 1. is to show the page only when the future <All build modes> is selected.
For a single build mode "Macro Values" and "Other" pages would be shown instead (and maybe something else).
The drawback is that a user always has to select <All build modes> before using the grid. Some users would not even notice the whole feature.

Solution 2. is to make a new category branch in the options tree for "Additions and Overrides", beside "Compiler Options". It would not be under the build mode GUI visually any more, and its versatility would be emphasized.

Solution 3. ... something else ...

This grid is good by itself. It allows doing things that are very difficult otherwise.
I just want to have the GUI as intuitive as possible.

Juha

With the build mode selector you select the active build mode, i.e the green cells.
With the edit button you can add, delete, reorder and rename build modes.
In other words: you need those things.

If I understand right, you have 2*2=4 combinations. Beforehand you had to set each option multiple times. For example the Linux options to all build modes for Linux (Or use conditionals). You can now create the options once for Linux, Win32, Debug and Release and you only have to enable them with the checkboxes. So IMO that should make setting up such combination build modes easy enough.
If you have lots of combinations I recommend to use conditionals.

Mattias

Thinking about it, one simple way to provide for that would be to add a conditional dropdown list to each option line (any, debug, release), and add a debug/release quick selector toolbar button.

Stephano

patspiper wrote

A suggestion: Since the Additions and Overrides don't apply to a particular build mode, I suggest that the build mode selector at the top be hidden when this page is selected in order to prevent confusion for newcomers.

That is one possible sulution, too.

Juha

Thanks. I added them as Overview.

Mattias

What is the difference to
Any = check all
debug = check only debug
release = check only release
?

and add a debug/release quick selector toolbar button.

Mattias

To switch between build modes, I don't go to compiler options. I just use the selector toolbar button next to the run button and select the build mode, which is extremely convenient.

My suggestion is to add another quick selector toolbar button in the IDE toolbar that allows the selection of debug or release. At the same time, every option line in the additions page would have a debug/release/any dropdown list that indicates whether this option line is applied or not, based on the debug/release selector toolbar button. If the option is marked debug, it will be applied to the build mode (provided it is checked for that build mode) if the toolbar debug/release selector is set to debug. The same applies to release. Any means that it disregards the debug/release selector. In other words, the combination of the current checkboxes and the debug/release/any dropdown list dictate whether that option will be used or not.

Let's say I select Linux build mode and 'debug' using the 2 quick selectors in the IDE toolbar, then only the options checked for the Linux build mode and having the dropdown list set to 'debug' or 'any' take effect. Changing the debug/release selector to release will apply only the options checked for the Linux build mode and having the dropdown list set to 'release' or 'any'.

Stephano

I forgot to mention that the purpose of this is having an extremely quick and simple access to changing targets and debug/release states when building a project. The build mode details are defined once, made as project defaults, and forgotten about.

IIRC, Delphi provides a quick debug/release setting.

Stephano

I have mixed feelings about this new grid GUI because its usage is not obvious or intuitive.

True.
But that's mainly because it's tasks are not intuitive. It provides the flexibility needed by experts. So it's an advanced or expert page.

Now build modes can be created in a GUI that is visually above the affected settings pages.

Yes, that's nice.

Earlier there was no visual hint of affected pages and one could only guess what happens. Now it is more intuitive.

Well, that is your opinion. Newbies have no idea what a build mode is. Now the topmost thing they see is build modes. That's not more intuitive. It is easier for experts.

And what if paths differ?
Don't get me wrong: Adding a directory to a path in all search modes is a needed feature. I'm just not convinced that an <All build modes> view is the right way. For simple values like boolean and integer it works in the Object Inspector and it will probably work in the compiler options as well. But I doubt that it works for non atomic values like search paths.

This new grid again screws the logic. It is a page side-by-side with other pages, and below the build mode GUI, yet it affects all build modes.

Actually most operations in this page affects only a few build modes. The difference to the other pages is that you don't need to switch the active build mode to change something.

Solution 1. is to show the page only when the future <All build modes> is selected.

All the feature requests I saw so far and that led to this grid view were about options that are applied to a single or groups of build modes, never to all. See the 2*2 build mode example of the related thread.

Intuitive and flexible bite each other.

Ideas:

Remove the "inherited page" and add its content to the "show options" dialog. One page less is more intuitive. And the user can see in one dialog where the final options originated.

Find a way to let the user use all FPC options. At the moment the user has to know the fpc options and add them to the custom options. It would be nice if the custom options have some tools to help here.

Fill the target OS/Processor/CPU comboboxes automatically.

Mattias

Debug/Release, Linux/Win32, gtk2/qt, EnableThis,DisableThat Many people need different groups.
I support adding tool buttons for that, but they must be freely definable.

IMO this is the opposite of intuitive.

Mattias

[...] IIRC, Delphi provides a quick debug/release setting.

How many build modes has Delphi?

Mattias

Mattias Gaertner wrote

I added them as Overview.

Hopefully this is kind of English ;-)

-Michael

i recall working with at least four different build modes in the last year or so... especially when working on the script i wrote for updating lazarus and using the default build modes that come with...

clean up + build all
normal ide
debug ide
optimized ide

yes, these are apparently for the IDE but i also had them, at one time, for each of my "projects" i was working on... until that section of the configurator was disabled... i use the term "projects" in quotes because they were projects for me but not projects (lpr) in lazarus... they were and still are mostly just individual pas files connected together by a few uses lines...

i rather miss the above, too... it was very easy to switch from debug mode to normal or optimized and then compile a new executable... it made it so much easier for me to compile four flavors of the same executable for testing and distribution if necessary...

of course, the above are only the default ones that come (came?) with lazarus... one can easily add their own and name them whatever they want with their own settings...

+1

But then the build modes interface design could present a challenge.

What's not intuitive in an 'applies to' column in the options grid?

Stephano

One which is practically equivalent to none ;)

I mentioned the Delphi release/debug setting because it would be similar to the release/debug quick IDE toolbar selector that I proposed.

Stephano

I don't know what logic you have here. Delphi release/debug settings are configurable, they are not hard-coded. In essence they are build modes.
Can more of them be added? I must look at Delphi again sometime.

Their GUI allows editing "parent" settings which both release and debug settings then inherit.
I only remember that the GUI is not very intuitive either. It is difficult to make an intuitive GUI for such a complex thing.

Juha

Oops! The Delphi I had in mind was D7, and this was my vague recollection of it. I could be mistaken too.

I liked Mattias' idea of having different configurable groups, though I am not sure how a proper interface would look like.

Stephano

patspiper wrote

Oops! The Delphi I had in mind was D7, and this was my vague recollection of it. I could be mistaken too.

Right, Delphi7 does not have release / debug settings, and IIRC has no quick selection for such things.

Juha

Uhhh... It requires some kind of grid GUI again with paths split into rows and build modes in columns with selection checkboxes, and that would be only for one path setting (like Include files).

Yes, that is good.
"Inherited" is in a wrong place because you cannot change anything there.

Find a way to let the user use all FPC options. At the moment the user has to know the fpc options and add them to the custom options. It would be nice if the custom options have some tools to help here.

It is good, too. You requested this already last autumn but I have not done anything for it.

Juha

Kudos and more....

IMHO the "stored in" could be a "dropdown" (like
custow/ide-macro/outdir) in each row.
then the actual matrix, would have less disruptions.

Each "Target" would then appear only once. And the "stored in" would be sorted (and thereby grouped) in each target block.

You have two types of build modes. That's less intuitive than one type of build modes.

Mattias

Well, that would be a very flexible solution.
But that is only useful for power users. All others would suffer. So, maybe we have to provide a normal and an expert view. Same for the custom options: Some need a simple memo, others need a matrix.

Mattias

The order of the three is fixed. It goes from settings for all projects, over the shared options of one project, to the user specific options of one project.
Theoretically there could be three checkboxes to hide and show the three storages, but IMO that is more confusing.

Each "Target" would then appear only once. And the "stored in" would be sorted (and thereby grouped) in each target block.

The order does matter and putting an option in the wrong storage can have serious effects. For example if you accidentally put a session option into the project, you will break your team mates code. If you accidentally put a project option into the IDE you might break your other projects.
IMO the storage and scope of an option must be made very clear to avoid such accidents.

I will add a todo to let the IDE warn, when you compile a project that changes the output directory of packages.

Mattias

If I may chip in, defending the normal users:

I can see why you're making this new page.

But this new page only makes sense when you use different build modes: For build modes, I think it is an elegant solution that lets you see in one glance, what options are used in the various modes.

But build modes I consider something that only experts or powerusers will use, those who do many builds for different targets/platforms.

The normal, casual user does not need this.

The additional specification of 'where the option is stored' is powerful, but adds yet another layer of complexity, another source of misunderstandings, and necessitates almost a dialog 'where did this or that option come from'. The additional option of 'to what to apply an option': same thing.

However, for the casual user, this is complete overkill.

For a casual user, the 'old' interface is clear, simple and accessible. There is no doubt where an option came from. All options are clearly visible. (OK, you may need to look on which page it is located)

For those options that have no support in the IDE, the custom options memo is there. Please do not remove it. For example, I never understood why there is no support for managing "defines" in the IDE, so I must resort to using that.

I am writing this email because I am afraid the lazarus devs may get 'carried away' and elevate the idea of build modes to a status where it dominates the options UI.

The point is that they make the UI more difficult to understand.

Hence my plea: For a casual user, build modes are an unnecessary burden. Do not build the entire compiler options management around it.

I can see why you want them, I can see their use.
But please make sure you don't push them onto people that have no need for it, because it no matter how useful, they do make things more complicated to use.

That said, I think the new page is a better idea than the solution Delphi used, which - for a casual user - is simply horrible to understand and there is no way to get rid of it in Delphi.

Please do not make the same mistake.

Michael.

...

In the light of this, maybe a few ideas.

The new grid is indeed an advantaged page. A concept that already exists for the editor-mouse-setings. A page normally hidden, by a page offering a few pre-defined defaults.

1) Maybe the entire grid, should be in the build-mode dialod (the dial[og that pops up on top of the options, if the [...] next to the dropdown is pressed). That dialog would then need several pages too. Yes, I know, it highlights the "current b.m." and therefore makes use of the drop down. But that is not important....
On the other hand, if a simplified (see 3) page exists, then this could be nested as a sub-page)

2) It will become a bit (a tiny bit) more clear, if there are pre-defined build mode (debug/release). But that is a drop in the ocean.

3) Having pre defined buildmodes, there could be a simplified page, with common options (like the mouse opts). Those would probably all be stored in the lpi (the place I guess beginners would expect it, as all the other options go there too). So there could be things (all acting o the currunt B.M>, as do all other chek-boxes)) like:
- add/strip debug to/from ALL packages
- set optimization (0..3) to all packages
- define ( -dSYMBOL) for all packages
- set option for all packages
- modify out-dir for all packages (maybe this should be automated, using the build mode name, or some unique id derived from it)

Not sure, maybe, instead of "all packages" the user can select.

like the mouse-opts, this would create the correct advanced settings. (Though in the xml, it is stored as the 2pre defined setting)

One thing this can do, is it can force setting on packages. This can not be (easily) done with the other options.

--------------------
On that matter, I am not sure, if the IDE-macro page should be advanced too.

[snip]

-------------------- On that matter, I am not sure, if the IDE-macro page should be advanced too.

Definitely :-)

To this day I don't understand what its intended purpose is :(

Michael.

[...] If I may chip in, defending the normal users:

Were they attacked?

True. And he can ignore them, can't he?

Some new features for experts were needed and there were several possibilities to implement them. With the 'old' interface approach several pages would have been needed. That would have been awkward for the experts and more confusing for the normals. With the grid, a lot of expert features were combined in a single expert page. In a normal application I would have marked it 'expert options'. But since all programmers tend to think of themselves as experts, that would achieve nothing.

In short words:
A single expert page is hopefully less confusing (aggressive).

For those options that have no support in the IDE, the custom options memo is there. Please do not remove it.

+1

For example, I never understood why there is no support for managing "defines" in the IDE, so I must resort to using that.

How would you manage "defines"?

What about a checkbox to hide the build mode options or maybe 'Show advanced features'?
That checkbox itself would of course be disabled, when the project uses advanced features.

Mattias

It seems you mix two concepts of advantaged page here. AFAIK the editor-mouse-settings is rarely used. It is not rocket science, but it is used so seldom, that you quickly forget how it worked and you have to learn it again on every use.

If a user uses the features of the 'Additions and Overrides', he will probably use it as often as the other compiler option pages. Very likely more often than the 'messages' and the 'verbosity' page. So it is more like 'class helpers' or enumerators. Some people avoid them, some use them often.

Michael's point was that casual/normal users do not want build modes at all.

If you mean adding all the compiler options pages in the environment options: -1

- modify out-dir for all packages (maybe this should be automated, using the build mode name, or some unique id derived from it) Not sure, maybe, instead of "all packages" the user can select.

Can? Must! Some packages need their fixed output directories.

Forcing arbitrary options on packages is dangerous. The GUI should not invite to do such things. The new page allows this, but the comments in this long thread made me confident that normal users will think twice before using it.
Dangerous options should be hard to set.

-------------------- On that matter, I am not sure, if the IDE-macro page should be advanced too.

Yes. At the moment it contains the conditionals and the exported IDE macros.
Maybe the conditionals should be moved to 'Other'. And maybe the exported IDE macros could be moved to the package usage options.

Mattias

Mattias Gaertner wrote

> For example, I never understood why there is no support for > managing "defines" in the IDE, so I must resort to using that. How would you manage "defines"?

Maybe similar to how Delphi does it and how the path entries work: semicolon seperated entries. Maybe with the possibility to edit them through a list box based dialog as well.

Regards,
Sven

Why is a semicolon separated list like

EnableThis;EnableThat;DebugThis

better then

-dEnableThis -dEnableThat -dDebugThis

?

Maybe with the possibility to edit them through a list box based dialog as well.

A list with checkboxes could be useful.

Mattias

I was talking about the advanced mouse settings. They do require a lot of knowledge/understanding.
The normal one is easy...

Yes the usage frequency is difference. Mouse options are set once and never again....
Build modes (or at least certain aspects of it), are changed every once in a while.

Many aspects of the new page will nt be used, but by a very small percentage of people. For those the usage frequency is equal to that of the (advanced) mouse opts.

Michael's point was that casual/normal users do not want build modes at all.

I think differently:

A majority of users want an easy to use debug/release build mode. And it should be possible to set it up / edit it with very little effort.

Further:
With the problems that GDB causes on some systems, it is very important to be able to set all packages to the same debug type (and this may for some users be stabs, for others dwarf, and yet others it may be no debug info on packages.)

No I did not mean that.

I meant adding a simplified page in the project options, that allows to control a subset of the new functionality (very much like the mouse is a subset of the advanced mouse)

Then this is not an option for the simplified page. Not something the less experienced user can decide.

Ok. but that is a matter of selecting the correct subset, for the simplified package

"debug type info" should be an option that a user may force on any package.

"optimization level" most likely too.

"removal of -Criot / run time checks" (NOTE removal, NOT adding) should be save in most cases (to be honest, a package that requires it to be set would at least be suspicious... That is, it can probably be constructed, but as for real live...)

Same as in the "build IDE" dialog?

+1

At least there should exist a Lazarus version for beginners, that allows to e.g. evaluate Lazarus/FPC without studying usage instructions for a long time.

Don't forget the audience that should *start* using Lazarus, what's their background (previously used IDE...).

DoDi

Why is

./paththis;./paththat;./pickthis

better then

-Fu./paththis -Fu./paththat -Fu./pickthis

?

> Maybe with the possibility to edit them through a list box based dialog as well. A list with checkboxes could be useful.

Maybe, but one should be able to add additional ones as well.

Regards,
Sven

Michael Van Canneyt wrote

> On that matter, I am not sure, if the IDE-macro page should be advanced too. Definitely :-) To this day I don't understand what its intended purpose is :(

I am happy to read this.
I have though I am stupid while everybody else is comfortable with the IDE-macro page.

I share the concerns of the new UI.
The new grid is OK by itself but its current location makes an illogical GUI. The setting pages + build modes form a 3-dimentional space. The selected build mode makes a 2-dimentional "slice" of that space visible. The settings on different pages then affect only the selected mode. It is logical and comprehensible.
Now, the new grid GUI shows the original 3-dimentional space in a different form, but it is placed inside the GUI for the 2-dimentional "slice". It causes a recursive loop in the space, a black hole is created and the universe collapses! :)
... Ok, that was a little too much ...

Yes, we must somehow divide for "normal" and "advanced" views. My original <All build modes> was an idea for that direction. I think it is still a valid option.
It would change the settings pages heavily when selected. Your grid and IDE-macro page would show only for it. The GUI for paths could have a new grid etc.

One idea was to show the advanced settings only when > 1 build modes are defined.
It is not practical because the plan is to have Debug and Release modes by default. They are useful for anyone.

Another issue is that there is new data structure associated with the new grid GUI. It also duplicates some existing settings. So, not only the GUI is illogical but also the data structure behind it.

Juha

Conditionals come in 2 "flavors": -dEnableThis -uEnableThat

Ludo

An 'Advanced' (or 'Show advanced features') button/checkbox would be very helpful, since it gives a hint of increasing complexity and "here be dragons" without the melodrama that Mozilla arouses with that phrase before you enter their advanced settings.
As you imply, 'Expert options' is unhelpful, since the description of the option(s) should relate to the level of difficulty of the option(s) rather than the capability of the user.

Howard

That's the one I meant.

These are only guestimations. It's new, nobody knows yet, what will be used how often.

I doubt that. I know more people not needing build modes. They ship/install there programs as they have tested them.

We can discuss that topic in a separate thread.

I see a difference here. The normal mouse options has a few controls and can do a few things. The advanced mouse options have lots of tables and you can fine tune a lot of settings. OTOH the new 'Additions and Overrides' has a few cells with custom options, IDE macros and output directories. You want to add page(s) with many controls that can do less.

Let's discuss that in another thread.

"optimization level" most likely too.

Some packages fail with some optimizations. For example we have currently a few workarounds in the LCL to work with some optimizations.

"removal of -Criot / run time checks" (NOTE removal, NOT adding) should be save in most cases (to be honest, a package that requires it to be set would at least be suspicious... That is, it can probably be constructed, but as for real live...)

Do you want one checkbox to add -Cr- -Ci- -Co- -Ct-? What about the other checks?

Mattias

Why is a semicolon separated list like EnableThis;EnableThat;DebugThis

This representation allows to add values to the symbols, not only to define them (Delphi compatible!).

better then -dEnableThis -dEnableThat -dDebugThis

This representation allows to list *all* dependencies, which can be turned on and off by simply exchanging "-d" by "-u". No need to type the full name (correctly!?) to re-enable a definition.

> Maybe with the possibility to edit them through a list box based dialog as well. A list with checkboxes could be useful.

This would not allow for concrete values, checkable with {$IF...}. Unless the list entries (checkbox Captions) are editable like "DebugLevel=3".

DoDi

That is how I would do them.

Michael.

Not yet, I wish to make sure it doesn't happen in future :-)

Till now, more or less, yes. But they are already featured prominently, so the casual user already must ask himself 'What is this?'. He should not have to ask himself this question.

That is just the point I am trying to make:
Please make sure the build modes do not dominate.

The build modes are very useful for advanced users. I do not question that. I just want to indicate that the casual user IMHO should not be confronted with them. (or as little as possible)

Michael.

Search paths are special. They are changed by the IDE depending on host OS and when files are added/moved.
That's why search paths are not in the custom options and theoretically they can use any separator. It is just common to separate them with semicolon.
Custom options are passed untouched (except for IDE macros) to the compiler.
At the moment the IDE has nothing special for Defines, so they can be passed unchanged to the compiler, i.e. in the custom options.

Means?

Mattias

You can see the purpose here:
http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Changing_the_LCLWidgetType_in_Version_1.1_and_above

And here:
http://wiki.lazarus.freepascal.org/Macros_and_Conditionals#Overview

And comfortable for two or three modes.
But for more modes it is not good.

Note:
The matrix in the new page is nice, but that's only one feature. The more important features are useful even if you have only one build mode: The package additions and overrides and the "global" options.

I could add a checkbox to only show the current mode instead of all modes in the grid.

One idea was to show the advanced settings only when 1 build modes are defined. It is not practical because the plan is to have Debug and Release modes by default. They are useful for anyone.

I doubt that. See Michael's, Dodi's and my mails.

Another issue is that there is new data structure associated with the new grid GUI. It also duplicates some existing settings. So, not only the GUI is illogical but also the data structure behind it.

What structure is duplicated?
The old structure duplicated all settings for every mode. The new structure has no such redundancy.

Mattias

Ok, we are getting off topic here. But to follow your lead: What do they do, if there app fails in test? Eventually I would expect they need some form of debugln (either with writeln/debugln or in a debugger)
Such debugging needs an exe, that has debug info, or that has writeln or other logging.

I will agree people who have not even an idea, that something like a build mode exists, will of course do all those changes by hand each and every time. But that does not mean they would not benefit from build modes. If they would however benefit from it, and once they learn that such a help exists, then I do not see, why they should not want it.

I do agree, that as long as they do not have an idea that something exists, or even only could exist, then they may not desire it either.

Or do you mean they ship their release with all the debug info in it?

-----------------------
To get back closer to the topic:
never mind the exact percentages, or if the amount of people is sufficient to be called a majority... and never mind how or if to count people who do not want it yet, because they do not know it could even exist....

Do you think, it is agreeable that release and debug build mode are desirable, even for people who are not otherwise want/need to dig into the functionality of the new matrix (and may or may not have the knowledge/experience/skill to do so)?

Would it be beneficial to users to be able to have debug/release, without having to learn the entire new matrix stuff?

Please go, and count again: 48 dropdowns, each more than 10 entries....

Essentially less. Though more correct would be "with more controls, that can do less"

The complexity of a page is not only defined by the number of controls. In the grid, the complexity, is due to the amount of things you can do, with very few controls.

Having controls that a dedicated to a single function instead will simplify things. But since the amount of things that can be done is too big to have a control for each of those things, it is needed to pick some of them only.

So I still thing that the average user would benefit from a subset, of options. (If we miss one that turns out to be requested a lot, it can be added later)

> "optimization level" most likely too. Some packages fail with some optimizations. For example we have currently a few workarounds in the LCL to work with some optimizations.

usually due to compiler bugs.
Users can get the same issue in there own code, yet we allow them to change the opt level. And we also allow them to edit it in the package opts...

riot was only an example selection / should apply to all such checking...

I did not say a single checkbox. Though a single checkbox would be possible (for remove).
The point is, that if you have packages (including self made ones) that have those options enabled. then it may be helpful to remove those options for a release build...

It is possible to do that in the matrix. But the less experienced user would not be able to do that.

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

Conclusion:

IMHO the gap is too big. There is only

- use the matrix, but that requires high level of experience from the user
- do not use it

But not using it excludes you from all of it....

There is no middle option for the user that is trying to advance, but not yet that high up.

Mattias Gaertner wrote

> It is not practical because the plan is to have Debug and Release > modes by default. They are useful for anyone. I doubt that. See Michael's, Dodi's and my mails.

Which ones?

There are many mails from 2 Michaels...

Michael Van Canneyt wrote a mail, that I am not sure what exactly he meant was not needed by less experienced users.

build modes here are in context of target/platform. Looking at the last statement, I am not sure this includes/excludes debug/release

The normal, casual user does not need this.

"This" the new page, or build modes ?

For a casual user, the 'old' interface is clear, simple and accessible.

This old interface already had build modes.

Maybe Michael can clarify.

DoDi wrote

This again leaves the question if it is just the new features, or would include a pre-defined debug/release build mode.

In fact a debug/release build mode might help *some* (probably not a huge amount, but some) people, when it comes to the size of the exe....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130608/2daf3fd7/attachment-0001.html>

Indeed.

Allow me to use some capitalisation to make sure people understand :)

By default, there should be NO MODES WHATSOEVER.

The words 'build mode' SHOULD NOT EVEN APPEAR in the GUI by default.

It is a BAD IDEA to force even these 2 'debug and releas' build modes on casual users. The 'useful for anyone' just IS NOT TRUE.

Hopefully it comes accross like this :-)

I understand that some developers want build modes, but that is a long way from pushing this concept onto everyone, including people that have absolutely no idea what a "build mode" is.

Heck, even the concept of building is confusing to a PHP programmer.

You may be surprised, but Lazarus can be quite intimidating to the new user (and not because of it's name). Anything to make it less intimidating for the beginner is good.
That includes completely hiding an 'Advanced' feature such as build modes.

Michael.

...

Ok, answers my other mail.
I agree, it should be easier for beginners.

Yet I disagree.

To make it easier to learn for beginners, it should not hid build modes.

It should hide almost *ALL* the other options. What does a beginner care/know about smart-linking/optimization/debug-info ......

*INSTEAD* of all those options, there should just be "Build for debug" / "Build for release".

Only the advanced user, then gets to see the rest.

Heck, even the concept of building is confusing to a PHP programmer.

Yes, but php is (was, last time I checked) a scrip language). Ignoring internal details (like compiling to byte code), the programmer does not even know that something is "build"

Using a language, in which you do not build, does of coulse not go with build modes ...

:)

Yes. The topic is more:
Should build modes get more or less prominent by default At the moment there are at least two groups:
- Hide build mode options by default
- Add the two build modes Debug/Release by default

Yes.

I will agree people who have not even an idea, that something like a build mode exists, will of course do all those changes by hand each and every time.

What changes?

Yes. Or just use strip to reduce it somewhat.

No. See Michael's and Dodi's mails.

Would it be beneficial to users to be able to have debug/release, without having to learn the entire new matrix stuff?

As I pointed out to Juha:
The matrix is a nice-to-have. It only makes life easier for those having many build modes. I could add an option to hide it. The other features can not be substituted.

If debug/release mode is useful without Additions and Overrides: These are independent. I would say Debug/Release is another topic.

Right. Bad example. ;)

I meant that adding options to all is not enough. You need to add an option to all except or only to this and that.

Note:
The alternative of having many dedicated buttons and checkboxes is having a good tool to understand and edit custom options. We need such a tool anyway.

There are many ways of implementing middle options. Not all of them need duplicate controls doing the same thing.
For example hiding complicated parts, or adding wizards to setup common things, or add more labels and hints to explain, or good documentation.

Mattias

I love it!

It only makes life easier for those having many build modes.

It also makes it easier with no build mode.

Now I have a very easy way to compile SynEdit with other settings, if I compile my SynEdit testcase. I really do love it.

It is,

Though not 100% It may benefit.

People may not like stepping into the LCL

     S := MyFunc(Form.Caption);

To get to MyFunc, one must step into GetCaption, if it has debug info....

Strip debug info does not help, since project debug info is needed....

So some people may want LCL debug, others not...

Ok, But again, a simplified page would have:

- Only lpi storage => reduce a huge level
- Only selected options (with description, instead of fpc command line)
- - They could then have an "appy to package" that pops up a list of all package in that project, and the user can select.

It would be an intermediate solution

Note: The alternative of having many dedicated buttons and checkboxes is having a good tool to understand and edit custom options. We need such a tool anyway.

Yes, we need.
Not sure, if it is an 100% alternative.

There are still so many combinations of how to set things. The point of the intermediate page is to reduce them.

Maybe...
Not sure if it is less work...

Also the intermediate page would store the users selection, as it is represented there.

If the user ticks the box: no run time checks, that would today (in advanced) be -Cr- -Ci- ......

But if FPC adds a new one, -Ca then that is not included in the advanced. But in the "the intermediate chekbok was ticked" we can add that to it, and the user does not need to worry

Yes.

No.

Only the advanced user, then gets to see the rest.

Sorry. IMHO totally the wrong approach.

You think build modes must be a given. I say that they should be banned.

I just want to set some compiler options. That's it. I do not want to care about build modes and where each option is saved and whatnot.

Never thought this concept would be so hard to grasp.

Michael.

BUt you are not a beginner.

Maybe we should look at at least 3 groups:

- Beginners
- Advanced, that want build modes
- Advanced, that do NOT want build modes

I can understand, that within advanced users both groups exist. Both have good reasons...
So there is a need for build modes to be optional.

For Beginners, I think we agree: It should be as simple as possible.

Only what is more simple?

1) A user that changes no option ever, it does not matter.... But users do want to debug, yet they want small exe....

2) They need to go through a vast amount of options, to find 2 or 3 options of interest for them (e.g. switch on/off debug info, or strip it...) That is the current situation

3) Select from the 2 options debug/release. And they never even see the huge amount of options we have today.

I can not see, how for a beginner, 3 would not be mucheasier than 2.

Of course3 does not help the advanced.... but that is a different point.

4)
Maybe there is a way, with external debug info, that a beginner never needs to see any of the then build modes can be present, and experts can decide, if they want a defaut with no build modes (and ignore all the build mode stuff), or if they do use them.

I just want to set some compiler options. That's it.

All the options are still there, so you do not need to worry.

Even if there are a default of debug and release mode, you do not worry. You never switch them, you only use one. You edit all options like you have always done.

Besides: The default for new projects can be saved. Delete the 2nd build mode, save as default, and you never worry again...

Deleting one build mode once, is much easier, than having to create it from scratch.

So providing it for those (of the experts) who want to keep it:
- saves a lot of work for those who want it
- adds very very little for those who do not.

Of course, if there was a good wizard to create it, then by default it could be absent.

Great :D, i will test it soon.

On Fri, Jun 7, 2013 at 12:48 AM, Mattias Gaertner <

That is the whole point of the discussion, to make sure that this remains possible in the future.

Open options dialog,
set 1 or 2 options (heaptrc jumps to mind),
close.

Besides: The default for new projects can be saved. Delete the 2nd build mode, save as default, and you never worry again...

You again make the same mistake:
For this to work, you need to be aware of build modes and how they work.

So you are already in 'level 2' when proposing this concept.

But never mind.

I hope I made people aware that build modes are not the nec-plus-ultra for everyone, and that forcing them on people will not necessarily be met with enthousiasm from all. So you know you should tread carefully :-)

It is up to the Lazarus devels to find a nice solution.

Michael.

The build mode edit window, opened from the '...' button, could have a button for creating the Debug and Release modes.
They would not exist by default but one could create them with minimal effort.

Still, the GUI must be designed to be as intuitive as possible with build modes defined.
Mattias suggested an option for hiding the new grid GUI. The option must be more generic, affecting all necessary places. The <All build modes> was an idea for such option, but it could also be a checkbox "Advanced build mode editing" or similar. The same setting would allow editing paths for many build modes.

Juha

Yes, but this was about the different preferences of expert users. I did write about beginners in the part you did not quote.

Besides, as I pointed out above, you do not need to do that:

If there are 2 build modes, you can completely ignore that they exist.
- Edit options (applies to active BM)
- Compile, or do anything that uses the settings (use active BM)

So it just works.

The "besides" above was: If you are aware, and do not like it, then you can remove it

I hope I made people aware that build modes are not the nec-plus-ultra for everyone, and that forcing them on people will not necessarily be met with enthousiasm from all. So you know you should tread carefully :-)

Agreed

What about using quick build mode selectors? Currently, if you have more than one build mode defined, then a build mode selector button appears to the left of the run button in the IDE toolbar. Pressing the arrow part of that button will let you quickly select a build mode without going through the compiler options and/or build modes settings.

The way I see it is to have some configurable way (more on this later) that allows the addition of one or more of these selector buttons: 1- Beginner or advanced user that does not want to know about any of this: no selectors (could be hidden if pre-defined) 2- Beginner who needs debug/release: One debug/release selector (could be pre-defined for him)
3- Advanced user who needs full control: several selectors (user defined)

Example of (3) would be:
- TargetOS/Widgetset selector (for cross compilation) and a debug/release selector
- Widgetset selector (such as qt vs gtk or qt vs win32) and a debug/release selector

The advantage for the beginner would be that he does not need to go to compiler options, and provides for the advanced user a quick selection way once he has defined his selectors. Moreover, once these are used as project default, there would be minimal need to visit the build mode page.

As for the configuration, a user defined table/matrix dictates which build mode to use based on the combination of the selector groups' selections can be used. It just adds a layer of complexity that the non interested user won't ever need to see.

Stephano

You could use some three state control which provides the possibility to either define a define (-d...) or undefine one (-u...) or don't do anything at all (define is just not passed to the compiler in any way).

A list with checkboxes for defines is of no use if you can't add new defines (or delete them if you don't need them anymore).

Regards,
Sven

+1

Obviously.

Mattias

Zaher Dirkey wrote

Great :D, i will test it soon.

?Sorry, it is like a chemical formula for me, Now how can i run my project in debug with packages have debug info also, without touch the packages file?

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130610/06ce695d/attachment.html>

Once you add something, there will be a "Target" = "*" and " means al packages and project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130610/3f3c1259/attachment.html>

...

I understand well the importance of the difference storage types, and even more to store an option in the correct place.

But I still thing it is too disrupting.

About the order: The order would be kept.
* Targets: abc
- Store IDE: Custom -Cr
- Store IDE: Custom -Cr
- Store lpi: Custom -Cr
- Store lps: Custom -Cr
* Targets: *
- Store IDE: Custom -Cr
- Store lpi: Custom -Cr
- Store lps: Custom -Cr

Within each target, the order would be kept.
Instead of using a "in matrix group/header", each storage group could have a color

If there where 3 radiobutton at the begin of each row

I | L | L | M | M
D | P | P | o | o
E | I | S | d | d
| | | e | e
| | | 1 | 2
_______________
/ Targets: abc
| * | o | o | [x] | [ ] | Custom -Cr
| * | o | o | [x] | [ ] | Custom -Cr
| o | * | o | [ ] | [x] | Custom -Cr
| O | o | * | [x] | [x] | Custom -Cr

And each radio (column) had a different color, that would only show if the radio is set. Changing the radio, will change the order. That could be deferred, until the user ends editing the TArget.

---------------------------
Then the next thing is "Target", maybe that could be more descriptive "Apply to packages:"
"Apply to project [x], packages: '*'"
"Options for project [x] and packages: '*'"

With the storage as radio, if the grid is empty, an empty (dummy) "Target" could be displayed.

Since the name of that line contains the description, users may realize that they can set options for packages.

The "Target" header should allow right click, and offer a popup to add rows (idemacro, custum,...)

See here:

http://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_project_and_all_packages

Mattias

Does that mean the user can not see the final result until he closes and reopens the dialog?

And I don't see how the users can see that the storage takes higher precedence than the targets. Can you give an example for two targets?

Move the mouse over a target. The hint shows the targets as a descriptive sentence.
At the moment you can edit the targets in place.
A descriptive sentence can not be edited in place. How do you want to edit it?

+1

Mattias

No, of course not.
Technically the entry can be sorted immediately, but that may be annoying to some. So maybe i is better to only move it, if you leave the row...
Then again, I have no problem if it moves immediately.

And I don't see how the users can see that the storage takes higher precedence than the targets. Can you give an example for two targets?

My idea came from the understanding I got from initial layout. And that did NOT include recognising the precedence.
All I understood was that they are displayed together, because they share the same storage. There was/is no sign to me, that this also indicates a priority/precedence.

Then maybe a column with a numeric precedence?

Another idea: do not put the storage as a row header: have it as a fixed column:

________________
|IDE | /Target
| | [x] [ ] Custom
| | /Target
|____| [x] [ ] Custom
|LPI | /Target
| | [ ] [x] Custom
....

Then it is less disrupting to the checkbox columns

Looking at this, I would still not guess the signify a precedence. Maybe there should be a numeric priority column? Then the grid could be sorted in different ways, if a user wants to find/compare things....

You misunderstood.

In the simplest case, it still has 2 columns (like now): Name and value. The name changes from "Target" to "Options for project and packages" The value is still * or Foo,Bar
I would prefer, the project to be a checkbox, and the packages a match string (editable in place).

Move the mouse over a target. The hint shows the targets as a descriptive sentence.

Too hidden, that info is way more important.

Also an empty grid should always have one target present. Even, if the target has NO the info that you can add options to packages, is *always* visible.

If you always have all 3 storage sections , then maybe a empty "target" in each....

> With the storage as radio, if the grid is empty, an empty (dummy) "Target" could be displayed. > > Since the name of that line contains the description, users may realize that they can set options for packages. >

On Tue, Jun 11, 2013 at 1:07 AM, Mattias Gaertner <

?But that not easy, why can not override it with project options in ?to all packages when match the Build mode (e.g. Realease1 Release Debug)

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130611/ffa0c6f0/attachment-0001.html>

IMO it should immediately show the result.

Maybe you misunderstood me. The storage encloses its targets. Each storage exists only once and can not be moved.
The targets are not really a group. Internally a target is merely a property of an option. But a target does not fit into a cell, it needs a line of space and most targets are the same I show them as groups.

All I understood was that they are displayed together, because they share the same storage. There was/is no sign to me, that this also indicates a priority/precedence.

The docs explain that the options are applied from top to bottom. IMO that is a simple and intuitive rule.

Then maybe a column with a numeric precedence?

IMHO that's less intuitive and over engineering.

The targets interrupts them already. A broader column means less space for the modes and options. The abbreviations IDE,LPI and LPS are not as clear as a sentence. It's not one grid, there are three, so some disruption is needed.
To lessen the disruption we could give the columns a zebra background and paint that background in the targets and storage rows too.

Do you mean:
| Options for project and packages | project: X | * |

> Move the mouse over a target. The hint shows the targets as a > descriptive sentence. Too hidden, that info is way more important.

Yes. It was merely a hint that this sentence function already exists.

That could be done.
Empty targets are not stored.

[...]

Mattias

Packages are separate entities, often created and maintained by other people. They have their own compiler options and especially their own directories and search paths. They were not tested with your settings. You can now change some of their settings, but you have to test carefully.

Mattias

On Tue, Jun 11, 2013 at 11:34 AM, Mattias Gaertner <

?Hmm, i understand, but what is in my mind:

1 - I made in my Package 2 modes Release and Debug, i can make more but that default for me and others
2 - Now in my project i made 3 modes for example Release, Debug, and Test (release but with memory leak)

when i am debugging, i choose Debug for my project, when compile it, i except that also my package that have Debug mode will recompile with Debug mode, and take the paths from Debug mode not release.

The problem what if i choose Test mode? here package will take Release because it is a default mode there, and the patches for units take from it.

It is more easy than write FPC parameters/options it is need experts users.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130611/daf6b0da/attachment.html>

Yes, I understand that from what you wrote.

At the moment the storage is displayed as an enclosure. Technically I still do not see it as such.
It is an attribute to al the rows in it.
- The attribute is not stored as value, but derived from where the data is (but that is internals)
- The attribute also enforces a place (range) in the precedence list

The targets are not really a group. Internally a target is merely a property of an option. But a target does not fit into a cell, it needs a line of space and most targets are the same I show them as groups.

That is ok

Yes, I know. But to the user (at least to me, and by that with all likelihood to at least some others) the target is more group-like than the storage-place

A broader column means less space for the modes and options. The abbreviations IDE,LPI and LPS are not as clear as a sentence. It's not one grid, there are three, so some disruption is needed.

At the moment the grid usus a lot more vertical than horizontal space. If a user has so many build modes that horizontal space becomes so valuable that a 3 letter column is an issue, then he also will have the same issue in vertical direction (unless all the buildmodes are unused). To make a useful buildmode, it mus have options that differ from the other modes, therefore the amount of rows will be similar big.

Why should it be 3 grids. The options apply to the project/packages, never mind where they are stored.
See above, storage is an attribute. I agree for the need to make it distinguishable, because of the effects on e.g. other team members, if it is stored in e.g. the lpk.
The left most column will give a clear enough indication.

The "Stored in" part of the sentence goes into the header. The words IDE,LPK and LPS (or abbreviations Glob, Proj, Sess) can be explained in a hint, or at the bottom of the page. Or an icon con be used.

To lessen the disruption we could give the columns a zebra background and paint that background in the targets and storage rows too.

That maybe ok. But I still think the disruption by extra rows should be avoided.

Something like that yes. (if the "X" is a checkbox)

The checkbox, can also go earlier, making it 4 columns:

| Options for project | [X] | and packages | * |

just an other thought an this. The empty "target" line could be painted in grey (low-lighted)

> Then maybe a column with a numeric precedence? IMHO that's less intuitive and over engineering.

True, except if the rows will be sortable by other columns too.

As a User I may want to see:
- all OutDir or IdeMacro together (even if that mixes options from diff storages)
- all Options with the same Target (though that depends how many overlapping targets I have)

Of course that maybe better be done using filters.

No, it is by design.
The IDE options are the defaults for all projects. The project options are more specific, so they must come after that. The session options are for the users own experiments. That's why they come last.

Mattias

On Tue, Jun 11, 2013 at 6:54 PM, Mattias Gaertner <

?As i understand, Session options saved in lps and not distributed to other developers??

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130611/99a81764/attachment.html>

Yes, the design maximizes the space for the value to avoid horizontal scrolling.
Most users will have only a few additions, so in most cases no scrolling is not needed.

If a user has so many build modes that horizontal space becomes so valuable that a 3 letter column is an issue,

You don't need many build modes to need horizontal space. Long values are enough. For example
units/$(BuildMode)/$(TargetCPU)-$(TargetOS)/$(LCLWidgetType)

then he also will have the same issue in vertical direction (unless all the buildmodes are unused). To make a useful buildmode, it mus have options that differ from the other modes, therefore the amount of rows will be similar big.

Mattias

[...] Why should it be 3 grids. The options apply to the project/packages, never mind where they are stored.

How do you want to mix arbitrary IDE from you and arbitrary project options from other people?

Mattias

Yes, I got that. And I did not argue against it.
But how does that relate to what I wrote?

I don't understand your question. It does not appear to relate to what I wrote.

[...] > | Options for project and packages | project: X | * | Something like that yes. (if the "X" is a checkbox)

Yes.

The checkbox, can also go earlier, making it 4 columns: | Options for project | [X] | and packages | * |

How does a user know that the [X] is about project?

Alternative:
- Using different colors or icons.
- A filter to show only rows of one Type and/or only one build mode.

- all Options with the same Target (though that depends how many overlapping targets I have) Of course that maybe better be done using filters.

Mattias

IMHO the risk of horizontal scrolling is far less a problem, than the disruption caused to the grid, by the additional vertical spacing.

I changed the IDE to hide the build modes on package compiler options. It is too confusing.

?Hmm, i understand, but what is in my mind: 1 - I made in my Package 2 modes Release and Debug, i can make more but that default for me and others

You can not make build modes in packages. The former build modes above the compiler options was a mistake by some refactoring. It was shown, even though it was not implemented. See above. I fixed that.

A package can react to the active build mode by using IDE macros. For example the $(TargetOS) is set by the project build mode.

Mattias

Correct.
They are for you own experiments.

Mattias

I answered the "never mind where they are stored". IMO users must mind where they are stored.

Mattias

What is the "risk of disruption"?

Mattias

sorry not "risk" since it actually is presence.

The disruptions of the grid by the rows inserted for the sections (that is what the whole discussion is about)

It also exist by the rows inserted for "targets" but there I can see a point in it, and the cost/benefit is slightly better.... But accepting it for the targets does not mean that it needs to be there for the storage sections too.

This is a question of visual representation only. This is not about changing any of the functionality.

Yes, in the sense that it is a choice. Ticking all or some build modes is a choice too. In either case making the wrong choice leads to problems.

Storage may affect co-workers.
But disabling a -Cr in your session profile can do that too: because code that compiles on the own box, will not compile for co-workers.

So in a more broad sense Users must mind to make the right selection. In the same way as they must for all other options.

My point was, the fact that the option is about storage (in part, in other parts about priority, but lets keep to storage here), does not make the option different from other options.

On Tue, Jun 11, 2013 at 7:44 PM, Mattias Gaertner <

Good, ?It is not just ?confusing me, it is made a bug also, when i open a package options and switch to another Build mode, it load the options from the project compile options, now with hide it no switching no bug.

Best Regards
Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20130611/d1d7a651/attachment.html>

Hi,

On 11/06/2013 16:54, Mattias Gaertner wrote:
[...]

how would that look if the order was exactly the reverse:

1- session options first as they are most likely to be changed/modded locally

2- project options second as they come to be modified AFTER the user has experimented with the session options AND propagate out to public

3- IDE options default for all projects, usually come when one has experimented on session AND project (and IFF confirmed on a few projects already, I think)

Also, a quick way to propagate 123 (e.g. button(s): Copy/Move to/from project options, between 1 and 2, Copy/Move to/from IDE options - between 2 and 3, that of course, only those options that do make sense being propagated around, and with indication, i.e. to grey out those that don't have any effect due to being overriden (with a hint as to why and where, too) ) comes to mind ;)

My ?0.02p :)

-L

Mattias

Both directions are ok.
What order a user prefers depends on what he is used to. Maybe a toggle can be added to switch direction.

You can use the up, down buttons to move options.
Maybe a "copy option", and "insert option" can be added to the popup menu.

Mattias