Re: [README] [IMPORTANT] rep-gtk and gtk+3

Am Thu, 12 Aug 2010 15:08:05 -0400
schrieb Clinton Ebadi <clinton unknownlamer org>:

> Christopher Roy Bratusek <zanghar freenet de> writes:
> > Hi fine folks,
> >
> > so GTK+ 3.0 will be in town around middle of September. Sawfish 3.0 which is
> > *currently* scheduled for June 2011 will be using it (or rather GTK+ 3.2 which is
> > released in March 2011). Either way: the glue-code generator for rep-gtk is rather
> > ugly.
> >
> > So there are two opportunities (actually there are three, but the third is rejected):
> >
> > a) port g-wrap to librep and get bindings to c-apps easily. Difficulty ****, examples:
> > only g-wrap itself.
> IIRC g-wrap is more or less unmaintained now so this is probably a bad
> idea (Guile 2.0 has a dynamic FFI built in based upon libffi).

librep has basic ffi bindings, which may be extended.

> > b) glue librep and gobject-introspection (gis) and get bindings to gis-using apps
> > easily (basically everything gnome-related). Difficulty **, examples: python-gtk,
> > gtkmm (and maybe other bindings) already gis, so we may learn from them.
> I'd take a look to what guile-gnome is doing as well.

the last time i've check it has been using g-wrap.

> > Well I would prefer b). The problem is: the missing manpower. So this is also a call
> > to contributors. (ehh.. to YOU - YOU there and YOU (who want's to leave the show now))
> >
> > Just to complete the list: c) would be switching to GUILE. Rejected. There are various
> > reason for rejecting the switch. (...)
> Actually, is there any reason to not retarget librep onto the guile-vm?
> By this I mean, if patches were to magically appear would they be
> rejected?

90%: yes… basically I've never rejected "magically appearing patches", but I doubt on
this thing.

> By targetting the Guile VM REP would gain the ability to call Guile
> functions... Scheme and REP are similar enough that it seems
> straightforward enough (the only hairy issue is probably nil as false --
> but Guile has a sort-of solution to this now for the emacs-lisp compiler
> by having a special #nil value that satisfies both false? and
> null?... ugly from a type theoretic standpoint but multi-language
> support is in the early stages).
> I'm familiar enough with the Guile internals to do this, but I've yet to
> really look around librep.

Well… I'm not sure how useful it is to use librep and then depend on guile doing the
stuff. FFI and GIS are better options if you ask me.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]