How to bind a style to a tab?

Task:

Change colour of the tab and bind it to the tab.

Attempt:

B1358-070

Question:

How do we ensure that the style of the tab stays bounded to the tab editor,
regardless where the tab editor may be moved to?

Base code:

// (1)
view = atom.views.getView(atom.workspace.getActivePane())
selector = "li.texteditor.tab.sortable.active"
viewTab = view.querySelector(selector)

// (2) Tab background: yellow
viewTab.style.background = "yellow"

// (3) Tab background: original
viewTab.style.background = ""

I’m not sure if this helps but I added colour to tabs with this snippet/hack in styles.less …

// ============================

// make tab text more readable

.tab-bar .tab {
//  color: #e0e0e0!important;
  color: white!important; // inactive tab text colour


  &.active {
    // color: #ffffff!important;
    color: white!important; // active tab text colour
    background-color: teal!important;

  }
}
// ============================

Thanks for answering.

No. Styling in general terms is not what I am aiming for.
Allow me to share what I have for my style file.

My own style sheet related to tabs
.tab-bar {
  font-family: "fira code";
  font-size: 8px;
  
  .tab.active[data-type$="Editor"] .title{
    color: white;
    background-color:  mix(white, @syntax-background-color,10%);;
  }
  
  .title {
    color: mix(@background-color-info, @syntax-text-color,5%);
    background-color: mix(black, @syntax-background-color,30%);
  }
  
  .tab, .tab.active {
    max-width: 110px;
  }
}

The aim is to develop some script

  1. Press shortcut button.

  2. The tab of the active editor is marked with a colour

  3. Wherever the editor is moved to, the tab should ‘move’ with it.

At times I have more than one copy of an editor open. This can be some challenge when marking a tab with another background colour.

Is there a way to add some type of attribute to the object that represents the tabs? This attribute should ‘move’ with the tab.

Just to clarify for my thinking … instead of “one copy of an editor” do you mean more than one Atom session open … or more than one tab open?

One session.

The “same text file opened in different panes” is an exception to look out for. The base request is like the animation in the 1st topic.

Simply add a class to your viewTab node:

viewTab.classList.add('yellow')

Then assign a color it:

.tab-bar .tab.yellow {
    background-color: yellow;
}

Or just use the existing color-tabs package

1 Like

@idleberg:
Thank you for giving such a nice idea.
Shortly - the problem stated in the first post is not resolved


Variation

An addition to ensure the active tab is also coloured:

.tab-bar {
  .tab.active.yellow, .tab.yellow {
    background-color: yellow;
  }
}

Tested

In Atom V1.43.0 Nightly 11 -

In Atom V1.42.0 Beta 0 -

Results:

The tab is coloured initially as expected. The colour remains when moving the “tab” around in the same “pane”. The styling is lost as soon as the “tab” is moved to another “pane”. It is the assumption that a new item is created based on the original object description. It is not a clone of the previous (now distroyed) item.

Atom V1.41.0 and Atom V1.43.0 Nightly 11 has the same result. In the case of Atom V1.42.0 Beta 0, the debug mode is triggered. It is unclear why this is the case. This occur even when Atom is in safe mode.

About color-tabs -

The same symptoms occur with that package: The added class is lost as soon as the “tab” is dragged to another “pane”.

Obviously, the class yellow gets removed when dragging the tab onto another pane. You might need to work with pane and/or editor IDs and use event listeners (e.g. on drag) that re-assign the class for the background color.

For starters:

const activePaneID = atom.workspace.getActivePane().id;
const activeEditorID = atom.workspace.getActiveTextEditor().id;
1 Like

@idleberg:
Thank you, your comments are helpful.
What follows is just saying aloud what the findings are + some ideas.
No action / reply requested.


That is what I thought – therefore the reason I started this conversation.

When a ‘text-editor’ is moved from one pane to another:

  • atom.workspace.getActivePane().id changes :slightly_frowning_face:

  • atom.workspace.getActiveTextEditor().id stays the same :slightly_smiling_face:


Agreed.

Possibly listen to removal of an element (‘text-editor’)
where it will register to listen for creation of a new element in a pane.

In the background keep track of all the ‘text-editors’ that are marked.
Add to the list the ID when the trigger occurs.
Removing from the list when the ‘text-editor’ is closed.

The ‘text-editor’ ID seem at first glance to be unique throughout the Atom’s session.
This needs verification.


Last note:

viewEditor = atom.views.getView(atom.workspace.getActiveTextEditor());
viewEditor.style.backgroundColor = "black";

The style implemented by the above code, remains pinned to the ‘text-editor’ even when it is moved to another location.

Well yeah, it’s the same text editor (so same ID) and a different active pane.

The tab is part of the pane. The element is recreated when the ‘text-editor’ is moved to a new pane location. Since you already knew this how would you suggest the style of the tab be bound to the ‘text-editor’?

Of course it does, you move it to a different pane

Yes that is clear.


I misunderstood the intent of your earlier suggestion.
On your earlier hint - what did you have in mind with the pane ID?

I just remembered in one of my packages I stored editors in an array (e.g. [activePaneID][activeEditorID]) to be able to identify them. Didn’t think any further or whether that’s applicable for your case.

@idleberg: Your replies have been helpful. Thank you.


The preliminary result of the script looks like:

Action seen:

  1. Open Atom.

  2. Create empty text-editors

  3. Move the text-editors to different locations.

  4. Mark text-editors by shortcut key

  5. Repeat 3 and 4.


All code constructed in the init.coffee file.

1 Like

  – only slightly off-topic

I liked the idea of being able to quickly identify editors (and panes) by some HTML attribute. So, I created a Node module that does just that. A useful compagnion library for all package developers!

It good that this topic could be a catalyst.
Yours is a good idea too. Thank you.
Because of this idea I am re-evaluating a project I am busy with.


My opinion on the atom-identify module:
Only atom.workspace.observe... is needed. The forEach loop is not needed.
The addEditorID and addPanelID is otherwise triggered twice.
The atom.workspace.observe... triggers for all editors/panels that were already there.

(note only 2 lines in initIDs… please ignore my attempt at ES6 style)

'use babel';

function initIDs() {
  atom.workspace.observeTextEditors((editor) => addEditorID(editor));
  atom.workspace.observePanes((pane) => addPaneID(pane));
}

function addEditorID(editor) {...}

function addPaneID(pane) {...}

const _default = initIDs;
export { _default as default };

It’s needed when Atom loads the project that was last opened. The observer only works for new editors/panes.

Triggering the addEditorID and addPanelID functions twice is not a huge issue. The below animation demonstrates when only the observer instructions are used.
trigger-identify


Does this satisfy your concern or did I miss something?
Thanks in advance.