Suggestions for Sigil Improvements or New Features

[BetterRed]

You're right, a ONCE ONLY notify, some of us are not blessed by the Lord with perfect recall.

No worries, I'll use Windows reminders.

[KevinH]

Most linux distributions turn off that feature since they only want you to upgrade to the distribution's tested builds. And for Windows and Mac, the only other way to check would be to poll Sigil's version.xml file in github much more frequently, but polling that file more frequently generates unwanted network traffic.

We think our version of update checking is fine.

[PeterT]

Originally Posted by BetterRed

You're right, a ONCE ONLY notify, some of us are not blessed by the Lord with perfect recall.

No worries, I'll use Windows reminders.

I've taken to using the Windows winget command to handle updates. A simple batch file on the desktop that just does a winget update -r to automagically download and install any needed updates.

[DiapDealer]

UniGetUI can also notify (as well as automatically update) for your winget needs, but it's gotten just a little bit difficult to tame in my opinion. It wants to handle updates for winget, pip, scoop, npm, chocolatey, et al -- all right out of the box. You can turn any of that off of course, but in my opinion the UI part of UniGetUI has become quite unintuitive and clunky.

[KevinH]

Okay, for those who are interested in Automation, I have created a work-in-progress of implementing Automation Lists like plugins with their own top level Automation menu with "Manage", "Run", "Edit" submenus that are dynamically built on the fly, along with converting the Automate tool bar buttons in QuickLaunch buttons you can assign to any list.

All of this is a very invasive change. It seems to me to place way too much energy and time into Automate Lists that are generally little to not used by most people. I was okay when it was just a toolbar icon, but this makes it a full fledged top level Automation menu with dynamic naming of Automation Lists possible as some people have requested.

If you want these changes as a new feature in an upcoming version of Sigil, I will need to hear from you.

For those who build your own, I have pushed this work in progress version of Sigil to my personal repo into the master branch:

https://github.com/kevinhendricks/Sigil

Please pull from there and build it and please provide feedback. Is this overkill? Should we tone this down to something much simpler (say just limit to 5 lists and not allow dynamic naming)?

Happy to hear pros and cons from anyone here.

I have built a Mac arm64 version of this and posted that build if anyone is interested. My Windows build is down, and since this is in my personal repo, we do not have access to CI builds. If anyone else makes a Window builds to share I will post it, too.

Here is a link to a Sigil.app Beta:

https://github.com/kevinhendricks/Bu...nMac/releases/

Grab Sigil.app-beta-Mac-arm64.tar.xz (it is signed and notarized)

And DNSB has nicely donated his Windows build which I have posted to my BuildSigilOnMac repo (same link above) as:

Sigil-beta-Windows-x64-Setup.exe

So please give it a try and let me know your feelings one way or the other.

[un_pogaz]

Hrf, I can't test the changes (Linux/Arch), but thank you for working on it. At least it will have been considered.

Else, a remark: If this change is accepted, wouldn't it be more practical to store the automation into a folder "automate/<string_id>.txt"? Scan all files in a folder containing with certainty an arbitrary number of automate, rather that instpect the root setting folder that contain many others unrelated thing?
On the other hand, I agree that this requires adding a migration function, but moving three files in a folder seems pretty light to me.

[Capricorn]

implementing Automation Lists like plugins with their own top level Automation menu with "Manage", "Run", "Edit" submenus:
I use the automation lists almost every day. So, yes, I like that idea of automation lists like plugins, as it would help to adapt it quickly.

[philja]

Re: Automation lists
I've tried your beta Mac arm version on my Macbook and first impressions are that it's a really great improvement. It works fine and although 5 lists might be enough for me at present, I think I'd soon outgrow that - like with saved searches.

I'm personally not bothered by only having 3 icons. I'm not a great user of icons on toolbars - they provide too much clutter for me and tax my memory as to what each icon represents.

Once a new automation has been named, it seems that the name cannot be edited? I do like user friendly names.

[KevinH]

Some responses ...

- Renaming an automation list is a possible addition to the Manage Automation dialog. I will consider adding it if this moves forward. But you can right now manually rename those files in Sigil Prefs before launching Sigil, and Sigil will handle it. The format is "automate" + your unique identifier + ".txt".

