I find it somewhat confusing that one reaches the
Prediffer settings over the "Dircompare" popup menu.
One should reach it central by the menu "Plugins".
Maybe with a "Settings" item or under the "Prediffer"
item.
(Here should stand "<Empty>" too, when there aren't
plugins, like at the "Scripts" menu.)
Plugins
-> ...
-> Prediffer
---> <Empty>
---> --------
---> No prediffer
---> Auto prediffer
-> --------
-> Reload plugins (debug)
Plugins
-> ...
-> Prediffer
---> <Empty>
-> --------
-> Settings
---> Prediffer
-----> No prediffer
-----> Auto prediffer
-> Reload plugins (debug)
Tim
Logged In: YES
user_id=804270
The problem in the dirview is that the list of plugins must be
updated when the selected files changed.
There are many many ways to change the selected files.
Point with mouse, arrows keys... and we are not going to
catch all this events.
Updating the enable/disable status, and the toggle/untoggle
one, is possible through the ON_UPDATE_COMMAND_UI event.
But not updating the order.
Personnally I like the "suggested plugins" and "other plugins"
categories. And I'd like to keep it for the mergeview.
Is it a big problem if plugins are unsorted in dirview, and
sorted in mergeview ?
Logged In: YES
user_id=652377
> Is it a big problem if plugins are unsorted in dirview, and
> sorted in mergeview ?
No big problem, i think it is better than nothing! ;)
Logged In: YES
user_id=631874
Slightly off-topic to this item, but can we remove that
'(debug)' part from 'Reload Plugins'? Yes I remember we
discussed it being used by plugin developers mostly, but
'debug' in release-version menu is a bit weird. :) Oh, and
words start with capital letters: 'No Prediffer'. And yet
another little bug: if there is no plugins loaded, 'Reload
plugins' is enabled.
Logged In: YES
user_id=804270
Remove '(debug)' : yes
Capital : yes
'Reload plugins' is enabled : it is normal, if you add a plugin
the directory, you may want to load it. The correct name
should be "Load plugins" in this case, but this entry is for us
developpers, no ?
Note for me : with OnInitMenuPopup, the submenu may be
updated just before it is displayed.
Logged In: YES
user_id=631874
Assigning to me since I really want to move plugin item out
of dirview context menu to main menu. Most users don't need
that item so it just wastes our menuspace and since its also
created dynamically it makes menu design harder than it
should be.
Logged In: YES
user_id=631874
Dropping from my list. I've tried couple of times without
success to get that dynamic menu working with normal menu in
mainmenu. Meaning there should be normal plugin menu items
and then dynamic list of availabel plugins.
Current situation is not nice, but I don't want to break
menus now.
Logged In: YES
user_id=787298
Originator: NO
Could this issue be looked into again? I find it very confusing that there is no central place to adjust a plug-in's options (Instead, some plug-ins require their own file name to be changed to reflect the options to be used, jikes!). If a plug-in has user configurable options, it should either be able to hook into WinMerge's option window to add a new page, or to a new "Options" menu below the "Plugins" main menu.
To do that, the plug-in API has to be extended to allow plug-ins to supply a HWND to their options dialog. See the foobar2000 SDK [1] for a good approach how plug-ins can add their options to the GUI of a modern C++ application.
[1] http://www.foobar2000.com/SDK.html
Logged In: YES
user_id=631874
Originator: NO
The problem is so far nobody has shown any interest in working with plugin code. It just needs real re-design which considers GUI, threading etc etc issues. Personally I have no interest or time.