Hello Plasma devs! I wanted to ask this question on IRC, but nobody's there at the moment. So I'm asking here instead.
I'm implementing the option to hide the selection marker in FolderView as per the proposal from the NetRunner project. (netrunner-os.com). (I'm now working for that project, doing various KDE polish tasks. This is my first task. I will soon publish a review request for it.) I have located all the relevant code and implemented all the necessary bits but one. The Overlay buttons are in a QGraphicsGridLayout. The "Click to view" button (the lower one) uses the QWidget::hide() method in hoverEvent() and successfully hides itself. The Selection button, on the other hand, is located above the first button, and QWidget::hide() results in an **ugly gap**. Thus I have to use the QGraphicsGridLayout::removeItem() and ::addItem() instead of QWidget::hide(). Now these functions have to be called once on settings change, not every time on hoverEvent(). This means I have to implement a public method in ActionOverlay void ActionOverlay::setShowSelectionMarker(bool show); which would add / remove the button from the layout and hide it, resulting in a proper button alignment. Now if I implement this method, for consistency and symmetry, I will have to do the same for the ClickToView button: void ActionOverlay::setShowClickToViewButton(bool show); There are currently no such methods. It's done differently. Does this mean that my method is incorrect? Will my implementation break incapsulation or the existing class design? Please approve or disapprove of this proposal, as I have to finish coding this (dead simple) task soon and go forward. The other problem with FW is that following a recent commit from Aaron Seigo, the configAccepted() method no longer aplies settings, which is perfectly fine per se. But, now when we click Apply or OK, the settings are written to the disk, but are **not** applied. Tested in trunk. This needs some solution as well. Best regards, Ignat Semenov _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
