Suggestions for Sigil Improvements or New Features

[DNSB]

Originally Posted by KevinH

Since the Find replaceall command returns the number of replacements made, inside Autmate() we could store that count in a variable (something like m_last_replacement count) and create two new search automation commands: one that only run its search if m_last_replacement count > 0 and and one that only runs its search if m_ last_replacement_count == 0.

This would only work with running saved searches. Would that be useful?

That is pretty much what I wanted. Not a high priority item as I suspect I may be in a very small group who have multiple searches that are run/not run in sequence.

[KevinH]

Okay, as a hopeful compromise, it turns out to be quite easy to tie the visibility of the entire dynamic top level Automation menu to the current Automation toolbar visibility.

So if a user has no need of automation lists, they can use current Sigil's View->ToolBars menu to hide the Automation Lists toolbar. Doing so, will hide the top level Automation menu completely. That will simplify the Sigil back to what is currently is now for those who do not use Automation lists. Nothing is lost or gained.

If a user wants to use Automation Lists , they can use the Sigil View->Toolbar menu to enable Automation Lists, and they will see both the Automation ToolBar for fast launching plus the new Automation top level menu (which they will need to assign associations and edit Automation Lists) as well as to run more than 3 automation lists.

These settings are remembered across Sigil's launches.

How does that compromise sound? Can everyone live with that?

In case you want to see it in action (and you build your own) please check out my personal Sigil github repo master branch. A link was provided earlier in this thread.

All feedback welcome.

[philja]

Originally Posted by KevinH

Okay, as a hopeful compromise, it turns out to be quite easy to tie the visibility of the entire dynamic top level Automation menu to the current Automation toolbar visibility.

These settings are remembered across Sigil's launches.

How does that compromise sound? Can everyone live with that?

All feedback welcome.

Sounds like an ideal compromise.

[un_pogaz]

Just test it and realy neat.

But depending of toolbar to display a top-level menu entry sound a bit weird to me because I'm used to assuming that the top-level menu will provide all the feature available in a software program, and that the icons toolbar is just shortcuts for the most used by the user that can custom it. That say, the automations was not availible elsewhere than in the toolbar so not a great change overhaul.

... and also raise a question: If we can do that for Automations menu, can we do that for the Checkpoints one? I don't use this feature, so this would free up space that the Automation menu will take.

urh. Maybe better that make it conditional to toolbar, it would give more granularity and customization to add a options somewhere in the Preference "Hide/show top-level menu" for each of this two entrys.

[BeckyEbook]

I built Sigil from your repository. Indeed, it works great. Users who don't use Automation don't have a menu or toolbar.
It's a very clever solution, so I'm all for it.

Overall, supporting more automation lists, the ability to rename them, and easy assignment to three icons are very good ideas.

---

One small note: I would move the "OK" button in the "Manage Automation Lists" window a little.

---

@un_pogaz's ideas are also worth considering, but there are some doubts:

