I've just decided to push my copy to my public git mirror, andreas, you can see the commit messages clearly this way:
http://www.git.ryanlewis.net/index.cgi/xournal++/ -rhl On Tue, Apr 19, 2011 at 10:31 AM, Ryan Lewis <m...@ryanlewis.net> wrote: > Indeed, after pointing Xournal++ to my checkout of poppler, > compilation went smoothly! > > I'd be willing to help test, let me know what you need. > > > -rhl > > > > > On Tue, Apr 19, 2011 at 2:50 AM, > <xournal-devel-requ...@lists.sourceforge.net> wrote: >> Send Xournal-devel mailing list submissions to >> xournal-devel@lists.sourceforge.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/xournal-devel >> or, via email, send a message with subject or body 'help' to >> xournal-devel-requ...@lists.sourceforge.net >> >> You can reach the person managing the list at >> xournal-devel-ow...@lists.sourceforge.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Xournal-devel digest..." >> >> >> Today's Topics: >> >> 1. Re: Xournal++ State (Andreas Butti) >> 2. Re: Xournal++ State (Michael J Gruber) >> 3. Re: collaborative xournal (Jonathan R Young) >> 4. Re: collaborative xournal (Andreas Butti) >> 5. Re: Xournal++ State (Bob McElrath) >> 6. Re: Xournal++ State (Michael J Gruber) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 18 Apr 2011 17:12:16 +0200 >> From: Andreas Butti <andreasbu...@gmail.com> >> Subject: Re: [Xournal-devel] Xournal++ State >> To: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> >> Cc: xournal-devel@lists.sourceforge.net >> Message-ID: <4dac54d0.1080...@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> >>>>> Regarding Images: >>>>> Having the option to not attach them (just like backgrounds) would be >>>>> really nice, with an element like: >>>>> >>>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>>>> filename="bg_1.png"/> >>>> why? >>>> >>>> The Image format I use is 100% compatible with the pach which is >>>> available for Xournal on sf.net >>> It's good to have it compatible (though that patch never made it into a >>> released version), but still the extension with 'filename=""' would not >>> break it. >> >> Are you sure? Try it out;-) >> >> Xournal has for reading always a loop which checks every attribute, if >> you have an attribute more it don't read the whole file. >> >> That's the reason why I leave everything exactly the same. (Even if you >> change the order of attributes it don't read the files any more). >> >> For me personal I said I leave it in the first release 100% compatible >> with Xournal (and optional with the image patch). And if all is working, >> the next release will use a new fileformat which is not compatible, but >> contains resources and new features. >> >> (based on ZIP instead of GZip) >> >>> Not attaching images is important because of file size, especially, but >>> not only when you include the same image several times. I would say it's >>> important for the same reasons out which backgrounds can be attached or >>> detached. >> This is an argument for using attaching images... >>> Also, imagine using a "library" of images that you include again and >>> again, or a workflow where you regenerate the image and want your xoj to >>> use the regenerated image automatically. >> This is no argument for attaching images, this is in my opinion against, >> because the data is may inconsistent. >> >> There is a Python API for Xournal++, which is not finished yet, and at >> the moment only used for testing, but later you should write a Python >> Plugin for this, so there is for sure no inconsistency. >> >>>> For future releases I'll create a new format (e.g. based on ZIP) which >>>> can handle resources better. >>>> >>>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>>>> background, but the filename is "wrong". But then it does find it on >>>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>>>> backgrounds is great and just what I would love for detached image >>>>> objects also :) >>>> I'll check this, I don't understand what you mean now, but I didn't >>>> really test background image yet;-) >>> Journal -> paper background -> Image: select "bend.png" >>> Save xoj. >>> >>> The xoj is: >>> >>> <?xml version="1.0" standalone="no"?> >>> <xournal creator="Xournal++ 0.1" fileversion="2"> >>> <title>Xournal document - see http://xournal.sourceforge.net/</title> >>> <preview>...</preview> >>> <page width="22.00" height="31.00"> >>> <background type="pixmap" domain="attach" filename="bg_1.png"/> >>> <layer/> >>> </page> >>> </xournal> >>> >>> Different filename. But when I close and reopen xournalpp finds it or >>> rather: I see now that there is a copy >>> >>> 2011-04-18-Note-15-07.xoj.bg_1.png >>> >>> in my workdir. Is that (copying background images) how it works with >>> xournal trunk? >> On the open dialog is a checkbox, "Attach to Xournal". Even on my >> application (but in Xournal++ it's may not working correct;-)) >> >> I'll may do the same for insert images. >> >> Andreas >> >>> Michael >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 18 Apr 2011 15:16:01 +0200 >> From: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> >> Subject: Re: [Xournal-devel] Xournal++ State >> To: Andreas Butti <andreasbu...@gmail.com> >> Cc: xournal-devel@lists.sourceforge.net >> Message-ID: <4dac3991.80...@fastmail.fm> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Andreas Butti venit, vidit, dixit 18.04.2011 12:41: >>> >>> >>> Am 18.04.2011 11:32, schrieb Michael J Gruber: >>>> Andreas Butti venit, vidit, dixit 31.03.2011 19:06: >>>>> Hello >>>>> >>>>> I'm still working on a new release, I did some re-factoring: >>>> ... >>>>> And there are also some things not working with "make install", if >>>>> somebody has time or good knowledge of autotools I would appreciate some >>>>> help;-) >>>> Ciao Andreas, >>>> >>>> what's the best way in which we can help (besides autotools)? It seems >>>> that there's no point investing in xournal (non-pp) any more, code-wise. >>>> So, since I'm very interested in getting image inclusion, I'm forced to >>>> look at xournalpp... >>> >>> Are you a developer? (You don't know Autotools either?;-)) >> >> C, not really C++. No autotools... >> >>> Else: Testing... As you did. >> ... >>>> Regarding Images: >>>> Having the option to not attach them (just like backgrounds) would be >>>> really nice, with an element like: >>>> >>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>>> filename="bg_1.png"/> >>> why? >>> >>> The Image format I use is 100% compatible with the pach which is >>> available for Xournal on sf.net >> >> It's good to have it compatible (though that patch never made it into a >> released version), but still the extension with 'filename=""' would not >> break it. >> >> Not attaching images is important because of file size, especially, but >> not only when you include the same image several times. I would say it's >> important for the same reasons out which backgrounds can be attached or >> detached. >> >> Also, imagine using a "library" of images that you include again and >> again, or a workflow where you regenerate the image and want your xoj to >> use the regenerated image automatically. >> >>> For future releases I'll create a new format (e.g. based on ZIP) which >>> can handle resources better. >>> >>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>>> background, but the filename is "wrong". But then it does find it on >>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>>> backgrounds is great and just what I would love for detached image >>>> objects also :) >>> I'll check this, I don't understand what you mean now, but I didn't >>> really test background image yet;-) >> >> Journal -> paper background -> Image: select "bend.png" >> Save xoj. >> >> The xoj is: >> >> <?xml version="1.0" standalone="no"?> >> <xournal creator="Xournal++ 0.1" fileversion="2"> >> <title>Xournal document - see http://xournal.sourceforge.net/</title> >> <preview>...</preview> >> <page width="22.00" height="31.00"> >> <background type="pixmap" domain="attach" filename="bg_1.png"/> >> <layer/> >> </page> >> </xournal> >> >> Different filename. But when I close and reopen xournalpp finds it or >> rather: I see now that there is a copy >> >> 2011-04-18-Note-15-07.xoj.bg_1.png >> >> in my workdir. Is that (copying background images) how it works with >> xournal trunk? >> >> Michael >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 18 Apr 2011 16:45:49 +0100 >> From: Jonathan R Young <jonathan...@gmail.com> >> Subject: Re: [Xournal-devel] collaborative xournal >> To: Bob McElrath <b...@mcelrath.org> >> Cc: xournal-devel@lists.sourceforge.net >> Message-ID: <4dac5cad.3020...@googlemail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hi - yes that is what I was thinking - basically build on the existing >> frameworks for collaboration, rather than build an application specific one. >> BTW - I am an IT architect, rather than a hard core developer (although >> I occasionally dabble, and used to code years ago!) >> Jonathan >> >> On 18/04/11 09:53, Bob McElrath wrote: >>> No I think he means to encode individual strokes into SVG and transmit them. >>> It's also then easy to synchronize just by looking at some stroke sequence >>> number, in case a client is disconnected. I think it's quite a good idea. >>> >>> FYI I just pulled the xournalpp source and it doesn't build, due to a >>> problem >>> with Settings.cpp. >>> >>> Andreas Butti [andreasbu...@gmail.com] wrote: >>>> This would be possible, but you cannot edit this again with Xournal. >>>> >>>> (SVG export is possible with copy paste or export in the current Xournal++) >>>> >>>> >>>> But I don't support DBUS or such a protocol at the moment. >>>> >>>> (And I won't, no time...) >>>> >>>> >>>> Andreas >>>> >>>> >>>> Am 18.04.2011 09:38, schrieb Jonathan R Young: >>>> >>>> I wonder if Xournal could offer/consume a DBUS / telepathy / tubes >>>> approach, perhaps using SVG as the transport format, so each completed >>>> stroke can be published in realtime, and other clients can consume >>>> that >>>> message and render it. >>> -- >>> Cheers, >>> Bob McElrath [ Heidelberg University, Theoretical Physics ] >>> >>> "If you're not failing every now and again, it's a sign you're not doing >>> anything very innovative." -- Woody Allen >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 19 Apr 2011 08:04:15 +0200 >> From: Andreas Butti <andreasbu...@gmail.com> >> Subject: Re: [Xournal-devel] collaborative xournal >> To: jonathan...@googlemail.com >> Cc: xournal-devel@lists.sourceforge.net >> Message-ID: <4dad25df.1060...@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Am 18.04.2011 17:45, schrieb Jonathan R Young: >>> Hi - yes that is what I was thinking - basically build on the existing >>> frameworks for collaboration, rather than build an application specific one. >> Can you make an example which framework should be used? >> (And why?) >> >>> BTW - I am an IT architect, rather than a hard core developer (although >>> I occasionally dabble, and used to code years ago!) >> Ok, then you can draw an UML component diagram or something like this=) >> >> >> (I passed my apprentice as "Applikationsentwickler" successfully, and >> I'm studying computer science, now in the 4th semester) >> >> Andreas >>> Jonathan >>> >>> On 18/04/11 09:53, Bob McElrath wrote: >>>> No I think he means to encode individual strokes into SVG and transmit >>>> them. >>>> It's also then easy to synchronize just by looking at some stroke sequence >>>> number, in case a client is disconnected. I think it's quite a good idea. >>>> >>>> FYI I just pulled the xournalpp source and it doesn't build, due to a >>>> problem >>>> with Settings.cpp. >>>> >>>> Andreas Butti [andreasbu...@gmail.com] wrote: >>>>> This would be possible, but you cannot edit this again with Xournal. >>>>> >>>>> (SVG export is possible with copy paste or export in the current >>>>> Xournal++) >>>>> >>>>> >>>>> But I don't support DBUS or such a protocol at the moment. >>>>> >>>>> (And I won't, no time...) >>>>> >>>>> >>>>> Andreas >>>>> >>>>> >>>>> Am 18.04.2011 09:38, schrieb Jonathan R Young: >>>>> >>>>> I wonder if Xournal could offer/consume a DBUS / telepathy / tubes >>>>> approach, perhaps using SVG as the transport format, so each >>>>> completed >>>>> stroke can be published in realtime, and other clients can consume >>>>> that >>>>> message and render it. >>>> -- >>>> Cheers, >>>> Bob McElrath [ Heidelberg University, Theoretical Physics ] >>>> >>>> "If you're not failing every now and again, it's a sign you're not doing >>>> anything very innovative." -- Woody Allen >>> ------------------------------------------------------------------------------ >>> Benefiting from Server Virtualization: Beyond Initial Workload >>> Consolidation -- Increasing the use of server virtualization is a top >>> priority.Virtualization can reduce costs, simplify management, and improve >>> application availability and disaster protection. Learn more about boosting >>> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >>> _______________________________________________ >>> Xournal-devel mailing list >>> Xournal-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/xournal-devel >> >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 19 Apr 2011 01:43:36 -0500 >> From: Bob McElrath <b...@mcelrath.org> >> Subject: Re: [Xournal-devel] Xournal++ State >> To: Andreas Butti <andreasbu...@gmail.com> >> Cc: xournal-devel@lists.sourceforge.net >> Message-ID: <20110419064336.gb13...@mcelrath.org> >> Content-Type: text/plain; charset=us-ascii >> >> I used xournal++ for a few hours yesterday to test, here are some notes/bugs >> about it: >> >> 1) Using rectangle select as middle mouse button (pen button) doesn't work. >> >> 2) Undo seems to redraw in 2 steps, separated by a second or two, and a crash >> always soon follows. >> >> 3) The Autosave/restore needs a UI. >> >> 4) After strokes are drawn they are re-drawn, it appears with slightly >> different >> width or anti-aliasing. >> >> 5) Toolbar edit (great!!!!) drag & drop to toolbars doesn't work. >> >> 6) Adding toolbar handles and letting the user drag them would be a better >> UI. >> >> 7) All the different types of toolbars needs to be cleaned up... >> >> 8) The added grey borders are not useful, IMHO it's just wasted screen space. >> Also the red border around the active page is not needed, I think. I assume >> this is because you want to know which page is "active" for e.g. pasting. I >> never had any trouble with xournal this way. >> >> 9) Initial zoom is giving me a page much smaller than my screen (this could >> be >> partially the X server's fault) >> >> 10) Some UI elements are now focusable with the keyboard (e.g. zoom slider). >> Long ago I submitted a patch that made all UI elements send focus back to the >> canvas so that the arrow keys on the bezel of tablet pc's would always scroll >> the page instead of e.g. changing the zoom when a UI element is focused. >> >> 12) The "very fine" pen has been removed. The finest pen is too fat for my >> taste. >> >> 13) Memory usage is drastically reduced. That's FANTASTIC. >> >> Great work Andreas! Let's get this thing into a release-able state! >> >> -- >> Cheers, >> Bob McElrath [ Heidelberg University, Theoretical Physics ] >> >> "If you're not failing every now and again, it's a sign you're not doing >> anything very innovative." -- Woody Allen >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Tue, 19 Apr 2011 08:49:46 +0200 >> From: Michael J Gruber <michaeljgruber+gm...@fastmail.fm> >> Subject: Re: [Xournal-devel] Xournal++ State >> To: xournal-devel@lists.sourceforge.net >> Message-ID: <4dad308a.1060...@fastmail.fm> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Andreas Butti venit, vidit, dixit 18.04.2011 17:12: >>> >>>>>> Regarding Images: >>>>>> Having the option to not attach them (just like backgrounds) would be >>>>>> really nice, with an element like: >>>>>> >>>>>> <image left="74.00" top="278.00" right="595.28" bottom="799.28" >>>>>> filename="bg_1.png"/> >>>>> why? >>>>> >>>>> The Image format I use is 100% compatible with the pach which is >>>>> available for Xournal on sf.net >>>> It's good to have it compatible (though that patch never made it into a >>>> released version), but still the extension with 'filename=""' would not >>>> break it. >>> >>> Are you sure? Try it out;-) >>> >>> Xournal has for reading always a loop which checks every attribute, if >>> you have an attribute more it don't read the whole file. >> >> That's not good. It should ignore that element only. Does it ignore >> unkown elements? >> >>> >>> That's the reason why I leave everything exactly the same. (Even if you >>> change the order of attributes it don't read the files any more). >> >> Uh. XML parser anyone? ;) >> >>> For me personal I said I leave it in the first release 100% compatible >>> with Xournal (and optional with the image patch). And if all is working, >>> the next release will use a new fileformat which is not compatible, but >>> contains resources and new features. >>> >>> (based on ZIP instead of GZip) >> >> What is the advantage of ZIP over GZip? >> >> On compatibility: I noticed that for a file "foo.xoj", xournalpp >> suggests "foo.xoj.pdf" for the exported pdf while xournal suggests >> "foo.pdf". Is that change intentional? >> >>>> Not attaching images is important because of file size, especially, but >>>> not only when you include the same image several times. I would say it's >>>> important for the same reasons out which backgrounds can be attached or >>>> detached. >>> This is an argument for using attaching images... >>>> Also, imagine using a "library" of images that you include again and >>>> again, or a workflow where you regenerate the image and want your xoj to >>>> use the regenerated image automatically. >>> This is no argument for attaching images, this is in my opinion against, >>> because the data is may inconsistent. >> >> I want it up to date with regenerated images in this case. Because that >> would be the "consistent" state in some use cases. >> >> I'm not arguing for a different default; I'm just claiming that there >> are use cases where you want to stay the image or background in the >> state from the time of inclusion and other use cases where you want an >> image or background to follow the state of a referenced file (like >> xournal's defaulft for annotated pdf's). >> >>> >>> There is a Python API for Xournal++, which is not finished yet, and at >>> the moment only used for testing, but later you should write a Python >>> Plugin for this, so there is for sure no inconsistency. >>> >>>>> For future releases I'll create a new format (e.g. based on ZIP) which >>>>> can handle resources better. >>>>> >>>>>> BTW: xournalpp produced that 'filename="bg_1.png"' for the image >>>>>> background, but the filename is "wrong". But then it does find it on >>>>>> restart! Quite confusing. OTOH, the "resuse image" dialog for image >>>>>> backgrounds is great and just what I would love for detached image >>>>>> objects also :) >>>>> I'll check this, I don't understand what you mean now, but I didn't >>>>> really test background image yet;-) >>>> Journal -> paper background -> Image: select "bend.png" >>>> Save xoj. >>>> >>>> The xoj is: >>>> >>>> <?xml version="1.0" standalone="no"?> >>>> <xournal creator="Xournal++ 0.1" fileversion="2"> >>>> <title>Xournal document - see http://xournal.sourceforge.net/</title> >>>> <preview>...</preview> >>>> <page width="22.00" height="31.00"> >>>> <background type="pixmap" domain="attach" filename="bg_1.png"/> >>>> <layer/> >>>> </page> >>>> </xournal> >>>> >>>> Different filename. But when I close and reopen xournalpp finds it or >>>> rather: I see now that there is a copy >>>> >>>> 2011-04-18-Note-15-07.xoj.bg_1.png >>>> >>>> in my workdir. Is that (copying background images) how it works with >>>> xournal trunk? >>> On the open dialog is a checkbox, "Attach to Xournal". Even on my >>> application (but in Xournal++ it's may not working correct;-)) >> >> Sure, but "attach" does something different from what I expected. My >> fault... There are 3 ways in which an image (inserted or background) or >> pdf (annotated or background) can be treated: >> >> A) refer to (relative or absolute) location (include path in xoj) >> B) include in xoj (as encoded content of an element) >> C) copy file to foo.xoj.<special ending> and refer to that >> C') derive a rendered version and apply C to that >> >> I wasn't aware of C until yesterday and thought "attach" does B. xournal >> does this with "not attached" (checkbox not checked): >> >> annotated pdf: A, e.g. >> <background type="pdf" domain="absolute" filename="/tmp/a/bend.pdf" >> pageno="1" /> >> >> background png: A, e.g. >> <background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" /> >> >> background pdf: C', e.g. >> <background type="pixmap" domain="attach" filename="bg_1.png" /> >> with a rendering of the pdf in <xojname>.bg_1.png >> >> I'm really wondering why it's doing that (rather then referring to the pdf). >> >> With the "attach" checkbox checked, xournal does: >> >> annotated pdf: C, e.g. >> <background type="pdf" domain="attach" filename="bg.pdf" pageno="1" /> >> with a proper copy of the pdf >> >> background png: A, e.g. >> <background type="pixmap" domain="absolute" filename="/tmp/a/bend.png" /> >> >> background pdf: C', e.g. >> <background type="pixmap" domain="attach" filename="bg_1.png" /> >> with a rendering of the pdf in <xojname>.bg_1.png >> >> That is, the "attach" checkbox does not even seem to work for >> backgrounds, and xournal always does C' (attach a rendered png) for >> pdf-backgrounds and A (refer to original png) for png-backgrounds. >> >> With the image patch for xournal, early version would do A and later >> versions would do B. >> >> Given that situation, I'm not sure that compatibility would be the best >> goal here... But in fact (and no matter what to do with the non-working >> background-attach option), to be as compatible and consistent as >> possible, xournalpp should never do B (xournal never did B), and >> inserted images should do C (by default)! As a positive side effect, the >> xml machinery would not have to deal with large binary-to-text-encoded >> blobs. Also, implementing A as an option for inserted images would be >> simpler then. I think the B-doing patch for xournal really lead us on a >> wrong path in this respect. >> >> Michael >> >> >> >> >> ------------------------------ >> >> ------------------------------------------------------------------------------ >> Benefiting from Server Virtualization: Beyond Initial Workload >> Consolidation -- Increasing the use of server virtualization is a top >> priority.Virtualization can reduce costs, simplify management, and improve >> application availability and disaster protection. Learn more about boosting >> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev >> >> ------------------------------ >> >> _______________________________________________ >> Xournal-devel mailing list >> Xournal-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/xournal-devel >> >> >> End of Xournal-devel Digest, Vol 17, Issue 3 >> ******************************************** >> > ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
