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