How to make Sigil live

[DrChiper]

Originally Posted by user_none

The big benefit to a language like C#, and Python is memory management. Not only do they (mostly) take care of it for you they hide pointers from the programmer so they don't have to learn about them. I'm amazed at the number of really good developers who work with languages other than C/C++ and they have no idea how to use pointers.

Do not be afraid of using pointers. The only thing is, like children, you have to keep your eye on them ...

[kovidgoyal]

Originally Posted by user_none

The big benefit to a language like C#, and Python is memory management. Not only do they (mostly) take care of it for you they hide pointers from the programmer so they don't have to learn about them. I'm amazed at the number of really good developers who work with languages other than C/C++ and they have no idea how to use pointers.

In my experience, a dynamic language like python has other big benefits - rapid prototyping and very easy long term code maintenance being the biggest.

Those two, along with the automatic memory management translate into a order of magnitude higher real world developer productivity.

I remember discussing rewriting Sigil in python with you when you were first taking over from Valloric, it's a pity that never happened. If it were in python, I'd have been willing to fold it into calibre and take over development. As it is, with the current code base, over the long term, it would actually be less effort for me to re-implement something like Sigil than maintain it.

[canpolat]

I think this forum has a problem about keeping threads on-topic

Originally Posted by user_none

I use OS X so dropping other OSs would mean dropping Linux. That said while Linux is not supported with binary installable packages it is still supported as a source build.

Cross platform support really isn't a big deal from a source level. Building packages is where the time is spent. The majority of the cross platform support comes from Qt. There is a surprising little amount of actual cross platform code in Sigil itself.

You're right. I thought leaving the packaging efforts out of scope would lessen the work. Just like in the case of Linux, some people would just hadle the packaging for Windows and doesn't need to be involved in the programming at all.

That said, perhaps the only way to really "save" the project is to convince a copule of serious developers joining the team.

Now, back to COBOL discussion.

[user_none]

Originally Posted by DrChiper

Do not be afraid of using pointers. The only thing is, like children, you have to keep your eye on them ...

Pointers honestly make programming much easier. I always feel constrained and limited when working on a project that isn't C/C++. That said the point is real and good developers don't always understand them because their area of expertise isn't C/C++.

Concepts like pointers and manual memory management require a certain design considerations. These are difficult concepts and it's difficult to do right. If it's not something you employ regularly it becomes a barrier to entry because it's additional things that you need to learn before you can contribute.

Originally Posted by kovidgoyal

In my experience, a dynamic language like python has other big benefits - rapid prototyping and very easy long term code maintenance being the biggest.

It has a lot of benefits. Code maintenance I'll disagree with because it really comes down to the design more so than anything else. That said I will concede that Python makes proper design easier. But I do think projects using a non-dynamic language can be easy to maintain.

Originally Posted by kovidgoyal

I remember discussing rewriting Sigil in python with you when you were first taking over from Valloric, it's a pity that never happened.

I started but dropped it. Sigils code base doesn't translate to Python at all. The way it's designed and the underlying concepts just don't work with Python. It ended up being I could spend some time working on it or spending more time reimplementing what's already there.

Taking over Sigil and immediately throwing all the code away and starting over didn't really feel like taking over... At that point I would be working on a completely different and new project. The only thing in common would be the name.

Originally Posted by kovidgoyal

If it were in python, I'd have been willing to fold it into calibre and take over development. As it is, with the current code base, over the long term, it would actually be less effort for me to re-implement something like Sigil than maintain it.

Honestly I don't think that would be necessary (though it would probably happen) if Sigil was written in Python because it would have more contributors.

[st_albert]

Originally Posted by user_none

Pointers honestly make programming much easier. I always feel constrained and limited when working on a project that isn't C/C++. That said the point is real and good developers don't always understand them because their area of expertise isn't C/C++.

Concepts like pointers and manual memory management require a certain design considerations. These are difficult concepts and it's difficult to do right. If it's not something you employ regularly it becomes a barrier to entry because it's additional things that you need to learn before you can contribute.

