[Valloric]

Originally Posted by Jellby

I noticed that, but it may also be interesting to see only one file, and not the whole flow at once.

Currently this is the way Sigil works. Adding the ability to separately view and edit each XHTML file would require massive re-engineering of the importers, exporters and the entire GUI which is currently geared towards single-flow editing. I'm not ready to do that yet. Not any time soon. Maybe in Sigil 2.0.

Originally Posted by Jellby

Well, I meant the ability to separately edit the CSS files, and decide what styles go in each file, etc.

Since separate CSS files are loaded as separate style tags, and separate style tags get exported as separate CSS files, I don't see why you can't decide which styles go into which file right now.

Originally Posted by Jellby

Can't XHTML and CSS validators be modified? Even if the specs are different, being able to use the standard validators would probably be useful. And in the meantime just using epub-chek would be of help.

Would be lovely, wouldn't it? Especially embedding epub-check. But they are all written in Java. Sigil is in C++. I have no intention of requiring the Java runtime for Sigil. And no, GCJ is not an option.

Originally Posted by Jellby

But it's not separately editable. For instance, I like to have "P. G. Wodehouse" as author and "Wodehouse, Pelham Grenvile" as file-as.

Yes, I agree, it's somewhat limited right now. You can't have everything in a 0.1.0 release, now can you?

Originally Posted by Jellby

I was thinking of adding a generic "date" and make the "event" property editable.

I was thinking of users being able to add their own date elements. That is, I go to an options screen, click on something like "Add new date event", and then type in "Reprint" or whatever. A list of these custom date elements would be in a list near that button. I would then go to the Meta Editor and the new date type would be selectable in the "Add Basic" dialog. Of course, in the background this would merely change the event attribute on the date element created.

You have to think of options in the form of "How am I going to present this to the user in a simple and usable way?". This is absolutely crucial, which unfortunately many OSS developers don't understand.

The average user doesn't give a rat's ass about "date" elements and "event" attributes. He doesn't want to learn what those are, and he shouldn't have to. He is adding metadata. It is all being worked out for him in the background.

This is also why books are loaded as a single flow and not a separate file. The user doesn't care that it's all actually a bunch of files, he wants to edit the book. He's used Word. He's used Open Office. He's used Book Designer. It's always a single flow because in his mind he's editing one book, the epub file.

Yes, the power users are going to lose some of their flexibility. I'll do everything in my power to help these 5% of users if it doesn't negatively impact the user experience of the other 95%.

You sound like you want to edit all of the XHTML, CSS, XPGT files etc. as separate files in an editor that would in the end just wrap everything up into an epub. That's great. But that's not what Sigil is. Not right now anyway. If something like this is added, it would be accessible by explicitly switching to the "advanced" GUI. I have no immediate plans for making this happen, although I would like to add it somewhere down the line. But not any time soon. There are more important issues to attend to, and they impact the other 95%, if not everyone.

Originally Posted by Jellby

By the way. In dates it is possible to store only year or year and month information (not day), but it seems Sigil defaults to 01 when day or month are missing (i.e, "1950" is displayed as "01-01-1950"). I think that should be fixed (I know, I'll add an issue )

This is also a GUI issue first, and an implementation issue second. The QDate object used to store dates demands months and days specified. Using this native Qt object provides us with an effortless way to edit them in a GUI: just shove the QDate into a TableView (like in Meta Editor) and the user is limited to entering only valid days, years and months. Each field in the date can be edited separately, and the object restrains the user to only valid values. Adding support for inserting only some parts of a date would mean ditching the native QDate objects and forcing users to type everything in as a text string.

Validating their input would be difficult at best. What format should they use? MM-DD-YYYY? DD-MM-YYYY? Dot's instead of dashes? What happens when the user types in "blabla"?

Americans want to use their weird middle-endian date format and I don't want to force them or the rest of the world to one version. QDate automatically changes it's display according to the locale.

My point with this is that enabling partial insertion of dates is more difficult than it seems and will have to wait until other issues are sorted out first. For now just use 1.1.YYYY. if you don't know the month or day.