Hi,

I want to understand what the different things on Advanced Build Options do.

"Clean all" :
Does it clean the parts that are selected for building? In this case it is redundant, selecting "Clean + Build" for those parts would do the same.

Or does is clean everything even if it is not selected for building? In this case, does it make sense? Who needs it?

"With packages" :
What packages does it mean? The user installed I guess?

Then, the parts to build. I understand
"LCL"
"IDE" and
"Examples"

but why are these included?
"Package registration"
"IDE interface"
"Synedit"
"Codetools"

They could be built separately from packages (I guess ?). When would someone build them separately from this window?
What is "Package registration" anyway?

There are also some logical mistakes in the UI. Like the Quick Build Options page has separate settings for "LCL interface" Target and IDE. It gives an impression you could set two different interfaces at once but you can't because they are mapped to the same "Advanced interface" list on advanced tab.

The dialog has some more issues with its UI design but I am planning to write another mail of it and propose improvements.

Regards,
Juha Manninen

Hi, I want to understand what the different things on Advanced Build Options do.

It is a front end for the different make commands.

"Clean all" : Does it clean the parts that are selected for building? In this case it is redundant, selecting "Clean + Build" for those parts would do the same.

IDE clean does not work.
Clean all should clean up even those files that are normally not created.

Or does is clean everything even if it is not selected for building? In this case, does it make sense? Who needs it?

Needed after restructuring/renaming things or if there was a bug in a former svn revision.

"With packages" : What packages does it mean? The user installed I guess?

Yes

Not yet.
But Codetools is almost there. When it works good SynEdit and IDEIntf will follow. The LCL needs some further specials.

When would someone build them separately from this window?

Lazarus devels working on the IDE do that all the time.

What is "Package registration" anyway?

This is the base registering unit needed by all packages. It can not be a package. When the LCL becomes a package this will be moved to the top and built first.

There are also some logical mistakes in the UI. Like the Quick Build Options page has separate settings for "LCL interface" Target and IDE. It gives an impression you could set two different interfaces at once but you can't because they are mapped to the same "Advanced interface" list on advanced tab.

You can build the IDE for qt and the LCL for wince.

The dialog has some more issues with its UI design but I am planning to write another mail of it and propose improvements.

The advanced page is for the IDE development or to compile the LCL with some special flags.
The quick page is for those using svn or cross compilation.

Mattias

Thanks for explaining.
I understand now that all the functionality there is needed.

But still, the UI design is not intuitive. I know this problem from my own UI designs. I had a great idea but still it needs some "dummy" user to click and find the problems.

Now the problems in Build Lazarus form :

1. Synchronized GUI controls. When synchronizing GUI controls they should not be placed on different tabs. The "Advanced" tab should contain some seldom used controls and they should not be changed automatically when clicking controls in "Quick" tab because it is not intuitive. There must be some visual feedback when the controls are synchronized. In practice they should be placed on the same form (or tab).

2. Redundant controls. I maybe could build IDE for qt and LCL for wince in two separate build runs but not during one build.
Those 2 comboboxes on Quick tab are synchronized to a single control on Advanced tab. They are exclusive to each other and thus misleading and useless.

3. For IDE developers only. I have basically just compiled Lazarus from SVN but still I am using the Advanced tab most of the time. I even get instructions like: "go to Advanced tab and deselect Examples". It is used by most Lazarus users, I dare to say. Hands up who haven't used it? Even a programmer's innate curiosity forces him to look at it and study its logic. Detailed settings also work as visual explanation of what the quick options do. I select Build All. What "All"? Then I see the detailed list and realize: ok, that "All".

If you really want to create config options only for IDE developers then you should hide them in a separate dialog and show it with a certain command line switch. Then you must make sure that the remaining options are enough for everyone else.

To make my point clear I created a mockup, or actually changed the Lazarus project's form. Screenshots are here:

http://koti.phnet.fi/juhamann/Lazarus/BuildLazarusQuick.jpg and
http://koti.phnet.fi/juhamann/Lazarus/BuildLazarusAdvanced.jpg

Notice how Advanced tab has only seldom used controls and they are not set automatically in any situation.

There is one more issue which I didn't change (yet). The quick build selection uses radiobutton which is not the best control here. A set of buttons would be better, or bitbuttons with some pics.
Those are not really radio-selections but shortcuts to other selections. They can be partly changed and overridden.

I can make another mockup of the form with buttons if this idea gets any support.
I could even try to change the Lazarus code. This change is about GUI, not program logic, so maybe I wouldn't mess up things badly.

Regards,
Juha Manninen

It is not just for IDE developers, but also for LCL developers to set extra options (e.g. enabling range checking).

FYI, originally, there was only the advanced tab (without tab), but users found that too complicated. So the current content was put on a advanced tab and a quick build was added in front.