[rant]
Sad but true. I was introduced to programming with Algol, and structrured programming was drilled into my head, even with assembler language(s). This was back in the late 1960's at Stanford. Don Knuth was a "god". If you do assembler programming, with its indirect addressing, the concept of pointers and dereferecing of pointers is not that big of a deal. But as was said, you gotta keep track of what you're doing. And yes, you can even use structured programming concepts in assembler language.

The point being, I am sadend fromm your remarks, at the implied thought that the concepts of structured programming (which can be implemented even in Fortran or Basic, but are "forced" in Algol, PL/1, Pascal, C, etc.) have fallen by the wayside.

I can't comment about Python, Ruby, etc. but I suspect that structured progamming principles can apply there too, even though they are not "forced" by the nature of the language. If you can do it in Basic (whch I did), you can do it in any language.

But as for OOP principles: I was never required to grasp them, though I tried to grasp on my own, but gave up for lack of suitible exercises.

I know this thread has veered off topic, but hopefully somebody can glean some insight as to (a) the reasons that Sigil must stay a C++ project (at > a million lines of code) or can be ported / recoded in some other language.
[/rant]

[mrmikel]

I looked online for anything which could convert C++ to python and the responses were all the same: No easy way.

It seems the reason it must stay C++ is because if you don't you are pretty much starting over.

The problem is that there are not very many hobbyist programmers in C++ and the professional programmers have full time jobs that occupy their time just like user none. The user base is just not big enough to make it pay as a job either. BAH HUMBUG (a little bit early.)

A way out of this is for someone to read this who is already fiddling with python code that can be modified to do a large part of this and can find other bits of code to cobble something together.

[Toxaris]

This is basically what we said all along. Conversion is a no go, so it would be building up from the start if it needs to be another language.
I never had the hart to start with c++. I did a small attempt about ten years ago, but remained at Delphi at the time. Now it is vb.net or sometimes c# if I don't have a choice.

[st_albert]

In terms of starting over, the Java project mentioned by elibrarian in post #6 of this thread looks promising on the surface, but seems to be stalled. They have 6 project members, but there have been no commits since the end of May.

Perhaps we should all bow our heads and pray "that the Lord of the harvest will send more java programmers to the project."



Albert

[colink]

Seems to me that if Kovidgoyal is willing to accept Sigil as a child product in Calibre, but only if it's written in python, then maybe the best thing for Sigil users to do is get some funding together so that he can spend lots of time working on it.

At the very least, the UI and feature set could be a beginning specification for what's needed in a new python based Sigil program.

[Hitch]

Originally Posted by colink

Seems to me that if Kovidgoyal is willing to accept Sigil as a child product in Calibre, but only if it's written in python, then maybe the best thing for Sigil users to do is get some funding together so that he can spend lots of time working on it.

At the very least, the UI and feature set could be a beginning specification for what's needed in a new python based Sigil program.

@colink:

With all due respect for your idea, if we had that type of funding, this discussion wouldn't be happening. The whole point of this thread is that putting Sigil into Python is a major project.

Righty-o?

Hitch

[colink]

Originally Posted by Hitch

@colink:

With all due respect for your idea, if we had that type of funding, this discussion wouldn't be happening. The whole point of this thread is that putting Sigil into Python is a major project.

Righty-o?

Hitch

Yes, and no.

Sigil's problem is that it violates one of the open source paradigms, in that the people who USE it also are able to MODIFY it. In Sigil's case, it seems like the vast majority of users are writers who are great at writing prose, but not so good at writing C++ or python.

Kovidgoyal already said that if Sigil had been written in python that he'd consider adopting it and adding it to Calibre.

So my thought, which wasn't very detailed, is that while no one aside from Mark Shuttleworth could afford to hire a full-time programmer to rebuild Sigil in python, that perhaps some of the 41 contributors to Calibre could be incentivized to take on that work.

Maybe we could raise enough money to get a Google Summer of Code project, or maybe a python user group or a community member would be willing to take it on. All those, however, require some kind of promotion or flag waving.

It would probably also require user_none's buyin, and Kovidgoyal really didn't talk about it beyond the bare idea of adoption.

[Hitch]

Originally Posted by colink

Yes, and no.

