> The more I'm looking into the code (and the development process) I'm > getting the impression that that's not what is happening. Why?
> Ryan's > suggestion to refactor the xournal++ code (which has not seen it's first > release) is a really extreme way of confirming my observation. Ryan thought there are a lot of memory leaks, but each object is counted with macros, so I can be sure there are no one. Ryan also wrote MVC is the wrong approach, but he didn't tell me the right. And he think I should not allocate object on the Heap, I should them allocate on the stack. I don't duplicate libraries, and I only use the headers which are installed on Ubuntu. And I don't implement new features at the moment, I'm only working on stability, Collaboration is not implemented by me, and this is a separate Module. Andreas Am 09.05.2011 08:39, schrieb Michael J Gruber: > Matthew Chan venit, vidit, dixit 09.05.2011 05:54: >> Hi Ryan, >> >> I'm not familiar with all the autotools magic you need to get it >> working, but I needed to modify the source files with the unresolved >> header dependencies to point to a local copy of CairoOutputDev.h >> >> Andreas and I have already discussed using PoDoFo as a replacement >> library for the current poppler workaround we are using. It's on the >> todo list, but it's also not a trivial change I believe. Plus since we >> need some other API changes to implement collaborative features, there's >> a hefty backlog. (Not your fault for bringing it up again though, I >> don't think we forwarded our full conversation back to the devel list.) > I thought the basic principle was to design xournal++ as a feature-par, > compatible xournal replacement first; implement additional features and > possibly a new incompatible format (if needed) later. > > The more I'm looking into the code (and the development process) I'm > getting the impression that that's not what is happening. Ryan's > suggestion to refactor the xournal++ code (which has not seen it's first > release) is a really extreme way of confirming my observation. > > Even minor new features may potentially introduce new instabilities > which xournal did not have (as the pdf info - LOGNAME issue showed). > Getting the new code base into a stable, compatible and extensible shape > is complicated enough already. > >> Further, on fedora (as I think it's been discussed here), we will >> not be able to include the relevant codes in the xournal packages, >> things should compile properly against the poppler-* packages >> already in the fedora repos. > I'd say any distribution deserving it's name has a policy not to > duplicate libraries and headers. There are exceptions, but in very > specific circumstances only (as far as Fedora/RHEL/... goes). > > Especially including a header for an interface which is not defined as > "stable" may render xournal++ unusable after an API-compatible (even > ABI-compatible!) update to libpoppler, so that policy really makes sense. > > Michael > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Xournal-devel mailing list > Xournal-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/xournal-devel ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