• Automation did not have a menu before, so linking the menu display to the toolbar seems OK.
• Checkpoints had a menu and a toolbar, so “keyboard users” could disable the toolbar but still have the menu and keyboard shortcuts. The current situation with "Checkpoints" is relatively neutral (it's about users getting used to the menu layout).
• We need to check whether disabling/hiding the menu causes the shortcuts to stop working.
• I don't know – maybe the latest proposal for an enable/disable option for the Checkpoints/Automation menu is worth considering? Then @BetterRed and other heavy keyboard users won't complain.

[BetterRed]

Originally Posted by BeckyEbook

. . .
Then @BetterRed and other heavy keyboard users won't complain.

I assumed my reading of Kevin's proposal… to access the Automation features from the menu bar, you will have to enable the Automation toolbar - was erroneous.

But after reading un_pogaz's and your replies it seems my reading was correct.

Apart from being navigable with one finger, most menus… including Sigil's… show the associated keyboard shortcuts.



It's the first place I look when I forget one… much easier than fishing out cheat sheets and burrowing into Preference settings.

Most toolbar button interfaces don't show them… including Sigil's. Some show them in tooltips… but that means holding the mouse still.

BR

[KevinH]

Originally Posted by BetterRed

I assumed my reading of Kevin's proposal… to access the Automation features from the menu bar, you will have to enable the Automation toolbar - was erroneous.

But after reading un_pogaz's and your replies it seems my reading was correct.

Apart from being navigable with one finger, most menus… including Sigil's… show the associated keyboard shortcuts.

Attachment 218619

It's the first place I look when I forget one… much easier than fishing out cheat sheets and burrowing into Preference settings.

Most toolbar button interfaces don't show them… including Sigil's. Some show them in tooltips… but that means holding the mouse still.

BR

I do not understand what you are trying to say? Yes to see the new top-level Automation menu in this proposed compromise solution you have to enable the Automation Lists in the View->Toolbars menu.

Does not the Toolbars menu at the top of the View's Menu work properly currently in Sigil?

Overall, are you for or against or neutral on the addition of a top level Automation menu?

Does this compromise work for you?

[KevinH]

No, checkpoints are a key safety feature to protect all users and are a really good idea in general for everyone to use. The Checkpoints menu will not be made optional.

You can successfully use Sigil and never once use its Automation features in fact, few users do. Automation up to this point is only available via toolbars.
If we add a top level dynamic Automation menu, then to keep Sigil's ui as simple as possible (again since most users do not use Automation and some do not want this feature), I thought as a compromise we would tie its visibility to the previously required toolbar that is the only way now to use it so the user could control it.

If people are not happy with this compromise, I guess I could make showing/hiding a top level Automation menu a Sigil user preference instead.

This is the approach used by almost all browsers for their "Developer" or "Develop" top level menus all the time. It would then default to off for most new installs of Sigil but could be enabled by a user. It would then hide the Automation toolbar as well hiding its toolbar since with no way to edit or associate lists with the toolbar buttons makes them worthless.

Would that be better? If there is no good compromise solution, then the whole idea of adding a dynamic top-level Automation menu would need to put on the back burner until a good solution that works for everyone is found.

Kevin

Originally Posted by un_pogaz

Just test it and realy neat.

But depending of toolbar to display a top-level menu entry sound a bit weird to me because I'm used to assuming that the top-level menu will provide all the feature available in a software program, and that the icons toolbar is just shortcuts for the most used by the user that can custom it. That say, the automations was not availible elsewhere than in the toolbar so not a great change overhaul.

... and also raise a question: If we can do that for Automations menu, can we do that for the Checkpoints one? I don't use this feature, so this would free up space that the Automation menu will take.

urh. Maybe better that make it conditional to toolbar, it would give more granularity and customization to add a options somewhere in the Preference "Hide/show top-level menu" for each of this two entrys.

[DiapDealer]

Originally Posted by un_pogaz

I'm used to assuming that the top-level menu will provide all the feature available in a software program,

There's your mistake right there. Many programs have advanced features that first need to be enabled in order to access them.

[un_pogaz]

I'm okay, it's a very good compromise, it pretty neat. Just a passing thought which have been clarified, thanks.

[KevinH]

Given what everyone has said, if we go ahead with this top level Automation menu we should at least treat it like Browsers treat the "Develop" menu in our Sigil Preferences just to be consistent with what most users would expect.

So if You look into Sigil Preferences under "Appearance", then click on the "Main UI" tab, I would add a new settings group to the bottom of that tab.

It would have the group title "Automation Menu (Advanced)"
Then indented under it a a check box with:
[-/] Show Automation Menu

The user can show then check or uncheck this as needed.

I will add a SettingsStore routines to store and access its value:

void setShowAutomation(bool);

bool showAutomation();

That will decouple the ToolBar from the Automation menu completely be something more inline with Browser "Develop" menu preferences.

Is everyone okay with this? If so I can make that change and put the whole thing to bed.

Speak now or forever hold your peace (as they say!)

[un_pogaz]

Perfect

[BeckyEbook]

I'm in favor of it too. The option in Preferences will give everyone the freedom to choose.

[DiapDealer]

I hate it!

Just kidding.

[KevinH]

Originally Posted by DiapDealer

I hate it!

Just kidding.

Whew!


Okay I have changed to use Sigil Preferences to control if that menu is visible or not. And broke the ties between the Automation Toolbar showing and the Automation menu itself showing.

Hopefully this is the last modification..

I have pushed all of this to my repo master so if you build your own, please take a peak and test it.


@BeckyEbook what did you mean about adding a space above the Okay button in the ManageAutomationDialog? Please see my screenshot below. There appears to be a reasonable distance to the Okay button (at least on a Mac).