Hi all, > I am looking into the development of xournal for some time and got a > bit confused. There is a C++ branch which seems to get some but not much work > at the moment. > There is a SVN and a GIT. In the GIT there seems to be a GTK3 branch. > Some Github forks exists as well.
There are basically two different things: xournal, and xournal++ (xournalpp). Xournal was written in C using GTK2. Its code base is stable, but is not evolving very fast anymore. The official repository is on sourceforge.net, both as CVS and GIT, accessible from http://sourceforge.net/projects/xournal/ The GIT repository read-only access is git://git.code.sf.net/p/xournal/code xournal-code The current codebase differs from the official release 0.4.7 by minor updates -- mostly adding a couple of translations, and minor bugfixes or fixes to the build system. Because there are a number of patches waiting to be triaged, and because I'm pretty uptight about evolving the "official" codebase, various power users have created their own git repositories -- the most relevant one here is probably Daniel German's on github. Daniel recently undertook a rewrite of xournal to use GTK3 + goocanvas instead of GTK2 + gnomecanvas, which are no longer well supported. The key reason to migrate, besides general modernism, might be Windows 8.1, which appears to have poor GTK2 support according to some user reports. I have not tested Daniel's code recently, but understand that by now it basically works and just needs maybe a bit more testing for stability etc. Feature-wise (from the user's viewpoint), I believe most of the github repositories, Daniel's included, are very close to 0.4.7 + various patches available on sourceforge. However, the passage to GTK3 + goocanvas is obviously a big architecture upgrade. On the other hand, Andreas Butti undertook a rewrite from scratch in C++, called xournal++ (or xournalpp). The official repository is the SVN at http://sourceforge.net/projects/xournal/ Because the codebase is completely different and various extra features were planned from the start, and because things evolved differently, this has a slightly different user interface and set of visible features. At some point I was confident that xournal++ was evolving fast enough to put xournal out to retirement soon; unfortunately Andreas had to take an extended break from working on it soon afterwards, which leaves xournal++ in a state where it's not clearly better than xournal yet (particularly from a reliability viewpoint). > I couldn't figure out what is the actual up-to-date repro resp. from > where to start. > Should one wait for the GTK3 port? > Is there any future for the C++ branch? Questions, questions. If you want code that's stable and 99.9999% reliable, start from the official repo (C and GTK2). If you want to start from what this code might become someday, it's quite possible that Daniel's GTK3 port will become the way of the future, but that's far from clear yet. (Also, given my pace, it'll take forever to merge things into the official repo unless I suddenly get a burst of energy; of course it could be that I'll just give up and ask Daniel to take over). Xournal++ will certainly remain something separate; if Andreas manages to complete it, it might be the other branches that won't have any future. > Furthermore, I have a bit trouble to start reading the code. Is there > any developer manual? Filestructure, coding style, etc.? For the main branch, Daniel once told me something along the lines of "it shows that there was a single author". I think that was not meant as a compliment concerning the coding style and readability :| Xournal++ ought to be easier to read since Andreas is at least a properly trained software person, while I'm just an amateur. > Actually, I want to add a presentation mode to xournal. That is > (ordered by piority): > > a) An extra window which mirrors the content of the actual drawing > area (to be placed on the video projector screen) Seems definitely possible but non-trivial. You'd need either to maintain two gnomecanvases by duplicating a lot of the code to handle both windows, or something else. However, if I may suggest, the reason why I've resisted such suggestions in the past -- besides the inadequacy of the libgnomecanvas architecture, which would force a lot of code duplication or other inelegant things -- is that ideally it would be either the X server (via xrandr configuration) that takes care of the boring task of mirroring a portion of the primary display into an external display, or the window manager (of course, one with features, i.e. not gnome-shell) or some add-on generic software that mirrors part of a given window onto another display via window capture. Or if you don't want to be generic, at least some add-on into the GTK API to make such things easier. That seems smarter than inserting such a functionality into every single piece of software that one might ever want to use to give presentations. > b) Make xournal aware of LaTeX beamer, which creates frames and > slides... a frame can consists of several slides to mimic the effect > of animations (add text and images part by part to the same frame). > Thus, a PDF which contains only a single frame might consist of > several pages. It would make sense, that Xournal keeps all kind of > annotation until the next frame. Well, for that you first need to make PDF files aware of LaTeX beamer, so good luck. The PDF file produced by latex/beamer, as far as I know, just duplicates the pages for a frame, and it's not easy at all for an external PDF reader/viewer application to figure out which pages of the PDF file correspond to a same logical Beamer frame. In addition, Xournal's awareness of the structure of the PDF file is quite limited -- it parses some of it to get pages, sizes, etc., and the "Export to PDF" code goes fishing around in resource directories a little bit, but the heavy lifting is all left to the Poppler library and xournal doesn't know all that much. That's indeed too bad, because xournal has mechanisms e.g. layers etc. that would come in handy in a beamer or similar context, but PDF doesn't have such layers as far as I know (or they're not in use). > d) Create a pane on the main window to see the next slide (and/or frame) Where would you put that pane? I just can't visualize it. Or maybe you want a side bar showing the whole list of page previews, as in e.g. evince and adobe reader -- in fact it's been a feature request, and I think xournal++ has it. This wouldn't be all that hard to impement. > e) Display presentation time (either way, just a clock, time in > minutes or time left) Why not an external application for this? > c) Switch state of the presentation window into black, white or freeze > (keep the slide to allow the presenter to search through the > presentation and after the right frame/slide is found unfreeze and the > presentation window will be updated) Meeh? Oh, got it. Well, should be easy enough once you have a presentation window. But those could be features of the separate generic software I advocate creating to make any application presentation-able. > d) set and jump to bookmarks easily I believe there's a patch for this somewhere on sourceforge.net but I haven't tested it. Once you decide how you're going to store the bookmarks and handle them in the user interface, the back-end code is very easy -- it's mostly user interface work. So: in my opinion some of these things are interesting, but I'd suggest looking into implementing features (a), (e), and (c') (external presentation window different from main document window, ability to display a timer, and to freeze the external presentation) as a separate piece of software that could cooperate with either xournal or a whole range of other applications. Beamer awareness is, as far as I know, impossible for an application that works at the PDF level. (Of course one could try to write code that attempts to parse the latex source. Ugh -- lots of work and probably not reliable.) 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 ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