http:/msg16989.html
http:/msg17833.html
http:/msg18289.html

Vincent

Vincent

Thanks, I read the mail threads. I mostly understand the use cases. Not everybody was happy with the solution then 2 - 2,5 years ago but it was a good compromise.

Still, the GUI design is non-standard and non-intuitive. I mean synchronizing controls between pages without visual feedback. Please ask any GUI-design expert. The initial impression of that dialog was weird. The problem is that one gets used to any UI after learning it and using it for a while but still it is weird for anybody new.
Then there is this mythical non-advanced user. Who is non-advanced? I think (in geek-world) we are all advanced.

One of my points is that the Quick page could be visible also for "advanced users". It would not do any harm.
A solution for this problem was proposed already in the first archived thread (above) by Al Boldi. I don't know why nobody commented on it then.

Instead of pages, have an "Advanced" button that fold and unfold additional config.

This detail-part of a dialog is getting more common and I like it. It is intuitive. It would solve most of this weird GUI behavior problem without changing any logic of the current tabs. The unfold / fold button would say: "Show Details >>" when collapsed and "Hide Details <<" when expanded. or "Details >>" / "Details <<"
or "Advanced >>" / "Advanced <<"
or "Expert >>" / "Expert <<"
or "Expand >>" / "Collapse <<"

Some other things like 2 comboboxes mapping into one radiogroup control should be cleaned, too. It is just not good GUI design.

I understand there are many use cases for this dialog. There could even be profiles adjusting the visibility options, like "LCL cross-compile" profile, "IDE cross-compile" profile and so on, but let's not complicate things too much now.

Regards,
Juha Manninen

Zitat von Juha Manninen :

Both pages are distinct.
Either you use only the quick page or you use only the advanced page. Instead of the tabs above maybe a check box 'Advanced options' would be better.
Because I only use the advanced options, I can't say anything about the usability of the quick page. This was created by some users.

Maybe my example was misleading. The advanced page is not only for IDE developers. For example when I debug something in synedit that appears only under gtk2 I enable LCL+SynEdit.

Dividing the buttons and the edit fields is useful for the casual user. For the lazarus devels who change targets and options frequently this would be bad.

Speaking for myself: I set this dialog on a short cut and I have so many options that the edit would be better a memo.

If you put everything on one dialog: yes.

You are welcome to improve the build dialog.
But don't split the advanced page.

I can make another mockup of the form with buttons if this idea gets any support. I could even try to change the Lazarus code. This change is about GUI, not program logic, so maybe I wouldn't mess up things badly.

Mattias

Mattias G?rtner wrote

You are welcome to improve the build dialog. But don't split the advanced page.

So... I was planning to make small changes there but it wouldn't be good with small changes. I made big changes instead. I didn't split the advanced page though.

Now I am waiting for feedback. This build dialog must be a "holy cow" for many Lazarus developers and now I changed it. Let's see... Below is description for issue #0015336.

Juha Manninen

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

I have implemented Build Profiles for Configure "Build Lazarus" dialog. There were 2 main ideas when doing it.

First, building for different targets is easier with configurable build profiles. All build-settings are stored in a profile and so it should fill every use case here. The profiles are saved in XML file and thus are persistent.

The other idea was to make the user interface more sane. It was stitched together from 2 different GUIs (Quick selections and Advanced page) and it was little weird in appearance and behavior.

Now the idea of Quick selections is extended to configurable profiles. Its user interface is mostly copied from External tools config dialog. Advanced page is now called Detail page and it can be hidden if needed. It look about the same as before.

If someone really doesn't like such profiles, he could define just 1 profile and change that. The GUI doesn't even let you delete a single profile by accident.

The program's internal object structure was changed heavily to keep it logical and to avoid duplicate data. The code for the actual build process was not touched however. This gives high hopes that it still works in different situations although I tested only few simple build types.

One change for the internal build-option-objects is that they are created only outside (by caller) and just referenced in this code. Earlier they were created in two places and then copied and assigned back and forth, often assigning to itself. It worked but I changed the logic now.

*** Issues: ***

1. Visual forms editor. I copied all the controls from Advanced page but then had problems when aligning and moving them. It looks like the form designer works well in simple cases but with some complicated interaction it goes nuts. For example I can't move OptionsLabel and OptionsEdit vertically even if I change anchors and alignments. The other labels move with identical anchors and alignment settings. And in the old form they behaved better with identical settings! Some Lazarus-guru could show how to do it.

2. QT related visual refresh problem. I experience a problem of an owner drawn Listbox for MakeModes but I am quite sure it is QT related. Radiobuttons in the listbox get updated visually only after moving the mouse pointer over the control. No need to click anything then.
I added commands like:

  BeginUpdate;
  EndUpdate;
  Repaint;
  Refresh;
  Invalidate;

