"ls" (not ls -l) support

[GoogleCodeExporter]

Should support multi-column output like plain "ls".

Original issue reported on code.google.com by cgwalt...@gmail.com on 19 Sep 2007 at 1:07

[GoogleCodeExporter]

Original comment by cgwalt...@gmail.com on 19 Sep 2007 at 1:48

• Changed title: "ls" (not ls -l) support

[GoogleCodeExporter]

I'd like to take this one

Original comment by KaiSchro...@gmail.com on 29 Jan 2008 at 3:58

[GoogleCodeExporter]

Ok, cool!  In my ideal world, GTK+ would include a nice canvas API and we could 
use
that.  But the way I see the options are:

* Roll a file view manually, using plain cairo on top of a gtk.DrawingArea
* Try a little harder and make the above hand-rolled code slightly more 
abstract, so
we could use it for other things internally
* Try somehow to extract the Nautilus code (I would be a bit sad at having to 
compile
C as part of Hotwire but it's not the end of the world)
* Pick a canvas:

Choices look like:

* http://developer.mugshot.org/wiki/Hippo_Canvas
* http://geocanvas.sourceforge.net/crcanvas
* http://sourceforge.net/projects/goocanvas

None of these are really perfect, but I have done some Hippo Canvas coding so 
I'd be
best positioned to help with it.

This is not a trivial issue, but it would be quite nice to have in.

Original comment by cgwalt...@gmail.com on 29 Jan 2008 at 4:10

[GoogleCodeExporter]

Any objections to this approach using a gtk.IconView (except, of course, being 
an
ugly proof of concept hack ;) )?

Original comment by KaiSchro...@gmail.com on 29 Jan 2008 at 5:41

Attachments:

• iconviewhack.patch

[GoogleCodeExporter]

Oh, I didn't know about GtkIconView!  Yes, that might be good enough.

The new file doesn't seem to be included.  Now...on an architectural level, 
here is
how I'd imagined this working. 

We already have an option '-l' to the LsBuiltin.  We need to propagate that 
from the
builtin to the renderer, so it knows to use the current column view.  There is
currently a very basic "metadata" channel from builtins.  Right now it's used to
display status, but my thought was that we'd also use it to influence things 
like the
UI display choice.

If you look at FileOpBuiltin which is a superclass for various file operation, 
it calls 

context.metadata('hotwire.fileop.basedir', 0, first_dn)

This is an arbitrary string that gets passed to the UI.

Now, getting that string all the way through the execution core into the 
renderer
system is going to be fun...there are many layers of abstraction =/

I guess we also have an open question whether there should conceptually be two
renderers, or one with two display modes?

I'm leaning towards the thought that there are two different ones, but I'm not 
sure.

Original comment by cgwalt...@gmail.com on 29 Jan 2008 at 5:58

[GoogleCodeExporter]

+#    import hotwire.builtins.apply   

Was apply failing for some reason?

-        self._table = gtk.TreeView(self._model)
+        self._model = self._liststore
+        self._table = gtk.IconView(self._liststore)

Now, a lot of things are going to fail if we change the TreeObjectsRenderer to 
not be
a TreeView =)  I think we need a new generic ObjectsRenderer subclass like
IconViewObjectsRenderer.

-    def get(self, path, size=24, animation=False, trystock=False, 
stocksize=None):
+    def get(self, path, size=64, animation=False, trystock=False, 
stocksize=None):

This is a pretty far-reaching change.  It could uglify things because images 
will be
loaded at 64 pixels, then potentially scaled down.  We should just pass size=64 
in
the code for the IconViewRenderer.

Original comment by cgwalt...@gmail.com on 29 Jan 2008 at 6:01

[GoogleCodeExporter]

If we have multiple possible renderers (which is what is going to be the best
approach probably), then we also need to implement issue 95.

Original comment by cgwalt...@gmail.com on 29 Jan 2008 at 6:03

[GoogleCodeExporter]

To make things clearer on this multiple renderers thing, I'm thinking of a UI 
vaguely
influenced by this: http://www.powershell.com/analyzer/index.html

Well, a ton of things are different too.

Multiple renderers will mean we need to improve the ClassRendererMapping to not 
be
one-to-one...also we get into issues like defining the default.

Original comment by cgwalt...@gmail.com on 29 Jan 2008 at 6:07

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> Was apply failing for some reason?
yes, a module called simplejson is missing.

> Now, a lot of things are going to fail if we change the TreeObjectsRenderer 
to not
be a TreeView
> -    def get(self, path, size=24, animation=False, trystock=False, 
stocksize=None):
> +    def get(self, path, size=64, animation=False, trystock=False, 
stocksize=None):
> This is a pretty far-reaching change.

don't worry - those are just hacks that were never meant to be committed. I am 
not
sure about the multiple renderers thing yet - I have to think about that a bit 
more.
And now, I first have to leave my computer for a few hours :). 

adding the patch with the missing file... (although its just a quick hack and 
not
that interesting at the moment).

Original comment by KaiSchro...@gmail.com on 29 Jan 2008 at 6:31

Attachments:

• iconviewhack.patch

[GoogleCodeExporter]

On this issue, we could have ls generate two different types of object - say 
File and
DetailedFile  It would normally generate File, but would generate DetailedFile 
if the
-l option was used.  DetailedFile could inherit from File, and might need only 
a pass
as the body.

Then the current FileRenderer could become the DetailedFileRenderer and the new 
short
renderer could be the new FileRenderer.

Original comment by dmi...@gmail.com on 23 May 2008 at 4:20