Hi,

What is the rationale for duplicating the 'Add' button in the package dialog ?

The buttons as they are now are highly confusing.
I preferred the old system where there was only 1 button. That was clear and intuitive.

If you really want to add a button (I will not argue that point, clearly someone thought it was necessary), then please give them a very distinctive look.

* The 'add other items' (the one with 2+es) button would be more clear if you gave it a 'New item' look. Which is, to my mind, closer to what it actually does.

* The 'Add' button would be best served with something that resembles the 'Open file' icon. Possibly with a small '+' sign overlayed.

I don't care so much what the exact images are, but please make it something very distinct; as it is now, it is very confusing. I keep pushing the wrong button, they are too similar. After many weeks of working with the dialog, this should no longer occur IMHO, a clear sign that things are not clear and intuitive. Hence the request.

Michael.

It is very unpleasant solution. Besides that with that "All >>" you can add only directory with all files and then you must delete all except that one file. With "All" you are adding only one file. Very confusing. Don't know why anyone changed that. That should be simple, only one dialog where Add units/files should have two buttons: "Add file(s)" and "Add dir(all files)".
So, +1

zeljko

Phew, someone else agrees :) I thought maybe I was getting too old and inflexible.... ;)

I agree with your remark.

IMO The only thing that needed changing in the 'old' dialog, was the ability to add multiple requirements. Now it means opening and closing the dialog 8 times or more to add each package dependency :(

Michael.

2015-03-23 5:46 GMT-03:00 Michael Van Canneyt :

+1

Luiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150323/8203abbe/attachment.html>

Michael Van Canneyt wrote

What is the rationale for duplicating the 'Add' button in the package dialog?

It solved this and many other complaints about usability : http://bugs.freepascal.org/view.php?id=24337

The buttons as they are now are highly confusing. I preferred the old system where there was only 1 button. That was clear and intuitive.

The old system was also far from intuitive. You needed at least 7 clicks to add one existing file.
What more, there was a filter which prevented adding some files, but didn't give any feedback.
The filter is still there in the "Add Files" feature. Then d'n'd was implemented and added files without using that filter. I added the button which opens a standard file open dialog and is consistent with d'n'd and shares some code with it.

If you really want to add a button (I will not argue that point, clearly someone thought it was necessary), then please give them a very distinctive look. [...]

True, it is not perfect.
My plan is to remove the "Add files in Directory" feature, or to move it to the "More >>" menu. It is needed extremely seldom. The standard file open dialog lets you select many files in one directory. If you have many directories then you must repeat it which is not a problem typically.

How to make it truly intuitive? I am NOT happy with the current situation either.
The features "Add Editor Files" and "New Requirement" in Project Inspector, and "New File", "New Component" and "New Requirement" in Package Editor should have buttons right next to the (new) "Add" button.
The old "Add Files" tab can be moved somewhere.
Then it makes sense to split the buttons into 2 rows and maybe use TCoolBar. Then the icons must be distinctive indeed. What do you think?

I guess you mean "Add" and "Add ..." buttons.
The standard file open dialog has multi-select enabled. It is not only for a single file.
What if you ignore the "Add Files" tab in the "other items" dialog? Pretend it does not exist.
It is a little better already, right?

Juha

I doubt you will find good icons.
Each function needs a caption with a few words to explain what it does.
Maybe use a dropdown menu like the "Use >>" button?

Mattias

Ehm, 'many other complaints' ? that is just your opinion :-)

I don't mind 7 clicks, as long as I know where to click.

What more, there was a filter which prevented adding some files, but didn't give any feedback.

Hm. Strange argument. If that is a problem, just give the ability to switch filters. Not a reason to completely change the way of working ?

The filter is still there in the "Add Files" feature. Then d'n'd was implemented and added files without using that filter. I added the button which opens a standard file open dialog and is consistent with d'n'd and shares some code with it.

No problem with all this, but the main issue I am having is that the icons are VERY unclear.

IMHO:

0. Remove the new "add (with 2 plusses)" button (see below)

1. The "Add stuff" must be destroyed entirely
(well, split into multiple dialogs).

2. Add a 'New item' button, with an icon which resembles 'new file'. It invokes the 'File|new..' dialog, but adds to the package instead of the project.

3. Duplicate the 'New item' functionality in context menu. Context menu and button bar should be in sync, IMHO.

4. Duplicate 'Add file(s)' (single plus sign) button functionality in treeview context menu.

5. "Add Directory" can be moved to 'more' and added to context menu.

6. "Add editor file' can be moved to 'more' and added to context menu. (Personally, I've never used this functionality, but practices may differ).

7. Add a new 'Manage dependencies' button (something with a package-like icon).

8. Context menu should also have 'Manage dependencies'

9. Rework dependencies management to something more sane. Multi-select etc.

The "clean up dependencies" should IMHO be removed, but that is a separate topic entirely.

Anyway, just my proposal...

Michael.

The function of the button is confused. So the icon is confused :)

Start by making a clear distinction in functions.

(see my proposal)

Michael.

Michael Van Canneyt wrote

Ehm, 'many other complaints' ? that is just your opinion :-)

I opened the report partly because of other complaints and questions. It was not only my opinion.

