Re: [Shapefusion-devel] building on linux

[tiennou <tie...@gm...>]

Le 2 mars 07 =C3=A0 00:21, Tito Dal Canton a =C3=A9crit :

> 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 =20
> 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 =20
> wxUSE_STD_IOSTREAM
> set to false... Of course I have it set to true ;-) Also =20
> 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?

Yes, feel free to commit at anytime you feel is right. This is =20
cooperative development after all ;-)

>> - 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 =20
> *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 =20
> logic.
> Also I think code duplication can be reduced to a great extent in the
> future, we just need the right idea.

That's what I think too...

>> - 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 =20=

> will
> do their best to display it as best as possibile when asked, and
> automatically rebuild their caches when they detect some change. I =20
> need
> to think about this...

We could send events related to changes containing the new =20
std::vector pointer, which then trigger an event handler in the =20
Browsers code...

> I managed to build! See the following screenshot... Looks like your =20=

> GUI
> bug is multiplatform ;-)
>
> http://altivec.fisica.indivia.net/shapefusion_wxdoc_first_test.png
>
> I had to do many fixes in the code, basically wxT's missing in every
> wxLog and wxUSE_STD_IOSTREAM cases. Is it worth committing them? I've
> also moved some files so I'm not sure what I have to do.

I love the look & feel of your *nix ;-) What's that ?

I thought that wxUSE_STD_IOSTREAM would be a problem for you, the =20
thing I found strange is why wxWidgets on OS X doesn't use this too...
Yes, as I said, feel free to commit when you fix bugs (the wxT is me =20
not having good wxWidgets practices).
In order to move things in svn, you need to issue a svn move (not =20
just mv), as svn will update your local copy information, and make =20
the actual mv. On some occasions (when the file you move has local =20
modifications, you will need to --force, because svn prevents that =20
due to the delete involved (a move is a svn copy/svn delete).
I don't know if you did, but I'd recommend reading the subversion =20
book, as there is lot of interesting stuff in there...

> Fortunately, the GUI bug seems trivial after all.
>
> The new code is not filling the main wxTreeCtrl at all, so what should
> it display? ;-) You are just creating the root item, but it won't be
> displayed because the tree control is created with the wxTR_HIDE_ROOT
> flag. This is compatible with what's in the screenshot I made: you can
> see the empty tree control on the left (white) and the dummy sizer on
> the right (gray). Like the "empty" editor of the original trunk.

I see what you mean... There is a discrepancy on OS X, the wxTreeCtrl =20=

takes all the space on the window (not just the left part, it extends =20=

up to the right side). I'll take a look at this when I have a better =20
grasp on GUI code...

> In the original trunk, the tree is filled in
> ShapesEditor::MenuFileOpen(), which is now completely commented out. I
> think the filling can be done in ShapesView::OnCreate(), just after =20=

> the
> creation of the root item (make sure you can access the sequence =20
> names,
> you need them). This will produce something more reasonable I hope :-)

I'll take a look at this... I see that you made some changes to the =20
trunk, I'll try to backport them to the branch (that way I'll =20
exercise my svn skills ;-)).
I've taken a look at compilation on Windows, but got stuck on =20
compiling wxWidgets... I'll try again when the branch-trunk merging =20
is done.

tiennou=