From: Thomas L. <ta...@gm...> - 2008-06-03 19:16:35
|
GIO is a virtual filesystem that has replaced gnome-vfs in GNOME. It is included with GLib, so programs can use it without depending on the whole GNOME stack. To experiment with GIO, I've create a new branch here: http://repo.or.cz/w/rox-filer.git?a=shortlog;h=refs/heads/gio If you've already checked ROX-Filer out, you can do: $ git fetch $ git checkout -b gio origin/gio $ ./AppRun --compile It's only for the super-curious at present. It's buggy and most things don't work. But, you can do e.g. $ rox -n trash:// to browse your virtual trash directory, or $ gvfs-mount ssh://user@host $ rox ssh://user@host You should be able to use it to look inside archives too, but I can't figure out the syntax at the moment :-/ API docs are here: http://library.gnome.org/devel/gio/2.16/ -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Tony H. <h...@re...> - 2009-07-14 17:11:40
|
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. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@gm...> - 2009-08-06 07:36:07
|
2009/7/14 Tony Houghton <h...@re...>: > 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 |
From: Lennon C. <le...@ri...> - 2009-08-06 08:09:52
Attachments:
signature.asc
|
Thomas Leonard <ta...@gm...> wrote: > Python does have rather a lot of overhead, > and a lack of static type-checking. I would have thought that waiting for IO, even locally, would easily swamp python's overhead? The lack of typechecking shouldn't be too much of a problem if you take advantage of duck typing - especially via the abstract base classes in newer versions (PEP 3119). It's probably also worth keeping in mind just how many ROXish utilities are written in python - standardising on a 'main' language would be good if its achievable. Also, the Filer could then use ROX-Lib (without having to maintain bindings for it). -- Lennon Victor Cook "He who receives an idea from me receives without lessening, as he who lights his candle at mine receives light without darkening" -- Thomas Jefferson |
From: Alex A. <cir...@gm...> - 2009-08-11 02:56:51
|
Vala? C#-like language with native access to GObject. Compiler outputs C which is then fed through GCC. - Alex Austin (651) 238-9273 "...and then I visited Wikipedia ...and the next 8 hours are a blur." On Thu, Aug 6, 2009 at 2:35 AM, Thomas Leonard <ta...@gm...> wrote: > > ... > > 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. > > ... > > -- > 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 > _______________________________________________ > rox-devel mailing list > rox...@li... > https://lists.sourceforge.net/lists/listinfo/rox-devel > |
From: Tony H. <h...@re...> - 2009-08-06 12:45:46
|
On Thu, 6 Aug 2009 08:35:56 +0100 Thomas Leonard <ta...@gm...> 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 |
From: Nicola F. <nt...@us...> - 2009-08-06 17:50:16
|
Il giorno Thu, 6 Aug 2009 13:45:33 +0100 Tony Houghton <h...@re...> ha scritto: > 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. http://oproj.tuxfamily.org/wiki/doku.php?id=lgob This is a quite complete set of bindings. I'm planning to use them in a short time but I still don't have any idea about their quality. -- Nicola |
From: Ben M. <be...@mo...> - 2009-08-06 23:07:31
|
Quoth Development of the ROX Desktop <rox...@li...>: > > There didn't seem to be much interest in the GIO branch and it was > never completed. I have to say I never liked the idea of ROX using GIO. GIO introduces a very Windows-like idea of pretending things are files that really aren't, which seems counter to the ROX philosophy of simple Unix file behaviour. IMHO things like SMB access belong in the OS filesystem layer, either with real filesystems like smbfs or 'virtual' filesystems like Fuse. I'd rather my filer concentrated on showing the files that are really there. > 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. <snip> > > More suggestions welcome... Well, Perl springs to mind, though I suppose it has much the same tradeoffs as Python. Since you don't seem to mind experimental languages, you might want to take a look at Perl 6/Rakudo, which aims to add features like (proper) static type-checking without losing the convenience of a dynamic language. It probably isn't fit to use for a production project yet, though. Ben |
From: Lennon C. <le...@ri...> - 2009-08-08 09:04:07
Attachments:
signature.asc
|
Ben Morrow <be...@mo...> wrote: > I have to say I never liked the idea of ROX using GIO. GIO introduces > a very Windows-like idea of pretending things are files that really > aren't, which seems counter to the ROX philosophy of simple Unix file > behaviour. So, things that aren't *local* files aren't files? 'Unix file behavior' is that a file is a stream of bytes - *any* stream of bytes, it doesn't need to actually be stored on a filesystem anywhere (hence why std{in,out,err} are considered files by POSIX). Desktop environments generally (if implicitly) put a couple of extra constraints on this - mainly that a file has an associated type, and hence associated actions - to make it more useful. But rox in particular has *no requirement* that a 'file' exist on a filesystem (see: dragging the icon from the typical roxish 'save' dialog to another app), so I find it silly not to remove the requirement of it being on a local filesystem (or, atleast, mounted to the local tree). > IMHO things like SMB access belong in the OS filesystem layer, either > with real filesystems like smbfs or 'virtual' filesystems like Fuse. > I'd rather my filer concentrated on showing the files that are really > there. I tend to think of GIO as Fuse done better: instead of a call stack that makes a syscall, goes into the kernel's filesystem code, and then *back out* into userspace (through a process that will make more syscalls, eg, through the networking libraries), it wraps the OS' APIs into something higher-level, and does the extra work for finding the resource *before* it starts making syscalls. It all just seems neater and more logical. Also, compared to making syscalls directly like ROX does now, GIO provides some other her niceties than just remote file access. For one, its API is higher-level and nicer to work with (particularly, it can do things asynchronously rather than by blocking); for another, it gives full windows support for free. -- Lennon Victor Cook "He who receives an idea from me receives without lessening, as he who lights his candle at mine receives light without darkening" -- Thomas Jefferson |
From: Neil G. <Le...@sc...> - 2009-08-11 02:42:46
|
On Thu, 06 Aug 2009 08:35:56 +0100, Thomas Leonard wrote: > 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. [snip] > More suggestions welcome... I'm prepared for the usual bout of derision, but I have been using Freepascal For lightweight things. It has some good middle ground, being Object oriented and generally less painful than C, but not Dynamic and garbage collected. The memory usage and speed are close enough to C to not really matter (C marginally faster, FPC marginally less memory). The compiler is well supported, and speedy (most of the time goes on linking, Which the next major release is hoping to fix with an internal ELF linker) You can easily knock things out by using Lazarus, which is a behemoth. If you use their components a helloworld is fairly huge, I'm not sure if growth beyond that is as bad. I use MSEIDE which is much lighter but quirky, as projects that are largely the work of one person are wont to be. I'm currently using Freepascal for a little educational programming thing on the OLPC XO. Talking to X direct without anything beyond xlib. I'm quite pleased with how it's going (apart from the fact xlib blows goats of course) |