Mattia,
I understand the idea to make wxPerl just with things of wxWindows, and
I'm making a lot of other foo things, that I don't want to introduce in
wxPerl to not break the wxWindows style. But with wxWindows we don't have
the problem of the dalay time to show a Splash, and if the Splash is slow to
start, it's not very useful. :-/
I can't obligate you to introduce the SplashFast.pm, but just think about
the use of the Splash without it!
Graciliano M. P.
> First, I appreciate the efforts you are putting on this, so read
> what follows with this appreciation in mind!
>
> >Mattia wrote:
> >> I'm not that excited about incorporating it ( I'd like to keep the core
> >> as small as possible ), but I can be convinced otherwise, of course.
> >
> >Mattia,
> >
> > My first example was just a big test, but was a mess in the code.
> > Too much changes in your modules just for one thing, the Splash.
> >
> > But I finished the SplashFast.pm module. It's simple and independent,
> > don't need changes in the other modules. Please thake a look in the
> > new .pm because 11 different peoples was looking about this
> > in the last 3 days, and asking me how to use.
> I know this; the problem is not in your code, is more: where do we
> draw the line of what is in wxPerl and what are modules based
> on wxPerl? I, personally, would like to include your SplashFast
> in wxPerl, but, if wxPerl becomes very popular, and, say,
> 100 people made their little module to do "Foo" using wxPerl,
> I would like these modukles to be external to wxPerl; I am not
> saying your last SplashFast.pm is not worth inclusion in wxPerl.
> is that it can work as well as an external module, so it does not
> need to be in the wxPerl distribution.
>
> I hope you can understand why I am exitant, I'd like wxPerl to
> contain just what is in wxWindows + contrib.
>
> On the other hand, it is handy for SplashFast.pm to be inside the
> distribution ( you just need wxPerl, no external modules ).
>
> Regards
> Mattia
>
|
