Re: Re: Some updates
Darren Vincent Hart <[email protected]> Tue, 07 Oct 2003 08:32:19 -0600
| Newsgroups | gmane.comp.embedded.stk.gui.devel |
|---|---|
| Message-ID | <1065537127.21794.6.camel@sway> |
On Tue, 2003-10-07 at 01:37, Marc Strämke wrote: > Darren Vincent Hart wrote: > > This last week I have done the following: > > > > 1) Found and squashed a bug resulting in the xine_panel seg faulting on > > destruction (thanks to vhmauery for the extra set of eyes.. two extra > > sets actually... nevermind... :-) > > > > 2) Added background image support to states. There is now another named > > constructor that accepts a std::string bg_image_path as its last > > argument. It needs to be the path and not an image::ptr since the > > image::create call requires a surface and the state object isn't > > constructed before we need it. > hmmm, this seems hackish, doesnt it? The user could aswell contruct the > image himself and provide an image::ptr (he has a pointer to the on > screen surface anyway) I struggled with this as well. Here are the two options: // my original implementation state::ptr main_state = state::create(app, image::create(screen, "path/to/graphic"); // current CVS implementation state::ptr main_state = state::create(app, "path/to/graphic"); While currently all states share the surface of the application, it seems hackish to me to pass a state's child another object's surface to draw on (and state isn't fully constructed, so we can't pass it state's surface), and certainly not intuitive. I also wanted it to be simple to create state's with image background (as I think most states will be created that way in practice), so I opted for the latter. Besides, it allows us to implement how the image is stored any way we wish (we may later find a better way than an image::ptr member variable...) Opinions? Darren > > > > Darren > > > > _______________________________________________ > Libstk mailing list > [email protected] > http://www.dvhart.com/cgi-bin/mailman/listinfo/libstk