On 01/17/2011 10:43 AM, Bob McElrath wrote: > A brief perusal of google tells me this is unlikely. I do not see people > porting complex libraries to android, in general. Android has its own > java-based graphics stack. > http://developer.android.com/reference/android/graphics/package-summary.html
All right. Then most likely one'll need the code to allow rendering to either cairo or to the Android graphics library. Though... https://bugzilla.mozilla.org/show_bug.cgi?id=565089 suggests that cairo can run on Android. It's the only evidence I could find. > Here is a tutorial that implements the very basics necessary for xournal: > http://www.tutorialforandroid.com/2009/06/drawing-with-canvas-in-android.html > > I think the UI implications of having multiple (GTK/Android) widget sets would > be enough of a nightmare for people to avoid such a thing. I don't know > whether > the gnomecanvas library (alone) can be ported, that would help. Libgnomecanvas is not a good model to use anymore. Andreas Butti's code rewrite renders directly via cairo, and doesn't use a canvas. I think this is better for various reasons. Andreas, you should plan for the possibility that one will want to replace Cairo by something else for mobile device ports. So: unlike my excessive dependence on libgnomecanvas, you don't want your data structures to rely on Cairo specifics. > So it would seem that an android app may be a complete rewrite of the canvas > and > UI pieces. > In terms of a "xournal library" I think the only thing that could be > extracted is the .xoj file handling. The page itself in structs Page and Item > are deeply dependent on Gnome/GTK. Huh, what about the whole application logic (how the journal's data structures react to user events such as drawing or erasing)? That also goes into a xournal library, no question... The existing data structures need to be made Gnome/GTK-independent anyway, in particular no reference to the gnomecanvas' data structures belong in there. I believe Andreas' code rewrite is doing precisely that, so it's going in the right direction! The way I see it, one could separate a library that contains most of the application logic. (But perhaps I am not to be trusted with this! My approach to software development is very empiric and I don't really have any formal knowledge of what's supposed to be a good project structure or not). Anyway, my instinct was to put in the backend library as much as possible, including: (1) loading / saving xoj files; (2) exposing the data structures in a form that allows easy manipulation both conceptually and graphically. Namely: the items (strokes, text boxes, etc.) in the journal should expose both a unique ID number that can be used to ask the library to manipulate them (delete the object, move it, change its color, etc.), but also the information needed to render them to a graphics stack that the library doesn't know about (e.g. the Android graphics stack); (3) manipulating the data structure by responding to command messages, where the information being passed is roughly comparable to what's currently in the undo/redo structure: examples of such messages would be: "change the color of item #135 to red", "delete items #135 and 237", "select all objects that lie inside this rectangle", "undo last operation", "paste selection at coordinates (x,y) on page 5, layer 2", "move all selected items by (dx,dy)", "add a polygonal stroke (x1,y1)...(xn,yn) on layer #3", "erase everything on layer #5 along the given polygonal path", etc. "add a new page of size w x h after page 6", etc. Then the logic of how to convert input device events to actions on the journal remains in the front-end, but the actual manipulation of the journal and some of the "hard logic" (the eraser algorithm to decide how to delete parts of strokes encountered along a given path, the shape-recognizer algorithm, etc., the undo/redo mechanism) stays in the library. However one place where these command messages would differ significantly from the current concept of elementary operation for undo/redo is "in-progress operations", such as while drawing a stroke or while using the eraser: an operation-in-progress should be built in stages, i.e. instead of directly passing "draw this stroke" as a single command, there'll be separate commands "prepare to draw a stroke", "add coordinate (x,y) to the path of the stroke", "finish stroke" (the last of these commands will then re-arrange all the commands into a single operation, but the rendering can be done properly on the partial stroke so that the display gets updated as expected). (4) rendering to various targets through an optional cairo dependency (so the frontend can use the library to render a whole page or just a rectangle to a bitmap, a GTK window, PDF file, Gtk-Print context indifferently); Then the "main" xournal combines this library with the GTK+ user interface (+ underlying UI logic, e.g. how pressing the "red" button can either switch the current pen or recolor the selection, or how clicking can either initiate a selection operation or drawing a stroke), relying on built-in cairo rendering, while the Android version can use its own graphics stack besides the UI. One thing I like about the idea of the library being able to perform conceptual operations on the journal as in point (2) above is that it provides much of the infrastructure changes needed to make collaborative editing over the network possible. Let me expand on this a bit. With such a concept of elementary operation messages being passed to the back-end, the networking mechanism can be inserted as an intermediate layer between the UI and the library that responds to commands -- commands can arrive either from remote instances or from the UI (and get forwarded to the remote instances). More logic will still be needed to handle conflicts and concurrent undo/redo histories, but having a message-based structure already cleans things up a lot. In fact, with a network-based long term evolution in mind, it is fairly clear that one should structure the library so that it lets the frontend treat the journal as not just a data structure (equivalent to the contents of the xoj) but also a collection of commands (whose end result applied to the initial state of the data structure is the current state of the journal). Then the frontend can just send a command ("erase stroke", "create page", ...) to the library, which is then able to provide the frontend with the new state of the journal (either as a collection of items, or rendered). And, this is where things get more interesting, each command in the operation stack can be either "on" (performed) or "off" (undone). Later on, the library should be able to selectively add or remove commands into the stack, even out of order, even if the operations seem to conflict with each other (e.g. I am drawing on a page, but at the same time my collaborator is deleting this page, and my instance of xournal only receives the message about it from his instance after I've drawn my stroke. So in effect I've drawn a stroke on a no-longer-existing page. But wait a moment, my collaborator then undoes his deletion, so my stroke actually gets to stay!). The internal data structures then acquire some sort of persistence that allows such "virtual" operations as drawing on a page that's not currently in existence but could re-exist if its deletion is undone. Keeping track of an initial state + the sequence of operations allows one not just to undo the last operation (still the most common scenario, so one should be able to do that without running through the whole history), but also to undo/redo older operations (by running the whole history from the initial state). (Other, milder changes needed for collaborative editing, is that there can be more than one operation-in-progress, and of course, more than one clipboard selection. But that's small stuff compared to having data structures that handle out-of-order operations and undo/redo). In any case, I think a library that merely reads/writes xoj files is pretty useless -- the data format is not that important in the grander scheme of things. A library that can present the data and act on it in an intelligent way via command messages is much more useful. 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 ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel