"Chris" <chris@widdows.demon.nl> wrote in message news:pk73vtojpt6sqsjfuogv8hp75nku1g4lrk@4ax.com...
> On Sat, 10 Nov 2001 12:32:45 +0000 (UTC), Laurentiu Pancescu
>
> <snip>
> >
> >WxWindows is too big and bulky, IMHO.  Another cross platform toolkit
that I
> >like is FLTK (www.fltk.org).  I've been using it on GNU/Linux, mainly...
> >
>
> I don't know fltk (except coming across it once or twice), but WxWindows was churning out multi meg apps with ease, so that turned me right off. Zinc for the desktop is free now, when I last looked at that it seemed pretty good. Anyway, I think it would be nice to a cross-platform option alongside the current Win/MFC stuff (which I want also).

FLTK is very good, I developped several apps with it, it's very fast and small.  And good looking, at least for someone used to SGI X apps (it emulates XForms).

About Zinc: I tend to be a little careful (to be read: -fpedantic) when saying something is "free".  Zinc is free like in "zero-price", but not like in "freedom".  I cannot use it for embedded software, for instance.  Since I develop proprietary sofware for a living (embedded software, to be exact), writing free software (free like in GPL) in my spare time became important. So, if I'd develop something that I might expect to run one day on some embedded system, I thik I'd use NanoGui, or MicroWindows (at least one of them is LGPL, but I forgot which :).

Oops, I guess we're far from topic of this newsgroup... I hope Jan won't ban me!  :)

> >I'll finish the port, and then try to convince Walter to put some
INCOMING
> >dir on the ftp.digitalmars.com, or some contrib section on DigitalMars. Perhaps I'm not the only one wishing to contribute code... ;)
> >
>
> I'm all for it, heck I might even have time to add to the effort to ;-) I had a go at imagemagick, but ran into all sorts of problems. The Watcom compiler did manage to get more going, but ended up just getting a little Win only shareware lib. Pity, imagemagick looks pretty good. Perhaps I should have another go, and keep posting the problems. One thing that made things a little difficult was that some libs took the __SC__ define as meaning Mac code, which didn't help. And the OLE/template stuff went haywire. DM++ has come quite far since then, so perhaps I should give it another go.

Unfortunately, I'm very caught with my "money-earning" work now (release season, apparently), and I will only have time for this during weekends, and not even that fully. :(

Is ImageMagick that you talk about the same lib I know from GNU/Linux?  Were you using it for GUI elements, or image processing?  I never used it... yep, "non-free" stuff again!  :)

> >> You're right, cannot find something similar to /include used in MSVC linker would do it.
> >
> >I think it's a rather minor inconvenient.  BTW, vdraw, one of the demo
apps,
> >has only 158k, statically linked with DMC port of V.  Not bad at all! :)
> >
>
> No, very nice, and that would compile/run wo alteration on Linux?

AFAIK, yes... I only got V GUI and VIDE as tar-gz sources, and compiled them on both Win32 and GNU/Linux.  My Debian GNU/Linux came with V GUI 1.22, but I considered that to be too old...  :)


Laurentiu

> Oops, I guess we're far from topic of this newsgroup... I hope Jan won't ban me!  :)

Nag!

Jan

On Thu, 15 Nov 2001 00:41:09 +0100, "Laurentiu Pancescu" <lpancescu@fastmail.fm> wrote:

<snip>
>Unfortunately, I'm very caught with my "money-earning" work now (release season, apparently), and I will only have time for this during weekends, and not even that fully. :(
>
>Is ImageMagick that you talk about the same lib I know from GNU/Linux?  Were you using it for GUI elements, or image processing?  I never used it... yep, "non-free" stuff again!  :)
>
It is the same, so it would go nicely with V, mainly for image processing. AFAIK it is free in the sense that you get the source and can do with it what you want. It doesn't cost any money either, at least that is how I read the license. It is a massive library, but does a lot you wouldn't find even the expensive 'market leaders'. Pity that I couldn't get it compile with DM++, once I got the stuff through the compiler (by leaving modules out) it started to bark when linking the demo apps. I listed the dll's and sure enough, the symbols were right there. After that I stopped trying.

<snip>
> No, very nice, and that would compile/run wo alteration on Linux?
>
>AFAIK, yes... I only got V GUI and VIDE as tar-gz sources, and compiled them on both Win32 and GNU/Linux.  My Debian GNU/Linux came with V GUI 1.22, but I considered that to be too old...  :)
>
>
>Laurentiu
>
So V seems pretty good, and whilst VIDE is probably very good, DM's is IMO better (if only for the reason it can do Brief keymappings better than most ;-)

Chris

"Chris" <chris@widdows.demon.nl> wrote in message
> Pity that I couldn't get it compile
> with DM++, once I got the stuff through the compiler (by leaving modules
> out) it started to bark when linking the demo apps. I listed the dll's and
> sure enough, the symbols were right there. After that I stopped trying.

Can you reduce it down to a small bug report?

