or remove files. :-)
I fixed that. I also fixed a bug in filter_test that would have been
revealed by the proper warnings flags. So whoever wrote that wins the
raster boobie prize for allowing a non-void function to return without a
value.
I also made the spec file auto-generated.
SVN revision: 2719
play with soon - want to get the stuff correct before I commit some more
stuff. dox is the start of dox2 the document viewer based on imlib2. Designed
so that the style of the docs is seperate from the contents. Will evolve
rapdily over the next week.
SVN revision: 2716
-bmp2pt add this too it's command line and it'll bump map to where the
cursor is.
otherwise you will just get bump mapping from an infinite dist lightsource
SVN revision: 2687
variable to another filter as willem requested the other day.
eg.
filter( var=anotherfilter( var=13,var=30 ), var=blum );
youcan have as manylevels of filters as you want.
* parser should be quicker, no need to add "NULL" to the end of a
imlib_apply_filter() command.
* some more funky filters should be added soon, at 4.45am i decided to leave
that job till t/m.
SVN revision: 2686
one, this means the bump_mapped pr0n will now render a coupla degree's faster
(gilbertt this is for you, and those pictures of pabs' mom)
* Update Imlib2.h and api.c to reflect changes
ps. on the road to the next gen script interpreter
SVN revision: 2677
here's my humble attempt of an xpm loader, based on Imlib1 code. Seems
to work fine on the xpms I found on my box. I'm not sure if the
progressive stuff is feasible, though :o) ...
SVN revision: 2654
(gilbertt)
Actually, made the gif loader give back what it's got without changing im->h
to reflect, or reallocing the image data. The reason for this is that it
already told apps what the image size was in the first progressive loader
callback, and changing it afterwards can cause confusion. Also, an app can
still handle/display a half-loaded image, as the rest is just filled black,
and the programmer knows how much of the image he got, 'cos he interrupted
it from the callback. If the programmer wants to trim the image, he knows
where to trim it, but if he/she wants to display a part-loaded image,
that'll work sanely.
I think this is more sane behaviour, having tested it in feh and
imlib2_view, but feel free to disagree ;-)
SVN revision: 2561