and debugged that they are really called but it doesn't help. I can test for GTK2 later. The old version with QT works but there parent control was TPage, now TPanel.
However, after waving the mouse over the box it all works perfectly (!).

3. I did not put much effort in profiles' add / rename dialog. It has basically 1 label, 1 editbox and OK and Cancel buttons. There must be similar dialogs around, also in Lazarus code base. I didn't find any though.

http://bugs.freepascal.org/view.php?id=15336

http://koti.phnet.fi/juhamann/Lazarus/BuildLazarus.jpg

All known issues are fixed.

Juha Manninen

Juha Manninen wrote

http://koti.phnet.fi/juhamann/Lazarus/BuildLazarus.jpg

Imho, too many controls. It's hard to understand what controls're actually controlling what is about to be build.

thanks,
dmitry

Do you have an idea to make it better?

Vincent

Vincent Snijders wrote

Do you have an idea to make it better?

Of course, i don't :) But i like hot it looks now.

thanks,
dmitry

Hello Lazarus-List,

you wrote

> Imho, too many controls. It's hard to understand what controls're > actually controlling what is about to be build.

VS> Do you have an idea to make it better?

Maybe adding the texts "Profiles" in the left selection box and "Build settings" in the right panel ?

dmitry boyarintsev wrote

Imho, too many controls. It's hard to understand what controls're actually controlling what is about to be build.

I think there must be many controls in the detail (advanced) page because the build process itself is complicated. The same problem is with the current build dialog.

You can click the "Hide Details <<" button and they go away :-) This detail-page visibility is saved for each project. You could define the details hidden for most build profiles and then define an "advanced" profile or something that shows the details.

Regards,
Juha Manninen

good work :)

zeljko

Right.
I even had it in mind but then I was fighting with Forms Editor and forgot it. What is the best UI control to place those header texts? I will figure out something...

Juha Manninen

Vincent Snijders wrote

Do you have an idea to make it better?

Here's my point of view how to make the build options shorter and cleaner: http://imagebin.org/75477

The top combobox "Quick Build options" allows to select predefined set of components.
The items of the combobox is: "Build LCL, Build LCL and IDE" etc (all options at the current Quick Build options")
With combo box change, marks at the components list below changes automatically.

If users changes marks at the list manually, combobox caption changes to "Custom". To make it clear that, current set of options is not one of predefined.

I've replaced a radiogroup of widgetset with the combobox. I know it's two-clicks instead of one, to select the widgetset, but it save space. Besides in Compiler option (Path tag), there's widgetset combobox too, not radiogroup.

That's it. http://imagebin.org/75477

I don't have a patch for the changes. Just sharing my thoughts.

thanks,
dmitry

P.S. The purple help button on the bottom-right is OSX hack feature :)

Something like this:

http://koti.phnet.fi/juhamann/Lazarus/BuildLazSimple.jpg and
http://koti.phnet.fi/juhamann/Lazarus/BuildLazDetails.jpg

Juha

IMO this combobox is better than the original 2 tab-pages. This way you get visual feedback of the changes. The original tab-control was just non- intuitive.

If users changes marks at the list manually, combobox caption changes to "Custom". To make it clear that, current set of options is not one of predefined.

What if someone wants to define and save new build options? That was the idea of my configurable build profiles.

I've replaced a radiogroup of widgetset with the combobox. I know it's two-clicks instead of one, to select the widgetset, but it save space. Besides in Compiler option (Path tag), there's widgetset combobox too, not radiogroup.

I like this combobox, too. I could change my version to use combobox and label "Widgetset" as well later.

There is one problem with your solution though: It shows all the controls all the time. The original idea with Quick Build Selections was to hide the "advanced" options. My solution has a "Hide Details" button for that.

Juha

Juha Manninen wrote

IMO this combobox is better than the original 2 tab-pages. This way you get visual feedback of the changes. The original tab-control was just non- intuitive.

AFAIK, 2 tabs are actually 2 independent build options dialog. Settings on one tab won't effect another tab... Personally I never used "Quick build options"

What if someone wants to define and save new build options? That was the idea of my configurable build profiles.

On the current Adv.Build.Dlg there's a button bellow "Save settings". It just stores the build options globally, so it's possible to store configuration without building.

Maybe 3 additional buttons can be added: "Save", "Save As" and "Delete", to manage custom settings. (i.e. next to the combobox) And "Save settings" are renamed to "Close". The button closes the dialog silently stores the latest build options as default. On the next dialog opening the last "closed" or "built" options are shown.

IMHO: There's no need in saving/storing additional build options.
Storing the last saved (or built) options is enough (It is now);

There is one problem with your solution though: It shows all the controls all the time. The original idea with Quick Build Selections was to hide the "advanced" options. My solution has a "Hide Details" button for that.