"Chris" <chris@widdows.demon.nl> wrote in message news:v8h8vtsqm18577lbobf2t7t77ghe0u3vp3@4ax.com...
> So V seems pretty good, and whilst VIDE is probably very good, DM's is IMO better (if only for the reason it can do Brief keymappings better than
most
> ;-)

DM's IDDE is really good, actually is by far the best I've seen on Win32. Compared to that, VIDE is rather primitive, but it has something that IDDE lacks: integrated support for generating VGUI apps, and support for different environments (BCC 5.5.1, Sun's JDK, gcc flavors).  It's even more important on GNU/Linux, where you don't find that many IDEs with low resource consumption.

About Brief... well, I'm using GNU Emacs on both Win32 and GNU/Linux!  :)


Laurentiu

Laurentiu Pancescu wrote:

> DM's IDDE is really good, actually is by far the best I've seen on Win32.
>


<dreaming>
DM's IDDE and compiler runnig native on the FreeBSD LINUX OSX.....
</dreaming>

Arjan

On Thu, 15 Nov 2001 16:41:07 -0800, "Walter" <walter@digitalmars.com> wrote:

>
>"Chris" <chris@widdows.demon.nl> wrote in message
>> Pity that I couldn't get it compile
>> with DM++, once I got the stuff through the compiler (by leaving modules
>> out) it started to bark when linking the demo apps. I listed the dll's and
>> sure enough, the symbols were right there. After that I stopped trying.
>
>Can you reduce it down to a small bug report?
>
>

Walter,

sorry, ImageMagick  is massive, and of course it only surfaced when I reached the final stage, the demo app. I started out by using the MSVC dsw file as a reference and using the IDDE, built the project, compiling each subproject (quite a few of them). Had trouble with both the static lib version and the DLL version (which I was aiming for), but more so with the DLL. Noticed some took __SC__ as meaning macintosh, which didn't help. Also, there was one lib that used OLE quite a lot, which the compiler didn't like at all (from memory, FHQ or FQX? subproject). From what I gathered at the time, something was going wrong with calling convention decoration of the symbols, when compiling for export it was producing something else than when producing the symbol to link with.

Anyway, it wasn't clear to me if DM was to blame, or that the code was being led into the wrong direction by all those cross-platform defines. But the sheer size was enough for me to stop trying, I bought a shareware lib for $30 which saved me hours of work and worked fine. But, it would be nice if some of these cross-platform tools would work easily for DM. But it is a major effort keeping up with the developments of these tools, so probably the only 'easy' way would be to have a MS VC switch, so the compiler and linker would react to the source as the stuff from MS, or get the maintainer to support and validate the tool for DM.

If I have the time I could start rebuilding the port, and once it starts producing errors, send you the whole project, but that will not be small be any means.

Your thoughts.....

Chris

Since DM can compile MFC and still be binary compatible with MSVC, it is pretty compatible. Of course, there always will be differences. I'll be happy to address them in small bug reports, but debugging a massive app is more than I'm willing to do at the moment :-(

"Chris" <chris@widdows.demon.nl> wrote in message news:ovscvtcvqcrljim56u87bh379hgomg0osv@4ax.com...
> On Thu, 15 Nov 2001 16:41:07 -0800, "Walter" <walter@digitalmars.com> wrote:
>
> >
> >"Chris" <chris@widdows.demon.nl> wrote in message
> >> Pity that I couldn't get it compile
> >> with DM++, once I got the stuff through the compiler (by leaving
modules
> >> out) it started to bark when linking the demo apps. I listed the dll's
and
> >> sure enough, the symbols were right there. After that I stopped trying.
> >
> >Can you reduce it down to a small bug report?
> >
> >
>
> Walter,
>
> sorry, ImageMagick  is massive, and of course it only surfaced when I reached the final stage, the demo app. I started out by using the MSVC dsw file as a reference and using the IDDE, built the project, compiling each subproject (quite a few of them). Had trouble with both the static lib version and the DLL version (which I was aiming for), but more so with the DLL. Noticed some took __SC__ as meaning macintosh, which didn't help. Also, there was one lib that used OLE quite a lot, which the compiler didn't like at all (from memory, FHQ or FQX? subproject). From what I gathered at the time, something was going wrong with calling convention decoration of the symbols, when compiling for export it was producing something else than when producing the symbol to link with.
>
> Anyway, it wasn't clear to me if DM was to blame, or that the code was being led into the wrong direction by all those cross-platform defines.
But
> the sheer size was enough for me to stop trying, I bought a shareware lib for $30 which saved me hours of work and worked fine. But, it would be
nice
> if some of these cross-platform tools would work easily for DM. But it is
a
> major effort keeping up with the developments of these tools, so probably the only 'easy' way would be to have a MS VC switch, so the compiler and linker would react to the source as the stuff from MS, or get the maintainer to support and validate the tool for DM.
>
> If I have the time I could start rebuilding the port, and once it starts producing errors, send you the whole project, but that will not be small
be
> any means.
>
> Your thoughts.....
>
> Chris