> What more, there was a filter which prevented adding some files, but > didn't give any feedback. Hm. Strange argument. If that is a problem, just give the ability to switch filters. Not a reason to completely change the way of working ?

No, the user selectable filter is another thing.
There are hard-coded rules that prevent some files being added because they are not valid for the project/package.
For some reason the rules are not needed when files are added by d'n'd or file open dlg.
The code is inconsistent, I was planning to consult Mattias later about it. Now I see there is another inconsistency :
http://bugs.freepascal.org/view.php?id=27720
The code needs refactoring so that logic for accepting / rejecting a file is in one place.

Project and package have lots of common features and similar code. I have already created a common base class and an interface for them. I hope it can be extended to share code for these dialogs.

Your plan looks good. You are clever!

3. Duplicate the 'New item' functionality in context menu. Context menu and button bar should be in sync, IMHO.

What should be in sync? The Enabled state maybe?

9. Rework dependencies management to something more sane. Multi-select etc.

It could use the "Open Loaded Package" dialog after some modifications.

The "clean up dependencies" should IMHO be removed, but that is a separate topic entirely.

Why? It is a very useful feature.

Juha

OK, that was not clear :)

That makes sense :)

Your plan looks good. You are clever!

Not clever, I simply like a simple dialog ;)

Like I wrote to Mattias: too many things are hidden behind 1 button. By separating out functionality, things become more clear.

I meant that IMHO items that appear in the button bar should also appear in the context menu.

> 9. Rework dependencies management to something more sane. Multi-select etc. It could use the "Open Loaded Package" dialog after some modifications.

If you add an option to select a package that is not loaded, yes.

Use case: When doing e.g. a checkout or download, you may end up with a new package that is not yet loaded in the IDE. You need to be able to add that to depencencies.

Not all packages are installed in the IDE.

> The "clean up dependencies" should IMHO be removed, but that is a separate > topic entirely. Why? It is a very useful feature.

I don't see how.
IMHO it is even wrong, because I want to see explicitly all dependencies added to a package/project.

Package A (unitA) depends on Package B (UnitA uses unitB) and Package C (UnitA uses unitC). Package B depends on Package C (unitB uses unitC). Invoking the dialog in A will propose to remove the C from the dependencies of A (transitivity). That is IMHO not wanted. If I remove the depencency on B (no longer use UnitB) then the dependency on C is lost. Hence, C must remain in the dependencies of A.

Maybe there are other uses of this dialog that I am unaware of. But as I said: that is another discussion entirely :)

Michael.

[...] > Why? It is a very useful feature. I don't see how.

Some IDE functions added dependencies automatically, creating redundant dependencies. The clean up function allows to remedy this.

IMHO it is even wrong, because I want to see explicitly all dependencies added to a package/project.

Removing the "clean up" function will not help here. Maybe the project inspector can be extended to show indirectly used packages, so you can see all dependencies.

If you remove the dependency A-B, then there is probably a reason for that. For example A no longer works with B.

Mattias

See below.

Yes, but A still depends on C.
If the only link from A to C is through B, then removing B will result in a missing dependency.

Michael.

And if not?

If the only link from A to C is through B, then removing B will result in a missing dependency.

The "clean up" function does not remove the A-B.
The "clean up" function transforms one valid state into another valid state. And it shows what it will do and the programmer decides if this is good or not. There is no force or automatism.

There is nothing wrong with your policy to list all dependencies. Don't force your policy on others.

Mattias

If you read the explanation carefully, you'll see that that was a given.

> If the only link from A to C is through B, then removing B will result in a missing dependency. The "clean up" function does not remove the A-B.

Euh ? I didn't say that ?

I was trying to explain why I think that removing the explicit C dependency (which the dialog proposes to do) is potentially harmful at a later stage.

The "clean up" function transforms one valid state into another valid state. And it shows what it will do and the programmer decides if this is good or not. There is no force or automatism.

I didn't say that either :)

There is nothing wrong with your policy to list all dependencies. Don't force your policy on others.

? I don't want to.

From what I've seen till now, this dialog seems useless (and potentially harmful) to me.

But like I already stated, there may be uses that I am unaware of, which could justify the existence of this dialog even for me. (for instance, it could start comparing actual used units)

Anyway, the discussion was about the package dialog. The dependencies is another matter entirely.

Michael.

Maybe I misunderstand you completely.
You said the "clean up" function should be removed. That means it has no use to anyone. Right?

Mattias

No, because I think it is potentially harmful and has (to my mind) currently no useful function.

Both aspects are important. There are many other things I consider useless in the IDE, and I don't think they should be removed, I understand that other people use them (e.g. folding, build modes and many more :))

Are there any other functions in this dialog, or is the transitivity the only thing that it checks ? If there are no other functions, then yes, I don't see why it should exist.

But, I repeat:
Maybe I am not aware of other functionality of this dialog, now or planned for the future, that would justify its existence even for me. (for instance: checking actual usage of units, detecting units that are in a package which is not in the list etc.).

I get the impression you seem to think I am crusading to get this dialog removed, that's definitely not so. I just wondered out loud: 'why the hell would this exist ?' :)

So, relax, no one is crusading :)

Michael.