Dear Andreas, Thank you very much for your message. Comments and proposal for how to proceed are after your message (quoted in its entirety since I'm cc-ing the xournal-devel mailing-list). Please read through and let me know what you think.
On 01/01/2011 04:06 PM, Andreas Butti wrote: > Dear Denis Auroux > > I am a computer science student from Switzerland, before I did an > apprentice as developer. > > I use Xournal since more then 3 years, more ore less all day, if I have > school, and I really like it. But since a year there are no changes any > more, are you still working on Xournal? > > Because there are no changes any more I decided to create my own Version > of Xournal. I used your version as base and wrote my own Xournal, the > user interface looks more ore less the same (it is complete > customizeable, all toolbar configuration are read from configfiles, and > there are different layout, so I can switch if I rotate my tablet). > > I wrote the complete backend in C++, and try to optimize the memory > usage: your version uses much memory if you open large PDFs, because you > hold all rendered pages in memory, this needs for a 150 page PDF about > 500MB, my version only holds the needed pages in memory, so it needs > about 40MB. > > The complete rendering is done with cairo, instead of gnome canvas. My > version handles bookmark, and has a full-text search (through PDF > background and Xournal contents). > > I first thought I will create my own project (a fork of Xournal, GPL), > but now I'm not sure any more. Maybe we can work together? My version is > more ore less a copy of yours, and has additional things, like > bookmarks, search etc. but its for the same target: a free Journal > application. > > I have attached some screenshots from my work. I'm working since more > then 3 or 4 months on this, but now its nearly finished, I think I have > more than 80% of all working... > > What do you think? > > > ps. there is also a Chinese student which started a fork of your > Xournal, because it has no bookmark handling etc: > http://code.google.com/p/exournal/ > > Yours sincerely > Andreas Butti *** FIRST IMPRESSIONS The screenshots look quite impressive. I don't feel I'm completely done with Xournal, but work has been keeping me very busy, and you seem to have more free time and more energy than I do. From your description about using C++ rather than plain C and not using gnome-canvas, it sounds like this is a major code rewrite. Am I right to assume that the internal data structure of the journal (items, layers, etc.) and algorithms to manipulate them (e.g. the eraser, the shape recognizer, etc.) remain essentially the same, and that most of your work concerns the rendering and interface? Is your version backwards compatible in terms of file formats? (this would be desirable to maintain for a while at least). There's a few visible English spelling mistakes; no big deal, I or someone else will be happy to help. *** IMMEDIATE PLANS FOR XOURNAL (or lack thereof) I am likely to remain quite busy for at least a few more months, and the only things I'll have time to do on the existing code base will be maintenance, namely: - fixing any important bugs that come up (high priority), - if time allows: reading through carefully, fixing and incorporating some popular patches or often-requested features, especially "insert images", "autosave" are the top two, then "multicolumn + lasso" and "ortho/snap"; and a few others (perhaps SVG export, ...). *** PLEASE NOTE: BUGFIXES SINCE 0.4.5; PORTABILITY Please note: there's already been some bugfixing and other small updates to xournal since 0.4.5, it's all in the CVS code base on sourceforge.net. From the ChangeLog: - win32 portability code (contributed by Dirk Gerrits) - fix bug in PDF export code on 64-bit systems (by Robert Buchholz) - fix hand tool bug when exiting canvas (#2905711) - translations: Italian (Marco Poletti), German (Stefan Lembach), Spanish (Alvaro), Brazil Portuguese (Marco Souza), Czech (David Kolibac), Dutch (Timo Kluck) - fix save bug with text boxes containing > 4095 characters - fix crash upon unplugging input devices - change close dialog box default to "save" (patch by Kit Barnes) - option to force PDF background rendering via cairo (slower but nicer) At least the bugfixes and win32 portability should be included (if you started from the main 0.4.5 tar.gz instead of the CVS version). The "diff -r" between 0.4.5 and CVS is still relatively small and manageable (if you exclude the translation files) to sort through by hand quickly. An important other thing to keep in mind is portability. I understand that Xournal runs reasonably well (though not perfectly at all) on Windows and on MacOS, and that it has a very active community on the Maemo platform (Nokia tablets). Portability to these platforms is an important issue for those user bases. It sounds to me that your code is more efficient memory-wise, and probably at least as efficient CPU-wise, so I think it's just a matter of making sure that you don't introduce dependencies on any really exotic libraries, and keep track of the appropriate conditionals in the code and build files. Win32 portability shouldn't be too hard to double-check and keep around. Regarding MacOS I have no idea what exactly MacPorts did and who's in charge so I can't tell what needs to be done. Regarding Maemo, the project is in the hands of Aniello del Sorbo (ani...@gmail.com), who might have his own comments and may want to decide for himself whether the new codebase will be beneficial or not. (Aniello, are you reading this mailing-list?) *** THE WAY FORWARD: TRANSITION TO A NEW XOURNAL? How reliable is your code? (I understand it's not finished, but one thing that will be important is stability since this is a "production" application for many people). (I'm *very* slow as a developer, but I take great pride in writing code that's nearly bug-free most of the time.) And, over the longer term, how likely are you to keep having enough free time to maintain your project? Assuming you'll be able to follow through and bring your version to a point where it's comparable to the current one in terms of reliability and remains maintained at least somewhat, I think your code may be the way forward over the longer term. I'd be happy to help along, and to continue to tinker with the code on occasion to add features or address bugs. For the time being, given that you still seem to be working very actively and that I have very little spare time, it's perhaps best if I don't try to interfere. Later on I'd be happy to take a look at the code and help along with any outstanding issues, then perhaps work on some features I've been interested in experimenting with (searching in handwritten annotations, handling alternative file formats, etc.). In general I'm most excited about implementing less obvious technical features and less eager to work on the user interface (it probably shows). I don't think a fork would be very productive (it just creates more confusing and incompatible choices for end users); given that xournal isn't likely to evolve much over the next few months, if you are reasonably sure you'll be able to arrive at a clean finished product and be willing to spend some minimal amount of time maintaining it over at least a year or two then it would be reasonable to start thinking of your version as a candidate next-generation xournal that will replace the current code a few months from the now. So: in short, I'm happy to let you become the main developer in charge of the next-generation code base and just help along (e.g. to maintain the parts of the code that are still close enough to mine for me to understand easily, or anything else that you feel I'd be best qualified for). *** CONCRETELY: Here's what I'd like to suggest as a possible way forward: 1. alerting other people who might be actively thinking about xournal. This message being copied to the xournal-devel@lists.sourceforge.net mailing list should be taking care of it. Please consider subscribing to the list (it's very low traffic) and posting updates when you reach major milestones; also if you need help, the list is small but there's a great amount of willingness and expertise out there. 2. once your code is sufficiently complete for end users to be able to try it out and at least at alpha quality, it becomes either a separate project (xournal++, xournal-ng, whatever) on sourceforge, or a separate code branch within xournal's sourceforge space (of course by that point you're also administrator of the sourceforge project). Even if in the same sourceforge space, the two code bases are kept completely separate (unless I'm mistaken about the extent of your code rewrite). 3. once there's been some testing and you're at least at beta quality, make a public release, which will remain alongside the old xournal for the time being; old-xournal is officially deprecated (i.e., bugfixes still happen and so does routine maintenance, but efforts to add features are no longer encouraged). 4. once there's a sufficient user base and everyone's happy, the current xournal will become a thing of the past. Maintainers of the packages for the most common distributions will need to be informed sometime around step 3 or 4, so they can decide what to do ("aggressive" distributions like Ubuntu will most likely want to jump ahead to the new codebase earlier than the more conservative ones). I'll be happy to help with the transition in any way I can. Also with the development, especially for things that are not too time-consuming. (If there's something that requires just a few hours of work I can easily find the time, but something that will take several days of continuous focused work is beyond what I can promise for the foreseeable future). By the way, if you ever have any questions like "how does feature X work?", "what does this do?" or "why is this implemented in such and such way?" do feel free to ask. I hope the above sounds reasonable, but let me know if there's any comments, questions or objections -- and congratulations for reading all the way to here, I know I'm very long-winded in my explanations. It's the professor in me :-) Best, Denis -- Denis Auroux aur...@math.berkeley.edu University of California, Berkeley Tel: 510-642-4367 Department of Mathematics Fax: 510-642-8204 817 Evans Hall # 3840 Berkeley, CA 94720-3840 ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
