[Thunar-dev] Unification of Treeview and Sidepanel

[dannym]

Hi,

Am Freitag, den 13.05.2005, 08:49 +0200 schrieb Jasper Huijsmans:
> On Thu, May 12, 2005 at 11:03:53PM +0000, Brian wrote:
> > Jasper Huijsmans wrote:
> > 
> > >Ok, guys, I don't think the next step in thunar development should be more
> > >mockups of the GUI. One comment on that: the goal is to make a 'simple' file
> > >manager; this doesn't mean complete lack of features, it mostly means no user
> > >interface overload. Combining trees and shortcuts in one view sounds like xffm
> > >to me, we already have that and that is not the goal. Keyboard shortcuts to
> > >switch between shortcut and treeview will hopefully be enough to satisfy the
> > >power users among us.
> > >
> > >Now, the way forward, IMO, is for one or more people to try and implement 
> > >backend code based on the interaction diagram created by benny. We (you?
> > >they?) should aim at creating the minimal features necessary for a file
> > >manager (listing files, copying/moving, mime types/program launching). It is
> > >easy to add features later, it is very hard to remove anything once people are
> > >using your program.
> > >
> > >I know both Brian (kelnos) and Erik (no short nick worth mentioning ;-) were
> > >thinking about starting to code on thunar soon. It's probably hard to
> > >coordinate things, especially without benny, but for people who are interested
> > >in writing some code for thunar, let's try and keep this list informed about
> > >what you intend to work on.
> > >
> > >	Jasper
> > >  
> > >
> > I can start porting the python interface to C and connecting some empty
> > callbacks to the buttons and such.

I wouldn't do that yet. Frontend code (or anything having highly
interconnected classes which happens to be the case with frontend code)
is one of the things C sucks majorly at. Keep it in python until the
very last point possible (that is, after every feature works and every
class and every method and member variable and signal and property is
clearly defined). Believe me, that is the fastest and least annoying
way, and I tried tons of ways ;)

What we need is all the backend stuff, like mime type detection and so
on working. The frontend is easy, and note that I have some working code
for both a frontend, a folder data model, a preview generator (but not
completely the thumbnail storage - benny mentioned something about
local .thumbnail folders that I dont have support for in the code)
already, which can be used as a gui starting point later on.

The really interesting stuff to do now would be the actual
"do-some-action" process, that does
copying/moving/renaming/chmoding/finding/generating-thumbnails/cleaning-caches/indexing and will be used by the filemanager "in background". This is the part that really needs to be thinked out how to do :)

I'm thinking that would use some kind of action pipe for commands with
some format like

"COPY\0boo://file1\0home:///path/file2\0\0" over the (local-kernel-only)
"wire"

and such, the process running in the background for every frontend and
being in an "eventloop" waiting for stuff to be requested. What to do
about the (error/ok) reply with pipes, I dont know. Two pipes (in
opposing directions) probably have the problem of associating the error
message to the affected command? Or not? Ideas ? :)

(and yes, I know a AF_INET socket would work just fine but I think thats
overkill - feel free to convince me otherwise)

Or is it already in benny's diagram as well ? *wonders*

cheers,
   Danny

> > 
> > The only reason I can see for using gtk 2.6 is that there are one or two
> > more stock icons. (Help dialog comes to mind. I believe that mousepad
> > has a preprocessor command that checks the gtk version)
> > 
> > I'd be able to start sometime after Tuesday, but I won't have much time
> > until at least the end of next week.
> > 
> 
> I'm not sure it is wise to start with the UI. I can imagine implementation of
> the user interface will depend quite a bit on the implementation of the
> backends. I don't remember if benny had any thoughts about this on the wiki.
> If you don't mind things being ripped out again it might not be such a bad
> idea to have some GUI C code to work with though. I suggest you have a look at
> the gtk file chooser dialog code as well as the python mockup.
> 
> 	Jasper
> 
> 
> > Brian Schott
> > 
> > 
> > 
> > _______________________________________________
> > Thunar-dev mailing list
> > Thunar-dev at xfce.org
> > http://foo-projects.org/mailman/listinfo/thunar-dev
> _______________________________________________
> Thunar-dev mailing list
> Thunar-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/thunar-dev