Feature Request(s)

[BeckyEbook]

Font 14pt

[KevinH]

So it just adds a scroller to the end of the clip bar.

Perhaps instead of 80, we reduce it to 60 with 30 per line? Or make segments of sets of 10?

[DiapDealer]

I'm not interested in doing much of anything, really.

Maybe if we reduced the number of clips per toolbar, more people would discover the Clips widget, which has no such limitation. The idea of 100 shortcuts being made available in linear format in the menu bar seems a little silly to me.

I'm not vehemently opposed or anything, I just don't get it.

[KarlG]

The advantage for me is that everything is immediately visible on the toolbar, whereas, depending on the size of the clips widget, scrolling is necessary

[KevinH]

Agreed, 80 (and more) may be a bit much but I could see maybe going from 20 per clip toolbar to 30 per clip tool bar (giving a total of 60 clip icons). There appears to be room on those bars and users can always hide both and use the clip window if they so desire.

[KevinH]

Originally Posted by KarlG

The advantage for me is that everything is immediately visible on the toolbar, whereas, depending on the size of the clips widget, scrolling is necessary

Now that you know how to tweak Sigil clips toolbars on your own you can have as many as you want.

We were discussing if Sigil master needs anymore than the 40 they have now or not. Typically making clips for very rarely used xhtml tags, and replicating existing h1-h6 tags icons may not be the most judicious use of clips.

By picking what clips to make wisely and following Pareto's 20% : 80% rule, most normal clip cases can be covered by the 40 existing clips icons available now, with rarer clips applied via the Clips Window..

[BeckyEbook]

Originally Posted by KevinH

By picking what clips to make wisely and following Pareto's 20% : 80% rule, most normal clip cases can be covered by the 40 existing clips icons available now, with rarer clips applied via the Clips Window..

I agree with this.
Toolbars with clips are very useful because using them is the fastest.
Add only the ones used most often to the toolbars and that should be enough for most users.
Clip Editor has more options and also allows you to group clips thematically.

IMHO I would not change this. 20+20 should be enough for "handy clips".

* * *

Returning to the issue of the invisible '>>' icon at the end of the toolbars: the problem only occurs on Windows in dark mode.
I have already worked out a simple solution, I will prepare PR once the new version of Sigil is released.

[KevinH]

Originally Posted by BeckyEbook

Returning to the issue of the invisible '>>' icon at the end of the toolbars: the problem only occurs on Windows in dark mode.
I have already worked out a simple solution, I will prepare PR once the new version of Sigil is released.

Great! Thank you!

[KarlG]

Originally Posted by KevinH

Now that you know how to tweak Sigil clips toolbars on your own you can have as many as you want.

We were discussing if Sigil master needs anymore than the 40 they have now or not. Typically making clips for very rarely used xhtml tags, and replicating existing h1-h6 tags icons may not be the most judicious use of clips.

By picking what clips to make wisely and following Pareto's 20% : 80% rule, most normal clip cases can be covered by the 40 existing clips icons available now, with rarer clips applied via the Clips Window..

Yes indeed, I can keep 40+40, because that's what I prefer, although it looks like I'll have to keep patching the source as, from the way the discussion is going now, it doesn't seem as if anyone wants to change the current setup.

I think saying that 'something isn't the most judicious use of clips' is purely subjective. Just because one could have 40 clips per toolbar, doesn't mean one should, but IMHO it's up to each individual user to decide what's 'judicious' and what's not.

Be nice if you would increase the number in HEAD, but if not then I suppose I'll just have either to live with constant patching or find out how one can keep a local copy in git updated with everything from HEAD but still keep local changes.

[KevinH]

When we make decisions for Sigil, we try to put ourselves into the shoes of a typical user of Sigil. Luckily, Sigil's main developers and contributors all use Sigil extensively and have for quite some time.

But given how bloated most software has become, and given the limited amount of time we have to spend supporting and developing Sigil, we need to make tradeoffs of new features versus usefulness for the typical user.

My argument was that with judicial choice and use of clips (and because of Pareto's 20% of features handle 80% of needs) that there is no significant benefit for the typical user of Sigil for adding to the current number of clip icons on the toolbar. Especially if the user chooses clips that are not redundant to existing tools.

Is that subjective? Yes. But some users can and do "misuse" features at times. So we just can not cater to all feature requests. We must evaluate each one wearing our "typical user" shoes.

That is the thought process we go through for most new feature suggestions.

But as I said, open source gives you the power to change things how you want it without having to worry about making any other users happy.

You can easily clone from Sigil's master branch in github, add in your changes which are all concentrated in main.ui. Make your build. Then when a new release of Sigil happens, you can pull directly from our github repo into yours and it will happily merge in your main.ui changes or alert you as to any merge conflicts if it can't. Plus the Sigil codebase evolves slowly making conflicts even less likely.

So no worries.

Hope this explains things.

[KarlG]

Yes absolutely. One man's meat is another man's poison and all that...

I was just a little bit disappointed because this change is only a few extra lines and if users use less than 20 clips per toolbar they probably wouldn't notice anything different anyway.

But of course, that's just the thin edge of wedge. As you say, you also have to think about the 'average' user and I can imagine it's not always easy to find a compromise.

It's fine, I already have a script which automatically downloads and compiles the latest version from master, so once i figure out the necessary git commands I'll make a diff of my changes and use it to keep my local copy updated with my changes.