All,
I said the first time, I am doing the refactoring because I don't understand
the logic of the code. Please don't take the small amount of work in
XournalMain.cpp as an example of my prior and future comments. I hope by
refactoring I will gain a greater understanding of the ideas Andreas had
while writing Xournal++.
Since people seem to be confused about my issue with the current codebase, I
will try and elucidate my thoughts for you guys once and for all. Before I
do though, I should just state, my refactoring of the code is not intended
to be a solution to the issues I will raise. I am again, doing the
refactoring to understand the logic.
The original source was written in C, it was decided to rewrite the codebase
in C++. This is a great idea. Lets make sure we understand why this is a
good idea. When one designs a program in C++ over C, they do so to write
code in more abstraction than in C. What does this mean? Over the years this
idea has evolved, and has stabilized to the concept of generic programming.
Concretely, one might point to classes and say, C++ has classes, but C does
not, so we are going to use those to be more abstract. However it is not the
case that just because you have these objects that you are necessarily
producing the correct abstraction. To design in C++ properly you need to
think generically about the code you are trying to produce (this is at it's
core the idea of generic programming, you have ideas in your head, you want
to describe them similarly in the code).
When I try to think generically about the design of Xournal, I expect, to
have a few relatively small objects, maybe one for the state of the GUI
buttons and such, and another for the state of the canvas (presumably
composed of GTK+ objects with STL/Boost containers).
I would then write libraries (i.e. generic templated code in header files),
which given objects such as these state objects, and maybe events of some
kind, performs actions on those objects. The library code would be the heart
of things, but, since we are being abstract, we want to minimize the amount
of libraries we need. These libraries and objects would be instantiated and
called, inside of some kind of GTK mainloop, which makes the whole thing go.
So an important point here is you shouldn't re-implement constructs that are
already written for you. Since this is an important point, lets consider
parts of the current implementation of Xournal++.
You use the GTK+ Library because you don't want to write the entire gui
stack from scratch. This is good. Much in line with that, you need not
implement your own iterators `/src/util/Arrayiterator.h` or your own
strings, `src/util/String.cpp,` because guys like Stepanov and Stroustrup
did that for you (in the STL).
One might think that this specific example is a contrive argument, but, if
you can't get strings right, you definitely will not design a more complex
structure properly either.
Along these veins, notice that you have many files describing how to
serialize objects, again, Boost already implements object serialization, and
provides an incredibly simple, generic, interface to extending/using it.
As I delve into the source more, I will be able to draw more and more of
these analogies. All I need to do is figure out what it is that your code
does, then we need to map them to concepts that we already have defined. For
example the Point object is essentially a pair<int,int>, or maybe a
vector<int>(2), bundled with a few functions which can be library-ized.
I'm not trying to belittle the efforts of the team here, I really appreciate
taking the time to release a preliminary C++ version of the code. What i'm
trying to say, in maybe a too abstract and non-direct fashion, is that you
should try and develop a preliminary Xournal++ which matches Xournal, but
design it properly (e.g. generically), instead of focusing on new features
right now, such as collaboration. After a proper generic design is in place,
adding new features will amount to extending your libraries where necessary,
as you build up a library of new tools, implementing new features should
become easier, as you already have all the algorithms at your disposal, in
a generic way.
You can certainly agree that there is little purpose in releasing a
functionally equivalent Xournal++, which under the hood is going to get
scrapped next release anyways due to poor design.
And as far as the comments i've read, "go off and do it then," as I've said,
I am going to try to, as best as I can, once I understand the current codes
(which might take time). I mainly just want to communicate my efforts to you
guys.
Thank you for your efforts, and patience in understanding my opinion, I hope
that I have convinced you that focusing on the generic design of the
implementation, is a worthwhile endeavour.
-rhl
On Mon, May 9, 2011 at 9:29 AM, Denis Auroux <aur...@math.mit.edu> wrote:
> Ryan: I'm not actively involved in Xournal++ and mostly trying to stay out
> of the discussion, but I'm not sure I understand the point of refactoring
> the code now.
>
> It's still evolving rapidly, Andreas is not done with the first release,
> and apart from the bugs that still need to be ironed out, the only obviously
> wrong thing I can see with the code is the dependencies on poppler
> internals, which tend to evolve quickly. As far as I understand this is
> going to be addressed.
>
> However, it's your choice.
>
> Denis
>
>
>
> On 05/09/2011 05:23 AM, Ryan Lewis wrote:
>
>> 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.
>>
>
>
> --
> Denis Auroux
> MIT Department of Mathematics aur...@math.mit.edu
> (on leave) and
> University of California, Berkeley aur...@math.berkeley.edu
> Department of Mathematics Tel: 510-642-4367
> 817 Evans Hall # 3840 Fax: 510-642-8204
> Berkeley, CA 94720-3840
>
------------------------------------------------------------------------------
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
