Am 17.01.2011 21:21, schrieb Denis Auroux: > 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. This never looks the same, you will always see a difference, and it is much more work, and you need buffering on android also.
Three reasons why I think it makes sense to use cairo. If we compile our libxournal to android we can also compile cairo to android, this is not much more work. Even, we haven't to discuss this now, because we are not doing the port now. May in two months there is android 3.0 out which has cairo integrated, or whatever... > 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. Even if I say we shouldn't do this: its simple possible...;-) All drawing is done in one class, we can simple remove this and replace this by another class, with all problems I told before (so it's may not so simple...) >> 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... Yes > 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. You separate Model, View and Control, then e.g. you say to the Model: insertStroke(myNewStroke); then the model fires to all Listeners: Hey, there is a new stroke, and this listeners are e.g. Views, and this View display then the stroke. Design Pattern, one of the most important: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller you can find this approach in my code, but its not possible to do it always "correct", because this is a theoretical pattern;-) But it should be possibel to use two Views, e.g. for presentations, not now, but later....;-) (I have to cleanup my code...) > 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). You don't do it like this, you have a Server, and a client. The server is the "Model", which contains the data, you add something to the model, and the model distribute a message to all views, hey, somebody added something. Then the views read this from model. > 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!) One of the typical multi-user problems, but with the current network and computer speed you don't have so big problems, It can happen e.g. that you draw a 1mm long line to a not existing page, but then you are really really good timed, and even then, you don't loose much data... > But wait a moment, my collaborator > then undoes his deletion Within the 50ms which the message needs to come to you? Wow... fast collaborator... (or a really long cable, then it takes more than 50ms;-)) > (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. I agree with you, I need about 3 or 4 hours to read the xournal file... This is more than 3 months ago, and my application is not yet finished;-) But at the end, now I'll try first to get a running version... Andreas > Denis > ------------------------------------------------------------------------------ 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