And that's what i don't like about your idea. I see no reason in "Hide" or "Show" ) IDE developers would always use show details (to control components rebuilt). b) Even if they don't change them, they can always be sure about what will be rebuilt.
c) The usual Lazarus user, would never use this dialog (i.e. installing a package rebuilds the IDE without showing the dialog) d) If a user ever needs the building dialog, he/she would be interested in the "details" anyway (simple human curiosity) e) It would be easier to explain a user how to use the build dialog, if the dialog is single-step, rather than 2 steps (the main form and the details)
f) There's no other dialog in the IDE that uses "hide/show details" style. Every dialog in the IDE, even overloaded with controls, shows all possible again: I'm not the one to reject or accept your patch. I'm just sharing my thoughts and I'm NOT telling that "hide/show" is bad idea at all.

thanks,
dmitry

dmitry boyarintsev wrote

On Mon, Dec 14, 2009 at 11:51 PM, Juha Manninen

Yes they affect each other very much!
This really proves how non-intuitive this UI is. You didn't even realize how it works because there was no visual feedback. I was also scratching my head for some time when learning about this dialog.

Yes, there is a need for saving build options. The Quick Options page is a half-baked solution for that. It is predefined and works for some people but not for many other people.
You want to add buttons? My Build Profile window already has buttons for adding, deleting and renaming.
Please look at my screenshots. I already defined "Build GTK2 Lazarus" and "Build QT Lazarus" and I actually used them. Other "advanced" developers have more varied and complicated settings (I guess).

example. It has a list of topics or headers at left side and then a details pane (or page) for the actual options.
True, there is no "Hide Details" button but it would not make sense in that context. When using Build Profiles it makes sense.

I would like to agree with your other points.
However some people wanted to hide the "advanced" page and created the quick options page. So there apparently is a need for a simple UI for build options.

Once again: I'm not the one to reject or accept your patch. I'm just sharing my thoughts and I'm NOT telling that "hide/show" is bad idea at all.

I think this "Hide Details" button is not very essential. It just gives more choices for different use cases. If you don't need it then don't use it.

More essential is the concept of configurable profiles. Imagine a developer who tests libraries or Lazarus itself on different platforms and OS and CPU. I could imagine they have use for this.

Regards,
Juha

Hello Lazarus-List,

Monday, December 14, 2009, 9:17:57 PM, you wrote:

JM> http://koti.phnet.fi/juhamann/Lazarus/BuildLazSimple.jpg JM> and
JM> http://koti.phnet.fi/juhamann/Lazarus/BuildLazDetails.jpg

There are some design glitches here and there (IMHO):

1) Both panels (regular and advanced) must have a fixed separation in between (some air).

2) Border of list in quick options is not left and right centered.

3) LCL interface box is not of same height as left box, ans is not top aligned. Also the text "LCL interface" should be presented in a distinguible fashion as a title, like a different background color from left to right extended.

4) The texts "Options", "Target OS", etc, must have some air in the left. Also the bottom checkboxes. Also the texts does not match the top of their comboboxes and text edits which produces a serious visual conflict.

5) "Help" and "Close" buttons must be bigger to allow internacionalization.

6) Black line below "Profiles", remove or add the same to "Build options".

Maybe this is very platform specific but the advanced should be in the left side and profiles in the right one due the "Close" button.

True. Added a splitter.

2) Border of list in quick options is not left and right centered.

Border? Do you mean the texts?

3) LCL interface box is not of same height as left box, ans is not top aligned. Also the text "LCL interface" should be presented in a distinguible fashion as a title, like a different background color from left to right extended.

The radiogroup is actually "alClient" aligned meaning it should occupy all the space there is. This is a radiogroup specific problem. I want to replace it with a combobox anyway.

4) The texts "Options", "Target OS", etc, must have some air in the left. Also the bottom checkboxes. Also the texts does not match the top of their comboboxes and text edits which produces a serious visual conflict.

I moved the texts but I now I experience a same Form Designer problem that I had earlier. When I try to move the "Options:" label, other controls move with it. As you can see it is too high and can't be moved separately. Must do a bug report later.

5) "Help" and "Close" buttons must be bigger to allow internacionalization.

They are autosized. Made Build and Save Profiles autosized, too. Now Build looks too narrow.

6) Black line below "Profiles", remove or add the same to "Build options".

What black line? Are we looking at the same pics?

Maybe this is very platform specific but the advanced should be in the left side and profiles in the right one due the "Close" button.

Uh, I don't know about that.

Updated
http://koti.phnet.fi/juhamann/Lazarus/BuildLazDetails.jpg with those few changes.

Juha

Hello Lazarus-List,

you wrote

> 1) Both panels (regular and advanced) must have a fixed separation in > between (some air).

JM> True. Added a splitter.

