- User Since
- Feb 16 2018, 8:50 PM (4 w, 4 d)
Replaced by D11352.
Great, but I found one more bug (and it affected order of items). This fixes it.
I am using Czech translation and I am satisfied with item order (but I keep only a few items in my systray). I like the current rule because it is simple and have some internal logic (even though it might not be obvious what the text of an applet is) and it is not just a fixed random order. I would rather not implement some crazy compare function just because it has somewhat reasonable results.
- put UnknownCategory first
- treat applets with category not in the list as UnknownCategory
- split reorderItem function into two
- add temporary hack whcih allows overriding applet's category (applets with wrong category are from diferent repos, so till they are fixed I added this hack, also does not contain Keyboard and Discover applets because I was unable to find their itemIds)
Mon, Mar 19
I'm not sure that is good idea: There are already some items injected in context menus (e.g. Unlock widgets action) and looking at my panel some applets' context menus are not injected. I believe it is because they have multiple menus bound to specific parts of itself and only applet's global menu is (and can) be injected. Most notable examples are systray except the expansion arrow and task icon manager except empty space (if it has set fixedWidth I was unable to find a place in it which would show me context menu containing Unlock widget action).
Sat, Mar 17
Also do we want this or two options instead:
- no expanding: maximumWidth = preferredWidth, and
- no shrinking: minimumWidth = preferredWidth?
Replaced by D11410.
Fri, Mar 16
@mart you were very right to point out the callLater because that is exactly what was broken. The code assumed that all calls of callLater with different arguments are executed but in fact only those eith different function are, rest of arguments does not matter. I somehow managed to run an older version of patch on my machine were callLater was applied to local helper function so it worked for me...
Ok, that looks that I did screw something. Time to investigate...
I guess Phabricator does not let me only respond to inline comments.
Thu, Mar 15
I do not have write access.
@painlessroaster is not me. What gave you impression he is?
Wed, Mar 14
+1 for picture instead of blue. With the current UI I would really appreciate option to choose text color independently on plasma color scheme (and such option would solve any static picture). Other possibility I was thinking about was 50 % opaque (default black) rectangle (with rounded corners) around control elements (i.e. like logout screen but only around controls not whole screen) but I have not found the way to position it where I want it to be...
Ahh sorry I misunderstood you. Moving this option to containment level seems reasonable although I'm not sure for how many other applets it might be useful -- except taskbar and Active Windows Control (the global menu applet in my screen shot and it already has this option) all applets I use are fixed width.
I understand you do not like adding options that you do not like adding options adjust think which should be configured on another level. But to be able to configure filling empty space at level of panel applets must not claim they need more space than they really do (and now taskmanager is doing exactly that). So possible solutions I see are:
- modified onConfigurationChanged so it triggers updates of properties depending on cfg_shownItems and cfg_hiddenItems
- make trash bin not draggable
- removed ComboBox hack (which was not working anyway) and added an overlay label to combobox showing S for items in cfg_shownItems and H for items in cfg_hiddenItems (this is meant as debugging tool only) -- when dragging the visibility values in comboboxes go wrong but those letter remain correct which leads me to conclusion that the problem is ComboBox component (@wsdfhjxc can you verify this behavior?)
Tue, Mar 13
Ping. The current version adds a configuration option fillWidth (enabled by default) which allows the applet to grow beyond its preferred size. I tested it in usual setup and with fillWidth enabled the behavior is unchanged.
I am aware of getFixedItemId, only forgot to mention it in summary. Right now it is not included mostly because it is another hack (but fixing stupid behavior of someone else so unavoidable) and I do not use DropBox, but if this gets any closer to landing, we should reintroduce it.
I really like the idea of being able to reorder the systray as I wish. I could not resist and took my stab on the issue (with drag&drop) D11292.
I see that relative luminance formula is more correct but I would like to point out that we do not need here to calculate precise luminance. The point of the ?: statement is to collapse colors close to back to real black because gray overlay with 50 % opacity does not look good. So the current formula looks good enough for me and I would even think about moving the threshold down a bit to 0.4 or 0.3. (Generally not collapsing to black is the save way, it may not look so good but the text will be still easy to read.)
Mon, Mar 12
Do I need to do anything to make it land?
With dark button background as it used to
but if you choose some crazy combination (like black text on green background) it will also work (without this patch the background here would be still black)
Sun, Mar 11
I guess I am not that confused anymore -- with normal color group the color of text (outside of buttons) is determined by text color theme setting but with complementary group by button text color.
@mvourlakos I did some more testing and I am really confused. The important color seems to be button text color in Plasma theme setting. Results:
I have the same problem in 5.12.2 release. I think the root of it is assuming that foreground in PlasmaCore.Theme.ComplementaryColorGroup is white(ish) and background is dark (this is true only if normal color scheme uses dark text on light background, which is default) and forcing that background is really dark (since D5036). My personal hack is just to replace ComplementaryColorGroup with NormalColorGroup (which obviously breaks default setup). A bit less of a hack would be choosing either NormalColorGroup or ComplementaryColorGroup depending on which one has darker background.
Wed, Mar 7
Moving appmenu instead of window title.
The patch definitely can wait until you finish the rework. A few thoughts that crossed my mind when reading proposed changes:
Mon, Mar 5
Would it be better to move global menu 1px down instead?
The changeVolume helper must be in PlayerControl class and MultiplexedService must only forward calls to it in order to volume change by mouse wheel also work for other sources than only mutliplex one.
- Added OSD support.
- Refactored osd & volume bounding logic into helper MultiplexedService::changeVolume.
Sun, Mar 4
The idea crossed my mind but I rarely use expanded version of the applet and there are two problems to deal with:
Fri, Mar 2
In previous revisions I used fillWidth = false but it is wrong because it not only prevents expanding but also it prevents applet from shrinking. So use Layout.maximumWidth = Layout.preferredWidth instead. Also after further testing I do not think the option must be restricted to icon version of applet only -- with full version (and Spacer applet) it allows you to align task on right side of panel which was impossible before.
Screenshots with Global Menu applet (panel contains Global menu, growing Spacer and icon taskmanager).
Thu, Mar 1
Not really -- if I understand correctly allocating space works following way: All widgets get space they claim they need and the surplus is split among widgets with fillWidth == true in ratio which seems proportinal to width of given widgets. So even if global menu took space needed to display all menu items there still would be an ugly gap on right side of taskmanager.
Choice whether to fill or not fill width was turned into config option and i possible to set (and used) only for iconsOnly
version of taskmanager.