Am 09.05.2011 14:23, schrieb Ryan Lewis:
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.
Ok, I misunderstood you.
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.
But the Macros can check for memory leaks, you can also use tools for
this but macros with a counter do also this job.
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.
I don't really understand why you are refactoring my code?
You wrote me if I use double "->" to access methods / objects this is
slow, but you created in the main code simple two new methods, OK, it's
not wrong to copy these 30 lines to a new method, I'm wondering who this
match together, then a method call needs also resources.
I don't do refectoring now, I'm working on the texteditor, which has a
lot of bugs.
*Please tell exactly why you try to do this, and what's your target.*
I don't understand this.
Andreas
-rhl
On Mon, May 9, 2011 at 2:53 AM, Andreas Butti <andreasbu...@gmail.com
<mailto: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
<mailto: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
<mailto: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
