I'm not saying not ever to allocate on the heap, i'm saying you **can** use
the stack sometimes. I also did NOT say MVC was the wrong approach, I just
questioned if it is the right one.
You shouldn't need to count your objects with macros, good design should not
have these ambiguities. No macro can verify the correctness of the code.
And, I am trying to refactor, I already started in XournalMain.cpp, and i'm
looking at the monolithic Control and MainWindow objects next, it's hard for
me to single-handedly rewrite your code, since I am still trying to
understand what it does, so I can't "just rewrite it quietly." Also, if you
are not interested in my changes, or if you move forward with major changes,
this merge will be, appropriately named, a giant headache.
-rhl
On Mon, May 9, 2011 at 2:53 AM, Andreas Butti <andreasbu...@gmail.com>wrote:
> > 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
>
------------------------------------------------------------------------------
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
