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

Reply via email to