- Yes using an automation folder inside Sigil Prefs would be easier but would break backwards compatibility. And to make things worse you would have to add a function in main.cpp to move those files into a folder, and it would have to exist for all time moving forward as people skip Sigil updates at times. Walking files (and no subfolders) in Sigil Prefs in quite fast and easy.

- Building Sigil on Linux Arch and Manjaro is quite easy to do. There are instructions for doing that, if you want to have a say on how things proceed in this case.

[KevinH]

Also, even if you are not a heavy user of automation, we need to hear your input on this proposed change.

As I said earlier, it is major/invasive change to Sigil's user interface, so I really do not want to go ahead with it if its presence is going to turn off some/many users. The Sigil user interface is getting huge. That is okay for a professional tool but does limit is appeal for many non-professional users.

All feedback welcome.

Personally ... I believe both "overkill" and "enshitification" are real and can happen incrementally and inadvertently even to open source projects. It is just something we must guard against. And Sigil can really only have a limited number of main menus in its ui and stay reasonable. If Automation is one of them that people want, I am okay with it. But only if it is truly useful like "CheckPoints", and "Plugins" were.

[philja]

Originally Posted by KevinH

Also, even if you are not a heavy user of automation, we need to hear your input on this proposed change.

As I said earlier, it is major/invasive change to Sigil's user interface, so I really do not want to go ahead with it if its presence is going to turn off some/many users. The Sigil user interface is getting huge. That is okay for a professional tool but does limit is appeal for many non-professional users.

All feedback welcome.

Personally ... I believe both "overkill" and "enshitification" are real and can happen incrementally and inadvertently even to open source projects. It is just something we must guard against. And Sigil can really only have a limited number of main menus in its ui and stay reasonable. If Automation is one of them that people want, I am okay with it. But only if it is truly useful like "CheckPoints", and "Plugins" were.

I don't see the addition of an 'automation' item on the main menu bar as a major invasive change. On the contrary, the improved functionality makes it worthwhile (for me).

But, if you want to keep it minimalist, could the 'automation' entry be in the Tools dropdown listing? That would also be a logical place to find it and, in my experience, the operations on and by an automation list entry are very similar to what we get for the Saved Searches entry under the Tools menu heading.

Most of the clutter on my Sigils' interfaces comes from the icons display, where I shut down as many Toolbars as I can and decrease their size to prevent them from taking up multiple rows.

[KevinH]

But you can turn off all the toolbars in the View menu. So users who did not use Automation could always hide that toolbar. I do not think adding more to the Tools menu is the answer as that menu is already cluttered.

I just want to be assured that adding an Automation top level menu is the right thing to do for the majority of Sigil users.

From a code perspective this change is quite invasive as the code requires its own new dialog, its own main menu, its own dynamically built menus that need to be torn down and rebuilt on the fly, a way to associate list names with toolbar buttons and remember them, etc. That was okay for a major new feature like plugins that everybody uses. It may not be right for a feature like Automation.

This is why am I am asking for broader feedback. Not just from the handful of people who requested an extended automation feature.

[DiapDealer]

I could provide an AppImage built from Kevin's fork fairly easily if there's enough interest in testing the proposed feature (especially among the folk whose distros might not provide new enough dependencies in their repos to build Sigil properly).

[KevinH]

I have now pushed a change to Sigil master to save up to 9 most recent files in the Files menu. This was just a one line change that needed no other supporting changes to work. We can revisit this at a future time if people really need more but let's try this first.

This change will appear in the next release of Sigil.

[un_pogaz]

I finaly can build it.
The change are realy good, realy fresh. Inside the Manage Automation dialog I will add a button "edit" and "rename", but detail.
Like philja, the automation entry in the menu bar is small and discret, and only have 3 icons for favorites automations is more than enough for me.
I have great hope and eagerly awaiting this feature to be approved. I love the automation feature, but being limited to three realy kill the feature for me. Is too short. I use several automations, and to overcome Sigil's limitations, I had to create plugins for the "add more of them".

I understand your concerns about "overkill" and "enshitification," but insofar as the automations is already a feature in Sigil, make it ala plugins is more a "tweark" of existing one, rather that creating a new ex-nihilo.
On that, I agree that Sigil is realy complet, and realy the limite of automation is my only point to raise.