Much better :)

> 2) Border of list in quick options is not left and right centered.

JM> Border? Do you mean the texts?

Not, but maybe it is a control limitation. In the "Build options" there is something like a listview with some icons in the top. The "X" icon is a bit left and just below it, there is a space (around 5-10 pixels), but the same box in the right have nothing.

> 3) LCL interface box is not of same height as left box, ans is not top > aligned. Also the text "LCL interface" should be presented in a > distinguible fashion as a title, like a different background color > from left to right extended.

JM> The radiogroup is actually "alClient" aligned meaning it should occupy all the JM> space there is. This is a radiogroup specific problem. JM> I want to replace it with a combobox anyway.

If it is a control limitation nothing can be done, except change the global design.

> 4) The texts "Options", "Target OS", etc, must have some air in the > left. Also the bottom checkboxes. Also the texts does not match the > top of their comboboxes and text edits which produces a serious visual > conflict.

JM> I moved the texts but I now I experience a same Form Designer problem that I JM> had earlier. When I try to move the "Options:" label, other controls move with JM> it. As you can see it is too high and can't be moved separately. JM> Must do a bug report later.

Controls are being moved quite sure because they are anchored ones to others, maybe you must remove all anchors (to other objects) while you design.

> 5) "Help" and "Close" buttons must be bigger to allow > internacionalization.

JM> They are autosized. Made Build and Save Profiles autosized, too. Now Build JM> looks too narrow.

Autosized buttons are great for internacionalization but awful from the design point of view. Also the Delphi way of placing icons just side by side with text is "catastrofic" :) unless you set the same button 20 times :)

> 6) Black line below "Profiles", remove or add the same to "Build > options".

JM> What black line? Are we looking at the same pics?

Yes. It seems to be the 3D effect of the "Add, Remove, Rename" toolbar.

> Maybe this is very platform specific but the advanced should be in the > left side and profiles in the right one due the "Close" button.

JM> Uh, I don't know about that.

As most people is right hand dealing with the mouse they (or us) have some inclination to leave the mouse in the right portion of the screen so more important (not used, important) operations should be in the right-bottom (in the bottom because most people have screens located upper their waists.

JM> Updated
JM> http://koti.phnet.fi/juhamann/Lazarus/BuildLazDetails.jpg JM> with those few changes.

It looks much better, cleaner and organized. Non aligned controls creates confusion in the brain, so as much squared divided the interface much easy to understand in a simple view and of course that's the reason that buttons in the horizontal plane must have the same height and buttons in the vertical one the same width.

It is much easy to understand this:

------------------
| % Button 1 |
------------------
------------------
| % More large |
------------------
------------------
| % Sh |
------------------

Than the "delphi" way:

------------------
| % Button 1 |
------------------
------------------
| % More large |
------------------
------------------
| % Sh |
------------------

Because text centered are quite easy to be detected but centered icons forces the brain to detect if the icon is a graphic or a letter and creates a unpleasant disorder sensation. In the first example is easy to use buttons based in their icon, in the second your brain must search for it. The solution is autosize:

--------------
| % Button 1 |
--------------
----------------
| % More large |
----------------
--------
| % Sh |
--------

It is easy but not looking nice due different vertical right limits.

I think I'm completly off topic now :) Sorry.

Maybe Juha has not yet spotted the anchor editor?

TBitBtn shows icons depending on platform.
For your own apps your can override this with
Application.ShowButtonGlyphs

This depends on platform.

[...]

About colors:
Don't mix fixed colors and themed colors.
You can use fixed text color on fixed background or theme color on theme background, but not fixed color on theme background.

Mattias

Mattias

Hello Lazarus-List,

you wrote

> Controls are being moved quite sure because they are anchored ones to > others, maybe you must remove all anchors (to other objects) while you > design.

MG> Maybe Juha has not yet spotted the anchor editor?

Hmmm... maybe...

> Autosized buttons are great for internacionalization but awful from > the design point of view. Also the Delphi way of placing icons just > side by side with text is "catastrofic" :) unless you set the same > button 20 times :)

MG> TBitBtn shows icons depending on platform.
MG> For your own apps your can override this with
MG> Application.ShowButtonGlyphs

I know, but anyway the results are not "pretty". Anyway but this is not a problem, it's "my" problem :) with how icons are painted.

> >> Maybe this is very platform specific but the advanced should be in the

[...]

> upper their waists.

MG> This depends on platform.

That's what I was thinking about...

MG> About colors:
MG> Don't mix fixed colors and themed colors.
MG> You can use fixed text color on fixed background or theme color on MG> theme background, but not fixed color on theme background.

That's a can of worms :)

Hello Juha Manninen:

I find the interface of profiles a little confusing:

