|
About:
GObject Builder (GOB) is a simple preprocessor for
easily creating GObjects (glib objects). It reads
a class description file with inline C code and
produces .c and .h object files for you. It allows
you to easily use most of the features of the
GObject system and avoids typos by reducing the
amount of code needed. In general, the amount of
code is about the same as for OO languages such as
Java or C++, but you still have to only use C and
you get all the power of the GObject system.
Release focus: Minor bugfixes
Author:
Jiri (George) Lebl [contact developer]
Homepage:
http://www.5z.com/jirka/gob.html
Tar/GZ:
ftp://ftp.5z.com/pub/gob/
Changelog:
http://www.5z.com/jirka/gob2.NEWS
RPM package:
ftp://ftp.5z.com/pub/gob/RPM/
Debian package:
ftp://ftp.5z.com/pub/gob/DEB/
Mailing list archive:
http://www.jirka.org/gob-list/archive/
Trove categories:
[change]
Dependencies:
[change]
No dependencies filed
|
|
» Rating:
8.35/10.00
(Rank N/A)
» Vitality: 0.05% (Rank 1414)
» Popularity: 1.18% (Rank 4934)
 
(click to enlarge graphs)
Record hits: 17,618
URL hits: 6,319
Subscribers: 21
|
|
Projects depending on this project:
DWI
|
|
Branches
Releases
|
Version
|
Focus
|
Date
|
|
2.0.15
|
Minor bugfixes |
21-Nov-2007 07:53 |
|
2.0.14
|
Major bugfixes |
05-Jan-2006 18:36 |
|
2.0.13
|
Minor feature enhancements |
16-Dec-2005 22:04 |
|
2.0.12
|
Minor feature enhancements |
23-Jul-2005 06:46 |
|
2.0.10
|
Minor feature enhancements |
23-Sep-2004 04:21 |
|
2.0.9
|
Minor bugfixes |
19-Jul-2004 20:04 |
|
2.0.8
|
Minor bugfixes |
12-Jun-2004 01:41 |
|
2.0.7
|
Minor bugfixes |
31-Mar-2004 18:21 |
|
2.0.6
|
Minor bugfixes |
20-May-2003 18:14 |
|
2.0.5
|
Major bugfixes |
16-Jan-2003 21:56 |
Comments
[»]
Convenient tool, but still only GTK+ expert could use it
by Changwoo Ryu - Nov 26th 1999 02:22:18
In GTK+ widget writing, the most painful things I think are its
method/signal/argument definitions. At least 200-300 lines are
required to make a full featured GTK+ widgets. GOB makes it
easier. Good.
But you should already have experience writing GTK+ widgets
in plain C. Otherwise, you could not understand the errors from
the generated C codes by your C compiler.
And if the widget code is longer than (IMHO) 700-800 lines,
GOB does little help. In this case, its GTK+ OO overhead is
relatively small. And it might be better to write just in C, since
you can confused by GOB syntax while writing the big amount
of code in one .gob file
[reply]
[top]
[»]
C++ vs. GTK+ object system
by Jiri (George) Lebl - Aug 18th 1999 19:30:43
Please do compare the C++ and GTK+ object system before posting something
like this. I think you'll find GTK+ object strikingly MUCH more flexible.
[reply]
[top]
[»]
Re: C vs. GTK object system
by Murray Cumming - Feb 26th 2001 11:49:35
> Please do compare the C and GTK
> object system before posting something
> like this. I think you'll find GTK
> object strikingly MUCH more flexible.
I'd be interested to know how you think that the C GTK object system is
more flexible rather than just more long-winded.
[reply]
[top]
[»]
Re: C vs. GTK object system
by Jiri (George) Lebl - Apr 12th 2001 14:16:13
>
> I'd be interested to know how you
> think that the C GTK object system is
> more flexible rather than just more
> long-winded.
>
>
It depends on your priorities for coding. C++ is
quite a different beast. You can get things like
signals for C++ with addon libraries, and you can
get a type system for C++ with addon libraries.
You can get named arguments as an addon too. But
then it's not much different then coding with
GTK+. The GTK+ (and GObject nowdays) comes with
all these and the unerlying language is much
simpler to understand. With GTK+ objects the
emphasis isn't given on subclassing and making
everything as an object. You still do mostly C
coding. If a project for example uses GOB, it
only uses GOB for those few classes it has. It
does not emphasize subclassing for things it's not
needed for. As owen once put it, it is more a
component system then an object system
I wonder why everybody mentions C++ as "the OO
language". If I was to mention a language that
GTK+/GOB would be closer to, it would be java or
Objective C. At some point in the future I plan
to use Java, when that gets more mature. Java is
very nice as a language, but I'm not too crazy
about it's libraries and compiler support.
[reply]
[top]
[»]
Re: C vs. GTK object system
by Murray Cumming - Apr 12th 2001 17:48:54
> You can get
> things like
> signals for C++ with addon libraries,
> and you can
> get a type system for C++ with addon
> libraries.
> You can get named arguments as an
> addon too.
Yes, you can get them all from the same 'add-on library'. That's a
language binding.
> But
> then it's not much different then
> coding with
> GTK+.
It's not too different. That's good. But it gives you less code,
clearer code, and compile-time type-safety. That's good too.
> If a project for example uses
> GOB, it
> only uses GOB for those few classes it
> has. It
> does not emphasize subclassing for
> things it's not
> needed for.
I don't think it's an advantage that GTK+ in C makes subclassing
difficult. Gtk-- in no way forces you to subclass, or emphasises that
technique. That's just something that's available to you, whereas the
difficulty of doing it in C means that people don't choose that design
technique when they should. And code becomes less clear.
I guess GOB is meant to fix this. It's just that C++ seems like a nicer
way to do that.
[reply]
[top]
[»]
Re: C vs. GTK object system
by Jiri (George) Lebl - Apr 12th 2001 23:33:45
>
> It's not too different. That's good.
> But it gives you less code, clearer
> code, and compile-time type-safety.
> That's good too.
>
GOB gives you quite a bit of compile time type
safety as well. Though with a focus that this
will all work from C code (that is not all your
code has to be in GOB, and in fact shouldn't).
Though compile time typesafety is many times
overrated. I'm more of a fan of runtime
typesafety, since it will catch all type errors,
though with the caveat that the code must run for
you to find errors. That said a certain amount of
static typesafety always helps.
>
> I don't think it's an advantage that
> GTK+ in C makes subclassing difficult.
> Gtk-- in no way forces you to subclass,
> or emphasises that technique. That's
> just something that's available to you,
> whereas the difficulty of doing it in C
> means that people don't choose that
> design technique when they should. And
> code becomes less clear.
> I guess GOB is meant to fix this. It's
> just that C++ seems like a nicer way to
> do that.
>
I didn't mean that this is because GTK+ makes it
hard to subclass. Just that the focus is
different. Yes everything that GTK+ object system
does is possible in C++, and the other way around
as well (though if you wish to do some things in C
you get into some deep voodoo land).
I'm still way more profficent in C, and don't
enjoy C++ very much. You can usually stare at a
piece of code in C and figure out what it does
exactly. With C++ there could be many things
going on behind the scenes that you would have to
look up in the class definition. Example, in C no
code is run until you explicitly call a function.
In C++ things like constructors, destructors and
various overloaded functions get run even when the
syntax doesn't say something would run.
And this is where the original C++ (or cfront)
differ substantially from GOB. all GOB does is
write the boilerplate for you. It does not
attempt to parse or change C code. It does not
understand C almost at all (all it can do is count
parenthesis and braces).
I have made an object system that is statically
typesafe and easy to derive purely using the C
preprocessor. However GTK+ doesn't do this. I'm
very pragmatic on this point. I want to use C. I
like GTK+. Thus GOB. GOB doesn't have the things
that I don't like about C++, and it has an easy
syntax for making objects, while allowing me to
still just use C. I'd be happier if GTK+ object
model didn't require so much boilerplate and was
more c preprocessor friendly, but it isn't. GOB
isn't written for the purpose of writing GOB, it
is something to scratch an itch.
[reply]
[top]
[»]
Back to the past
by Frederik Bilhaut - Jul 13th 1999 05:40:09
I'd just like to advice C users that there now exists a nice language
called C++ that is really object oriented, and has all the power of C. At
the beginning, it needed various sorts of preprocessors to be translated it
to C, and then to be compiled. But now it is a real language, compiled as
is. No need of curious things to make classes!
Check it out ;-)
[reply]
[top]
[»]
Re: Back to the past
by Murray Cumming - Feb 26th 2001 11:54:23
Quite right. I don't see how this can be said to require only C. That 's
like QT saying that moc requires only C . If you want a better C, then
it's already been done.
[reply]
[top]
[»]
Re: Back to the past
by Murray Cumming - Feb 26th 2001 11:56:36
I meant 'saying that moc requires only C plus plus', but the plus sign
doesn't show up.
[reply]
[top]
|
