Problem with full path in tabs

As a programmer, I really really don't like the tab names directory opus provides (having multiple tabs with "(C:) bin" or equally similar names isn't quite helpful), so I've been trying to get full path in tabs working (based on tab-labelizer.js). I circumvent the whole shorting logic and simply set the full path as tab name which is working fine for the tab names themselves, but in the overflow menu, whenever there's a \t inside the path, the rest of the path gets right aligned. Also, if tabs get really long, the "new tab" button can get pushed out of view, this shouldn't be possible. I'd really like to see this functionality implemented properly, then DOpus would be perfect (at least for me ;)). But at least for now, a fix for the weird \t behavior would be appreciated.

Here's a screenshot of the problem:

We've made a change for the next release which will prevent \t in custom tab labels turning into a tab character.

If you're aiming to use really long/wide tab labels, showing tabs on the left or right may be preferable to the top and bottom positions.

Thank you very much for your reply. Per your suggestion I've moved the tab-bar to the left and I do like it there. Now I feel like it would be quite nice if the text was actually right aligned, because if the tab doesn't completely fit the available space, the beginning of the path is usually less important than the end, so cutting it off is less of a problem.

Is proper support for showing the full path in tabs a thing you guys might tackle in the future?

Wouldn't you then end up back where you started, only seeing the last part of the folder names like you do by default?

Showing full paths on the tab names seems unwieldy to me. I'm not sure that could ever work well.

In situations where there are lots of folders with the same names, I tend to add a single word before the folder names to differentiate the tabs, using a script that looks for specific paths to decide which words to add. (When having folders from one place on the left and the other on the right isn't enough by itself.)

You could also use the accent colors to tell folders from different areas apart. (e.g. make everything under C:\Folder1 have a red accent, and C:\Folder2 a blue accent, so that C:\Folder1\Bin is red and C:\Folder2\Bin is blue.)

I mean we do sort our data into hierarchical folder structures for a reason. Showing only the last bit of that information is shortsighted to say the least. What I meant was shortening from the beginning of the path (maybe leaving the drive shown) is preferable. If you have, for example, a path like this: C:\Users\whatever\source\thirdparty\somethirdparty\somesolution\someproject Users\whatever is less important than the last 3 or 4 folder from the right, to decipher quickly what folder you are looking for. That's all it is for me, I want to be able to quickly discern between folders, having only the actual folder for that is not very efficient.

I do agree to a certain extent, that always showing the full path is not the optimum, but it sure beats the default behavior by a lot. At least it does for me.

edit: Thanks for the recommendations by the way, but they are unfortunately only workarounds and not a solution. Changing folder names is not always viable, and I'm not quite sure about the colors.

edit2: I just remembered, notepad++ has a solution for tabs that I prefere: multiple lines :wink:

C:\Projects\...\Subdir1\Subdir2 wouldn't be any more useful if the name of the project is in the truncated part in the middle. There aren't really any perfect solutions here that don't involve writing scripts by hand to choose the parts of the path that differentiate it from another similar path, which a piece of generic code can't really do. And extremely long tab names just don't make sense to me.

You can add a menu to Opus which lists all your open tabs as an alternative way to switch tabs. Maybe that would work better for what you're doing.

No, but then I can increase the size of the tab bar so that I can see all I need to. Also, to circle back, I don't want any shortening whatsoever and do prefer multiple lines instead of overflow-menus. But if I have to have shortening, it's usually better to remove parts from the start, than from the end...

I'm not asking for a perfect solution here, just one I can work with. Not everything has to be solved perfectly to be (more) useful and I don't think this issue is too complicated that the only feasible approach is a user-made script. It's quite sad that you have made up your mind about this issue and are not even open to more helpful solutions than the default behavior. I don't really understand it ether, considering the vast amount of configuration options that are available.

With the tabs on the left or right, the width can be anything you want.

We don't like multi-line tab controls, and probably won't ever implement that. (Although we have changed our minds in the past, so nothing is impossible. But the multi-line tab concept was in the User Interface Hall Of Shame for a reason. :slight_smile: )

A user-made script is not too complicated either. :slight_smile:

We do have some ideas about how we could provide a way to have a more simple way to create rules about tab names for specific paths without having to write a full-blown script. I don't know when or if we'll implement those but it is something we're thinking about, in conjunction with some similar changes in other areas. Something in between simple configuration (which isn't always powerful enough) and scripting (which is powerful but also has a higher barrier of entry).

Not every suggestion is going to be implemented in the program. There are also better ways to solve these problems, I think.

All I can find about that is multi-line tabbed dialogs and yes, a tree control for a large amount of settings is certainly better than a lot of tabs. Again, I don't need a perfect solution, but it is really baffling to me that you cannot see value in the concept of showing a full path to switch between views. I mean even the simple windows explorer, which you aim to replace, has that option. Granted, it's less useful because there are no tabs, but at least it is there as an OPTION.

While I don't think this basic functionality should be the responsibility of the customer, scripts are also an even less optimal solution to the problem. I also couldn't find a way to retrieve the available space for tabs (width of the tab bar) or a way to right align the titles. There is also no scrollbar if the tabs are wider than the available space. This is all pretty basic stuff...

Of course not. It's just unfortunate that, while you are looking for these "better ways", we are stuck with the worst possible solution.