1) As far as I have understood, there is a default profile, the one that is used when you select the menu option "Build lazarus". If this the case, the buttons up down have no sense because the order of profiles has no meaning, it's not like a list of paths or cascade rules. It 's confusing, the user may wonder "What happens if I move a profile up or down? is the building system going to apply them in order?". I think it only needs a button "Set this profile as default".
2) Each profile should be saved separately. When you click edit a profile, the profile form should open in a new form with buttons save and cancel. I don't like the idea of saving other profiles I don't see and that I may have changed without realizing.
3) If you edit a profile in a separated form, you can't show details as you do now. There are two options:
a) Reuse the edit form, instead of the label or icon "edit"., you may use a more generic label "Properties" so if the user wants details opens the edit form and cancels.
b) Add at the bottom of the form the detail, as user can't change (now uses the form), you needn't radiobots, just label "Widget: GTK", so you don't need so much space.

So the interface needs:
- Show which is the default profile (perhaps adding the string "(Default)" in the listbox of profiles)
- A button to set the default profile to the selected one.
- A delete profile button.
- A "new" profile button that opens the form for edting. Perhaps intializating the data, except name, with the current selected profile
- A "properties" button, that open the form for editing the profile. Or an "edit" button that opens the form, and add to the list form a way display details of the selected profile.

- The save button for the full list disappears.There is nothing to save but the default profile.
- The editing form, besides the current data, needs a name. We could also remove the rename button from then profiles list from.

Excuse me my broken (and perhaps rude) English.

Regards
Santiago A.

El 14/12/2009 21:17, Juha Manninen escribi?:

It is an alClient alignment problem again. I will learn to use the Forms editor differently later.

Ok, it was TToolbar.EdgeBorders --> ebTop. I removed it. Otherwise I will have a pause now with my edits.

Regards
Juha

Santiago A. wrote

Hello Juha Manninen:

Hello!

The order may have a meaning to the user.
Same thing as with Tools --> Configure external tools... For the computer it makes no difference but for the user it can make a difference. If the order was not configurable then someone would very soon complain about it. And that would be OK because a user should be able to order his own list of settings if he wants to.
In my implementation the default profile is the one selected. There is no need for a button to select it again. It is very intuitive IMO.

2) Each profile should be saved separately. When you click edit a profile, the profile form should open in a new form with buttons save and cancel. I don't like the idea of saving other profiles I don't see and that I may have changed without realizing.

How can you change a profile without realizing it? :-) Ok, just kidding...

Actually having a separate "edit profile" window is a good idea. However it is the opposite of the original dialog's logic. Most developers are now using just the advanced page. The quick options page was a hack for some people's needs. Your solution would require more mouse clicks to change build settings and I guess some people would not like it.
My solution is kind of a compromise here. It allows easy and quick editing but still offers a sane and intuitive GUI.

You mean like a read-only form showing the values? We could implement some read-only setting to my Build Profiles, too. Some profiles would be read-only until you explicitly select to edit then.
I was planning to change Widgetset radiobutton to combobox already. That would save space and make it look cleaner.

So the interface needs: - Show which is the default profile (perhaps adding the string "(Default)" in the listbox of profiles) - A button to set the default profile to the selected one.

The default profile is the one you have selected in the list.

- A delete profile button.

There is one. It says '-' and Remove.

- A "new" profile button that opens the form for edting. Perhaps intializating the data, except name, with the current selected profile

There is an "Add" button for that. It behaves just as you described.

- A "properties" button, that open the form for editing the profile. Or an "edit" button that opens the form, and add to the list form a way display details of the selected profile.

Yes, let's see what other people think of that.

- The save button for the full list disappears.There is nothing to save but the default profile. - The editing form, besides the current data, needs a name. We could also remove the rename button from then profiles list from.

Yes, if renaming was done in a separate form then the rename button would be useless.

Regards,
Juha Manninen

What anchor editor? Ah, that one! I was looking at it some time ago and wondered what it does. Delphi doesn't have such, or does it? At least I never used one. It seems to be very powerful now that I learned it. Great!

But I have complaints (again), too. The anchors (set of booleans) in object inspector map directly to anchor editor window settings. However there is no indication of which control the selected one is anchored to. I though it is anchored to the parent control, but no.

I suggest removing the set of booleans from object inspector's anchors and instead have a button there which opens the anchor editor. (A button like Listbox.Items has). This would be a deviation from Delphi but who cares. Now it is misleading and duplicate. I know, it is a small thing once you know it but an intuitive GUI is still an important goal, IMO.

I was able to fix all the small alignment problems. JoshyFun: the Radiogroup alignment problem was due to BorderSpace settings.

About colors: Don't mix fixed colors and themed colors. You can use fixed text color on fixed background or theme color on theme background, but not fixed color on theme background.

Is themed color such as clWindowText and clCaptionText? And fixed color is like clMaroon which I used for text, or how?

