Created attachment 3607 shows current thunar and proposed UI changes for comparison hey, as previously discussed on irc i wanted to propose some minor, yet imo enhancing changes to the thunar UI. at the moment thunar features a 6px outer padding, which makes it look like a bulky window-border. i'm proposing inner padding instead, which keeps the elements from sticking to the window-borders (which also wouldn't look good) and keeps them nicely aligned, yet it doesn't add a cumbersome extra area. the mockup shows both the current thunar and the proposed version. (note that there is also a statusbar change, but there will be a separate bugreport/feature-request for that, i just wanted to save me some time by doing only one mockup, that's all.) (btw it's not really possible to theme only this part to make it look like in the mockup attached, so it'd have to be a code-change.)
Yes, fully agree.
*** Bug 7504 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Yes, fully agree. thanks for the reply jannis. funny this "bug" got reported twice in two days (after going under the radar for years) :) btw kalikiana fixed a very similar issue in postler, maybe he can help with a patch or at least a proposal.
(In reply to comment #0) Looks pretty. In relation to the padding, you might want to also mock up border/padding for when vertical and/or horizontal scrolling appears for both the F9 side pane (on left) as well as the main pane. Just to be sure. Also, re the status bar change, two things: - presumably if the side pane is not shown, then the status bar would span the entire window? - Currently (Thunar 1.0.1), the spanning width of the "Location Selector" depends on which location selector is used (Pathbar style or Toolbar style). Pathbar style spans the main pane (same as your new mockup status bar), whereas the Toolbar style spans the window with or without the side pane showing.
(In reply to comment #4) > (In reply to comment #0) > > Looks pretty. thanks > In relation to the padding, you might want to also mock up border/padding for > when vertical and/or horizontal scrolling appears for both the F9 side pane (on > left) as well as the main pane. Just to be sure. hm, right, i can do that (after the easter break, i'm going away tomorrow morning), even though i'm not 100% sure it's needed. (jannis?) > Also, re the status bar change, two things: > - presumably if the side pane is not shown, then the status bar would span the > entire window? the statusbar-bug is here: https://bugzilla.xfce.org/show_bug.cgi?id=7497 (and yes, in that case the statusbar would again span the whole window, because the whole window would equal the context pane) > - Currently (Thunar 1.0.1), the spanning width of the "Location Selector" > depends on which location selector is used (Pathbar style or Toolbar style). > Pathbar style spans the main pane (same as your new mockup status bar), whereas > the Toolbar style spans the window with or without the side pane showing. i think i can see where you're going, but that never bothered me. i know nautilus does it differently, but i personally prefer the idea behind thunar's implementation of the pathbar/toolbar.
This is fairly easy to implement except for one thing: the status bar is a ThunarStatusbar which derives from GtkStatusbar. That bar has a shadow type set by default which causes it to have this horizontal separator-style line above it. We cannot easily get rid of that except in themes. Well, we can override the default look by hard-coding a GtkRcStyle for the status bar but I'm not sure this is a good idea. It might be ok but I am unsure as to whether this is common practice or bad developer behavior. ;) Another option we have is to make ThunarStatusbar a custom widget derived from GtkHBox or GtkFrame. This has the advantage that we have full control over the visual appearance. The downside is that we have to implement the GtkStatusbar features we need (well, there are not many so it's not much work) but more importantly, we'll lose the resize grip. I remember there were plans in GTK+ or at least in Ubuntu to move the resize grip to the top-level window instead of only having it in the status bar but this certainly did not happen in GTK+ 2.x, so we'd lose the resize grip no matter what. Not sure how important it is though, we don't have it in other windows either.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #0) > > > > Looks pretty. > > thanks > > > In relation to the padding, you might want to also mock up border/padding for > > when vertical and/or horizontal scrolling appears for both the F9 side pane (on > > left) as well as the main pane. Just to be sure. > > hm, right, i can do that (after the easter break, i'm going away tomorrow > morning), even though i'm not 100% sure it's needed. (jannis?) I am not sure what is meant by border/padding for scrolling. There is a 1-2px shadow around the inner part of the scrolled window (which consists of the view and the scroll bars) and that won't go away. In Chrome (and possibly Firefox as well) this 1-2px shadow is placed outside the scroll bars instead of only decorating the inner part of the scrolled window. But this we can't (or rather shouldn't) do. It's custom code they are using there. > > Also, re the status bar change, two things: > > - presumably if the side pane is not shown, then the status bar would span the > > entire window? > > the statusbar-bug is here: https://bugzilla.xfce.org/show_bug.cgi?id=7497 > (and yes, in that case the statusbar would again span the whole window, because > the whole window would equal the context pane) Yep, also easy to implement. Already have it running like this here. Again, the only annoying thing is the horizontal line above the status bar content. > > - Currently (Thunar 1.0.1), the spanning width of the "Location Selector" > > depends on which location selector is used (Pathbar style or Toolbar style). > > Pathbar style spans the main pane (same as your new mockup status bar), whereas > > the Toolbar style spans the window with or without the side pane showing. > > i think i can see where you're going, but that never bothered me. i know > nautilus does it differently, but i personally prefer the idea behind thunar's > implementation of the pathbar/toolbar. This is somewhat off-topic. I'm reluctant to change this part of the UI, just so that you know. ;)
(In reply to comment #6 and #7 - darn you, mid-air collision!) > I am not sure what is meant by border/padding for scrolling. There is a 1-2px > shadow around the inner part of the scrolled window (which consists of the view > and the scroll bars) and that won't go away. In Chrome (and possibly Firefox as > well) this 1-2px shadow is placed outside the scroll bars instead of only > decorating the inner part of the scrolled window. But this we can't (or rather > shouldn't) do. It's custom code they are using there. i don't think anything should be custom for the scrollbars, they work great the way they are right now imo. > Yep, also easy to implement. Already have it running like this here. Again, the > only annoying thing is the horizontal line above the status bar content. agreed, that line is not very pretty. it would be interesting to test the effect of hardcoding it with the usual suspects of engines (murrine, pixbuf, aurora, equinox, clearlooks, xfce and maybe a few others). if you really think this is a direction you wanna go let me know if you need help testing. > Another option we have is to make ThunarStatusbar a custom widget derived from > GtkHBox or GtkFrame. This has the advantage that we have full control over the > visual appearance. The downside is that we have to implement the GtkStatusbar > features we need (well, there are not many so it's not much work) but more > importantly, we'll lose the resize grip. I remember there were plans in GTK+ or > at least in Ubuntu to move the resize grip to the top-level window instead of > only having it in the status bar but this certainly did not happen in GTK+ 2.x, > so we'd lose the resize grip no matter what. Not sure how important it is > though, we don't have it in other windows either. yes, that's a problematic part that i was kinda aware of. in ubuntu (from 11.04 which will be released in two weeks) the resize-grips will be on the window-level, meaning you have to deactivate them for windows that shouldn't expose one (e.g. xfdesktop). afaik and iirc this is a gtk3 feature that has already landed there (at least in some dev-branch is suppose) and was backported to gtk2 by ubuntu. anyhow, gtk3 is still a release or two away for xfce and ubuntu is only one distro, so i'm not sure any of this counts as an argument. the question really is how important the resize-grip is (it's definitely not hurting, but since windows can be resized in xfwm4's top corners as well, it might also be ok to lose it). also, i would have proposed some overlay instead of the statusbar-widget, but that's gtk3-only, right? > This is somewhat off-topic. I'm reluctant to change this part of the UI, just > so that you know. ;) true, and: good :) i'm really happy with the way this looks and works!
Created attachment 3611 Patch to drop window padding and move the status bar Here's a patch that implements the proposed changes. It removes the 6px window padding, makes the side pane take up all vertical space (moving the status bar below the directory view) and enforces the GtkStatusbar::shadow-type to be GTK_SHADOW_NONE. Haven't tested it with any themes other than Shiki-Brave which I'm using. Please give feedback.
Note: It would be easy to move the scrollbars inside the frames of scrolled windows but I just tried that and it looks ugly (at least with my theme). Can be done easily though by adding code along the following lines to the gtkrc file of the theme or to ~/.gtkrc-2.0: style "scrollbars-in-bevel" { GtkScrolledWindow::scrollbars-within-bevel = 1 } class "ThunarStandardView" style "scrollbars-in-bevel" class "ThunarShortcutsPane" style "scrollbars-in-bevel" class "ThunarTreePane" style "scrollbars-in-bevel"
sorry for the late reply, was away for the last two weeks. will test this as soon as i got a few things back in order, so it might be a few more days until extensive feedback. thanks for picking this up jannis!
Implemented in master now: commit a6650a997c975d09a7c881329564cdfe5626e1b6 Author: Jannis Pohlmann <jannis@xfce.org> Date: Fri Apr 15 14:07:52 2011 +0200 Improve the UI according to bugs #7496 and #7497.
(In reply to comment #12) > Implemented in master now: thanks jannis, you're the best!