IDE toolbar

[balazsszekely]

Hi,

Is this a useful IDE feature? Please watch the video in HD(720)!
http://youtu.be/YCCdoaNwvP8

regards,
GetMem

[Martin_fr]

Very useful / Great.

Is it (Or will it be) persistent (save and restore when IDE is closed and reopened)?

You should submit a patch (mantis). So it can be reviewed (and if needed coding style and implementation can be discussed)

I am not yet sure who from the team will look at it. But it definitely would be nice to add.

[Blaazen]

What visual componet is used for toolbars ?

[balazsszekely]

@Martin_fr

Is it (Or will it be) persistent (save and restore when IDE is closed and reopened)?

It will be persistent, it's not yet implemented though.

I am not yet sure who from the team will look at it. But it definitely would be nice to add.

We already did some IDE improvement with Juha Manninen, if he agrees I would like to work with him.

@Blaazen

What visual componet is used for toolbars ?

I put the original Toolbar to a TPanel +  implemented some drag and drop features + created the option panel. It's really not a big deal...
The main advantage is: we can get rid of the horizontal component palette and use the more advanced Components window(has a search bar, it's much easier to locate components). Of course this is a personal preference, some people may prefer the classical, horizontal palette.

[JuhaManninen]

We already did some IDE improvement with Juha Manninen, if he agrees I would like to work with him.

Yes I am ready. Your improvements for the component list were good. I know the component palette code now well after I made it configurable.
Your changes shown in the video look good and I believe they can be applied.
However they will not be enough. We must rethink "out of the box" the whole palette GUI. Now it has some serious issues:

1. The palette tab-control and the list window are not truly equal alternatives to each other. The palette can be hidden but not moved or docked anywhere else. This will be even a bigger problem if tabs are split into multible rows which is a reasonable feature request.
I think the main window is not part of the docking system mainly because of the palette. This is one more reason to redesign it.

2. It should be possible to hide the whole palette or list when there are no Forms or DataModules where to put components, and maybe replace it with something else. The current DataModule filtering is kind of a half-ass solution. It hides the components which cannot be placed on a DataModule, logically it should hide all of them if there is neither a Form nor a DataModule.
Delphi has solved this problem with a context aware component list.

Number 2 is a complex issue. What to show instead of components in a context aware system? Should the IDE main menu be context aware, too? Et cetera ...

Number 1 should be improved by making the palette a separate dockable window. It requires changes to the palette API in IDEIntf. Now it is hard-coded to some GUI controls. I can look at that.
Then the main window should be included in docking as a dock-host window. Unfortunately I don't know AnchorDocking well.

[balazsszekely]

I did understood part2, which is indeed a complex issue.
Part1 should look like this(or something similar)?

http://youtu.be/D58il0OjfLw

Other then multiple lines in the component palette and the possibility to dock/undock, what would be the benefit of the new component palette window. This way, we will have two very similar(not quite the same) window: components(List, Palette, Inheritance) and the newly created component palette window.

[kapibara]

@GetMem Nice work! It could be an option. But getting rid of the horizontal component palette is a really bad idea. I think the current component palette is fast and easy to work with and doesn't use up extra horizontal space. Beginners who doesn't know where the components are can simply rightclick the component palette and select view all. Personally, I would not use the Components window because it takes up too much space on the screen, hiding forms and code. And I would go nuts having to hide/show it every time it was needed to drop a component on a form. But for some it might be just right.

[balazsszekely]

@kapibara
But getting rid of the horizontal component palette is a really bad idea.

You're right. What I meant to say is to have the possibility to hide the component palette. If you install Indy and IBObjects(this is just an example), finding a specific component it's very tedious, that's why I prefer the components window.

[kapibara]

True, Indy creates so many tabs you can scroll for ever. My solution was to put Indys tabs last on the palette. When I need an Indy component I press "end" to jump last. Or right click palette and "view all".

Anyway I'm sure some users would like the components window too, so please dont take my comments as critique of your effort.

[JuhaManninen]

Other then multiple lines in the component palette and the possibility to dock/undock, what would be the benefit of the new component palette window. This way, we will have two very similar(not quite the same) window: components(List, Palette, Inheritance) and the newly created component palette window.

Nice video again.
I actually meant the window should be dockable with AnchorDocking like the other windows are. Then it would be an equal alternative with them. That requires of course that the main window is made a possible dock-site.
Now I understand that is a problem when no docking is used. It must have an alternative docking as your version has. Complicated ...
There can be temporary / experimental versions in trunk. If you want to make a patch, go ahead.

The palette is surely needed. Even Delphi got an external DDevExtensions palette because they did not provide one themselves any more.
There could be even other alternative GUIs for components, although I don't know what exactly.
The 3 panes in the component list could also be separated into their own windows.