I suppose yes, there should be a seperate datastructure that describes
stuff on the document, and a whole sperate code part that is responsible to
put it on screen(s), another one to write it in files etc.
Especially with network implementation stuff needs to have for example ids
rather than just offsets, so its clear what commands are talking about. For
text/graphic based stuf I recently did my own causal concurrency operation
transformation engine: http://ideoloom.com/ So I got an idea what it takes,
for xournal tough the requirements seem to me to quite simpler if you only
want to synchronize key strokes (and deletions, moves etc) it isn't as
tough as editing text documents at the same time. For text elements I
suppose having the last client the say what the text node contains is for
this use case fair enough.
Anyway, as long there isn't much time spent on xournal I don't have to fear
that HEAD is going to deviate much from my dirty presentation patch anytime
soon ;-)
Kind regards, Axel
On Wed, May 11, 2016 at 1:40 AM, Denis Auroux <aur...@math.berkeley.edu>
wrote:
> Thanks! Yes, as you have noted it is currently nearly impossible to do
> this cleanly due to poor code separation between xournal and gnome-canvas.
> At the same time, I am not sure that just placing the gnome-canvas calls
> and data structures in wrappers would be the right thing -- it won't in
> itself provide cross-canvas portability unless the other canvas works
> really in exactly the same way as gnome-canvas (though I guess that two
> copies of gnome-canvas do indeed work the same way as one :-). Ideally one
> would do some complete code rewrite to better separate the user input side
> (things that act on a xournal document, be they drawing actions, network
> events in a future networked implementation, undo requests, etc.), the
> viewing/rendering side (whether it's via a canvas, for printing/exporting,
> or other future purposes), etc. and the actual operations on the document
> themselves. Not a realistic goal for the time being given the lack of time
> I have to spend on xournal.
>
> Denis
>
>
> On 05/10/2016 01:29 AM, Axel Kittenberger wrote:
>
>> Dear list,
>>
>> attached is a patch that adds presentation mode capabilities to Xournal.
>> It opens a second window in full screen mode on another monitor with the
>> zoom level fixed to one. The standard window on the monitor with the pen
>> enabled is zoomable. This is intended to be used as teaching tool as
>> replacement to a blackboard in larger lecture halls. When simply
>> mirroring the monitors I figured one has to write quite big on the pen
>> enabled monitor to be able to write cleanly and thus wouldn't fit much
>> content on a screen. With this mode, one can zoom in on the control
>> monitor to comfortably write cleanly, while the studends see the whole
>> page, also comfortable as it is projected to a big overhead screen.
>>
>> It is an ugly hack I do not request to be applied, but I want it to
>> serve as discussion base how to make this in a clean and portable way.
>>
>> The main issue is that many calls to the canvas are direct, so it needed
>> to patch all the places that interact with the canvas at all. Since
>> there is also discussion to be able to replace the canvas
>> implementation, would it be a good idea to encapsulate a little more, to
>> have "xo-canvas" as pseudo-object class, that all places call, and where
>> it could decide to actually draw on two canvases, or to change the
>> canvas implementation with only having to alter a few places?
>>
>> The second issue with this patch is more simpler pragmatic hacking. I
>> didn't bother to add options in the menu, it's simply another binary to
>> be called that will fail if it cannot detect two monitors. But thats
>> less an issue to add, when the former things are cleaned up. Some of the
>> zooming stuff is a little odd, since I didn't fully understand the code
>> in interaction with PDF, I changed it so the resolution looks good on
>> the presentation monitor, which is the important thing in this mode
>>
>> Kind regards, Axel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data
>> untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>
>>
>>
>> _______________________________________________
>> Xournal-devel mailing list
>> Xournal-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/xournal-devel
>>
>>
> --
> Denis Auroux
> UC Berkeley, Department of Mathematics
> 817 Evans Hall, Berkeley CA 94720-3840, USA
> aur...@math.berkeley.edu
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
Xournal-devel mailing list
Xournal-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xournal-devel
