michael.venables wrote: > The problem, as I see it, with the gtk breadcrumb system is that the crumbs, > themselves, do not scale. If there's not enough room to display an entire > crumb, you get no crumb at all. If you have a really long current crumb, it > can knock all the preceding crumbs out of view, and if the current crumb is > too long to be displayed in its entirety, you can wind up with no crumbs at > all, since the contents of the crumbs don't scale down.
> (This > whole issue of horizontal space and line length issue really only pertains to > using the File System view, anyway.) I don't know if it makes sense to design for deep folder paths and narrow Sonata windows, as I'd guess both are rare. That being said... > The great benefit of breadcrumbs is that it saves mouse-clicks. If it causes > you to use more clicks, then it's lost its efficiency. Unlike the gtk > implementation that knocks previous crumbs out of view to display long crumbs, > you should always be able to move up to the parent crumb with only one click. Although I think the biggest benefit is to orientate the user, I agree that we want to force the root crumb and the parent crumb to always show somehow. > If there's not > enough space to display the name of the parent crumb, then it should display > as an icon. (Probably a file folder would be appropriate, since an up arrow, > while perfectly sensible for moving up a directory tree structure, doesn't > make as much sense if your crumb trail moves horizontally.) I agree. And probably put the full name in a tooltip. > If the current crumb is too long to display fully, the title should truncate > with ... at the edge of the screen, the way long entries do in the Library > album view. Good point. > When there are enough crumbs to require scrolling the trail, a LEFT arrow > should be placed after the FILESYSTEM crumb. (There's no reason to eat up > space by adding a RIGHT arrow unless it's needed to move that way. Sonata has > never supported moving forward, only back. It might be nice to be able to move > forward.) > It would be super-cool if the trail could be rolled with the mousewheel. > Nautilus allows this; I don't recall if Thunar does or not. I don't know if any scrolling is really useful here. You can always go up one step at a time or directly to the root just as before. Now, how to best implement a dynamic layout like this in pygtk? We need a left-aligned (mirror if the language is right-to-left) box layout which can do ellipsis in the middle to fit its allocated width, plus some constraints: * the minimum width is condensed root crumb + (condensed parent crumb if any) + (ellipsis if any) + (condensed current crumb if any) * the natural width is all crumbs in full Start with the natural layout and continue until we fit in the allocated width: 1. Condense the root crumb. 2. Replace an increasing amount of the crumbs after the root with the ellipsis until right before the parent crumb. 3. Condense the parent crumb. 4. Truncate the current crumb to fit. At least it doesn't sound impossible... _______________________________________________ Sonata-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/sonata-users
