2. Re: Lin32Lib?
On Sat, 21 Apr 2001, jbrown105 at HotPOP.com wrote:
> Anybody know of a clone of Win32Lib for Linux? I'm trying to write one that
> uses GraphApp, but the code is so premature that it isn't even worth showing.
> The other alternative I know of is Llama/GTK, but it's too broken to be of
> much use. If you know of any alternatives, please don't hesitate to post a
> reply. (Please do hesitate to email a reply 
Just Kidding).
> TIA,
> jbrown
Unfortunately, there isn't one.
Programming directly to xWindow using Xlib is out of the question:
two or three pages of code just to get a window open.
GraphApp, as you've seen, is limited by the underlying Athena or Motif widget
set, both of which are pretty primitive.
Most of the good packages, like QT, are written in C++, which makes interfacing
with them very difficult.
That leaves GTK, which is written in C, and is fairly high level with a
reasonable set of widgets. Unfortunately, no one has wrapped it for
Euphoria. Dave Cuny made a try, but if he was unsuccessful, there's
no point in me even trying. ;)
I think the only choices are to learn C++, or come up with a thousand bucks
to buy Kylix. :(
Regards,
Irv
4. Re: Lin32Lib?
Kylix is Delphi for Linux.
Delphi is a RAD Tool (descended from Turbo Pascal) from Borland/Inprise
(anyone know which they call themselves these days?).
It a product I've lusted after myself for the last few months.
>From: jbrown105 at HotPOP.com
>Reply-To: EUforum at topica.com
>To: EUforum <EUforum at topica.com>
>Subject: Re: Lin32Lib?
>Date: Sat, 21 Apr 2001 16:24:27 -0500
>
>
>
>Hmm. Well. Maybe there is a way. Someone (clearly not me) should write a
>shared library for the widget libraries (such as QT) and then write a
>wrapper
>for Euphoria on top of that! It could work, except we'd need A C++
>programmer
>who knows QT as well as Euphoria. Then it might work. Maybe.
>
>P.S. I'm trying to wrap EasyGTK right now. However, it still requires a
>wrapping for GTK, so I'll have to keep tinkering w/ my easygtk library to
>add
>that stuff in.
>
>P.P.S. Wrapping GTK for Euphoria would work if it supported structures.
>
>P.P.P.S. What's Kylix?
>
>On Saturday 21 April 2001 2:10pm, Irv wrote:
> >
> > On Sat, 21 Apr 2001, jbrown105 at HotPOP.com wrote:
> > > Anybody know of a clone of Win32Lib for Linux? I'm trying to write one
> > > that uses GraphApp, but the code is so premature that it isn't even
>worth
> > > showing. The other alternative I know of is Llama/GTK, but it's too
> > > broken to be of much use. If you know of any alternatives, please
>don't
> > > hesitate to post a reply. (Please do hesitate to email a reply
>Just
> > > Kidding).
> > > TIA,
> > > jbrown
> >
> > Unfortunately, there isn't one.
> >
> > Programming directly to xWindow using Xlib is out of the question:
> > two or three pages of code just to get a window open.
> >
> > GraphApp, as you've seen, is limited by the underlying Athena or Motif
> > widget set, both of which are pretty primitive.
> >
> > Most of the good packages, like QT, are written in C++, which makes
> > interfacing with them very difficult.
> >
> > That leaves GTK, which is written in C, and is fairly high level with a
<snip>
>
>
>
5. Re: Lin32Lib?
You could use my Graphics Engine for Linux which can be used
with Jirri's widgets or you could use it to rewrite david's DOS windows
library to use my Graphics library. The reason I wrote this library was
to give a user the same graphics features and functions that are
supported in DOS Euphoria but ARE NOT SUPPORTED by LINUX Euphoria.
Bernie
6. Re: Lin32Lib?
Irv Mullins wrote:
> That leaves GTK, which is written in C, and
> is fairly high level with a reasonable set of
> widgets. Unfortunately, no one has wrapped it
> for Euphoria. Dave Cuny made a try, but if he
> was unsuccessful, there's no point in me even
> trying. ;)
Actually, the reason I dropped it had little to do with being able to wrap
GTK. It was more that I ran into conceptual difficulties with resolving
paint issues between Win32Lib and GTK. I'll give more details on that if
people are interested. The gist is that Windows lets you draw anywhere on
the window that you want, while GTK doesn't - you are only really allowed to
draw on canvas objects, or you end up resorting to writing directly in XLib.
I ended up trying to develop a module for SWIG to help wrap stuff like GTK
and wxWindows, but I was having major problems with BCC of my machine. I
eventually took a break from the whole thing and started working on another
project, and never got back to wrapping GTK.
If anyone is interested, I still have the tools I used to parse the files in
order to generate the files. They work OK, but require a *lot* of hand
editing of the results. I think that if went the other way around and
scrubbed the GTK include files so the parser didn't have to contend with
every obscure bit of C syntax known to man, you'd be much more successful.
Be warned that there are a *lot* of GTK include files - the more people you
have helping you on the task, the better!
In addition, if instead of directly converting the wrappers from C to
Euphoria, you generated a C file that in turn generated the Euphoria
wrappers, you'd have a much easier time building the zillions of constants
that you would need. In fact, the best approach would probably be just that:
write one program to wrap the functions, and another to generate constants
and structures.
At the time that I had written my wrappers, you still had to resort to
working with structures quite a lot - for example, just to set colors.
Hopefully, there are a lot more helper functions available that make this
unnecessary.
GTK is a great toolkit, and (as mentioned), one of the few that is written
in C. It is possible to wrap C++ libraries (such as wxWindows), but there's
a bit more hassle involved.
I've also looked at EzGTK, and it's pretty neat as well. But if you are
trying for a Win32Lib approach to things, you'll probably want to use a
bulletin-board sort of widget manager instead of the defaults provided but
EzGTK.
While GTKLib is a great idea, I don't think that it will ever be more than
50% compatible with Win32Lib. There's just too much Win32 specific stuff in
Win32Lib for that to happen. Still, I think that the general Win32Lib
framework (since it's based on VB) is fairly platform independant, and would
serve you well.
I'll be glad to answer any more questions!
-- David Cuny
10. Re: Lin32Lib?
Howdy!
As I've stated in an earlier post, my biggest problem with going the GTK route
at
the moment is due to the fact that, after repeated tricks and/or tweaking, I've
yet to get Euphoria to link up to the GTK .so file using open_dll(). So,
Bernie's idea is gaining popularity in my mind ... I've downloaded eu_engin and
I'll be taking a look at it.
Concerning Jiri's widgets, is he still supporting the project? I've written to
him and asked, but I haven't gotten a reply (he's no doubt taking full advantage
of retirement and autumn down there in the south 40. Back six months or so
ago, he had a small disaster in which what was his most recent version of the
widgets were accidentally deleted. Since then, I haven't heard anything about
them.
Jiri? Mr. Craig, any thoughts on the open_dll() dilemma?
-- Travis --
11. Re: Lin32Lib?
----- Original Message -----
From: <jbrown105 at HotPOP.com>
Subject: Re: Lin32Lib?
>
>
> David wrote:
> > Actually, the reason I dropped it had little to do with being able to
wrap
> > GTK. It was more that I ran into conceptual difficulties with resolving
> > paint issues between Win32Lib and GTK. I'll give more details on that if
> > people are interested. The gist is that Windows lets you draw anywhere
on
> > the window that you want, while GTK doesn't - you are only really
allowed
> > to draw on canvas objects, or you end up resorting to writing directly
in
> > XLib.
>
> So? Why not have Win32Lib fake a canvas?
>
> > While GTKLib is a great idea, I don't think that it will ever be more
than
> > 50% compatible with Win32Lib. There's just too much Win32 specific stuff
in
> > Win32Lib for that to happen. Still, I think that the general Win32Lib
> > framework (since it's based on VB) is fairly platform independant, and
> > would serve you well.
>
> I though that's why you were working on Llama, which wouldn't have all
that
> extra Win32 specific stuff, but still support the general Win32Lib
framework.
>
> P.S. When I tried to work on Llama/GTK, most of my changes were
ineffective.
> For example, I couldn't figure out how to pass a char array to gtk_init,
or
> why gtk_entry_set_text keeped saying it's parameter wasn't a GTK_ENTRY
type.
> Is this because of Euphoria's inability to use structures and such, GTK's
> assumtion of interfacing with C code (I assume), or because of an
improperly
> wrapped GTK?
>
> TIA,
> jbrown
>
>
>
>
>
12. Re: Lin32Lib?
jbrown wrote:
> So? Why not have Win32Lib fake a canvas?
And break all those existing programs? It seemed better to start from
scratch with a new library. But writing a multi-platform library is a
never-ending process, and I ultimately decided that finding a pre-existing
cross-platform library (wxWindows) was a better plan. But that's another
long story...
There's another twist to the story: almost all the GTK development was done
in Windows. Someone did a port of the Gimp to Windows, and you can use the
DLLs to write GTK apps. For me, it was a lot easier than working in Linux,
since I'm more familiar with the DOS prompt than the Linux command line.
But this caused me a bit of grief. I had written a Euphoria program to read
the GTK include files, and generate wrappers for the structures. But
apparently because of alignment issues, the position of structure fields is
different under Windows than it is in Linux. That meant that some of the
code would fail - seemingly randomly - under Linux.
> I though that's why you were working on Llama,
> which wouldn't have all that extra Win32 specific
> stuff, but still support the general Win32Lib
> framework.
Yeah, that was the plan. I didn't take into account how much of a pain it
would be to do. Ultimately, I decided it wasn't really the optimal way to
go.
> P.S. When I tried to work on Llama/GTK, most of
> my changes were ineffective.
Odd.
> For example, I couldn't figure out how to pass
> a char array to gtk_init, or why gtk_entry_set_text
> keeped saying it's parameter wasn't a GTK_ENTRY type.
Well, GTK has it's own type system built in.
> Is this because of Euphoria's inability to
> use structures and such,
No, there are lots of programs (like Win32Lib) that interface C strutures.
> GTK's assumtion of interfacing with C code
No, also not an issue. There are lots of counterexamples to that, too.
> or because of an improperly wrapped GTK?
Most likely.
-- David Cuny
13. Re: Lin32Lib?
- Posted by jbrown105 at HotPOP.com
Apr 23, 2001
I'm not very good at C++ programming, so I'm not sure if I can do that,
although I'll probally try. Anyone else will to give it a go as well?
On Mon, Apr 23, 2001 at 08:39:52AM -0700, Matthew Lewis wrote:
>
>
>
>
> > -----Original Message-----
> > From: Irv Mullins [mailto:irvm at ellijay.com]
>
> > Most of the good packages, like QT, are written in C++, which
> > makes interfacing
> > with them very difficult.
>
> Actually, I don't think that it would be as difficult as you might think
> (not that it'll be simple). Working with COM has given me a new insight on
> interfacing with C++, since that's effectively what happens with COM. Also,
> in working with COM, I think I might have solved some other problems that
> might get in your way.
>
> Here's what I think you'll need to do:
> - Get a hold of the constructor for an object. It should return a pointer
> to the object.
> - Wrap the member functions just like you would with C.
> - Pass the pointer to the object as the first argument in any function call
> (C++ does this implicitly).
>
> I suspect that the functions will have to be loaded by ordinal (C++ name
> decoration isn't much to look at), so you'll probably need to get your hands
> on a lib file or some other kind of documentation on the lib. This could be
> the most difficult part, except that I guess since this is linux, you ought
> to be able to get a look at the full source, right?
>
> And then you'll probably need to load the .so's manually (since
> open_dll/define_c_func don't seem to work by ordinal). So you'll probably
> have to call them by pointer (no problem, since fptr.e in EuCOM should work
> in linux :).
>
> Matt Lewis
>
>
>
--
Linux User:190064
Linux Machine:84163
http://jbrown105.1avenue.com