By theme background you mean the actual control's color property, right?

Or, is there some hidden setting for themes somewhere?

Regards,
Juha

Zitat von Juha Manninen :

Delphi does not have it.

But I have complaints (again), too. The anchors (set of booleans) in object inspector map directly to anchor editor window settings. However there is no indication of which control the selected one is anchored to. I though it is anchored to the parent control, but no.

If no anchor controls are set the Anchors work Delphi compatible and the object inspector makes sense.

I suggest removing the set of booleans from object inspector's anchors and instead have a button there which opens the anchor editor. (A button like Listbox.Items has).

?
Anchors has this button since the anchor editor exists.

This would be a deviation from Delphi but who cares. Now it is misleading and duplicate. I know, it is a small thing once you know it but an intuitive GUI is still an important goal, IMO.

Many properties depend on others.
If we would hide all properties that might confuse users there would not be many left in the OI.

Yes

And fixed color is like clMaroon which I used for text, or how?

Yes

By theme background you mean the actual control's color property, right?

It depends.

Or, is there some hidden setting for themes somewhere?

Well, there are lots of theme settings hidden to LCL apps.

Mattias

Uhh, I missed that one also somehow. Ok.

I guess your point is to use colors below clNone in the color listbox. ... but there are no nice colors there, just black, white and grey (and very few others).

Anyway, this is not important now. I am more curious about the fate of my patch. I am ready to tweak it more if it has chance to be included in Lazarus. If not, then something else should be done to the build dialog. It is just not good GUI design now.

Who decides? I understood that nobody saw any fundamental problem with my Build Profiles, disagreements were about the GUI.

Regards,
Juha

Zitat von Juha Manninen :

I will apply it if the gui problems are solved.

Speaking for myself: I use the dialog sometimes a hundred times a day and so I need a quick frontend where I can quickly set what to build and define the options. I don't care where the buttons are placed or if the widgetset is a combobox. But all options should be on one page/panel/control. Profiles will not help me much. Of course this page could be hidden by default.

I'm not sure what the best frontend is for others. Many will probably just use it for a clean rebuild after svn update, cross compiling the LCL or building the qt IDE. Cross compiling the LCL will be eventually done automatically by the IDE, so windows/mac users just need a function to rebuild the IDE clean (with or without packages). That's why I think most users will not use profiles and therefore the frontend for the profiles should be less prominent. In other words: When you show the dialog the first time it should not start with buttons to create/delete profiles, but with controls to compile the IDE, LCL.

just my 2 cents.

Mattias

+1

I don't know why but once per year we get a new idea of how to improve this dialog :) Personally I like it as it is now. I can quickly rebuild the part I need with desired settings. I never used the previous year improvement - the Quick Build Options page. If profiles are really needed then I don't argue if they go to the same Quick Build Options page :)

Best regards,
Paul Ishenin.

We'll I use it, but it's bit boring to type options everytime when I want to crosscompile for win32 under linux. So that's why I need some kind of profile's.
I prefer build dialog as it is now (quick build options means nothing to me - I don't use it at all), only one thing is needed : if I choose win32, then I want that my options are loaded from somewhere for win32, so I don't need it to type it each time I want to crosscompile ide.
So, just few changes are needed in current dialog: 1.combo box instead of TEdit control for Target OS/CPU 2.Options saving/reloading per TargetOS/CPU

zeljko

zeljko wrote

So, just few changes are needed in current dialog: 1.combo box instead of TEdit control for Target OS/CPU

There is a combobox already for Target Directory and CPU, but they have no selections. I wanted to ask about it, is it a not-implemented feature? What should be there?

2.Options saving/reloading per TargetOS/CPU

The configurable Build Profiles would solve that.

Juha

Juha Manninen wrote

There is a combobox already for Target Directory and CPU, but they have no

I implemented Target OS and CPU combobox selections a few months back. The patch is still somewhere in Mantis. I'll try and find the mantis report and see what is outstanding to get it applied.

The configurable Build Profiles would solve that.

Sorry, I did not follow the complete message thread. When you say "build profiles", do you mean only for Lazarus IDE rebuilding, or do you mean build profiles for our projects?

I'm wishing for the latter - like MSEide has. That way I can quickly rebuild my projects as release builds, debug builds, extra optimization, maybe even cross-compile options etc... This would be a pretty awesome addition to Lazarus IDE.

Regards,
- Graeme -

Build Profiles for Configure "Build Lazarus" dialog, basically IDE and LCL + options.

http://koti.phnet.fi/juhamann/Lazarus/BuildLazSimple.jpg http://koti.phnet.fi/juhamann/Lazarus/BuildLazDetails.jpg

I'm wishing for the latter - like MSEide has. That way I can quickly rebuild my projects as release builds, debug builds, extra optimization, maybe even cross-compile options etc... This would be a pretty awesome addition to Lazarus IDE.

Yes, that would be great, too.

Juha

Sorry I ask this but why wouldn't the profiles help you when you "use the dialog sometimes a hundred times a day and so need a quick frontend where you can quickly set what to build and define the options" ? I see that as a perfect use case for my Build Profiles.

Juha

Only for the IDE.

I'm wishing for the latter - like MSEide has. That way I can quickly rebuild my projects as release builds, debug builds, extra optimization, maybe even cross-compile options etc... This would be a pretty awesome addition to Lazarus IDE.

I'm working on build modes, build conditionals and build variables for projects+packages.
One of the goals is to make the LCL a normal package. When this is achieved, you don't need to use the build lazarus dialog to cross compile the LCL any longer. You can simply set the project TargetOS and TargetCPU and the IDE will automatically cross compile the LCL if needed.

Mattias

Because I use a dozen -d flags as needed and set the parts as needed. You know, when you add a -d flag you have to compile a part clean, because FPC does not. This would easily result in 50 profiles. And I work on five different machines. A TCheckListbox would help me, where I can add options and turn them on if needed.

Mattias

My solution can handle 50 build profiles easily! :-)

