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