[prev in list] [next in list] [prev in thread] [next in thread]
List: kde
Subject: Re: Language Bindings
From: "Joshua J. Berry" <jberry () mvhs ! net>
Date: 2000-08-26 4:47:04
[Download RAW message or body]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html><head></head><body>I
had a thought along the lines of this discussion that I'd like to bring
up to the KDE community in general...hopefully to prevent this kind of thing
from occurring in the first place.<br>
<br>
Why not write a Universal Toolkit that can draw widgets using both Qt and
Gtk, as appropriate? Programs written using this library wouldn't have to
know or care which desktop environment they were running under; they would
issue a command to, say, add a button to a window, and the Toolkit would
translate this command into the equivalent Qt or Gtk calls. That way, instead
of developers having to write _two_ instant messaging clients, _two_ MP3
players, etc. they would just write one that could use both DE's without
having to know the difference. Programs could easily switch back and forth
with no recompilation or anything like that.<br>
<br>
I've already played around with this concept a little bit in Perl (<a class="txt-link \
txt-link-freetext" href="http://sourceforge.net/projects/utk/">http://sourceforge.net/projects/utk/</a>),
and it seems to work pretty well (even the HTML part). It would also simplify
writing bindings for other languages...just write the library in C++ and
use XS, SWIG or whatever else to translate to Python, Perl, Tcl (or maybe
[incr Tcl]), etc.<br>
<br>
Any thoughts? Does this seem like a viable option, if not in this particular
case, then at least for the future? I'm more than willing to take it on
(though I'll need some help with the Qt side of things, and maybe with the
language bindings), but I thought I should first see how my idea would be
received.<br>
<br>
-- Josh<br>
<br>
Timothy R. Butler wrote:<br>
<blockquote type="cite" cite="mid:000001c00f02$156a1980$0101a8c0@g4958">
<div class="text-plain"><pre wrap>Thanks Andreas,
Perhaps that is not a good first endeavor in the C++ and C worlds, eh? While I
know Perl (the language I know the best) and C/C++ have some commands in common,
it's probably not enough to attempt to port a whole GUI from C and GTK to C++ and
QT.
Perhaps someday though...
-Tim
-----------------------------------------------------------------
Timothy R. Butler Universal Networks
Information Tech. Consultant Christian Web Services Since 1996
ICQ #12495932 AIM: Uninettm An Authorized IPSwitch Reseller
<a class="txt-link txt-link-abbreviated" \
href="mailto:tbutler@uninetsolutions.com">tbutler@uninetsolutions.com</a> <a \
class="txt-link txt-link-freetext" \
href="http://www.uninetsolutions.com">http://www.uninetsolutions.com</a> \
===================== "Solutions that Work" =====================
> -----Original Message-----
> From: <a class="txt-link txt-link-abbreviated" \
href="mailto:kde-request@lists.netcentral.net">kde-request@lists.netcentral.net</a> \
> [<a class="txt-link txt-link-freetext" \
href="mailto:kde-request@lists.netcentral.net">mailto:kde-request@lists.netcentral.net</a>]On \
Behalf Of Andreas Pour > Sent: Friday, August 25, 2000 8:22 PM
> To: KDE general mailing list
> Subject: Re: Language Bindings
>
>
> "Timothy R. Butler" wrote:
> >
> > > That depends on how "organized" the program was written. If the \
program > > > logic (in your case the communication stuff) is separated \
nicely from > > > the GUI code, then it doesn't matter whether or not you \
use C or C++ in > > > the port (well, it doesn't matter anyway, more or \
less). > >
> > So, for that to work, the communications components would have to be
> > command-line based, and the GUI separate - correct?
>
> Not necessarily -- although that does provide a clean separation. If it
> were written in C++, you would want a "Yahoo Chat" and "IM" class that
> handle all the communication stuff and don't handle any GUI stuff. Then
> you could use these classes and wrap any GUI around them. In the C
> world, you'd want all the code for the communication stuff to be in
> separate code and header files w/out any GUI-specific code intermixed.
> Basically a separation between the GUI and the rest of the program --
> modular code design.
>
> Extra work to make it work that way, though, so it's often not done.
>
> Ciao,
>
> Andreas
> -- Send posts to: <a class="txt-link txt-link-abbreviated" \
href="mailto:kde@lists.netcentral.net">kde@lists.netcentral.net</a> Send all \
commands to: > <a class="txt-link txt-link-abbreviated" \
href="mailto:kde-request@lists.netcentral.net">kde-request@lists.netcentral.net</a> \
Put your command in the SUBJECT of > the message: "subscribe", "unsubscribe", \
"set digest on", or "set > digest off" PLEASE READ THE ARCHIVED MESSAGES AT <a \
class="txt-link txt-link-freetext" \
href="http://lists.kde.org/">http://lists.kde.org/</a> > BEFORE POSTING
> **********************************************************************
> This list is from your pals at NetCentral <a class="txt-link txt-link-rfc2396E" \
href="http://www.netcentral.net/"><http://www.netcentral.net/></a> >
</pre></div>
</blockquote>
<br>
<br>
<div class="signature">-- <br>
<br>
<hr align="Left" color="#808080" noshade size="2" width="50%">
Joshua J. Berry<br>Monte Vista High School<br>Venture High School<br><br>Network
and Systems Administrator<br><br><a href="http://www.mvhs.net/~jberry/" \
target="_blank">http://www.mvhs.net/~jberry/</a><br><a href="mailto:jberry@mvhs.net" \
target="_blank">jberry@mvhs.net</a> <p><small>This E-Mail "signature block" does \
not constitute a legally-binding signature.</small></p></div>
</body>
</html>
--
Send posts to: kde@lists.netcentral.net
Send all commands to: kde-request@lists.netcentral.net
Put your command in the SUBJECT of the message:
"subscribe", "unsubscribe", "set digest on", or "set digest off"
PLEASE READ THE ARCHIVED MESSAGES AT http://lists.kde.org/ BEFORE POSTING
**********************************************************************
This list is from your pals at NetCentral <http://www.netcentral.net/>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic