[Shapefusion-devel] building on linux

[Tito D. C. <ti...@da...>]

On Thu, 2007-03-01 at 21:34 +0100, tiennou wrote:
> I would prefer keeping modularity, because maybe one day this 32- 
> collections-per-shapes-file could be lifted...
> That's just a thing, but creating an editor for Aleph One mean  
> enhancements can be made to the files Aleph One uses (provided Aleph  
> One team agrees), but that might be for a future time...
You're right.

I think you were correct in moving ShapesEditor things to ShapesView.
That's what's intended: the *View contains the GUI. I'm trying to build
on Linux to reproduce the GUI bug, but I'm stuck in fixing bugs and
making my system like the new code. I guess you have wxUSE_STD_IOSTREAM
set to false... Of course I have it set to true ;-) Also utilities.h and
MyTreeItemData* are to be moved to Shapes/, they don't have a point in
being in the top level directory. May I commit these fixes when done?

> I'm commiting right now... I really need help on this damn white- 
> background problem ;-). I think it would be better to keep the  
> separation between ShapesView and ShapesEditor, because GUI code is  
> awful, but if this is the only way...
As before, it's the right way to do it I guess.

> - Refactoring things about thumbnails, because there is a couple of  
> code duplication out there, caused by the separation between Frames  
> and Bitmaps...
> This limitation could be lifted by merging Frames and Bitmap at  
> loading time, and splitting them again when saving.
Hmm, no. Let's keep bitmaps and frames well separated. Even if
ShapeFusion displays them in a very similar way, in Shapes logic they
are well defined entities... Bitmaps are chunks of pixels, frames are
bitmap "wrappers" that just *reference* a bitmap, but they are *not* to
be treated as bitmaps. I think that's an important distinction. So I
say, let's keep a little code duplication and respect the Shapes logic.
Also I think code duplication can be reduced to a great extent in the
future, we just need the right idea.

> - Maybe they could be passed pointers to the std::vector so they  
> could manipulate the structure directly, or something...
What I didn't like about the old trunk were those AddBitmap/AddFrame
methods in *Browser. Maybe we could make *Browsers more intelligent:
just give them the appropriate collection std::vector pointer; they will
do their best to display it as best as possibile when asked, and
automatically rebuild their caches when they detect some change. I need
to think about this...

Tito
-- 
Physics is reverse engineering