Features and development discussion #3
Comments
|
Yes, I noticed the border being too thin by default. In the next update it is made thicker and thickness goes up or down with size. Hope that makes it much better. Check in the next udpate once you get it. |
I think that will help quite a lot, even if you don't allow it to be tuned manually. Looking forward to the update. |
|
Update notification finally came through so I logged out when I got a chance and WWWWWOOOOOOWWWWWW.
Very minor issues, that may not even be worth looking into: If I make the OSD bigger, the first time it shows it can be partially off screen if it started at an offset 50% (edge of screen). But then the next time it is back on screen, and stays on screen. So the location is not updated until after it gets displayed once. Same when making it smaller, it will be away from the edge, then be touching the edge again on subsequent displays, as it should. Also the pill shape can display oddly the first time after changing the size. This is most obvious if you make a big change in the size. It comes out right after the first time. After the update I had to change a setting before the OSD would come back on screen. It was hidden somewhere, probably due to the change in reference points between v8 and v10. But changing a value made it pop up in the middle where the defaults were set. Might cause some confusion if you don't update the existing values to make sure the OSD appears within the screen with the new offset scheme. One thing that might make sense to change is reversing the vertical axis offset. Right now negative values push it toward the top of the screen, and that seems odd. I don't think most people will think of the axes that way. Negative horizontal means "left", so negative vertical would make more sense if it meant "down", just like a normal X/Y graph. It is tremendously improved in general. |
|
Thanks a lot for your review and appreciation! Glad you liked it. |
|
Alright, about the first time error in positioning and pill shape - good catch :). Both position and pill shape use the height/width of the OSD. Position uses it to avoid going out when placed at the edge and Pill uses to compute the curve radius. And the height of OSD , (which I query from Gnome at runtime), is dynamic and depends on the size/styling and content of OSD. This was causing an issue which should be mostly fixed in upcoming update where I have changed the ordering of these computations. Yes, this update was breaking the preset position due to new positioning system. I had put that warning in the message on Gnome extensions site as well as reddit. A lot of people had to update the settings which is unfortunate but was unavoidable. This is also the reason I don't want to further change it now unless absolutely needed. So we are stuck with up -ve. I had added tooltips last time but in next version I am also making it more explicit with a pic in settings. The next version will have some refinements in position/size logic, hopefully the first time shift thing is also sorted and there is additional feature to select only the elements that you want to see from: icon, text label, level bar and numeric %. Thank you for your detailed review, stay tuned for next update! |
|
Two things I should say right away before I forget.
What I would propose for dealing with point 2 is coming up with a less generic word to include in the name of the extension, but I realize that may not be a super easy thing to do at this stage. Alternately, the search algorithm also seems to look in the description, so if one was clever about the words included in the description...
I can understand the hesitation. Once people start using a project (like my https://toshy.app), you don't want to disrupt their settings if it can be avoided. But I don't think most users will find the inverted vertical offset to make much sense. Won't be much of a problem after the first use though, I guess. And if you have a graphic to guide the user, well... 👍🏽
Are you inside my brain? Get out of my brain! But seriously, that's the kind of thing I would try to do, to make the tuning process easier. Nice. 👍🏽 Wonder if it would be practical to have it stay on the screen for a couple of seconds and keep updating "live" while going clicky-clicky with the mouse (or holding the mouse button down) to change a value. That would be 🔥 👌🏽 👨🏽🍳 . You're obviously pretty decent at this already, but try to keep in mind ways to make your code as easy as possible to maintain in case the next GNOME update messes with how it works. If you think long term, you might surprise yourself coming up with abstractions that will keep it working more reliably over time. 👍🏽 |
Oh cool, thanks for sharing your app, looks great 👍🏽. You've a valid point, internally the screen and all widget coordinates are (0,0) at top left and increase towards right and down so that's what I had in mind. Anyway, hope the graphic now makes it clear in settings. The new version is up btw, and the test-OSD follows all the settings including hide delay to show you the effect of chosen settings. And yes, you can click-click or hold the mouse button and see results live. Great point about maintainability and right abstractions, esp. if the project grows. Initially, I didn't think about adding any features, just wanted to put it out there as I was using it locally. Thank you for your thorough review of the extension and for sharing your insights! |
|
Already grabbed the v11 update, and...
I see what you mean about the top-left (0, 0) coordinate origin. Being just an offset from that, the inverted vertical axis makes a bit more sense. Can't fault you if that made the offsets easier to deal with. The graphic explains it anyway. The label property is inconsistent, though I don't know if that is something the extension can control. Volume OSD has a text label, brightness OSD doesn't. I've always disliked putting numeric values on OSDs because they have a tendency not to stay at consistent intervals. So it would show random numbers that are just redundant with the level bar anyway. Don't suppose your extension could force the numbers into a set interval? (5 or 2, if I had a choice, or selectable between the two) Being able to hide the level bar is an interesting option. But again, I've never cared for the random numbers, so I probably won't use that unless the numbers could be forced to be less chaotic. Seems like there is a text rendering glitch sometimes where some of the characters (label or numeric %) will be misaligned internally. Mostly when the OSD is up against the edge of the screen and vertical. Could be a peculiarity of my own machine. It's hard to replicate reliably. Pretty weird when it happens, like multiple characters are being sliced through at an angle and slightly offset. Seems highly dependent on size and placement. I'm able to trigger it right now at size 36, horizontal -50.0, vertical whatever. But something tells me you may not be able to replicate it. Pulling the OSD even 0.2% away from the edge seems to always make it go away. So maybe something to do with the way you're keeping the OSD from going off the edge, or maybe just GNOME being GNOME. Or the graphics driver. Once again you've added quite a significant set of changes in a very short time. Not sure what else you could even do with it. You might have noticed I like to throw out a lot of ideas, and you pretty much nailed everything I could come up with. That's highly unusual. 🤣 🎉 🌮 🎉 (yes, that's a taco in the middle) |
|
Hmm. I don't generally mess with opacity much but I know it was working before. Just tried it and it no longer seems to have an effect at all. At either end of the scale the OSD looks the same. Can't think of anything I might have done that could prevent that from working. |
|
OK, the way the opacity works is throwing me off. Did it always only affect the background color, not the regular color? It didn't seem to be doing anything because I had box shadow on, which puts a shadow behind the whole thing. So starting with a dark color as the background, it appeared as if nothing was happening. But a light background color will get more transparent and show the shadow. So it's working, but only on the background color, and if the box shadow is enabled the window behind the OSD won't show through the shadow. Kind of confusing the way it works. The foreground/border color is the thing that doesn't change opacity. |
The extension controls how the OSD displays, the individual apps control the contents. Out of the 4 components (icon, label, level, %), the icon, label and level value is sent by the app that generates the OSD e.g. Volume, Brightness apps or Lock Keys/Caffeine etc. These apps can also limit the monitor where they want to show it. Brightness does not send any label and on my laptop it also restricts to Primary only. Similarly, apps like Lock Keys do not send level information as it is not applicable. Finally, out of all the content that is sent for an OSD, you get option to choose what to show. I did think this might need some documentation :), I will add to ReadMe when possible.
The numbers aren't random but are certainly redundant with level. Basically, the apps generating OSD send the level value (so they decide the intervals) and that same value is used to show level bar or numeric. The intervals displayed must match the internal logic used by that app.
The dreaded text glitch is here. I was hoping it is a my machine thing as you didn't yet mention it :). As you correctly figured, mostly when vertical, around edge, at particular size etc. so size and placement dependent and unreliable to replicate. Also, as you mentioned, I cannot replicate it at the settings you provided, looks good here. I wasted a lot of time trying to adjust the sizing logic (size of icon, the containers and text) to minimize this occurrence but not able to rid it completely. I figured, the main culprit is the rotation. Vertical rendering of text isn't reliable esp. if you rotate it at runtime. Thankfully, adjusting the size a bit seems to fix it generally. Let me know if it becomes too frequent, I don't have a fix but will maybe look further.
That is correct, the opacity is only for the background. This is usually how it is implemented, i.e. transparency on the background and foreground should remain prominent. The thing is, too many customization options also means that some combinations will not be good or rather many won't be good :) but there is freedom to choose. I did think it might be easier to have fewer options or restricted combinations (in this case, no opacity option on foreground) or some presets maybe but well, did not dwell much in that direction. I suppose, some detailed documentation of scenarios would be helpful. I will get to it at some point. |
|
Yeah, I figured your extension would have nothing to do with the input. Not random, but just doesn't go smoothly from 100-96-92-88, or something like that. And if you hold the key for even a tiny fraction of a second it starts repeating rapidly. The shell seems to have its own ideas about how keyboard input works for changing such settings, entirely separate from normal keyboard input settings. I would kind of like to see the ability to tune the opacity of the foreground color if that is possible, so that a really "ghostlike" OSD could be created, which with only partial opacity seems difficult. Picking a sort of "blendable" foreground color kind of simulates it, but that's not the same as real opacity with the starting color of your choice. One thing that might be helpful is to have a note somewhere about how the box shadow can interfere with how opacity affects the appearance. That really threw me off for a minute when I had black as the background color. When you have so many options to play with and some of them are kind of incompatible or might make the OSD difficult to see, what I like to see an app implement is a "Reset to Defaults" button, as a quick way to get back to normal and start fresh with trying to get the look you want. Just an idea, and about the only one I have left to throw at you. I wouldn't worry about the text glitch, just make a note about it in the README about adjusting the position slightly and otherwise forget about it. It's usually not that obvious even when it's happening. Rotated text has a long history of being a PitA, and not the tasty kind. Oh, sorry, one last idea, is it possible to set a different font for the OSD that wouldn't affect anything else on the system? Seems to be independent of the font settings exposed in the GNOME Tweaks app. When I first saw the text glitch I was kind of like, "Did they set the OSD font to Comic Sans? That's actually kind of cute--Oh, that's a rendering glitch." Whether you think allowing the user to set the OSD font to some variant of Comic Sans will lead to the godlike ascension or complete destruction of mankind is a personal judgement call. 🧙🏽 ⚡ I'll leave this open for now since you've marked it "Discussion" (which of course it devolved into pretty quickly, my fault). |
In case you want to change the interval for Volume on key-press, you can do it dconf. Go to /org/gnome/settings-daemon/plugins/sound/ or plugins/media-keys and set volume-step param.
I will get you something for that in the next update
Yeah, need to add few items in ReadMe, not sure how many will read it though. Adding a help tab is another option but I will just go with readme for now.
I like this idea, will add a reset button.
While some weirdness is sure there, the thing that I see relatively more often is like 'bleeding text'. But I saw that recently when working on a doc so seems also some issue with my display or more likely connectors.
Adding font option in settings sounds a bit overkill as there's hardly any text. But the answer to your question is 'Yes'. You can do it in the stylesheet.css file. Just add an entry like: Yes, it did turn into a discussion but an interesting and useful one, much better than developing in a silo. So thanks, and we shall meet again once I get the next update rolling :) |
Thanks, I will look into that.
Cool. 👍🏽
I put a whole FAQ in my README for now, it's quite long. And it is not obvious at all but there is a table of contents in the top-left corner that GitHub generates from the Markdown "headers" that you put in the README. But most of us barely read even the short ones. It is a good place for documentation, but your approach of adding helpful guiding info to the actual UI is a solid one. 👍🏽
Probably want to figure out issue #4 as part of that. Something is not quite right with the coordinate defaults or "fencing" on a totally clean system, that leads to the OSD immediately being off screen (and it doesn't automatically bring itself back on screen after the first usage).
This is referring to the I disagree that it is overkill. You've expended effort to make a way for users to customize the appearance of the OSD in multiple ways visually. I think it only makes sense that the font face, when there is text present, can have a strong effect on the overall aesthetic. Kind of the "icing on the cake" in some cases. And I'm not even one of those arty designer types that obsesses over fonts or themes my desktop to heck. I just think it would be fun to have a choice, and the default is kind of boring. And I may have produced a project with literally thousands of lines of Python and Bash written almost entirely from scratch, but I still find it annoying to have to look for a configuration file and edit it by hand. Go figure. 😆 🤣 |
|
Sorry, posted this on the wrong thread. Reposting here: If it's the v12 update, I already tried it out last night, but I was a little preoccupied when I was first messing with it. Fairly sure that the foreground color after the update changed to something transparent, which led me to look into the color selector, but I found that the only way to change the opacity was to get into the custom color dialog. Was that the intention? I can't recall whether there was a custom option before, I never looked for it and didn't think about it. Maybe it was there the whole time? When I go into the custom color dialog and try to change settings, it doesn't retain the color, so I have to use the color dropper to grab the existing color displayed on the main window, and then adjust it from there. Kind of awkward, but I think this might be a limitation of how the color dialog and custom color dialogs work. I was able to create a pretty ghostly looking OSD by using some transparency on the custom color for the foreground. Kind of neat. I did try to reset the settings this time, and the defaults are interesting. It's centered, with a transparent light gray background color, no shadow, and a light blue main color. Trying to show off what it can do with the defaults? Pretty good choices. What occurred to me with all these different settings to mess with is that the extension would be significantly enhanced with the ability to save a list of named presets that the user could swap between while they get familiar with everything, or presets that go with different themes the user likes to shift between. But that could be quite a bit of work. You'd have to find a way to save all the settings somewhere, and be able to load them on demand, and display the list, etc. I don't know if there's a framework for that in the code you're dealing with, that might make it easier. Or if you want to get into it at all. When I did things like that in my own code I had GPT-4 helping me put it together. If you were going to go down that road, you could also have a list of your own built-in presets that show off what the extension can do, as well as letting the user save their own. Just another one of my crazy thoughts. |
Yes, the color opacity is only through the custom color pop up. It was not available before, added in last update. It is for people who know what they are doing 👀 , like you, else some might end up making the OSD disappear. It is annoying that the color pop up doesn't retain the color, hope they fix it. Later on, if settings become more elaborate, I will maybe separate it. The presets thing is not crazy at all. It is what I meant when I mentioned presets earlier in this thread. I thought on the same lines, having some presets to show some possibilities or for people to save their own. Yeah, it will need some work not just to manage several sets of settings but also to have an intuitive UI to change, save, load presets. I have added it to future list, after font setting.
great 🔥 |
OK, so it was not my imagination that it wasn't there before. Still, the only reason I checked the custom color dialog is that you defaulted the color to have some transparency. It's a reasonable approach, to remind some users that there are alpha channel controls in the custom color dialog. Too bad about the trouble retaining the color. I ran into a lot of limitations in the color dialogs when I made an app that has a background color option, so I know what you're dealing with, somewhat. It's worse when your app is cross-desktop, because it can end up using an entirely different color dialog on a different desktop.
Oh yeah, I must have glossed over it. Will be interesting to see that, if you've got the time and patience to put it in place. Don't hesitate to use even the free ChatGPT to help put that together. It's pretty decent with simple utility code blocks.
That will be so fancy if it's part of the presets. 👌🏽 I'm not sure if this is some kind of built-in ability with the extension frameworks, but you may need to think about having generic "fall back" fonts in place in case the user's custom font choice goes missing, like you frequently need to do in CSS. A missing font file could at least raise some kind of error that you should watch out for and catch, to keep the extension from possibly crashing. But that's just a guess. And you're probably already planning on making sure that's not an issue. This thing is already fire 🔥 🔥 🔥 . |
|
Playing with v13. You're doing things even I haven't thought of or suggested. But exactly the kind of things I would do if I was playing with a project like this.
Would be nice to have access to the formatting string for the clock. I typically show day month date and then 24-hour time in the top bar, so the default formatting in the OSD comes out a bit different. The "reset" buttons have a curved arrow that resembles the Amazon "smile" graphic. That doesn't really evoke "reset" to me as much as a fully circular reverse arrow would. I actually only discovered the new weird shapes by accident, though I see it is in the tool tip. I wasn't even going to mess with the shape but I wanted to see the custom font so I kept clicking buttons, because both the brightness and volume changes show no text on this device (unless I change the audio device from the default). It's a 2011 iMac (27-inch), running Tumbleweed at the moment. Anyway, what happened to reveal the weird shapes is I was messing with the iMac through the GNOME Connections remote desktop app, and the touchpad clicks keep getting "stuck", so I noticed that the values could go past +/- 100%. The result is pretty unique. 👏🏽 It got me to check out the README ,and I saw the screenshot showing off the capabilities of the new shapes and custom font. 👍🏽 👍🏽 With this goofy click problem I feel like I wish there was a "Test OSD" button somewhere that would show the OSD without actually changing anything. Just an idea. I am fairly certain that long font names cause the preferences window to widen to accommodate the additional width of the control where the font name is displayed. Not a big deal, but you might want to give the control its own line to be on, for a bit more room. You're probably aware of this, but the font size is static and doesn't scale along with the size of the OSD, if you change the OSD size (%). Not sure what, if anything, could be done about that, since fonts can render in different relative sizes even at the same point size. Fonts are complicated. But I feel like it could theoretically be possible to apply a percentage modification of the chosen font size to keep its relative size matching the OSD size change. Last observation, the font name and size don't seem to be aligning the same way in the control where they are being displayed. Almost seems like the font name is aligned to the top of the control, while the size digits are aligning to the center or bottom of the control. Hope you're still having fun! The progress is really something to see. |
|
It's been far too long so let me add some updates here. Ah, the clock OSD format, good point. I will match the top bar format (will check) so it is consistent. I had changed the Reset button, it should be better now. Icons have a problem of not being available or not being symbolic. Font name length issue should be mostly fine now with Adwaita ui. Earlier, I kept font size static since it was set by the user, however I have changed it to alter with OSD size while trying to keep the ratio (font : OSD) similar. Also, finally published an update to save multiple profiles, Hope that helps. Alright, that's a wrap, have a good one :) |
Ah, I was about to look into that, since Tumbleweed already jumped onto GNOME 45 and the extension stopped working on that system.
The ability to customize it would probably be appreciated, even if you start it by copying the state of the top bar clock. I like to have a lot on the top bar clock, but would probably prefer a simpler time display for the OSD.
Yes, I have noticed that basically all icons can change or go missing depending on the icon theme the user installs. Tricky.
That sounds like an excellent set of improvements. |
neuromorph
changed the title
The box border can look a little jagged around the curves, on a 1080p screen, with it being so thin. And unless it's the right color it can be pretty difficult to see. If there is an easy way to make it adjustable in thickness or have any effect on how it gets feathered into the background, that could be fun to play with.
If this is too difficult to implement, not a big deal.
The text was updated successfully, but these errors were encountered: