XYplorer Beta Club

TheQwerty wrote:

j_c_hallgren wrote:Or having a narrow vertical colored bar, especially at left side, like prior to line #/name, that would be outside the range of any other zebra/colors in list would maybe be easier than tab backrounds, and would still be very visible...possible width about the same as split line between tree and catalog...I think I would most likely prefer this choice instead of tab background, as it's more flexible and doesn't conflict with tab hdr colors.

I agree this needs some more tweaking to get the ideal solution.

That's kind of what I was thinking with the Boxed Branch Bar.
Only I was allowing the user to put it on any edge, and I was thinking more along the lines of the width of a scrollbar or status bar.

I think that might be a very good solution though.

I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

PS: http://www.xyplorer.com/xed/hilitebranches.htm
Click 3-4 times on the image and see a similar idea visualized.

admin wrote:I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

While it's true one would loose some space, it would be users choice as to how much or how little, as a column heading wouldn't be needed, but just the split/divider thus making minimal width less than any other columns...

And I'd be willing to give up the width of one character or so to get this column when I felt it needed, by reducing Tree width or some other col to offset.

While it may not be that simple to implement, I presumed that doing a vertical pseudo-column would be much easier than a horizontal one, so I thus went in that direction.

PS Update: Just looked at the XED samples...I really like #5! Makes it really clear where one is yet doesn't interfere with other things!! I find #4 a bit confusing due to color overlays.Update to update:
You added that PS while I was typing my prior reply, and your reply to this while I was typing PS Update!

j_c_hallgren wrote:

admin wrote:I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

While it's true one would loose some space, it would be users choice as to how much or how little, as a column heading wouldn't be needed, but just the split/divider thus making minimal width less than any other columns...

And I'd be willing to give up the width of one character or so to get this column when I felt it needed, by reducing Tree width or some other col to offset.

While it may not be that simple to implement, I presumed that doing a vertical pseudo-column would be much easier than a horizontal one, so I thus went in that direction.

See PS on my previous post...

Thanks Don, for implementing this. But like others feel, i too think that changing the whole list might be a little too much and as it has been discussed around here, having one vertical bar on list should be sufficient.
I see that we now have a user-definable line number column width (View>column>set line number column width) and user has 3-8 pixels to choose from. If that part alone could be colored then user can choose how much of context he/she needs.
Or probably 3 pxs (default now) could mean no color at all and anything between 3-8 px colors the pixels before Line number column. That way you dont have to bother about space since its user's problem.

The other advantage I just realized of having colors as shown on XED #5 http://www.xyplorer.com/xed/hilitebranches.htm is that when a parent folder is scrolled off the screen, yet its children are still visible, such as may occur when a particular user (Admin/All users/Hallgren) within Doc & Settings is the boxed folder and you've expanded folders where similar ones occur within other paths, you'd still know that you are within that user grouping, which you now don't see.

serendipity wrote:and user has 3-8 pixels to choose from.

BTW: It's not nbr of pixels for Line nbr width, it's nbr of digits!

I like #5 too. Are we still discussing about list color or is there a new move to change the tree coloring too? I like the tree coloring as it is now.
If this is implemented in the list, it would meet most of our needs and I see a lot of potential for this in the search tab. And jacky can join the party.

j_c_hallgren wrote:

serendipity wrote:and user has 3-8 pixels to choose from.

BTW: It's not nbr of pixels for Line nbr width, it's nbr of digits!

, you are right. 3-8 pixels would be nothing.

serendipity wrote:I like #5 too. Are we still discussing about list color or is there is new move to change the tree coloring too? I like the tree colors as they are now.

I was just following up on that tangent, as I would use that method if available as alternative option for Boxed Branch compared to current method as I just realized ( ) that I was using Highlighted folder because I had long ago found the current Boxed coloring interfering with my readability of folders within it, and was a bit too intrusive no matter what color I chose, and thus went back to simple Highlight of parent, which results in the issue of scrolling as I'd written before...(I've not set any new highlites or boxes in last few months, and I use colors sparingly)

j_c_hallgren wrote:

admin wrote:I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

While it's true one would loose some space, it would be users choice as to how much or how little, as a column heading wouldn't be needed, but just the split/divider thus making minimal width less than any other columns...

And I'd be willing to give up the width of one character or so to get this column when I felt it needed, by reducing Tree width or some other col to offset.

While it may not be that simple to implement, I presumed that doing a vertical pseudo-column would be much easier than a horizontal one, so I thus went in that direction.

Just to make it clear I am not talking about a column, or adding a component IN the list.

I'm thinking of a component adjacent to the list, and as such there should be no difficulty in implementing it horizontally rather than vertically.

Also remember, it can't just be a column in detailed view because then it becomes just another thing that the detailed view has and the other views miss out on. (Kind of like making multiple selections with the selection rectangle.)

Now perhaps the easiest solution for the time being would be to leave it as is (change the background) on non-detail views and just add a color column or background color to the line numbers for the detail views and not change the entire list's background color.

In the Tree, I love things how the are now, no need to change anything there.

In List, I had suggested to use the icon "column" so that it doesn't take any space up, but it is true that it may not be visible much...



That said, using the Line column as well might just do the trick, since it's a column that can be very small. Maybe it should support a "size" of 1 or 2 (now starts at 3), and also allow to come without any text filled in. Yeah, so no line numbers anymore, but only the boxed color.

Or another idea completely to go along with TheQwerty would be to add that color somewhere on the Statusbar... ? The only thing is that is then applies only to the current location, hence has no meaning on search results.

But to be honest, I don't think I would use it actually.

TheQwerty wrote:

j_c_hallgren wrote:

admin wrote:I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

While it's true one would loose some space, it would be users choice as to how much or how little, as a column heading wouldn't be needed, but just the split/divider thus making minimal width less than any other columns...

And I'd be willing to give up the width of one character or so to get this column when I felt it needed, by reducing Tree width or some other col to offset.

While it may not be that simple to implement, I presumed that doing a vertical pseudo-column would be much easier than a horizontal one, so I thus went in that direction.

Just to make it clear I am not talking about a column, or adding a component IN the list.

I'm thinking of a component adjacent to the list, and as such there should be no difficulty in implementing it horizontally rather than vertically.

Also remember, it can't just be a column in detailed view because then it becomes just another thing that the detailed view has and the other views miss out on. (Kind of like making multiple selections with the selection rectangle.)

Now perhaps the easiest solution for the time being would be to leave it as is (change the background) on non-detail views and just add a color column or background color to the line numbers for the detail views and not change the entire list's background color.

Well, I don't have a problem with the current state of things. I just added a possibility, and it works well depending on your color choice and other settings. Nobody is forced to use it.

Personally, I set my backgrounds to subtle shades of blue, red etc and it doesnt interfere with my previous colors. After much thought i think i like it now but i am open to other ways of doing it too.

BTW: a bug related to this is, if you have a folder starting with a number (eg. 01-XY), then the background color is that of its parent not its own box branch.

serendipity wrote:BTW: a bug related to this is, if you have a folder starting with a number (eg. 01-XY), then the background color is that of its parent not its own box branch.

Thanks, good find! Fixed.

I recently found myself making heavy use of boxed branches once again, and remembering what a great feature it is!

Unfortunately, we never did come up with a solution to the other problems mentioned here but maybe we could re-open this with fresh eyes now?

1)

jacky wrote:Anyways it's not good when using Zebra stripping

This is still the case, and I really think the solution is an option to allow XY to calculate the color based on the background color.

I believe in this now meaningless thread it was being discussed and Don felt it was too smart. My opinion is that it is the sort of helpful smart that I would find extremely welcome. Not to mention there was some precedent set by the fact that this smartness has long been used for the sorted column:

History wrote:v6.80.0043 - 2008-01-27 15:16
. . .
* In a box-colored list, the color of the sorted column is now
determined automatically. Looks better.

2) We were discussing alternatives and I suggested possibly showing a small colored bar that the user could place on any edge of the list:

admin wrote:

TheQwerty wrote:

j_c_hallgren wrote:Or having a narrow vertical colored bar, especially at left side, like prior to line #/name, that would be outside the range of any other zebra/colors in list would maybe be easier than tab backrounds, and would still be very visible...possible width about the same as split line between tree and catalog...I think I would most likely prefer this choice instead of tab background, as it's more flexible and doesn't conflict with tab hdr colors.

I agree this needs some more tweaking to get the ideal solution.

That's kind of what I was thinking with the Boxed Branch Bar.
Only I was allowing the user to put it on any edge, and I was thinking more along the lines of the width of a scrollbar or status bar.

I think that might be a very good solution though.

I agree. Alas, the implementation is not a very joyful thing. Also you lose some space. Let's wait a bit until something even better comes along...

The user-specified edge is likely still difficult, but thanks to the breadcrumb bar, visual filter, and quick search info bars the space issue is less valid and the joylessness may have been reduced.

However, let me push the bar just a bit and suggest something a little more radical...

Folder View Settings 2.0

1. On Enter Script
   A script that is run when user browses to a location triggering this FVS.
2. On Leave Script
   A script that is run when the user leaves this FVS.
3. Branch Bar
   A toolbar shown in the list when using this FVS and consisting of user-specified:
   1. Icon
   2. Title
   3. Bar Background Color
   4. Toolbar buttons

The enter/leave scripts help to bring CEA closer to reality.

The branch bar allows a user to create a contextually aware and relevant toolbar, while possibly providing relief to those wishing that the main toolbar could become two rows.

I'm sure we all have a button or two that we keep visible all the time (or hide in an expandable section) but only need in a couple of folders. This allows us to keep the functionality but reduce some of the always present clutter.

The background color, title, and icon provide an alternative solution to the boxed branch in list/similar folders problem.
Ideally, these fields could also be set via script (including the enter/leave script) thus allowing a single FVS for multiple locations with the ability to change the bar's background color/title depending on the actual path.

Let's discuss!
(Or just rubber-stamp it and put it into v16.30.0018! )

Well, actually I'm just preparing v16.40, and you dig out a thread from v6.80.0044. You are an optimistic guy!