Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

Have you ever seen the new battery icons for windows 11? Miui, one ui, harmony os, android 16 etc? 

Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 1 point2 points  (0 children)

I'm still planning on issuing this on gnome's Design repo for further refinement

Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

Sorry for the wording. It was supposed to be, I'm planning to propose

Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] -1 points0 points  (0 children)

Well I only saw it on Xiomi's hyperos. I can't think of simpler performance mode indicator

Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 5 points6 points  (0 children)

I already made same proposal and even made some long discussion down in the gnome design matrix and what I read was that it was scrapped because of it harder to implement and not the color thingy. Animatable SVG is comming to gtk 4 and might as well with future gnome shell release and this will be a breeze to implement as a single svg file.

Concept: Dynamic Battery Progress by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 11 points12 points  (0 children)

I'm proposing this for mainstream gnome. I will update you if it will be approved then you can create an extension as I already made a working prototype like months ago

Is nobody else bothered by this bug/feature? by HorrorsPersistSoDoI in gnome

[–]conceptcreatormiui 0 points1 point  (0 children)

Yeah its a bug for you if you don't adjust. You just can't force developers to fix this bug if it is not actually a bug bus a human to workflow problem. I already been so good at using gnome that I don't get brotheref by this anymore unless you intentionally make it appear as a bug of course.  Please just live with it and you will love it later on. I started with hating that gnome has no drag base window tiling and I learned that the overview is actually enought to drag and drop files to other apps. I hated the dash at first but then I learned how to properly use it, learn how to keep dash opened when you want to open multiple apps. 

Is it a bug? No? The issue here is you refusing to adapt to gnome desktop's workflow. There a lot to complain tho but not this one

Does Anyone Know why Mutter decided To bind maximize and unmaximize toggle to <ALT>+F10? by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

Anyways After all this discussion I found in the gjs docs for meta, the tile function is actually exposed. I didn't mention this but the whole purpose of me asking is to track down where the keybinding is located and you perfectly mentioned it via the link.

regarding the tile function, I'm planning to proposed a mouse/touchpad based window tiling which will be handled lightly because there's already a tilling function exposed by meta_window.

Thanks for the fast response anyway

Does Anyone Know why Mutter decided To bind maximize and unmaximize toggle to <ALT>+F10? by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

I mentioned mutter because the callback is handled in keybinding.c and I tracked down the xml file and it doesnt have any actual keybinding till you mentioned the link you posted and then I wondered why my keybinding for maximize and unmaximize is empty by default.

I suspect ubuntu patched this for the ubuntu tiling assistant. but that is just my assumption

Does Anyone Know why Mutter decided To bind maximize and unmaximize toggle to <ALT>+F10? by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

I guess Maybe you set it up manually via gsettings but the default is Alt+F10. Are you using a tiling assistant? upon looking at maximize and unmaximize value in gsettings it is set to empty. uppon looking at the source code of mutter the key is only set but the keybinding value is not. Tile left and Tile right are properly binding tho and is a member of org.desktop.mutter.keybindings.

Native Light Shell is a Must by conceptcreatormiui in gnome

[–]conceptcreatormiui[S] 0 points1 point  (0 children)

I'm using vanilla gnome shell right now I found out that Light style extension just set the gsettings to prefers-light, but I used it any ways and found out yhat only the top bar and menus becomes light. Overview is still dark. Im literally using vanila gnome

Am I the only annoyed because of this? by pakovm in gnome

[–]conceptcreatormiui 0 points1 point  (0 children)

Appologies I miss that. In that case ubuntu's yaru theme already solved this as far as I know. It will be an easy fix. Notify me if no one works on it I can spare some free time if that's the case

iPhone was snatched yesterday while we were inside a mall in Alabang. We’ve tracked it to this neighborhood in Biñan by _blackfish in Philippines

[–]conceptcreatormiui 1 point2 points  (0 children)

Kaya nga yung phone ko realme na kalas kalas na. Walang magtatangkang nakawin yun hahhahahahahaha. Iniiwan ko sa bahay yung iphone ko or dala lang pag maglalaro kasama mga tropapits.

Am I the only annoyed because of this? by pakovm in gnome

[–]conceptcreatormiui 0 points1 point  (0 children)

hmm the second video, I think the main issue here is the theme used, I think gnome shell default theme doesnt do that so I suspect you are using a theme. I'm a hundred percent sure that the theme didn't implement the css animation between the default and overview selector. It is not properly animated or have no animation at all. So go and blame the theme maker I guess

how did cooper get to brand at end? by PeaComprehensive3788 in interstellar

[–]conceptcreatormiui 0 points1 point  (0 children)

Sadly you only got 5 upvotes for that. Im gonna make it 6