Re: [Shapefusion-devel] things

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

Le 1 mars 07 =C3=A0 12:54, Tito Dal Canton a =C3=A9crit :

> Hi, I'm finally examining your branch and I'm happy to see what was
> done. Good job! Code looks a lot more organized and clean (and I guess
> it will be event better once we merge and all that). I'm glad you
> decided to go back to std vectors.

I read on the wxWidget site that wxList predated the time std:: was =20
cross-platform, so I though it would be better to use wx-things =20
instead of std:: ;-)

> I have a comment on ShapesDocument. The member "mCollections" could
> actually be a simple static array rather than a std::vector, since =20
> we'll
> always deal with 32 collection slots.

I would prefer keeping modularity, because maybe one day this 32-=20
collections-per-shapes-file could be lifted...
That's just a thing, but creating an editor for Aleph One mean =20
enhancements can be made to the files Aleph One uses (provided Aleph =20
One team agrees), but that might be for a future time...

> Also in ShapesDocument::SaveObject(), you say
>    ShapesCollection    coll =3D mCollections[i];
> but it should be a pointer I guess.

Hmm, I don't see this part, and the code in svn is out of date.
Anyway, I tried getting the GUI working again by binding ShapesView =20
to ShapesEditor : I thought I could keep ShapesEditor and instanciate =20=

it from ShapesView, passing it a pointer to the child frame. However =20
this crashed with an error I don't recall, so I moved everything from =20=

ShapesEditor to ShapesView, and now I get a complete white background =20=

(instead of the typical MacOS X background).
I'm commiting so you can take a look at this, I'm afraid there is =20
still something I don't grasp in the wxWidgets way ;-)
I'm not sure I correctly made the link between View and Document... I =20=

replaced all instances of payload to ((ShapesDocument*)GetDocument)-=20
 >, because that seemed the only way to retrieve the ShapesDocument =20
after loading, but as GUI doesn't work I can't test this. gdb told me =20=

that it was a ShapesDocument so I casted it... I wish there was more =20
stuff about the Document/View framework on the net...

> I think that ShapesLoaders classes could all go inside ShapesElements.
> That would be the "master" file for the shapes editor. What about =20
> this?

Yes, that can be done, but I thought that the ShapesElement class =20
could be renamed and kept separate, because it will prove to be =20
useful when I'll have a look at Sound files. But as it is just a =20
small debugging class, I will put ShapesLoaders and ShapesElement =20
inside ShapesElements...

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

I've been thinking about the different View/Browsers. I would like to =20=

know what do you think about...
- Refactoring things about thumbnails, because there is a couple of =20
code duplication out there, caused by the separation between Frames =20
and Bitmaps...
This limitation could be lifted by merging Frames and Bitmap at =20
loading time, and splitting them again when saving.
- Maybe they could be passed pointers to the std::vector so they =20
could manipulate the structure directly, or something...

tiennou