Renaming a layout corrupts the list of layouts
Bug #1262709 reported by
Stephen Boddy
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Terminator |
Fix Released
|
High
|
Stephen Boddy |
Bug Description
Description:
Maybe it's just my large config, but sometimes I rename a layout and in the config file the new layout has the default "New Layout" name, and another layout entirely picks up the name intended for the new layout. Unfortunately it's a bit hit and miss as to when this occurs.
Expected behaviour:
Don't mess up my previous layouts :-)
Related branches
Changed in terminator: | |
status: | Confirmed → Triaged |
summary: |
- Adding a new layout mixes up the titles of exisiting layouts + Renaming a layout mixes up the titles of exisiting layouts |
summary: |
- Renaming a layout mixes up the titles of exisiting layouts + Renaming a layout corrupts the list of layouts |
description: | updated |
Changed in terminator: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
OK I edited the title and description to better describe the issue which I eventually tracked down.
When a layout is renamed an "edited" signal is generated calling a function on_layout_ name_edited. The first parameter passed to this function is the cell that was changed. The old value is taken from this cell, and that value is used to lookup the entry in config. The new name is passed as another parameter.
At least that is what is supposed to happen. For some reason every so often (10-20%) the wrong cell is passed. This is what causes the wrong layout to be renamed. What is really strange is that as well as the cell, a "path" is passed. The path is a sequence of numbers that point to the cell, yet the path is always correct even when the cell is wrong. I have implemented a workaround to handle this by using the path to look up the value from treeview.
This behaviour (as far as I can see) does not happen in the GTK3 port, so I'm thinking this is something in the gtk libraries that has been fixed (knowingly or not) in the interim.
Note that the Profile list uses the same code, and although I have not seen it, it probably occurs there too. I will check and implement the same fix if so.
Will update the ticket when the fix gets committed.