Ok, I understand the situation now more or less.
I keep the configurable TCheckListbox for options in mind.

Juha

I saw the MaxProfiles=100 constant. ;)
I didn't dare to ask, but maybe now it is time: Why this limit?

Ok, I understand the situation now more or less. I keep the configurable TCheckListbox for options in mind.

I don't think that Paul and me are normal users. If we would really need it we would have implemented it ourselves.

I really appreciate your effort to make the dialog more comfortable and I'm sure many users need profiles. Just keep in mind that the majority are pascal programmers - they are spoiled and want it simple.

Mattias

Mattias Gaertner wrote

I saw the MaxProfiles=100 constant. ;) I didn't dare to ask, but maybe now it is time: Why this limit?

Yes, good question. I copied that part of code from ExtToolDialog. There was a limit defined as

  MaxExtTools = ecExtToolLast-ecExtToolFirst+1;

The constants are in IDECommands unit and apparently needed for all main menu actions.
So, I didn't think of it much at that point but just made the code compilable. There is no actual need for such limit.

Right, but the build dialog is a bit intimidating when seen for the first time. I understand there have been efforts to simplify it.

If the profiles pane is visible all the time, does it bother you "super- users"? It can be made hidden by choice but then the GUI needs to designed little differently again.

Juha

2009/12/18 Juha Manninen :

Build Profiles for Configure "Build Lazarus" dialog, basically IDE and LCL + options.

Ah, I used to simply use the Advanced tab, which works pretty well for what I need. But then I don't rebuild the IDE 100x a day. :-)

Couldn't this new dialog also be used for users projects? I'm not sure how different the IDE treats user projects compared to rebuilding the IDE.

2009/12/18 Mattias Gaertner :

One of the goals is to make the LCL a normal package. When this is achieved, you don't need to use the build lazarus dialog

Nice. This should make life much easier. :)

2009/12/18 Mattias Gaertner :

in 50 profiles. And I work on five different machines. A TCheckListbox would help me, where I can add options and turn them on if needed.

That is exactly how MSEide works. No fancy interface required, just setup an many various compiler options in the grid and tick which ones applies to which build modes. Simple, but very affective. One difference in MSEide is that those build modes apply to projects too (the MSEide itself is a project too). There is no separation between building the IDE compared to building a user Project. But then MSEide doesn't have multiple GUI toolkit backends like in the case of LCL.

--- El vie 18-dic-09, Paul Ishenin escribi?:

Even when I don't use it a hundred times (maybe about 95 :D) I hate when every two thousand or so times I have to erase and type new custom options and targets for crosscompiling and then have to type back again restoring the settings for normal use.

So I miss a profiles feature here, yes.

I like it also, but I would like it more if it had just a combobox where I could choose a profile plus a button or a context menu (or one item in combobox) to ask for a new profile name and that's all. :P

Jesus Reyes A.

Encuentra las mejores recetas en Yahoo! Cocina.
http://mx.mujer.yahoo.com/cocina/

Jesus Reyes wrote

So I miss a profiles feature here, yes.

Good to read some others like the idea, too. I first thought it is an extremely cool idea but later started to doubt.

Good idea, too, but it has one problem: there is no way to delete, rename or reorder the profiles.
Deleting, renaming or ordering list entries is a natural thing to do. If they were missing then somebody would complain, and for a good reason.

It means there would need to be another UI for managing the list entries.

Juha

Big difference.

But there are similarities between profiles and build modes.

Mattias

Add a '...' button near the profiles combobox with a new dialog for managing profiles.

Best regards,
Paul Ishenin.