Re: GIO branch

Tony Houghton <[email protected]> Thu, 6 Aug 2009 13:45:33 +0100
Newsgroups gmane.comp.desktop.rox.devel
Message-ID <[email protected]>
On Thu, 6 Aug 2009 08:35:56 +0100
Thomas Leonard <[email protected]> wrote:

> There didn't seem to be much interest in the GIO branch and it was
> never completed.

I wasn't interested in it back then, but I am now. Rather than have
samba running all the time just for odd occasions (OTOH I suppose I
could have it running from inetd) I'd rather use an smb client on Linux
to copy files to and from a Windows share. smbclient is painful, and
Nautilus is wonderful in comparison, even though it's not as good in
general as ROX-Filer and keeps throwing up vague error messages for
smb:// operations.

> I did experiment with a Python version of ROX-Filer that used GIO in 2008:
> 
>   http://repo.or.cz/w/rox-shell.git
> 
> But GIO has changed a bit since then and I don't think it will work
> now with some patching. Also, I got a bit distracted with getting a
> tree view working, which turned into this:
> 
>   http://sourceforge.net/projects/tree-shell/develop
> 
> Very unfinished and not very ROX-like, but quite fun. It uses
> libclutter 0.8 for the display.
> 
> I think I need to pick a new language first, though. Developing in C
> is just too painful, but Python does have rather a lot of overhead,
> and a lack of static type-checking. Haskell is way too slow, and
> probably not well suited to this kind of thing.

Anything else without such comprehensive bindings to common libraries as
python has is likely to be more painful than C, I would have thought.

> D looked nice. It is OO, and has garbage collection and exceptions,
> but it's not too heavy and it's much cleaner than C++. However, the
> GCC front-end (GDC) is completely unmaintained and the LLVM front-end
> only supports the obsolete D1 version. Also, D programs tend to suffer
> from segfaults due to dereferencing null-pointers (as with C). Last
> year, I patched support for nullable/non-null types into D's type
> system so the compiler can statically ensure that you never try to use
> a pointer that might be null:
> 
>   http://delight.sourceforge.net/
> 
> I also added native support for GObject bindings, so you can access C
> libraries using GObject as if they had an object-oriented D interface,
> but I didn't get as far as integrating it with the garbage collector
> and it's probably a bit buggy. I also replaced the curly braces C
> syntax with Python-style indentation.

If you're going to that much trouble you could try experimenting with
psyco.

> E (erights.org) is fantastic for writing responsive applications that
> access slow remote resources, and has nice security properties too,
> but the main implementation runs on the JVM, so it's very slow. It
> also lacks decent static type checking.
> 
> More suggestions welcome...

I've heard a few good things about lua lately. I don't know much about
it, but it seems to have less overhead than python on the one hand and a
lack of library bindings on the other. It's supposed to be easy to
interface with C though, so perhaps a C core with the complicated
high-level stuff done in lua would work.

-- 
TH * http://www.realh.co.uk

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july