Hey, first KDE contribution here. I was digging through code trying to fix [bug 427530](https://bugs.kde.org/show_bug.cgi?id=427530) when I found this copied-and-pasted block in LayoutManager::save(). This MR moves the block into a lambda to remove code repetition.
I am not a C++ programmer and although nothing changed that I could notice, it would be smart to sanity check and/or test this before merging.
--new introduced external spacers of main layout are
used from parabolic effect in order to keep the contents
of main layout in balance. That produces a much better
visual result for the user because when the user hovers
an item, that item is zoomed and the mouse is still
present at first hovered position.
When trying to compile the new Multiple Screens feature released yesterday I got this error on KDE neon:
```bash
[ 83%] Building CXX object app/CMakeFiles/latte-dock.dir/lattedockadaptor.cpp.o
[ 84%] Linking CXX executable ../bin/latte-dock
/usr/bin/ld: CMakeFiles/latte-dock.dir/view/clonedview.cpp.o: in function `Latte::ClonedView::translateToClonesOrder(QList<int> const&)':
clonedview.cpp:(.text+0x1aaa): undefined reference to `Latte::ClonedView::ERRORAPPLETID'
collect2: error: ld returned 1 exit status
make[2]: *** [app/CMakeFiles/latte-dock.dir/build.make:2270: bin/latte-dock] Error 1
make[1]: *** [CMakeFiles/Makefile2:1806: app/CMakeFiles/latte-dock.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
```
After some research I found this StackOverflow answer:
https://stackoverflow.com/a/3026148
Which referenced this FAQ by Bjarne Stroustrup:
https://www.stroustrup.com/bs_faq2.html#in-class
In summary, if a `static const` is initialized in a class, and later is used as a reference in an implementation file, it should also be declared inside the implementation file. The initialization can live only inside the class.
Maybe the compiler used by @mvourlakos has an optimization to overcome such construct.
In my case by adding these two lines I could compile it on KDE neon (after fixing the first error, compilation failed on a second spot).
--This is a HUGE FEATURE and so important for multi-screens
users. It is introduced as one single commit because it
reimplements plenty of infrastructure changes and it will
be easier to identify newly introduced bugs.
--Users can now choose for their docks and panels to belong
at various screen groups. The first two screen groups introduced
are AllScreens and AllSecondayScreens. In the future it might
be possible to provide CustomScreensGroup that the user will
be able to define specific screens in which a dock or panel
should be always present.
--Current solution specifies an Original dock or panel and clones/copies
itself automatically to other screens. So docks and panels in other screens
are just real docks and panels that reference themselves to original
docks and panels.
--Clones are destroyed during layout startup and are automaticaly
recreated. It is suggested to export your layouts through the
official Layouts Editor in order to share them because in that case
clones are not included in the new generated layout file. If in any
case you do not this and you share your layout with any previous
versions then your clones will just appear as separate docks and
panels that belong to specific screens.
--Automatic syncing was introduced in order to keep up-to-date
the configuration of Original docks and panels with their referenced
Clones.
--Automatic syncing currently works for all docks and panels settings,
for all normal applets configurations and for all subcontaiments
configuration such as systrays.
--Automatic syncing does not work for applets inside subcontainments
such as Group Plasmoid. In such case it is suggested to configure
your applets inside your Group Plasmoid in the original dock or panel
and afterwards to trigger a recreation for the relevant clones
--Manual recreation of clones is easily possible by just choosing
the dock or panel to be OnPrimary or OnSpecificScreen and rechoosing
afterwards the AllScreensGroup or AllSecondaryScreensGroup
--the new code is more consistent and calculates the
appropriate place to add an applet much better
based on the distance that dropped applet is
having with each layout.
--this way a layout designer can force to its users
the desired color palette for each dock and panel.
BeCareful: designers should be very careful with this
because they take responsibility to disable latte auto-coloring
at per-applet basis in order for chromatic applets to NOT
be autocolored from latte because they already provide enough
contrast.
BUG:435714
--provide addAppletItem function
--provide reorderSplitters in Start and End
layouts when an applet is added in them and
the splitters are moving in faulty position
--when an applet is not loaded properly is removed
from its registered order
--when an applet is loaded properly but is not found
in the registered order is at in the end of the stack
--improve types and references and add types splitted
at better places. So now we have
- LatteCore.Types that are global for all components
- LatteTasks.Types that are private to tasks plasmoid
- LatteContainment.Types that are private to latte
containment
Amy Rose
Michail Vourlakos
Rodrigo Pedra Brum
Alexander Lohnau