Christopher Faylor wrote:
Is there anything similar to this in Red Hat, Debian, SuSE, etc.?
Well, /etc/profile, hosts, passwd, group and other core config files are
owned by the 'setup' package in Red Hat Linux. Then there's the
initscripts package for the rc.d directory. And most of the
Charles Wilson wrote:
John, why don't you create a bashutils package, to serve as a
collection of (moderately) useful bash scripts and settings. For now,
it could contain only bashcompletion, but later you could add -- oh,
bashprompt, or something...
I'm sure every daily bash user has
Christopher Faylor wrote:
I just perused the setup.exe source for the first time in a long time
and found a few copyrights from a few different people.
I understood that when you signed the consent forms, you signed over
your copyrights to Red Hat, for simplicity's sake. Therefore, the
Robert Collins wrote:
There is a step beyond... rather than a copyright assignment, we can
require mugshots :].
HAVE YOU SEEN THIS CODER: Wanted for improper curly-brace placement on 5
systems
--
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m
Robert Collins wrote:
This does not belong in setup. It belongs in a postinstall script for a
package. One possible package is the one John Morrison put together that
I'll be uploading realsoonnow. Another is cygwin itself.
I just wrote such a patch. See the patches-l. Further discussion
Christopher Faylor wrote:
(who's madly trying to think up some scheme to make the gold stars actually
worth something)
Votes on ITP requests and suchlike.
Christopher Faylor wrote:
That's right. RPM does not have Recommends, and that would be nice. It isn't
designed to be UI based, though.
Is this a real problem?
Wouldn't the eventual solution still have to have a setup.ini-like file,
that at least lists all the available packages? You can use
Williams, Gerald S (Jerry) wrote:
installer when needed/requested. The base Cygwin installer
could then be done using MSI or whatever and could initiate
reboots/etc. as needed before starting the package updater.
Rebooting is a cop-out in this case. All the setup program has to do is
stop
Warren Young wrote:
stop running services before starting the upgrade.
Thinking more about it, couldn't you just call LoadLibrary() on the full
path to cygwin.dll, and if that succeeds, get the process list from it
and send out kill signals?
If LoadLibrary() doesn't succeed, either Cygwin isn't
Christopher Faylor wrote:
How are they packaged elsewhere?
I seem to recall that the practice of packaging all the BSD games
together is most common on more 'traditional' *ixes, like the BSDs and
Slackware. It's been awhile since I played with any of those systems,
though, so my memory is
Yitzchak Scott-Thoennes wrote:
I'd leave out ones that are already packaged elsewhere (banner, wtf,
fortune,
etc.) or ones that don't build easily.
I don't see people wanting 'just' fortune, or 'just' wtf. More likely,
a person will be making a decision about whether they want their Cygwin
Yitzchak Scott-Thoennes wrote:
How big is a complete bsdgames binary package for Cygwin?
the tarball is about 750k.
That doesn't seem excessive for a single package.
Brian Dessent wrote:
Another possibility might be to embed the .chm or .hlp file in the .exe
as a resource. I don't know if that's feasible or not.
Tricky at best. Both WinHelp.exe and hh.exe are separate programs, and
their APIs seem to have no way to tell them to look at a resource inside
Brian Dessent wrote:
That reminds me... another idea that cgf mentioned earlier was having
setup.exe offer to show the README files of packages it just installed.
I'd only go for that if there were a short version of the README,
containing just the barest things you need to be aware of when
Igor Pechtchanski wrote:
Circular dependencies are not bugs.
Well, there are two types of circular dependencies, and they're only a
problem in one of these instances.
Circular dependencies of packages in operation is not a problem. That
is, you can say that there is Package A which uses
Warren Young wrote:
To be effective, the option would have to be enabled by default, with
the ability to turn it off.
I've thought of a better way to handle this: versioned setup hints. The
first time you install Cygwin, you have to at least skip past all of the
hints explicitly. When you
Christopher Faylor wrote:
I don't think that the option of reading READMEs should ever be turned
off, unless it's via a command line option. I'd rather annoy people with
the prospect of documentation than casually turn it off because they decided
once that they didn't want to see it.
At the very
Gary R. Van Sickle wrote:
It's a magical Windows batch/Perl script combo in a single file.
If this were distributed along with Cygwin, it would be even simpler.
Just tell the person to go to c:\cygwin\bin in explorer and double-click
this script to run it. (Can't ask them to run it from
Gerrit P. Haase wrote:
Still no joy.
What is the problem?
The MySQL++ examples hang, as reported a few messages back in the thread:
http://sourceware.org/ml/cygwin/2005-08/msg00151.html
Thanks for your effort, but I'm ready to give up, for the overriding
licensing reasons stated elsewhere
Sorry, wrong list.
Brian Dessent wrote:
Except, from the standpoint of setup there is no way to distinguish the
following two scenarios:
A) User knowingly uses local company mirror, or uses a non-official
mirror to install non-official packages.
B) 2 years ago, user chose a mirror located on a ISDN line in Outer
Brian Dessent wrote:
There can be
at most only one mirror URL in the dialog that is not official:
Ah. I didn't know that limitation.
I'm thinking an asterisk after the name (with
dialog text explaining its meaning), since using color becomes confusing
when you also have the
the upstream documentation in
/usr/share/doc/PKG-VER.
Cygwin port maintained by Warren Young warren at etr dash usa dot com
Please address all questions to the Cygwin mailing list at cygwin@cygwin.com
Brian Dessent wrote:
Most standard autoconf/automake-generated configure scripts support the
use of DESTDIR for the make install step.
Ah. Then I think I can fix this by making ctags' Makefile.in honor
DESTDIR. Tiny patch with low impact, so likely to be accepted upstream.
I have just packaged ctags for Cygwin for the first time, due to the
recent release of version 5.6. Since I'm new at this and I'm using my
own hand-rolled package build system, please treat this as a newly ITP'd
package. It looks right to me, but it needs review.
The files:
Chris Sutcliffe wrote:
I have just packaged ctags for Cygwin for the first time, due to the
recent release of version 5.6. Since I'm new at this and I'm using my
own hand-rolled package build system, please treat this as a newly ITP'd
package. It looks right to me, but it needs review.
I'm
Warren Young wrote:
I have just packaged ctags for Cygwin for the first time, due to the
recent release of version 5.6. Since I'm new at this and I'm using my
own hand-rolled package build system, please treat this as a newly ITP'd
package. It looks right to me, but it needs review.
Anyone?
Dr. Volker Zell wrote:
Builds fine, GTG.
Thanks for testing it!
Why don't you use cygport, it'll help in the long run ?
I haven't been paying close attention to it. I thought it was still
considered experimental. Are you endorsing it for general use, then?
I had bad luck with g-b-s
This is a reprise of my previous ctags thread.
To reiterate, because I'm a new maintainer using a relatively untested
build system, I'm treating this like a new ITP, even though ctags is
already part of the Cygwin distro. I'm creating a new thread as a
result of Corinna's recent HEADSUP
Corinna Vinschen wrote:
Since you had a GTG already, I've uploaded your package and entered
your name in the maintainers column of my secret maintainer file ;-)
So will you _finally_ tell me where the underground lair is, then?
Thanks for your faith on this. This new ctags is needed to
Version 5.6 of Exuberant Ctags has been uploaded.
Exuberant Ctags is a companion to programmers' editors such as vi and
emacs. It extracts tags from source code, which the editor then uses
to locate symbols in the program on demand.
This release is to track a new upstream release. It is
Warren Young wrote:
Version 5.6 of Exuberant Ctags has been uploaded.
Yes, I know I sent this to the wrong list please bear with the
newbie... :)
Corinna Vinschen wrote:
Now that Microsoft has finally dropped support for Windows 98 and Me,
we're going to drop 9x support as well.
http://www.rosemaryclooney.com/LyricPages/dingdongwitchisdead.html
Package files:
http://tangentsoft.net/cygwin/ctags-5.7-1-src.tar.bz2
http://tangentsoft.net/cygwin/ctags-5.7-1.tar.bz2
This just reflects the release of a new upstream version.
Although I've been the ctags maintainer for nearly two years, this is
only my second package submission due to
Jari Aalto wrote:
Web server problem?
No, just a brain fart. I uploaded them to my testing server, and then
didn't push them to the production server. Sorry about that.
Jari Aalto wrote:
Tar builds fine, but few observations:
- move documentation in /usr/share/doc
- /usr/share/doc/Cygwin/ctags-5.7-1.README is missing
The docs were all there, I was just using the pre-LSB directory scheme.
I've rebuilt the packages and re-uploaded them. (Same URLs.) Does
New upstream release; replaces previous.
http://tangentsoft.net/cygwin/ctags-5.7-1-src.tar.bz2
http://tangentsoft.net/cygwin/ctags-5.7-1.tar.bz2
Tughan Hafizoglu wrote:
$ ( echo root ;
sleep 1;
echo password;
sleep 1;
echo df;
sleep 1 ) | telnet 192.168.0.X
Why not use ssh instead? Use keys instead of passwords and you get
automatic logins easily. You can even pass the command to execute on
the
Dave Korn wrote:
+ std::string proxyString(((std::string)ProxyOption).c_str());
I'm not a C++ expert, so maybe I'm missing something, but if I read that
right you're taking ProxyOption (type StringOption), calling the std::string
conversion operator to return a std::string, getting a const
Corinna Vinschen wrote:
/etc/fstab - Yes and get rid of the registry entirely
ACK.
Upgrading pain could be eased if setup.exe (or a postinstall script,
perhaps) detected that /etc/fstab doesn't exist, and created it from the
registry entries.
Max Bowsher wrote:
* doxygen
I'm interested, contingent on seeing what it takes to build it.
* expat
I can do this one, but I'm concerned because expat.sf.net isn't
responding right now. Did expat die again while I wasn't looking?
* sqlite3
I know very little about using SQLite
Yaakov (Cygwin Ports) wrote:
For those that may be interested in adoption, there are updated versions
of some of these now in Ports:
Okay, thanks for the leg up. I'm guessing you'll keep maintaining these
packages? I started my versions from yours, but had to remove several
features
Taking over maintainership of this package from Max Bowsher. Ported
build from g-b-s to cygport and updated from 1.5.1 to 1.5.5, so I'd like
at least one GTG before I post the RFU message.
http://etr-usa.com/cygwin/doxygen/setup.hint
http://etr-usa.com/cygwin/doxygen/doxygen-1.5.5-1.tar.bz2
Taking over maintainership of this package from Max Bowsher. Ported
from g-b-s to cygport and updated from 1.95.8 to 2.0.1, so I'd like at
least one GTG before I post the RFU message.
Also, we need a ruling on what to do with the existing expat 1.x stuff.
It seems there's an ABI difference
Taking over maintainership of this package from Max Bowsher. Ported
build from g-b-s to cygport and updated from 3.5.1 to 3.5.6, so I'd like
at least one GTG before I post the RFU message.
The -2 on the package name is because this is pretty similar to Yaakov's
cygwin-ports version, which is
Brian Dessent wrote:
Otherwise, you potentially violate the GPL licensing requirement to
provide the source as it would disappear from the mirrors entirely as
new 'foo' versions pushed the old one off.
So what I need to do, then, is rebuild the 1.95.8 package so it _only_
builds the DLL
Dave Korn wrote:
requires: cygwin libpng12
The requires: line looks wrong to meWhy libpng?
Ask Max. :) It may have had to do with a historical ability to use
graphviz/dot or something like that. Max's latest doesn't do this, nor
does mine, because I can't get graphviz to build
Yaakov (Cygwin Ports) wrote:
It's been in Ports for over a year...
Yes, but your version builds a whole bunch of bindings and such that you
can't do using only packages in the official Cygwin distro. When I said
I couldn't get graphviz to build, it's because I was still in the
process of
Dr. Volker Zell wrote:
Builds fine from source, but the cygwin specific patch has 0 bytes. So
there is no README and the .hint files are missing
Yeah, I've been meaning to ask about that...
Is there a way I can get Cygport to generate this patch for me? It
seems like it should be able to
Yaakov (Cygwin Ports) wrote:
| Is there a way I can get Cygport to generate this patch for me?
You need to put these files into foo-ver-rel/CYGWIN-PATCHES/.
I actually stumbled across that earlier, but I convinced myself it
couldn't be the right way to do it.
foo-ver-rel doesn't exist
Christopher Faylor wrote:
I'd like to get a list of things to check for.
- Missing README and setup.hint in the -src.tar.bz2. (No cygwin.patch)
Charles Wilson wrote:
How is cygport supposed to
create, ex nihilo, your custom README and custom .hint files,
I don't expect it to. I keep versions of these files in the same
directory as the cygport file. cygport could be told about these files,
and copy them into the proper location
New maintainer, new upstream version, new packaging system. The
problems that came up in the ITA thread of last week have been fixed.
files:
http://etr-usa.com/cygwin/doxygen/setup.hint
http://etr-usa.com/cygwin/doxygen/doxygen-1.5.5-1.tar.bz2
New maintainer, new upstream version, new packaging system. The
problems that came up in the ITA thread of last week have been fixed.
Note that the following set of files includes a legacy libexpat0 package
and a new hint file for the old version of expat. This introduces
libexpat1, which
New maintainer, new upstream version, new packaging system. The
problems that came up in the ITA thread of last week have been fixed.
executables:
http://etr-usa.com/cygwin/sqlite3/setup.hint
http://etr-usa.com/cygwin/sqlite3/sqlite3-3.5.8-1.tar.bz2
shared library:
Dr. Volker Zell wrote:
I would also recommend to build outside of the source tree.
I didn't know it was possible with non-autoconf build systems. Thank
you for cluing me in about:
lndirs
this. :)
-MAN1DIR = man/man1
+MAN1DIR = share/man/man1
Yes, too bad there isn't a
Corinna Vinschen wrote:
What are the names of the subdirs? Which files should be in which dir?
Can you please rearrange this to a working expat directory tree which
can be uploaded with a single wget?
Sorry, I didn't realize you were leaving such decisions up to newbie
maintainers like me.
Dr. Volker Zell wrote:
When building and packaging with your .cygport file I do not get shared
libs.
It may not be possible. It's set to try to build shared libraries, but
you get this during the build:
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin
shared
Corinna Vinschen wrote:
Any problem to prepare a script like Dr. Volker Zell does?
wget -O- http://etr-usa.com/cygwin/expat/slurp.sh |sh
Lapo Luchini wrote:
Dr. Volker Zell wrote:
usr/bin/lemon3.exe
Isn't this the parser-generator needed only for the build itself?
It's possible that some SQLite users have come to rely on it, assuming
it will be available. It's not entirely an internal use only tool; it
has its own web
David Ziants wrote:
Are all the mirrors equal?
They're supposed to be. If you can rediscover the problem mirror, you
should report it here.
A bit of history:
Back in May, Max Bowsher gave up maintainership of a bunch of packages.
I adopted a few of them, and released sqlite3-3.5.8-1. There was some
concern about the fact that my package didn't ship with a DLL version of
the library, only a static library. I got comments from
Christopher Faylor wrote:
Would anyone mind if I changed the format of setup.hint to some
existing markup language?
What problems are you trying to solve?
I am not sure that the setup files require XML though.
I agree.
yaml
This seems closest to the current setup.hint format, and
Christopher Faylor wrote:
What problems are you trying to solve?
The one in the paragraph that you snipped.
I saw that you want a database, but I don't understand why. What does
this give you?
I don't doubt that there's a good answer. It's just that most of us
don't deal with upset, so
Charles Wilson wrote:
setup's understanding about
cygwin mount points, and setup's ability to faithfully recreate windows
ACL's and replace in-use files...)
Wouldn't cygwin1.dll give rpm.exe these abilities?
(2) cygwin rpm
+ much more complicated in-use file handling (because
Warren Young wrote:
Postponing postinstall scripts that depend on scheduled
file installation? Fuggetaboutit.
Can we postpone the script execution, too?
Another possibility occurs: instead of hiding all the MoveFileEx() stuff
inside setup.exe or rpm.exe, can cygwin1.dll be asked to do
Corinna Vinschen wrote:
Well, there's still the 1.5/1.7 entanglement problem, but that's not going
to be fixed, so we can't count that.
What entanglement problem?
This one: http://www.cygwin.com/ml/cygwin/2009-01/msg00648.html
Corinna Vinschen wrote:
What entanglement problem?
This one: http://www.cygwin.com/ml/cygwin/2009-01/msg00648.html
Well, that's not such a big issue, is it? As long as upgrading works
fine...
shrug It may be enough that the problem and the solution is now
documented on the list.
Maybe
Christopher Faylor wrote:
No more RFU email - you get to upload stuff yourself.
Yay!
I hope you have an automated way to manage ssh keys. I find, with
Gna/Savannah, that I have to add or change a key every few months, due
to adding or replacing a build/test machine. I expect this to
Christopher Faylor wrote:
Also, as far as I can tell, there is no remembering of anything going on
now. The buttons are off by default. Is that right or am I missing
something in the complicated setup code?
That's fine if setup.exe only directly creates the cmd.exe based shell
icons. It
Charles Wilson wrote:
I suggest adding a tag to setup.hint whose value is an icon title
#1. WAY too simplistic.
For some cases, sure. It suffices for many others, though, probably
even most others. If you want to add more tags to the design, fine, but
for v1.0, these other options
New upstream release:
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21*' -r \
http://etr-usa.com/cygwin/sqlite3/
This is the first version packaged explicitly for 1.7. Previous 3.6.2
was copied over from 1.5 repo.
New upstream release:
wget -e robots=off --cut-dirs=2 -np -nH -A'*5.8-1*' -r \
http://etr-usa.com/cygwin/ctags/
setup.hint unchanged.
This is the first version packaged explicitly for 1.7. Previous 5.7 was
copied over from 1.5 repo.
New upstream release:
wget -e robots=off --cut-dirs=2 -np -nH -A'*1.6.1-1*' -r \
http://etr-usa.com/cygwin/doxygen/
setup.hint unchanged.
This is the first version packaged explicitly for 1.7. Previous 1.5.5
was copied over from 1.5 repo.
On 12/14/2009 8:57 AM, Corinna Vinschen wrote:
On Dec 11 10:40, Warren Young wrote:
New upstream release:
Your setup.hint file still refers to libreadline6 while the latest
release is libreadline7.
Thanks, it's fixed now:
http://etr-usa.com/cygwin/sqlite3/setup.hint
On 12/15/2009 10:42 AM, David Rothenberger wrote:
Was this intentional?
No.
I don't know why, but my local .cygport file changed between 3.6.2-1 and
3.6.21-1, causing various files to be put into the wrong packages.
You'll also find that *.a went in the lib package, not devel.
I'm
This fixes packaging errors in -1, which should be removed.
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-2*' -r \
http://etr-usa.com/cygwin/sqlite3/
This fixes some packaging errors in -1 and adds manpages to the package.
wget -e robots=off --cut-dirs=2 -np -nH -A'*1.6.1-2*' -r \
http://etr-usa.com/cygwin/doxygen/
Previous -1 should be removed.
This fixes a b0rked source patch -1 and -2, which should be removed.
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \
http://etr-usa.com/cygwin/sqlite3/
Yes, I'm aware that I should be testing these packages better. No need
to tell me I am a doofus. I already know that.
On 12/18/2009 3:23 AM, Corinna Vinschen wrote:
There are also older releases left,
1.5.1-1 and 1.5.5-1. The 1.5.1-1 release is from 2006. Shall we
remove it?
I'm not emotionally attached to those releases, but then, I don't use
doxygen on Cygwin. (I only use one of the packages I
The previous -2 release had a completely wrong source patch relative to
the original sources, which caused it to be all but useless. Thus,
everyone who got the -2 should upgrade.
Sorry wrong list. I'm on a *roll* this week...
On 12/28/2009 1:26 PM, Christopher Faylor wrote:
On Mon, Dec 28, 2009 at 12:16:59PM -0800, Rob Walker wrote:
It's been almost a year and a half since I made a request to have
Cygwin's GNU make updated with the upstream patches for colons in
dependencies and VPATH directives:
Don't we get that
On 6/2/2010 3:01 PM, Christopher Faylor wrote:
It could be that there is an application
used by thousands that works well in the console window while failing
miserably under a tty/pty.
Does mintty currently work around any such problems?
If so, how hard is it to just keep finding them and
On 6/2/2010 7:02 PM, Christopher Faylor wrote:
Does mintty currently work around any such problems?
I really don't understand the question in light of the observations that
there will be problems with some MS-DOS applications if we switch to
mintty because of cygwin's pty implementation.
On 6/3/2010 5:39 AM, Corinna Vinschen wrote:
Does anybody
have a problem with that? If so, would you take over maintainership
for pine?
Aren't all the cool kids using alpine now instead?
On 11/30/2010 12:00 PM, Corinna Vinschen wrote:
On Nov 4 15:07, Yaakov S wrote:
On Sun, 2010-10-03 at 02:04 -0500, Yaakov (Cygwin/X) wrote:
Cygwin's sqlite3 (3.6.21) is ten months old, and some current software
already needs more recent versions. Could you please update sqlite3 to
the latest
On 12/1/2010 6:58 AM, Warren Young wrote:
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.6.21-3*' -r \
http://etr-usa.com/cygwin/sqlite3/
Grr...
wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.3-1*' -r \
http://etr-usa.com/cygwin/sqlite3/
On 3/18/2011 12:06 AM, Christopher Faylor wrote:
On Thu, Mar 17, 2011 at 10:28:49PM -0500, Yaakov (Cygwin/X) wrote:
I wish to propose that Cygwin READMEs no longer be absolutely required
for Cygwin packages, for several reasons:
AFAIK, they never were absolutely required.
One could take
On 7/26/2011 5:01 AM, Corinna Vinschen wrote:
This discussion reminds me of the new icon format in Vista, which
support icons of up to 256x256 bytes in PNG format.
Pixels, not bytes, unless you were thinking about 8 bpp paletted images.
I don't see -- in the almost nonexistent docs -- that
On 7/26/2011 2:17 AM, Corinna Vinschen wrote:
What about modernizing the Cygwin icon?
Check the other options in cygicons-0.dll. The one with the glowy green
wedge is okay.
Or, what about having a mintty
terminal icon with a small C in it? The only problem with this is, I'm
anything but
On 7/26/2011 7:45 AM, Charles Wilson wrote:
Fortunately, fatbuttlarry also provided a linux version (PNG, 237 x 256,
RGBA, 8 bit) that we could use to enhance the existing .ico
http://www.kde-look.org/content/show.php?content=36393
I've updated my
On 7/26/2011 1:36 PM, Andy Koppe wrote:
Regarding Warren's effort, the challenge is that it still needs to
look good at 16x16.
It's rather lazy to simply create the 16x16 by scaling down the 256x256.
It'd be better to take the existing 16x16 and package it with my
256x256, since the current
On 7/27/2011 1:41 AM, Corinna Vinschen wrote:
You say you already have created such icon files before. Would you
have fun to create a new official cygwin.ico?
Here you go:
http://etr-usa.com/cygwin/mintty-icon/combined.ico
That file contains a 256 px 32 bpp (RGBA) Vista (PNG) icon
On 7/27/2011 2:04 PM, Andy Koppe wrote:
- The 16x16 has white dots in the corners.
That was a feature. But you no like it, I make go 'way.
- There are black edges around the icons. Those need to be transparent.
Why?
I purposely redrew the edges in the smaller icons for contrast and
Collecting all Corinna reply answers here:
On 7/28/2011 3:08 AM, Corinna Vinschen wrote:
It seems that black was a bad choice for the Cygwin C.
Is there a reason we cannot change it now? I don't see that Red Hat has
filed a US trademark on the logo. Even if they had, it's usually better
On 7/29/2011 9:21 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Warren Young sent the following at Friday, July 29, 2011 10:12 AM
http://etr-usa.com/cygwin/logo/glowing.ico
http://etr-usa.com/cygwin/logo/logo-glowing.ico
I've fixed it so the original URL is correct. (None
Couldn't resist doing another. I call this one The Matrix:
http://etr-usa.com/cygwin/logo/matrix.ico
On 8/3/2011 2:37 PM, Andy Koppe wrote:
- The 256x256 version still has Warren's dark border around the
terminal. Not only is this spoiling the KDE Oxygen team's work,
There's a 50% transparent black (so, gray when composited over white)
border in the original KDE artwork. Are you saying you
On 8/3/2011 11:49 PM, Andy Koppe wrote:
Warren's has the advantage of a 256 version and that it's more
tweakable assuming he provides the vector version it's presumably
based on.
Sorry, there is currently no vector version. Effects like bevels and
shadows are raster effects. However, based
1 - 100 of 245 matches
Mail list logo
