Re: GIO branch

Thomas Leonard <[email protected]> Thu, 6 Aug 2009 08:35:56 +0100
Newsgroups gmane.comp.desktop.rox.devel
Message-ID <[email protected]>
2009/7/14 Tony Houghton <[email protected]>:
> Is there any news about the GIO branch? Browsing the git repo it looks
> as if it fizzled out about a year ago. I've been using Nautilus to
> transfer files to and from Windows lately and it's far nicer than
> smbclient. It would be nice if ROX-Filer could do this too, possibly
> with an extra app to browse the network, but I don't know how
> authentication would work then.

> I'm starting to feel that the ROX desktop is in danger of falling behind
> GNOME in overall usability even though the core filer is still better
> than Nautilus. Being able to use ROX-Filer over a network (without being
> confined to native filing systems like NFS) would give it a big shot in
> the arm.

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

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.

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.

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...


-- 
Dr Thomas Leonard		ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1

------------------------------------------------------------------------------
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