What Features or Tools does Sigil Still Need Yet?

[KevinH]

Darn! DiapDealer beat me to it!


This is actually not a bug. If you look closely at the image you posted from Sigil Preferences you will see you have made "Bell" the Default dictionary (Note: "default" is just a dictionary name like "Bell". Any dictionary name can be set to be the Default dictioanry. See my attached screenshot of your image.

If I add an additional user dictionary and call it test. I can enable it in those Preferences but I have to make sure that I have not made it the "Default" dictionary.

I can then run your test and it all passes.

So try again but this time make sure Default is set to "default" when you exit Sigil Preferences.

Hope this helps.

Kevin

Originally Posted by Ashjuk

Thanks Kevin.

Here is what I do if anyone else wishes to try it.

1. Open any book
2. Go to Edit/Preferences/Spellcheck Dictionaries
3. Click on Add and create new dictionary for the book.
4. Open any chapter.
5. In code-view right-click any underlined misspelt word.
6. Click on Add To Default Dictionary.
7. Check in code-view that word is no longer underlined.
8. Go to Edit/Preferences/Spellcheck Dictionaries and remove the dictionary created at step 3.
9. Close and return to code-view and check word again.

If the word is once again underlined it shows that the word was added to the dictionary created for the book and not the default as per the menu.

[BeckyEbook]

Originally Posted by KevinH

The key is that for a word to be under the cursor the cursor must be in one of the positions indicated by the '|' below, not after the word (one spot for each letter).

|w|o|r|d

So to me it appears to work as expected. What am I missing?

Hmmm…
For me, it works ALSO when I am standing AFTER THE WORD, except when there is also an opening or closing tag in this place.

|w|o|r|d| --> YES
|w|o|r|d</p> --- NO
|w|o|r|d<b> --- NO

[KevinH]

But that must be something Qt specific then. If followed by a space or whitespace is will select backwards. If followed by text it will select forwards. It should never select backwards in my opinion. Either way there is not a lot of control I have over selecting backwards or not.
I would have to create my own routine to do that and I really do not want to do that for so minor a thing.

Thanks for testing it and reporting back. I will leave it as is (a quirk of Qt internal selection).

[BeckyEbook]

I don't think there's a need to change – you just have to be aware that it's better to stand at the beginning or middle of a word and you'll be fine.

Inserting tags for individual words is now so fast that you can get addicted

[Ashjuk]

Originally Posted by DiapDealer

I think a big part of the confusion here is that "Bell" IS your default user dictionary. As indicated by the text "Default dictionary: Bell" in the lower portion of the dialog you posted an image of in your above post.

And since "Bell" and your default dictionary are in fact one and the same, it is only natural there is no difference between choosing to add to the default user dictionary, or choosing to specifically add it to the "Bell" user dictionary.

Selecting a user dictionary in the preferences and then clicking 'OK' makes that dictionary the default directory (check out the tooltip when mousing over a blank area in the user dictionary list). There is no all-time-default user dictionary--even if it happens to be named "default". Just rename it something other than "default" if you want to avoid confusion.

Originally Posted by KevinH

Darn! DiapDealer beat me to it!


This is actually not a bug. If you look closely at the image you posted from Sigil Preferences you will see you have made "Bell" the Default dictionary (Note: "default" is just a dictionary name like "Bell". Any dictionary name can be set to be the Default dictioanry. See my attached screenshot of your image.

If I add an additional user dictionary and call it test. I can enable it in those Preferences but I have to make sure that I have not made it the "Default" dictionary.

I can then run your test and it all passes.

So try again but this time make sure Default is set to "default" when you exit Sigil Preferences.

Hope this helps.

Kevin

Thanks guys.

I have to admit that I had completely missed that at the bottom of the dialogue box.

I have just tried it and see that whenever you add a new dictionary that one becomes the default.

Personally I find that counter-intuitive, in my mind the default dictionary should always be 'default' and not change to a user created one.

Perhaps it might be a good idea to make the default dictionary fixed as such - that way the right-click Add To Default Dictionary would function as it reads at all times and add to 'default' irrespective of how many other user created dictionaries there are.

Anyway I will remember that next time.

[DiapDealer]

Originally Posted by Ashjuk

Perhaps it might be a good idea to make the default dictionary fixed as such - that way the right-click Add To Default Dictionary would function as it reads at all times and add to 'default' irrespective of how many other user created dictionaries there are.

Why would we want to take away someones ability to define their own default user dictionary? Where would words go when selecting "Add to Default" if they deleted the user dictionary named "default" (as is their right and choice)?

You're getting hung up on semantics. "Add to Default" is not intended to mean "Add to the user dictionary named 'default'". It's intended to mean "Add to the user dictionary you've defined as your Default one".

We may entertain the notion of making choosing which user dictionary a user wants to select as their default more definitive. One that's not quite as fickle as accidentally leaving it selected (as in the case of creating a new one) in the dictionary dialog. But we're not going to hard code "Add to Default" to only ever add words to a user dictionary named "default".

[Ashjuk]

Originally Posted by DiapDealer

Why would we want to take away someones ability to define their own default user dictionary? Where would words go when selecting "Add to Default" if they deleted the user dictionary named "default" (as is their right and choice)?

You're getting hung up on semantics. "Add to Default" is not intended to mean "Add to the user dictionary named 'default'". It's intended to mean "Add to the user dictionary you've defined as your Default one".

We may entertain the notion of making choosing which user dictionary a user wants to select as their default more definitive. One that's not quite as fickle as accidentally leaving it selected (as in the case of creating a new one) in the dictionary dialog. But we're not going to hard code "Add to Default" to only ever add words to a user dictionary named "default".

Fair enough.

It just seemed a little odd to me that having a user dictionary named default - that is created automatically by Sigil - this is no longer the default when you add another alternatively named one.

Now that I know how it works I should not have any more issues.

[KevinH]

I started thinking more about this but I strongly dislike using a table with columns that are empty or represent more than one thing or or that simply do not make sense for a particular value.

If you split out main title and its file-as, and author (and its file as), language (primary and secondary), and use a big box for description ... you really need two different tables to handle most of the rest:

The first for other creators and contributors with 4 columns:

Marc-Function, Name, File-As, Creator vs Contributor

And the second scrolling table for all other name value pairs with columns:

Name, Value

This can hold all identifiers, all dates, all subjects, rights, formats, additional descriptions, sources, cover, and etc.

Shoehorning things into a single flat table like we did with epub2 just makes no sense to me.

That is why I like our existing MetaEditor. As differing columns just become added properties under the main entry. So the whole thing becomes a list which can be reordered easily and at will and effectively allows a variable number of columns to be available for any specific metadata entry.

So maybe a MetaData starter page with just this:

Title, File-As
Author1, File-As
Author2, File-As
Author3, File-As
Language1, Language2
Big Description Box

With a button to take you to the current MetaData Editor for all else.

Thoughts?

Alternatively we could stay with the current MetaEditor and try to replace all code pieces with translated names but keep the list with added extras approach, but try to do more to hide the code itself.

The actual menus to add Elements in the current, is really not far off the Add Basics we used before.

I just hated the table approach we used before as we just shoehorned various metadata length pieces into those misnamed columns.

Ideas? Thoughts?

Originally Posted by Doitsu

While Sigil has a fully functioning metadata editor, I liked the table-based design of earlier versions better.

Here's a mockup of a table-based metadata editor (based on my epub2 metadata plugin) that I'd like to see in a future version:



(The Title File-As box should be hidden for epub2 books.)

I know that it'll be difficult to create a solution that works for epub3 and epub2 books, but especially new Sigil users will probably prefer a table-based GUI over a tree-based GUI.

[KevinH]

The other thing I do not understand is why people think the current MetaData editor is so bad?

To use Sigil, you need to know basic html coding and basic css coding. You need to understand the layout of an epub, you need to understand media types, and urls, you need to understand the function of an ncx and nav, and opf. You need to understand regular expressions for advanced search and replace. You need to understand clips. You may even need to understand some basic javascript for epub3.

So Why on earth do we expect people who understand all of that to have an issue with dc metadata and simple things like that?

I still think Sigil should cater less to wysiwyg newbies and focus more of helping users and epub developers do things quickly and efficiently that need to be done.

If newbie users want to edit just MetaData and not the book itself, there are a large number of tools including calibre's library management software will let them do that without them having to know anything about css or anything about html at all.

So do we really need a "simpler" front-end for basic metadata. I would think a tool that would allow the user to create and change advanced metadata would be more useful.

What am I missing?

Perhaps time spent on improving and updating the User's manual should be of higher priority?

Comments? Thoughts? What level should Sigil really be targeting?

[KevinH]

In fact, you probably need a separate table just dedicated to titles.
You can have main titles, series titles, collection titles, titles in alternative languages, position in series, etc.

So 3 tables:

A table for titles
A table for Authors creators contributors
A table for all name: value style metadata

[KevinH]

Perhaps, a basic MetaData plugin would be best that just handles the simplest cases but that works for epub2 and epub3.

[Tex2002ans]

Originally Posted by KevinH

If you split out main title and its file-as, and author (and its file as), language (primary and secondary), and use a big box for description ... you really need two different tables to handle most of the rest:

There should at least be the 3 mandatory EPUB metadata:

• Title
• Author
• Language

I think these should stand out more prominently + NOT be deletable.

These 3 are also the most common use-case, so making these easy to find/read/adjust is a huge QoL improvement.

Originally Posted by KevinH

Alternatively we could stay with the current MetaEditor and try to replace all code pieces with translated names but keep the list with added extras approach, but try to do more to hide the code itself.

Yes.

Here's yet another example I just ran across.

I recently opened up Jellby's latest EPUB:

https://www.mobileread.com/forums/sh...d.php?t=335691

He made extensive use of metadata, but:

dc:contributor   Jellby
      opf:role   bkp
dc:creator       Ramón Cilla
      opf:role   ill

Off the top of your head, can you tell me what those 2 roles are?

While skimming through Add Property > Role... I'm assuming bkp = "Book Producer".

In that menu, names are human-readable, but no 3-letter code.

And in the main Metadata Editor, it's all 3-letter codes, but not human-readable.

Potential Enhancement #1

Making Add Property > Role a sortable 2-column format:

asg   Assignee
[...]
bkd   Book Designer
bkp   Book Producer
[...]
ill   Illustrator

(Sorted by 2nd column by default.)

Now that would be great. Then you could use it to find what you need OR an easy way to figure out what 3-letters = what.

I'm betting that would help even more in non-English, since Spanish might display:

bkp = Productor de libros

where English 3-letter-opf:role =/= foreign language spelled-out.

Imagine being a Spanish Sigil user, and trying to figure out what "bkp" stands for.

Potential Enhancement #2

Human-readable Metadata Editor.

Remove "code-speak" and replace with human language.

Current:

dc:title        Otros cuentos
dc:creator      José Fernández Bremón
  opf:file-as   
  opf:role      aut
dc:language     es
dc:contributor  Jellby
  opf:role      bkp
dc:creator      Ramón Cilla
  opf:role      ill

Potential:

Title           Otros cuentos
Creator         José Fernández Bremón
  File As   
  Role          Author
Language        Spanish
Contributor     Jellby
  Role          Book Producer
Creator         Ramón Cilla
  Role          Illustrator

I (ranted) about this back in 2017:

"Please, give us back old metadata tab!" (Post #24)

Other good info/ideas were buried in there.

And as I explained in that thread, the advanced code could still be there, just hidden under the surface.

When you double-click an entry to edit, perhaps the "real code" shows up:

• Double-clicking "Creator" -> "dc:creator".
• Double-clicking "File As" -> "opf:file-as".

Any sort of metadata that isn't normal, can still just display its code form.

Like in Jellby's EPUB, at the very end he has:

prince-style     pdfoutput_css

So even in the "human-readable editor", anything non-standard could still display straight code (just as it does now).

Originally Posted by KevinH

The other thing I do not understand is why people think the current MetaData editor is so bad?

A lot of these QoL adjustments not just help complete noobs, but also helps speed up advanced users.

Take Jellby's EPUB as an example.

Quick! What is the Language of this book?



Okay okay, you finally found it. But what about now?



Okay okay, you finally found it... But what about now?



Ahhh yes, Spanish. And it's right up top!

Oh, and those people were all Illustrators, I thought they were ill.

Side Note: Back in 2020, I wrote a little about (and linked to great videos) where a UX guy walked through an open source music program, MuseScore: Post #26, "Quick Question". He explains/shows how all these little niggles add up, and some minor QoL adjustments can really add up to help EVERYONE, at all skill levels, use the program more efficiently.

Originally Posted by KevinH

Perhaps time spent on improving and updating the User's manual should be of higher priority?

That may help as well, but not many people are helping on that front besides me.

And the ones that do write instructions/tutorial-type-stuff, tend to write too technical.

Perhaps still just focus where you're best, making Sigil better and better.

Originally Posted by KevinH

Comments? Thoughts? What level should Sigil really be targeting?

While yes, I think Sigil is an EPUB tool that's more towards intermediate/advanced, there's still a chunk of users that are just normal, non-technical authors.

Just a few days ago we had one wander into MobileRead:

"Sigil 1.4.3 - Validation Not Catching Errors Now"

Obviously she's not a complete "noob". She's used Sigil for many years, creating hundreds of EPUBs.

BUT she's not advanced/technical... just your typical author.

For that type of user, more simple, step-by-step instructions help. But not just her, they help ANYONE trying to use Sigil.

- - -

Let's say you wanted to validate your book, and you wanted to install FlightCrew:

Method #1:

Here you go:

https://github.com/Sigil-Ebook/flightcrew/releases
https://github.com/Sigil-Ebook/Sigil...idation-Plugin

Sigil Plugins: https://www.mobileread.com/forums/fo...play.php?f=268

Good luck.

Method #2:

Step-by-Step (with Pictures!):

https://www.mobileread.com/forums/sh...47#post4088447

Now, even someone who recently stumbled upon Sigil (or hasn't been following MR + all the Sigil threads for 5 years) could follow that.

Originally Posted by KevinH

Perhaps, a basic MetaData plugin would be best that just handles the simplest cases but that works for epub2 and epub3.

Maybe, maybe... but I think human-readable + splitting those 3 mandatory ones will be a HUGE step in the right direction!

[KevinH]

I think that Human Readable is doable. Right now we use the codes as they are language independent meaning when a user selects something in the Dialog you have to convert from a translated language specific string to a "code" at that time to build up the output.

In place of that, we could wait and do that once just as the metadata was being saved and once when it is loaded. Thereby keeping everything is its language specific form throughout the editing session.

I will play around with that approach first. Let's see just how doable that is without a complete redesign.

The key to this being an existing one to one mapping from language specific word to codes. This will be true for english but for all languages used in Sigil will some of the subtler differences result in different enough wordings. Many volunteer translators do not actually use the software itself.

Thanks for your input.

[KevinH]

As for title, author, and language, that is fine for epub 2, but order is significant and an expanded title might be more useful or mean more in epub3, author order matters, language order matters, title order matters so leaving them at the top alone and not part of the table to be moved around would not work. Preventing their deletion also makes no sense as a user may want to start fresh and deleting it may be the easiest option.

I am hoping making the output more readable is doable. And maybe adding a check for basics and warning the user on exit they are missing key pieces is doable, but keeping those items separate and not delete-able is too restrictive for epub3.

And I know people love epub2, but with the intl push in books especially in Europe and Japan means epub2 days are numbered if not already gone. Epub3 will eventually dominate. So supporting epub3 metadata well is definitely the goal for Sigil. And, Doitsu's Epub2Metadata Plugin covers epub2 metadata quite well already.

So I will take a shot at making the current editor be more human readable and add a warning telling people if they are missing the basic 3 and giving them a chance to rectify that which they will be ready to override at will.

Once I have something, we can post a few test builds for people to feed back on.

[Tex2002ans]

Originally Posted by KevinH

I think that Human Readable is doable.

[...]

I will play around with that approach first. Let's see just how doable that is without a complete redesign.

And I know I've opened up a bunch of EPUBs with disastrous metadata.

Nearly impossible to even disentangle it, so I tend to strip everything down to the barebones. (Hence also accidentally deleting mandatory metadata with the "Remove" button.)

Originally Posted by KevinH

Thanks for your input.