[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pablo-devel] I did take a look at the code:
From: |
Abhishek Nayani |
Subject: |
Re: [Pablo-devel] I did take a look at the code: |
Date: |
Tue, 13 Nov 2001 10:29:34 +0530 |
Hi,
On Tuesday 13 November 2001 01:13 am, Ries van twisk wrote:
> Hi Abhi,
>
> I do this by mail because properly I don't have much time at my work.
> Here are some toughts:
> 1) in the class Frame I see a 'selected_flag' i don't think it should be
> there. It's better IMHO to remove it and create two PtrLists:
> - One list for all frames on the document/page
> - One list for all frames that are selected.
> We can store both list in the frame class itself as a point to a
> QPtrList. This will add 4 bytes off memory to the class but this is I
> thing much cleaner and it allows us to create groups of frames. If we
> don't use grouped frame then we should add it the the Page class:
> QPtrList<Frame_Info> frame_list; QPtrList<Frame_Info>
> selected_frame_list; A group off frame is extreemly useble when doing
> repeated actions on a lot of pages. in that case it will save is 4 bytes
> of memory. give it a tought....
I have put the selected flag in the frame to help it know how to draw
itself
in the two states. Even if we maintain a separate list for selected frames,
we require this for the visual change. Anyway , right now i am storing the
selected frame in the pointer current_frame. it can easily be changed to a
ptrlist.
> 2) I see that code for frame positioning and frame size is still
> seperated from eachother. Peronally I think that's a extreemly bad way
> of OO design. The power of OO is to combine both code and values so a
> object can 'maintain' itself. Ofcource this is not a 'xtrict' world but
> should be followed where we can. Can you point me to a side on where
> they explain this design and the advantage/disadvantage of it?
Actually i find no need for the frame to know where it is . This is in
conformance to the OO principles ( need to know principle ;-)). How we can
use this is: the frame knows the its own size, so it creates a QPixmap of
that size, draws everything on it and returns the pixmap to the above layer ,
which here is the Page. The page can do whatever it want to do with it ie
place it anywhere. I am maintaining a strict hierchy here. The other way we
can do , how i do it now, is the page will create a QPixmap of its size and
give it to the frame along with the position where to draw itself. So every
thing is buffered here. we only require the frame to know the actual
co-ordinates if we want the frame to know where it is and do some
calculations based on that info. which we are not doing. we are not going to
use the frame co-ordinates as the frame is going to calculate everything
relative to itself. you can see how this progresses. FYI, the book i am
referring to is "Design Patterns - Elements of Reusable Object Oriented
Software" -by Erich Gamma et al. I very much like this book and am trying to
learn something from it. I recommend u buy the book. As a case study, he
describes how to go about writing a WYSIWYG editor , just what we need. I
have also readup on some of the papers referenced by the book on design.
What i am trying to do with the Glyph is implement the flyweight pattern &
composite pattern.
> 3) I don't understand wy we have q Point3D. Is it because we need to put
> frame after a other frame or on top of a other frame? If so way don't we
> follow the QptrList, first item is bottom and every next items is on top
> of the other item?
The normal glyphs aren't going to be handled directly. They will always
be
enclosed in some frame. For these, i will use the Point2D struct, whereas for
frames which might overlap each other, its far more simple and easier and
efficient to just maintain the z co-ordinate than try to maintain them in a
list in some order. We are reducing the no. of calculations required here. We
just fill in the point3D add it to the list and forget. We will be doing the
comparision when we will be drawing it. As shuffling the list can be quite
heavy on the resources.
> i'll try to get on chat tommorrow morning.. Same time
See u there,
Bye,
Abhi.
>
> Ries
>
> _______________________________________________
> Pablo-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/pablo-devel
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com