Make sure unaccounted-for indicator containers (like the not ready app
indicator indicator containers) in the right panel box are on the left
of it, since the right panel box is logically right-to-left and to avoid
unnecessary shifting should they become accounted for.
Do this by not acting upon a new AppIndicator/KStatusNotifierItem item
immediately (as in trying to position it properly and maybe saving it to
settings), but rather act once the app indicators "ready" signal emits
by simply saving new items to settings and ordering the top bar boxes.
Let `BoxOrderManager` do the relevant work itself and get rid of
`AppIndicatorKStatusNotifierItemManager`.
This is also in preparation to make the addition of
AppIndicator/KStatusNotifierItem items work again.
Simplify `#overwritePanelAddToPanelBox` heavily by just calling the
original function in the overwrite and ordering the top bar and handling
new items afterwards.
Note that AppIndicator/KStatusNotifierItems are still not supported with
this refactor.
Introduce new `BoxOrderManager` to basically act as a heavy wrapper
around the box orders stored in settings, so that the other extension
code has easy methods to get, set and interact with box orders.
Refactor most of the code initially with it in mind.
Note that `#overwritePanelAddToPanelBox` needs more refactoring to
properly make use of that new idea (and it also needs refactoring in
general).
There are situations, where no `associatedRole` for a given
`indicatorContainer` can be found (e.g. the GameMode GNOME Shell
Extension seems to cause such a situation, when you have it enabled and
lock and unlock GNOME).
Previously this would crash the extension. With this fix, those
`indicatorContainer`s just get ignored.
There was an issue where, when you started Gnome Shell, the icons
weren't corrently ordered. It seems that this issue was caused by a
combination of the following two things:
1. When determining the insertion index in `determineInsertionIndex` (in
`getPositionAndBoxOverwrite` in `_overwritePanelAddToPanelBox`) the
`boxOrder` got set to `boxOrders.something`, which doesn't make much
sense considering that the `index` was determined by using
`resolvedBoxOrders.something`.
So set `boxOrder` to `resolvedBoxOrders.something` instead, to obtain
an `insertionIndex`, which makes sense.
2. Ordering the `right` panel box from right to left (in
`_orderTopBarItems`) seemed to cause issues (, which are probably
caused by the indices not making sense with the children box counts
at insertion time).
Therefore and also because the regular (left-to-right) ordering seems
to work just fine even for the case described in the comment (, which
provides the reason for right-to-left ordering,) just use regular
ordering for all boxes.
Fixing these two things may also fix other incorrect ordering behaviour
at other times.
Previously the `panelBoxChildCount` would just be the child count of the
right box before new items got added, which would result in incorrect
indices for new child insertions being used (in
`panel.insert_child_at_index`), since `panelBoxChildCount` would just
account for the current children, not for new ones.
This resulted in the following issue:
When you used the settings to move an item from e.g. the middle box to
the right box, the right box would get ordered incorrectly.
So fix this issue by getting the max of the right boxes current children
and the `validBoxOrder.length`.
Move the logic for the creation of special box orders
(`createValidBoxOrder` and `createRestrictedValidBoxOrder`) into an own
class.
Moving this logic into an own class makes the `Extension` class lighter.
Move the AppIndicator/KStatusNotifierItem logic
(`handleAppIndicatorKStatusNotifierItemItem`, `createResolvedBoxOrder`
and `_applicationRoleMap`) into an own class.
Moving this logic into an own class makes the `Extension` class lighter.
Introduce for the new file a new directory `src/extensionModules`.
Fix the following issues:
1. Let's assume we have a default (reduced) Gnome Shell top bar like
this:
- left box: activities, appMenu
- center box: dateMenu
- right box: keyboard, aggregateMenu
And now assume, we changed the (reduced) configured box orders to
define the top bar like this (while the extension wasn't running for
this test case):
- left box: activites, keyboard, appMenu
- center box: dateMenu
- right box: aggreateMenu
Now for the old version of this extension, the following would
happen:
The extension would put the "keyboard" into the configured right box
order on extension start, despite it being already in the configured
left box order.
This would happen, because the extension would look at each box
individually at startup to determine if new items should be added to
its box order.
And therefore it would add "keyboard" to the configured right box
order, leading to the (reduced) corrupted box orders looking like
this:
- left box: activites, keyboard, appMenu
- center box: dateMenu
- right box: keyboard, aggreateMenu
And then, since the extension orders the top bar initially on start,
the extension would put the "keyboard" item into the right box (since
the right box would get ordered after the left box).
(And even if the config situation were different, so that the
originally configured box would have been ordered after the wrongly
configured box, the configured box orders would have still been
corrupted.)
Fix this issue by considering all top bar boxes in
`_createUpdatedBoxOrder/s`.
2. Let's assume we have the default (reduced) configured box orders like
this:
- left box:
- center box:
- right box: appindicator-kstatusnotifieritem-KeePassXC
And now assume, we changed the (reduced) configured box orders to
define the top bar like this (while the extension and the
"KStatusNotifierItem/AppIndicator Support" extension weren't running
for this test case):
- left box: appindicator-kstatusnotifieritem-KeePassXC
- center box:
- right box:
Now we would first start this extension and then the
"KStatusNotifierItem/AppIndicator Support" extension.
For the old version of this extension, the following would happen:
The extension would have put the KeePassXC
KStatusNotifierItem/AppIndicator into the configured right box order
and the right box, leading to the (reduced) corrupted configured box
orders looking like this:
- left box: appindicator-kstatusnotifieritem-KeePassXC
- center box:
- right box: appindicator-kstatusnotifieritem-KeePassXC
This would happen, because the logic for the `Panel._addToPanelBox`
overwrite assumed that the new item should be added to the box the
item addition initiator requested (even tho the item might be
configured to go into another box).
Fix this issue by considering all top bar boxes for the
`Panel._addToPanelBox` overwrite.
One can see based on those two test cases, how those two issues create
problems.
So fix the issues as explained above and fix them together in this one
commit, since they are related.
Move the creation of an updated box order into an own method, so that
this method can be used elsewhere in the future to easily get an updated
box order.
Handle AppIndicator/KStatusNotifierItem items differently (and better)
for the following reasons:
- These items have a role, which isn't very helpful for identifying the
associated application.
- These roles seem to be different for each application run.
- There can be multiple AppIndicator/KStatusNotifierItem items for the
same application (multiple instances of that application running).
Overwrite `Panel._addToPanelBox` of Gnome Shell `js/ui/panel.js` with a
custom method, which handles top bar item additions to make sure that
they are added in the correct position.
Move the valid box order creation into an own method.
This makes the `_orderTopBarItems` method cleaner and allows other
methods to easily create valid box orders as well in the future.
Introduce box orders, which allow this extension to save the order top
bar items should be in.
On extension enable, save new top bar items to those box orders.
I'm using version 1 for the first development phase (like what major
version zero (0.y.z) is in Semantic Versioning 2.0.0), so that the first
production version then gets version 2.
