Hi, first of all thanks to all the anwers. I am really happy to see so much activity around xournal. Well, it might be worse to notice that from an outsider perspective the project development seems pretty much stalled. As it was said there is a difference between power-user who read through git-branches and normal users. From a normal users perspective xournals dev activity seems very low. Reading now all your answers, I think this is an rather unfair treatment and maybe an small update on sourceforge explaining the current situation will make many people happy.
Please give me some time to read through all the post in details. Here are just some first remarks Some of you mentioned to use e.g. xrandr to get a mirror of the slide on the projector. I tried that today and it worked. However, it was a bit troublesome and it really did not feel very solid. I tried the seetings on a VGA monitor with 1024x768 since that would be the resolution of the video projector. I ended up with xrandr --output DP2 --off --output DP1 --off --output HDMI2 --off --output HDMI1 --off --output LVDS1 --mode 1366x768 --pos 0x0 --rotate normal --output VGA1 --mode 1024x768 --pos 243x92 --scale-from 880x661 --rotate normal Some of it is redundant, but I kept it just to make sure it works out-of-the-box for most situations. However, starting the lecture, I saw some of the menubars and some of the lower GUI part on the video projector. It was not that bad but there was a little error. Furthermore, I tested this for a fullscreen, zoom to 182% setting (I wanted to maximize the drawing area on the tablet PC). Luckily I use a tiling wm without borders and thus, I end up with pretty much the same screen on every start. Can't imagine the trouble if you have to work with floating windows. Thus, I believe this solution, despite it works nice, might have to many ways to give you trouble. So what could be done? 1. Creating an extra window for xournal for the video projector. Controlled by and from xournal it would always depict the correct frame independent of any GUI changes in the meantime (zoom, moving, fullscreen, etc.). I guess that is the reason many of those programs go for a own second screen. 2. Create someting more smart based on xournal, which takes care of the right values. I could think of a little program which allows you to draw a rectangle (similar like a screenshot program) and the content of the rectangle would be mirrored by the video projector. That little program could sit in the taskbar or be called by a hotkey to allow changes anytime during the presentation. That would even allow to zoom-in to parts of a frame (albeit since it is entirely pixel-based it would get ugly for large zooms). During the practical test today I noticed I really miss the following features. 1. Preview of the next slide ( I accidenetly showed the result to the students seconds after I asked them to figure it out by themself ;) , because I thought it is still a few clicks away). 2. Bookmarks or freeze. I had to go to frame X several times again and it is rather confusing for the students to see all this crazy fast steps going backwards or fowards until I manage to reach the right slide. As I understood both was done by andrey/xournal (the students project from DMG) . However, I could not find anything like that on github. Really would love to see a link for that I also tested the GTK3 branch. It looks much nicer and "up-to-date" and I really like it. However, the canvas for the pages was heavily distorted and at the begining drawn above the menu and toolbar. Might be a problem with my tiling window manager (i3 wm). However, as for my two newbie-cents. Once it is declared stable you might get xournal 5.0 out. I can't see at the moment the cons and pros of C vs. C++, well I know them, but can't tell how does this influence the functionality of xournal. As for beamer and PDF. There are already programs which can deal with slides and frames from beamer reading the PDF only. PDFPC is one example. Furthermore, I believe it should not be hard to leave a note in each PDF page which indicates a new frame. That would allow to read at which pdf page a new frame starts. Would be really interesting to see how this would work together with xournals layers. Thanks again for all your feedback, I will read them more carefully and answer one-by-one over time Thanks Torwag On 19 November 2013 01:18, Denis Auroux <aur...@math.berkeley.edu> wrote: > Dear all, > > My take on the confusion about future plans and the various branches is as > follows: > > - Confusion for "users": > > One should be aware that none of the people in this discussion, and probably > none of the people reading this mailing-list, are just plain "users". A > "user" is someone who most likely either got xournal from their linux > distribution's package system, or at the very most, googled "xournal" and > then clicked on a ready-to-download link on sourceforge or some other web > page. At most they might have downloaded a tarball and typed "make; make > install" upon instructions to do so from some go-to power user they spoke > with. The ones who are legitimately confused and having this discussion are > rather power-users who know how to clone a repo and apply a patch, and have > their own opinions about GTK2 vs. GTK3, project forks and naming, or this or > that. > > In other terms: as far as actual users are concerned, there's no urgency to > resolve the situation *provided* that package maintainers for the main > distributions don't get confused themselves. It may still help if the repos > with non-standard versions clarify that they are a fork or experimental > variant (perhaps also indicating in what main ways they differ) and provide > a link to the stable codebase. > > - Stable vs. unstable, naming, etc.: my own take is that it's too early to > resolve things. Given recent trajectory, my feeling is that in a few months > or a year, we'll have: > > 1. historical xournal codebase (mine) -- stable, still in use for most > mainstream distributions' packaging, but doesn't add nontrivial features > anymore and stays with GTK2. > > 2. whatever comes out of Daniel's work -- presumably something that combines > the GTK3 work with some of the work done by his students and other patches > he's been playing with. Presumably this will lives on github in > dmgerman/xournal at first, unless by then I've handed him the keys to the > sourceforge.net repositories. If we anticipate an extended transition and > slow adoption period then probably some working name for the GTK3 version is > needed (xournal3 anyone?) -- though the executable file should still be > called "xournal" since it's meant as a drop-in replacement and we don't want > distributions to start packaging both side by side. If this emerges as the > clear leading repo I will probably want to start pointing people to it on > the main sourceforge web page, and adventurous distributions like Ubuntu > might want to start looking into packaging this one instead of plain > xournal. > > 3. xournal++ is its own thing, and may or may not take off on its own. > > Of course in this vision of things I'm assuming that Daniel continues to be > really active and move things forward, to the extent that in practice he > takes over. There are other possible futures. My point is that it's too > early to tell. That's too bad for those of you who want to contribute code > and may have to choose which codebase to work on. (Note however that xournal > and "xournal3" are not yet so insanely different that patches for one can't > be ported to the other!) > > Best, > Denis > > > > > On 11/18/2013 12:01 AM, D M German wrote: >> >> >> >> I would like my $0.02, adding to what has been said. >> >> Denis Auroux twisted the bytes to say: >> >> Denis> There are basically two different things: xournal, and xournal++ >> Denis> (xournalpp). >> >> Denis> Xournal was written in C using GTK2. Its code base is stable, >> but is >> Denis> not evolving very fast anymore. >> Denis> The official repository is on sourceforge.net, both as CVS and >> GIT, >> Denis> accessible from >> Denis> http://sourceforge.net/projects/xournal/ >> Denis> The GIT repository read-only access is >> Denis> git://git.code.sf.net/p/xournal/code xournal-code >> Denis> The current codebase differs from the official release 0.4.7 by >> minor >> Denis> updates -- mostly adding a couple of translations, and minor >> bugfixes or >> Denis> fixes to the build system. >> >> Denis> Because there are a number of patches waiting to be triaged, and >> because >> Denis> I'm pretty uptight about evolving the "official" codebase, >> various power >> Denis> users have created their own git repositories -- the most >> relevant one >> Denis> here is probably Daniel German's on github. >> >> About some extra repos: >> >> * Scholiar: https://github.com/dmgerman/scholiar >> >> Before we had an official git repo, I started incorporating patches >> from Sourceforge and adding some of my "scratch-my-own-itch" >> features. Once we had an official repo, and to avoid naming problems I >> changed the name of its repo to scholiar. It has gotten out of sync >> with xournal, mostly in windows compatibility. This is the xournal I >> use day to day in my laptop. >> >> Some features on it: >> >> - Jump to next/previous annotation >> >> - Automatically export to PDF when saved >> >> - Always use touch as hand tool >> >> - Add A5 size paper (my favorite one :) >> >> - Maximize height >> >> - Optionally remove menu and toolbar when in fullscreen (useful for >> presentations) >> >> - Scroll to next/previous PDF file in same directory as current one. >> >> - New page adds default one rather than copying the current PDF page >> (useful when doing presentations) >> >> - Do not allow horizontal scroll >> >> * dmgerman/xournal >> >> My fork of official xournal. I try to keep it up to date. My goal was >> to used it to port scholiar features to xournal. But it has ended >> being used for gtk+ and to talk to other xournal developers instead. >> It has several branches: >> >> - master. Tracks official >> - gtk3 my efforts to make it run under gtk3+ >> - for-andrey cmake support (not merged anywhere else yet :) >> >> As Denis mentioned, the gtk3 is usable, but needs some finetuning. The >> core of the work is done. >> >> However, this was a MAJOR rework. Xournal is very tied to the >> GUI. The code changed everywhere. I have done some refactoring, added >> new code, and removed a lot of old code. >> >> What it needs the most is testing and still the porting of some >> features. You can find an update here: >> >> https://github.com/dmgerman/xournal/blob/gtk3/towardsGtk3.org >> >> - Lasso needs to be reimplemented >> >> - Text editing. It works but looks ugly. I haven't been able to get >> it >> to work. >> >> Also, pointer/mouse/pen management is different in gtk3. This has >> created new bugs, but also opened new opportunities (it is now easy >> to distinguish the type of device the user is using). >> >> * andrey/xournal >> >> Four students (Andrey, Jared, Derek and Jordan) took to improve >> official xournal for a capstone project at our University. The most >> important features they implemented many features but the ones I >> recall the most are: >> >> - bookmarks (really nice, neat) >> >> - thumbnails >> >> - ink mimicking more real pens (variability of intensity of color based >> on >> writing speed). It is really neat. >> >> - Search in PDFs and annotations. >> >> - Support for PDF Table of Contents >> >> You can see an example of their work here (created using xournal): >> >> http://turingmachine.org/~dmg/temp/xournal499.jpg >> >> >> I haven't used their version on a day-to-day basis (thinking about it I >> should, given that I'll benefit a lot from their features :) >> >> My goal is to incorporate many of their features into xournal, as I >> finish the work with GTK3. But you can their branch. >> >> >> Denis> Daniel recently undertook a rewrite of xournal to use GTK3 + >> goocanvas >> Denis> instead of GTK2 + gnomecanvas, which are no longer well >> supported. The >> Denis> key reason to migrate, besides general modernism, might be >> Windows 8.1, >> Denis> 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 >> Denis> it basically works and just needs maybe a bit more testing for >> stability >> Denis> etc. >> >> Denis> Feature-wise (from the user's viewpoint), I believe most of the >> github >> Denis> repositories, Daniel's included, are very close to 0.4.7 + >> various >> Denis> patches available on sourceforge. However, the passage to GTK3 + >> Denis> goocanvas is obviously a big architecture upgrade. >> >> I agree. >> >> Denis> On the other hand, Andreas Butti undertook a rewrite from scratch >> in >> Denis> C++, called xournal++ (or xournalpp). >> Denis> The official repository is the SVN at >> Denis> http://sourceforge.net/projects/xournal/ >> Denis> Because the codebase is completely different and various extra >> features >> Denis> were planned from the start, and because things evolved >> differently, >> Denis> this has a slightly different user interface and set of visible >> Denis> features. At some point I was confident that xournal++ was >> evolving >> Denis> fast enough to put xournal out to retirement soon; unfortunately >> Andreas >> Denis> had to take an extended break from working on it soon afterwards, >> which >> Denis> leaves xournal++ in a state where it's not clearly better than >> xournal >> Denis> yet (particularly from a reliability viewpoint). >> >> Long time ago I looked into xournal++ but it was still incomplete. >> >> I have mentioned this to Denis, but I am totally in owe that Xournal is >> 100% reliable. Except for one bug it was reported recently to me, it has >> never crashed on me (and I use it a lot). Before the porting to gtk3 my >> changes were very incremental. >> >> >> 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? >> >> Denis> Questions, questions. If you want code that's stable and 99.9999% >> Denis> reliable, start from the official repo (C and GTK2). If you want >> to >> Denis> start from what this code might become someday, it's quite >> possible that >> Denis> Daniel's GTK3 port will become the way of the future, but that's >> far >> Denis> from clear yet. (Also, given my pace, it'll take forever to merge >> things >> Denis> into the official repo unless I suddenly get a burst of energy; >> of >> Denis> 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 >> Denis> to complete it, it might be the other branches that won't have >> any future. >> >> My attempt to gtk3-ize xournal has made me understand the code more than >> I ever imagined :) I can help answer question about hacking the code. I >> think the best way is to say: "I want to do X, where do I start?" >> >> >> Furthermore, I have a bit trouble to start reading the code. Is there >> >> any developer manual? Filestructure, coding style, etc.? >> >> Denis> For the main branch, Daniel once told me something along the >> lines of >> Denis> "it shows that there was a single author". I think that was not >> meant as >> Denis> a compliment concerning the coding style and readability :| >> >> Denis is a mathematician and I am software engineering researcher :) >> >> The code is really good, and I wish most programs would be as resilient >> as Xournal (seriously) but there are two main problems with xournal that >> are hard to tackle: >> >> - Lack of encapsulation. The code relies on few global variables, making >> reentrancy a really hard problem. This imposes problems trying to >> create two instances/windows of xournal that talk to each other >> (either with the same document or different documents). >> >> - Integration of GUI. Xournal is very tied to the GUI. It can be >> separated, but it would take time (and potentially making it less >> reliable). >> >> Another interesting problem is that xournal stressed some libraries it >> was using to the point of breaking them. There was code to deal with >> some bugs in libraries in the past that are no longer needed. >> >> Denis> Xournal++ ought to be easier to read since Andreas is at least a >> Denis> 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) >> >> Denis> Seems definitely possible but non-trivial. You'd need either to >> maintain >> Denis> two gnomecanvases by duplicating a lot of the code to handle both >> Denis> windows, or something else. >> >> One of my colleagues solves this problems very smartly. He places the >> projector in a region of the screen, so he can annotate, but leaving a >> region that he can only see where he places the notes. He uses >> Latex/Beamer. He can then see both the slides and his comments and >> annotate on the slides at the same time. He uses xrandr to accomplish >> this: >> >> xrandr --output VGA1 --mode 1024x768 --scale 0.66699x0.66699 --pos 0x129 >> >> Denis> However, if I may suggest, the reason why I've resisted such >> suggestions >> Denis> in the past -- besides the inadequacy of the libgnomecanvas >> Denis> architecture, which would force a lot of code duplication or >> other >> Denis> inelegant things -- is that ideally it would be either the X >> server (via >> Denis> xrandr configuration) that takes care of the boring task of >> mirroring a >> Denis> portion of the primary display into an external display, or the >> window >> Denis> manager (of course, one with features, i.e. not gnome-shell) or >> some >> Denis> add-on generic software that mirrors part of a given window onto >> another >> Denis> display via window capture. Or if you don't want to be generic, >> at least >> Denis> some add-on into the GTK API to make such things easier. That >> seems >> Denis> smarter than inserting such a functionality into every single >> piece of >> Denis> software that one might ever want to use to give presentations. >> >> >> I totally agree. I think xournal is a note taking and PDF annotation >> tool, not a Swiss army of annotation. It is better to be good at >> something that to be average or below at many things. >> >> >> >> d) set and jump to bookmarks easily >> >> Denis> I believe there's a patch for this somewhere on sourceforge.net >> but I >> Denis> haven't tested it. Once you decide how you're going to store the >> Denis> bookmarks and handle them in the user interface, the back-end >> code is >> Denis> very easy -- it's mostly user interface work. >> >> The features from the 499 team have done this very nicely. >> >> One of my biggest concerns (and why I renamed my fork and have been >> working on branches) is that I don't want to dilute the xournal name. If >> a user downloads xournal they should have a warranty of reliability. I >> think the solution might be to create a big warning at the beginning >> that (when appropriate) that this xournal is not official and complains >> should not be directed to Denis. >> >> We really need a way to manage that. >> >> Personally, I think we need the following with regard to the future: >> >> - A reliable version. Where the features are rock solid. >> >> - An experimental version. This can be used by early adopters to try a >> set of new features. Then the features can be backported to reliable. >> >> - Braches/repos for specific experimental features /subcommunity. For >> instance, I might have features that are not to be ever part of >> xournal. This also includes features that our benevolent dictator >> (Denis) does not deem appropriate for xournal. >> >> So yes we have a mess. And we need to start cleaning it :) >> >> I think the move to git has helped tremendously to manage all these >> features. Unfortunately my scholiar branch is not forked from it, so it >> requires some work to backport it to the current xournal repo. >> >> And by the way, if anybody wants to try a newer version of xournal for >> windows (official + two extra features: don't scroll horizontally and >> touch as hand) try it here. No warranty :) it works on win8.1 on desktop >> mode (I have been using it on my Lenovo Thinkpad tablet 2 for a while). >> >> (warning, this zip file might be removed any moment) >> >> http://turingmachine.org/~dmg/temp/xournal.zip >> >> Denis, totally out of topic, have you tried the Japanese chalk? >> >> >> --dmg >> >> >> -- >> Daniel M. German "A person may cause evil to others >> not only by his actions >> but by his inaction, >> and in neither case >> he is justly accountable >> John Stuart Mill -> to them for the injury." >> http://turingmachine.org/ >> http://silvernegative.com/ >> dmg (at) uvic (dot) ca >> replace (at) with @ and (dot) with . >> >> >> > > -- > 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 ------------------------------------------------------------------------------ Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
