Quote:
Originally Posted by kiwidude
Spending an hour fine tuning a document only to have it irreperably corrupted to start again has happened so many times to me that it corrupts my view as "very buggy" when in fact that particular issue is quite possibly just "one" bug. But for me it is a showstopper.
|
Ok, I've had that happen to me. The thing is, though, in every case, I could trace the fault back to
me typing in mangled xhtml, particularly on global find/replaces, or doing something stupid like deleting the closing </style> tag in a header, etc. The 'bug' was behind the keyboard. This doesn't deny the fact that the data loss that happened in such cases was indeed very annoying. I think the only real bug that bothered me was the intermittent issue with find/replace commands being automatically reverted so you'd have to issue them twice.
Now, I think it's very valid to complain that Sigil should be more forgiving of users who type in mangled code, and it seems that the 0.4 release goes a long way to address that. Obviously, Sigil is at a stage where it
needs to accommodate 'stupid users' who, like me, will occasionally forget to type a quotation mark or >. But this is more an issue of transferring functional demands from the user to the program than a bug
per se.
Quote:
Originally Posted by Valloric
When I started Sigil, I figured others would want to join in fairly quickly. From what I gather, this didn't happen for several of reasons:
1. I already talked about the effects of C++ on potential developers. That's covered.
2. One long-time OSS developer brought out another interesting point in an email. He said I fixed things "too quickly". When someone noticed a major bug or a key missing feature, I'd hop on it. Development was fast and constant for a one-man project. Too fast and constant, he said. Devs usually join when they want something taken care of and the current devs can't/don't want to.
|
There's also the issue that Sigil is your baby. You have a vision of how you want it to work and what you want it to do. This is, actually, largely related to the C++/python issue and the whole topic of plugins. A casual developer can write a plugin without delving into the main codebase and possibly corrupting code that already works. If the plugin's buggy, or it serves a function that the maintainer thinks is irrelevant, then that's fine - it's outside the main structure and users can utilise it or not as they choose.
But when a contributor has to alter the core of the code in order to implement a feature then you can (and should) worry about unintended effects on the overall design. The code looks well-modularised, so edits shouldn't actually break stuff outside the part that's being changed, but they can have an effect on overall functionality that might not be immediately manifest.
I've seen this happen before on an OSS project to which I contributed, where a new contributor joined and became very active - he produced a lot of very useful new code, but his design goals were clearly different to mine. After a few months he started rewriting modules I'd worked on and removing elements that I had inserted to satisfy my own design goals. At that point I quietly slipped away from the project - the new guy was doing a lot of good work (far more than me at that point) and it wasn't worth debating issues that were, at that stage, rather minor, but I could see that they had the potential to develop. If you have a good relationship with the other developers, then the obvious thing to do is discuss these issues and develop a common consensus, but if there is a one person who 'owns' the project by virtue of the amount of effort they spend on it, then you tend to be wary of stepping on his/her toes, which can often happen inadvertently.
[Phew, that was all rather long-winded.]
To tell the truth, I was happy with version 0.1.8, and used that for a long time. I only upgraded to 0.2 some time after it was released (I think it was the issue about global find/replace). And to be honest I've only just started trying the 0.4RC. Feature-bloat is definitely an issue. Take a look at Sigil's main (indeed, the only real) 'competitor' for ePub-editing, OxygenXML - it's a sprawling, massively-capable commercial program that has a load of complex functionality for editing and transforming XML and has advertised itself as an ePub editor for a while now. But only with the most recent version has it become able to do something as simple as find/replace code across all the files in an ePub. In terms of ePub editing, Sigil knocks this $400 program into a cocked hat, not because it has more features, but because it has the
right ones.
There's something to be said for getting a core set of features working and then stopping at a particular point. I think Sigil could still develop a bit in terms of user-friendliness, and it will obviously need to accommodate ePub 3, but all this talk about commercial involvement makes me worry that a lean, focussed tool might turn into a sprawling giant.
[Hmm, long-winded again, sorry.]