Sigil's problem is that it violates one of the open source paradigms, in that the people who USE it also are able to MODIFY it. In Sigil's case, it seems like the vast majority of users are writers who are great at writing prose, but not so good at writing C++ or python.

{shrug}. I don't agree that it "violates one of the open source paradigms;" I well remember EZPublish, which was purportedly (and allegedly still is) OS, and the vast, vast majority of EZP users certainly can't modify it. That's just one example. There is always, in OS, a tiny core group of hardcore users who have the capability to modify the source, and a much larger community of users who can't.

The same is true here; the reality of the situation is simply that we have a much smaller user base to begin with than, say, Joomla or Mambo or the like. Sigil occupies a niche spot; it's a halfway house for people who want to build their OWN ePUBs, but want some shortcuts. It's not a word-processor for the nine bajillion people who come here thinking it's really WYSIWYG ePUB-making, and it's not real "coding," either (I mean by that, it's HTML and CSS, not...assembler, or PHP or what-have-you). The number of people who want the finite control really making an ePUB in X/HTML is limited, by the very nature of humans, who obey the laws of physics and take the easiest path.

I suspect Jutoh already has more users than Sigil, even though it costs $40, just because it's far easier to learn. And let's not forget AWP, which runs about the same, and can output an ePUB that's not bad, for the average DIY'er.

Kovidgoyal already said that if Sigil had been written in python that he'd consider adopting it and adding it to Calibre.

So my thought, which wasn't very detailed, is that while no one aside from Mark Shuttleworth could afford to hire a full-time programmer to rebuild Sigil in python, that perhaps some of the 41 contributors to Calibre could be incentivized to take on that work.

Maybe we could raise enough money to get a Google Summer of Code project, or maybe a python user group or a community member would be willing to take it on. All those, however, require some kind of promotion or flag waving.

It would probably also require user_none's buyin, and Kovidgoyal really didn't talk about it beyond the bare idea of adoption.

Personally, I don't think it would take Shuttleworth, but it wouldn't be merely $500, either. I'm sure converting Sigil to something else--Python, or whatever is needed--could be done; it's essentially a rewrite of the entire program. The question is, does anyone really want to do it? Sure, there are 41 Calibre contributors, but quite a few of those folks have already contributed here already.

Let's face it, most regular users of Calibre aren't interested in something like Sigil--that's why they are using Calibre. So they don't have to learn something like Sigil. The intersection of the sets is likely small, or those people who are primarily Calibre users first, and Sigil users second, are using Sigil for the minor tweaking that they can't already do with ePUBTweak. The base Sigil users likely don't have a large or heavy use of Calibre, either--for making ePUBs, anyway. If they are like me, they use it for what it's intended for--cataloging purposes.

So it's not clear to me that there's funding that could be had by the "simple" expedient of saying, let's roll it into Calibre, and I would be the first to say I have very dismal hopes that some volunteer Python user group would be willing to take it on. There's a bajillion crowd-sourcing hopefuls out there, and this particular project, for such a small base...dunno. Most self-publishers aren't even interested in ePUB, because they don't know what it is, or understand it, so the demand from the general public is extremely small (I cannot tell you how many of our clients don't even download their final ePUB copies, FWIW).

Don't know. It's very disheartening.

Hitch

[user_none]

Originally Posted by colink

Sigil's problem is that it violates one of the open source paradigms, in that the people who USE it also are able to MODIFY it.

That statement is complete bull. Sigil fully embraces the concept that people who use the application can modify it. The only thing stopping someone from doing so is themselves. There is nothing missing, left out, or intentionally put in place that prevents someone from doing so. The only thing that prevents anyone from modifying Sigil is the knowledge in their own head. Knowledge which I might add is freely available for them to learn if they choose to do so.

Saying that Sigil violates open source paradigms because people don't know how to code could be said about EVERY open source application out there. This statement is the same as stating that Ford prevents people from changing their own oil because they don't know how to use a wrench.

Originally Posted by colink

perhaps some of the 41 contributors to Calibre could be incentivized to take on that work.

Who do you think has been developing Sigil. I've put just as much if not more time, work, and code into Sigil as I have into calibre. Grant is probably in the same situation for contributions too.

Fact is, calibre developers aren't interested in Sigil. They are completely different projects for different markets.

Originally Posted by colink

Maybe we could raise enough money to get a Google Summer of Code project, or maybe a python user group or a community member would be willing to take it on. All those, however, require some kind of promotion or flag waving.

Having worked on several open source projects and managing a few as well this isn't how it works. People who develop open source applications typically do so because they find the project interesting and enjoyable. Going to some random Python community isn't going to convince anyone to work on a project they have no interest in. Especially when you're going to them and saying, "see that, spend the next few years rewriting it from scratch."

If someone wants to work on Sigil they can. If no one wants to then it doesn't get updated.

Originally Posted by colink

It would probably also require user_none's buyin, and Kovidgoyal really didn't talk about it beyond the bare idea of adoption.

Rolling it into calibre would be an option if it was written in Python but it's not so it's not a valid option.

I have considered starting a rewrite in Python myself. Consider that it took 4 years to get Sigil where it is. If we estimate 1 person working full time on Sigil over that time period (which I think is a reasonable estimate) and we estimate that Python is 4 times more productive than C++ we can assume it will take 1 year of full time development to get to the same level Sigil is currently at. Working part time on Sigil we can estimate 2 years to get a rewrite to the level Sigil is at now. So is it worth years worth of effort to get to the point we're already at?

For me right now the answer is no. I'd rather spend my time on other projects. Sigil isn't fun anymore so I don't have much motivation to work on it. Also, Sigil's community is a major turn off. While people on Mobile Read are very friendly and great most of Sigil's users aren't on Mobile Read and ridiculously entitled and abusive.

[Katsunami]

Originally Posted by user_none

I have considered starting a rewrite in Python myself. Consider that it took 4 years to get Sigil where it is. If we estimate 1 person working full time on Sigil over that time period (which I think is a reasonable estimate) and we estimate that Python is 4 times more productive than C++ we can assume it will take 1 year of full time development to get to the same level Sigil is currently at.

I've been considering to try something like a rewrite in Python, mostly because I would like to write a program that's useful, and of which there aren't already a bazillion counterparts out there. (But for now, don't hold your breath....) I've been thinking...

Could one...

1. Use QT as the GUI framework using PySide or PyQT?
2. Use QScintilla (Scintilla's QT counterpart) as the editor?
3. Use Webkit as the browser?
4. Port Sigil's EPUB capabilities into a library to use as a springboard to get the editor running as an EPUB-editor, instead of merely another SciTE clone?
5. Glue all of that stuff together using Python? (Cython, Swig, Ctype, etc...)

Then we would have the very basics: a program that can open, save, edit and preview EPUB's, but it won't have any other stuff like TOC-editing, Metatag-editor and such, but those could be created one at a time.

Then later on, the Sigil EPUB library could be rewritten in Python piece by piece.

How much would development time possibly be shortened?

For me, the greatest roadblock is the EPUB-stuff. I just don't know anything about it. I know how an EPUB looks like from the inside of course, but I don't know all the details that are necessary... that's why I use Sigil.

I for one *can* program in C and C++, but I won't do it in my spare time as well as for work (I mainly write stuff in C and sometimes C++ for microcontrollers.)

Sigil's community is a major turn off. While people on Mobile Read are very friendly and great most of Sigil's users aren't on Mobile Read and ridiculously entitled and abusive.

I'm very sorry to hear that.

Originally Posted by user_none

I've found C# to be Java but done right.

Heh. I've found C# to be "Delphi with C-syntax". Not too strange, since they have the same architect.

[Katsunami]

Originally Posted by user_none

I'm amazed at the number of really good developers who work with languages other than C/C++ and they have no idea how to use pointers.

In the Netherlands, there's an entire generation of people coming out of school that haven't even touched C or C++. Many schools and universities have standardized on Java and/or C#.

I've met many people who can otherwise program more than well enough, but don't know pointers, and when required to use them, they actually don't "get it". They get confused like hell.

I found that quite strange, but it seems that pointers are slowly becoming a thing of the past, except for very low level coding.