Re: [As-users] AfterStep 2.0 beta4 release

Sasha Vasko (
Thu, 18 Mar 2004 12:06:11 -0600

M.-A. DARCHE wrote:
> Running the AfterStep 2.0 beta4 release with the libpng-dev package
> provides a much more enjoyable user experience.

gald you like it :)

> I'm even more sorry because this seems to have convinced you to add
> libjpeg and libpng in libAfterImage in the end :-( as seen from CVS.

I was pondering doing it for some time, and another reason I did that 
was as it was needed for port to win32 ( yeah, I know I know, I'm evil :).
The good side of this is that I no longer have to maintain alternative 
set of images in XPM format, for those who don't have libpng installed.
So overall it will reduce the size of the distro - not increase it.

Also I was able work around possible conflicts with already installed 
libraries, as png/jpeg/ungif/zlib sources are compiled directly into 
libAfterImage - so you will not end up with several versions of libPNG 
scatered around the system.

> I run Debian systems and I had read about the need to have the
> libpng-dev package. But since ./configure didn't complain about that I
> thought I had all that was needed. I really do think, like others on the
> list, that having libpng and libpng-dev is a good practice.

Yeah, I was explained that quite often its preferred to not install 
devel packages, for example on embeded systems with limited space, on 
fileservers, etc.

>>> 2. A call to "Exit -> Restart session" in the menu caused an error. I
>>>    could not find the core dump as in my filesystem advertised :
>>> Printing Debug Information :
>>Thanks for reporting that - fixed.
> I could not test that since the CVS code doesn't build at the moment.

doesn't build? whats the error ?

>>> 3. I could not make work any of the form and script "screenshot"
>>>    utilities.
>>Script and Form Modules has not been implemented in 2.0 yet - what you 
>>trying to use are the leftover from old afterstep installation - they 
>>won't work.
> Can we help on this even if we don't know AfterStep C code ?

Well, surely anyone willing to help - can help. Form module is somewhat 
large project within the project, as it includes its own library of 
widgets. In fact it was originally created to facilitate something like 
AfterStep Desktop Environment. I think the idea was of Guylhem Aznar 
back in 1998. I don't really have any hopes for achieving such an 
ambitious goal, due to several reasons, such as lack of advertisement 
muscule of major corporation, the fact that AfterStep is sort of a black 
hole as viewed by Open Source Establishement, etc, etc.

There are two approaches to fixing Forms module :
1) rewrite all the widgets in the library to make use of new 
libAfterStep/Image facilities (which should simplify things alot).
2) rewrite Form module to make use of GTK or FLTK widgets if available.
3) drop Form module completely.

I personally favor first approach, as I'm greately dissatisfied with 
GTK, and although I like FLTK - it does not have sufficient market 
penetration. (Qt is completely out of the question, don't even ask why).

Another use for Form module might be for long overdue ascp.

If anyone wishes to engage into Form module fixing in ob=ne way or 
another - feel free to, I'll suply all the needed 
information/help/anything. The only requirement I have is the same as 
what women expect of a men, and what men rarely deliver - a commitment :)

>>> 4. I did not manage to change the background of any of the desktops.
>>>    The configuration I use was in a file
>>>    afterstep-2.00.beta4/share/afterstep/looks/look.Border. I restarted
>>>    afterstep and selected this file in the "look" menu with no effect :
>>Have no idea where you got this look from - its not in the 2.0 distro. 
>>That maybe another leftover from old afterstep installation.
> This look is a look I'm trying to come up with as a contribution to
> AfterStep. It should feature window borders when done.
> I'll do other tries before reposting.

TRy sending me the look - I'may point out some mistakes/errors/etc.

>>>     want. But AfterStep follows standars and good pratices in so much
>>>     domains that using well-formed XML is a something that one might
>>PLease feel free adding all those doublequotes and submitting me a patch.
> Patch included in this email. XML normalization has been done like that :
> $ for i in ./backgrounds/Plain_Textures/xml ./backgrounds/xml ./desktop/bars/xml ./desktop/buttons/xml ./desktop/icons/mini/xml ./desktop/icons/xml ./desktop/tiles/xml; do tidy -xml -modify $i/*; done

Applied the patch - thatnks alot, especially for the README change.

>>filename extentions are evil. period. for example what prevents me from 
>>slapping .jpg on xpm file? Nothing, and I could very well do that - 
>>leaving you very confused. On the other hand if you have alot of files 
>>with extentions of .jpg, and you set up your config accordingly, but 
>>then you decide to switch to PNG format - you are in deep trouble now, 
>>as you have to change all your config files, and you have to somehow 
>>support lots of users ot there who have .jpg files referenced from their 
>>File type should only be decided from the file contents. It should never 
>>be based on filename. Silly tradition of associating filenames with file 
>>type comes from equally silly MS Windows, and it'd be wonderfull if it'd 
>>stayed in there only. If you want to use more MSWindows-nesque system - 
>>please use KDE.
> Don't be insulting, you know just like me that file suffixes helps a lot
Did not mean to insult, sorry about that - this issue tend to get me 

> for automatizing, otherwise you would not use .c files for AfterStep

Its difficult to deduce content's type of the plain text file, and 
.c.h.cpp are a crude fix to attempt to fix it. It does not really work 
well, as one could put C++ code into .c file, and that will work on some 
systems, while being broken on others. So again using extentions is evil 
here. Properly written compilers should be able to deduce what grammar 
is used to alter compilation accordingly.

> code, would you ? But as for the AfterStep XML images I now really agree
> that suffixes should be avoided. And as a side note, one can find some
> XML files with the .xpm suffixes in AfterStep at the moment.

Yes, and the reason is that I did not want to break old configuration 
based on XPM files, as I switched to PNG. So I had to create "shortcuts" 
to PNG files using XML. As the result you get ugly situation where files 
with extention of .xpm really are XML files. That was what convinced me 
to drop extentions altogether for any new image file added.

> Regards,

Thanks again for the patch.
As-users mailing list