Suggestions for Sigil Improvements or New Features

[KevinH]

If we add a rename and edit button to the Manage Automation Dialog should we then remove the Edit submenu completely leaving just the Run menu?

Originally Posted by 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.

[philja]

Originally Posted by KevinH

If we add a rename and edit button to the Manage Automation Dialog should we then remove the Edit submenu completely leaving just the Run menu?

Bravo, un_pogaz! Yes, that sounds like a reasonable simplification.

[KevinH]

Yes, quite a large simplification as it removes an entire dynamic menu and its entries as well as removes 3 interface routines in a quite large and already crowded MainWindow.cpp.

So I just added support for a rename and edit buttons to the ManageAutomation dialog and moved all editing to that Dialog.

I think that is a nice compromise.

I have just pushed these changes to my personal Sigil repo (see earlier link).
So if you build your own, please feel free.

That said, I think the existing betas are close enough to get a feel for this feature and so that users can evaluate it and comment.

So far, I have heard only positive feedback for this feature and no one (but me!) has expressed any reservations.

So if you have an opinion one way or the other and want to be heard, please add to this thread.

[DiapDealer]

I've not tried it yet. But then I don't really utilize Automations anyway. I would really like to hear from users other than the few who were pushing for the feature in the first place. Major overhauls to Sigil's codebase for the satisfaction of a handful of people doesn't make me feel warm and fuzzy if I'm honest. If it could be accomplished with a tweak here or there, that would be one thing. I'd sure feel better about it if people who never really gave something like this much thought started warming up to the notion. But there seems to be a bit of an echo chamber happening so far. **shrug**

[DNSB]

For myself, I have two Automations I use with almost every ePub I edit. The current 3rd automation gets edited on a regular basis to add whatever I currently want it to do. Something that I would personally use but might be a bit of a pain to implement would be allowing conditional Saved Searches to be run in an automation which would save me a couple of mouse clicks in most edit sessions.

Edit: I know I can run a saved search with replace all but what I was looking at was a conditional saved search based on a result from a previous saved search. If the previous search did a modification then run the second search otherwise skip it. For now, I just look at the number of replacements done.

[un_pogaz]

Originally Posted by KevinH

Yes, quite a large simplification as it removes an entire dynamic menu and its entries as well as removes 3 interface routines in a quite large and already crowded MainWindow.cpp.

So I just added support for a rename and edit buttons to the ManageAutomation dialog and moved all editing to that Dialog.

I think that is a nice compromise.

Thanks, perfect.
Else, I see that Sigil don't reasigne previous automation to the corresponding icons. That would be convenient, but if it can't be done safely, not a big deal (note to migration imcompatibility).

---

Originally Posted by DiapDealer

But there seems to be a bit of an echo chamber happening so far.

Even so, I strongly recomande do make it expandable and dynamic. If the user want to use 3, 10 or 0 automations, they free to do so. When currently limit to 3 automation imposes this choice on all users and seem arbitrary to me.

[DiapDealer]

Originally Posted by un_pogaz

When currently limit to 3 automation imposes this choice on all users and seem arbitrary to me.

Of course it would seem arbitrary to you. You're a heavy automation user. What your're missing is that there are countless more users out there who never use them at all. Who might have to contend with potential bugs that major code changes (for the few) could introduce.

We get that you like the proposal. Your position is noted. Now we'd like to hear from others.

[KevinH]

Originally Posted by DNSB

For myself, I have two Automations I use with almost every ePub I edit. The current 3rd automation gets edited on a regular basis to add whatever I currently want it to do. Something that I would personally use but might be a bit of a pain to implement would be allowing conditional Saved Searches to be run in an automation which would save me a couple of mouse clicks in most edit sessions.

Edit: I know I can run a saved search with replace all but what I was looking at was a conditional saved search based on a result from a previous saved search. If the previous search did a modification then run the second search otherwise skip it. For now, I just look at the number of replacements done.

Please be more specific? What exactly do you mean by "conditional"? Do you really mean "any modification" by the previous saved search?

A small example here would really help I think.

Also, how do you feel about the overall change to use a main menu and dynamic names? I could not tell if you were overall pro or con or neutral.

Thanks,

[DNSB]

What I meant is to be able to look at the results of the previous search/replace to decide if the current search will be run. This would need two possibilities for the conditional. If results equal 0, skip otherwise execute. If results not equal to 0, skip otherwise execute.

Mildly in favour of the change. I can live with either but the new setup is more aesthetically pleasing to me.

[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?

[odamizu]

Originally Posted by DiapDealer

... I would really like to hear from users other than the few who were pushing for the feature in the first place. Major overhauls to Sigil's codebase for the satisfaction of a handful of people doesn't make me feel warm and fuzzy if I'm honest. If it could be accomplished with a tweak here or there, that would be one thing. I'd sure feel better about it if people who never really gave something like this much thought started warming up to the notion. But there seems to be a bit of an echo chamber happening so far. **shrug**

Originally Posted by KevinH

... 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 ... This is why am I am asking for broader feedback. Not just from the handful of people who requested an extended automation feature.

I am content with Automations as they currently exist in Sigil.

I have 3 simple Automations but really only use 2.

I also have no need for Automation to be expanded, and the phrases "major overhaul" and "invasive" make me wary.

Just my 2 cents. Thank you

[KevinH]

The terms "invasive" and "overhaul" describe the amount of work that was done to add that feature (ie. lines of code touched, changes to headers, etc). That just means lots of testing will be needed. We are in no rush to release anything so there will be time for testing and bug hunting if needed.

My real concern is the addition to a new top level menu, as the number of top level windows are finite and limited especially by smaller screen systems. So do we use up a main menu for a feature request that may not help many users. That is the question that needs to be answered by users.

[retiredbiker]

Originally Posted by KevinH

The terms "invasive" and "overhaul" describe the amount of work that was done to add that feature (ie. lines of code touched, changes to headers, etc). That just means lots of testing will be needed. We are in no rush to release anything so there will be time for testing and bug hunting if needed.

My real concern is the addition to a new top level menu, as the number of top level windows are finite and limited especially by smaller screen systems. So do we use up a main menu for a feature request that may not help many users. That is the question that needs to be answered by users.

For myself, I don't use any automation; I just have not needed it. Most of my editing work is in LibreOffice. If I get everything right there, Sigil makes a near-perfect epub out of it and I have little editing left to do.

[theducks]

The closest to automation I use is saved S&R groups. And that has been there for a long time.

[KevinH]

I will look to see how easy it would be to use the View menu to hide the entire top level Automate menu. If that is doable without causing new problems, then if we decide to go ahead, users can hide it completely. Maybe the best of both worlds, as it re-simplifies the ui for the majority of users, and those interested in Automation lists can enable it.