1 |
Am Sun, 9 Apr 2017 23:40:15 +0200 |
2 |
schrieb David Haller <gentoo@×××××××.de>: |
3 |
|
4 |
> Hello, |
5 |
> |
6 |
> On Sun, 09 Apr 2017, Kai Krakow wrote: |
7 |
> >Am Sun, 9 Apr 2017 19:09:23 +0200 |
8 |
> >schrieb David Haller <gentoo@×××××××.de>: |
9 |
> > |
10 |
> >> On Sun, 09 Apr 2017, Kai Krakow wrote: |
11 |
> [...] |
12 |
> >> |
13 |
> >> Tell us, why exactly would one need upower again, anyway? |
14 |
> > |
15 |
> >If you don't need it, don't use it. This was an example, not a call |
16 |
> >to use it. |
17 |
> > |
18 |
> >It reports battery status of peripherals for me. |
19 |
> |
20 |
> Surely, there must be other apps to report this for you, besides a |
21 |
> mem-hogging behemoth, that (I guess) actually does not much more than |
22 |
> 'cat /sys/...something'! .5 Gig or even more?? You're kidding me, |
23 |
> right? Riiigghhhhhtt????? That's just plain insane! Stuff like that |
24 |
> should run in a few KB. Or a few MB with a fancy GUI and DE |
25 |
> integration. |
26 |
|
27 |
It uses 1M of memory currently. The 512M limit I set is just a safety |
28 |
boundary. I don't actually want to limit it, but when it goes havoc |
29 |
it's as least limited. |
30 |
|
31 |
> You could probably do that with a few lines of perl/python/ruby plus |
32 |
> the toolkit of your choice (Tk, Gtk, Qt, Wx, Fltk, ...). |
33 |
|
34 |
Yes, I could probably code everything myself in tiny little |
35 |
scriptlets. But it's not worth the effort. This machine has 16G of |
36 |
memory, it can run full-blown KDE, it uses 5G of memory after fully |
37 |
booted (including two containers, mysql and elasticsearch, for devel |
38 |
purposes), and that boots in 30s from a mixed bcache/btrfs file system. |
39 |
|
40 |
> I e.g. wanted a minmal clock to have while playing movies fullscreen. |
41 |
|
42 |
That's what I have a smartphone for. I don't sit in front of my PC to |
43 |
watch full-screen movies (tho, the TV is connected to the machine). |
44 |
|
45 |
> Result: ~21 lines of generously formatted perl using Tk and a |
46 |
> bold-white-on-black (easily changeable) digital clock with a mere |
47 |
> 38x20 pixels in the right-top-corner (easily changeable). |
48 |
|
49 |
That's a nice solution if you have enough time and want to stay |
50 |
minimal on system pressure. I just want to stay minimal on |
51 |
distractions, so I don't have CPU meters and whatever always visible |
52 |
on screen. I also don't need all those fancy live graphics of memory, |
53 |
disk usage, CPU, load, whatever on the X root window. I never |
54 |
understand what's the purpose of that is anyways because I have |
55 |
multiple windows in front of it. Hence, I even have no icons on the |
56 |
desktop, just some different background images to easily distinguish |
57 |
between energy profiles: I'm using activities to switch between |
58 |
"listen to music", "watch videos/play games", "development", and |
59 |
"browse internet and other desktop activities". And I hardly use menus |
60 |
to start programs: I use the krunner search and a fullscreen launcher |
61 |
for my favorite apps. I really hate those deeply nested menu launchers, |
62 |
I want flat easy structures, searchable. During development I almost |
63 |
only use keyboard shortcuts. |
64 |
|
65 |
> Haven't implemented the "Keep on top" stuff right though yet, but ISTR |
66 |
> that should be possible too with perl/Tk. Or any of the above |
67 |
> mentioned lang/toolkit combos. And the "on-top" stuff also depends on |
68 |
> your WM in the details. |
69 |
|
70 |
That should be pretty much standardized by now, probably you could just |
71 |
call "xprop -set" from your scripts. |
72 |
|
73 |
> And anyway: 'eix batt' spits out e.g. x11-misc/xbatt, |
74 |
> x11-misc/xbattbar, x11-plugins/wmbatteries... |
75 |
|
76 |
Plain old X programs with Tk or xwidgets are exactly not what I am |
77 |
looking for. I seek a visually streamlined desktop, so I mostly |
78 |
exclusively use Qt or KDE programs excepts there's no suitable |
79 |
alternative. So, e.g. I still use gitk a lot although I found git-cola |
80 |
appealing. Still I'm doing lot of git stuff directly on the console. I |
81 |
use git-cola only for fast and easy hunk committing and visual browsing |
82 |
of current workspace status. |
83 |
|
84 |
> As I do just have a normal below-desk PC, I can't help with the |
85 |
> /sys/*batt*? stuff, but if it breaks down to basically displaying the |
86 |
> contents of some files under /sys/ then it's a piece of cake whupping |
87 |
> up an UI displaying that as e.g percent or whatever.) |
88 |
|
89 |
I have a normal below-desk PC, too, hidden inside the desk, and 6 or 7 |
90 |
years old [1]. But I use a wireless mouse and keyboard for working - I |
91 |
don't want cables and lots of stuff visible on or under my desk. And I |
92 |
want some battery warning/status for these devices, integrating with |
93 |
what I run: KDE Plasma. |
94 |
|
95 |
> Probably, I'd just have to change the "update" sub (1 line) of my |
96 |
> clock to read that /sys/-file instead of the time and |
97 |
> whoopididoooda ;) |
98 |
|
99 |
You are free to put it on github or so, I'd even be curious looking at |
100 |
it. |
101 |
|
102 |
> A fancy graphic bar would be a bit more coding. |
103 |
|
104 |
It's always nice when new features integrate easy as I can tell from my |
105 |
own projects, tho I do ruby mostly. |
106 |
|
107 |
> Oh, and have a look at gkrellm and its plugins. It might have all you |
108 |
> want already and then some :) |
109 |
|
110 |
No, I hate that. See above. Too overwhelmin, too distracting, and |
111 |
either it steals screen real estate or isn't visible anyways and thus |
112 |
no need to run it altogether. As I said, I never understood why one |
113 |
would need such fancy monitor stuff. If I feel the need of monitoring |
114 |
some status, I usually do this in a console window using CLI tools. |
115 |
|
116 |
> Now, integration in the "big" DEs of KDE/Gnome3, you're screwed. |
117 |
> Royally. But that comes with those DEs anyway. Like Gnome3 requiring |
118 |
> systemd (WTF?)... |
119 |
|
120 |
Systemd actually does a lot of things right for me, like bringing the |
121 |
system up and down reliably which sysvinit/openrc often didn't. And it |
122 |
does this fast. |
123 |
|
124 |
> But, you can still display stuff without "integration". |
125 |
|
126 |
Actually, I want integration. And I wish that the Linux desktop would |
127 |
gain a lot more progress here. I guess it's always a game of choice |
128 |
vs. integration: With Linux, you have a lot of choice but also a lot of |
129 |
competing solutions which do not integrate so well with each other. |
130 |
|
131 |
Don't get me wrong: I prefer choice and configuration over vendor |
132 |
locking, but I think that all those Linux components need to learn to |
133 |
integrate better with each other, and systemd is one big player of |
134 |
this. And by this I don't mean to lock down hard dependencies to |
135 |
systemd. But systemd provides a long needed API definition that |
136 |
everyone could implement. Depending on such an API would be okay for |
137 |
me, hard depends on systemd, tho, is not what should be done, as that |
138 |
would take away choice. |
139 |
|
140 |
> Myself, I found WindowMaker in ~200[01] and am happy as a bunny since |
141 |
> then, I think I had to change just one option _ONCE_ since then in my |
142 |
> config. One "forced" change in ~1[67] years? I'll call that ok! Sure, |
143 |
> there was new, optional stuff, but documented and often times even |
144 |
> appearing as e.g. a new checkbox in the WPrefs app. Compare _that_ to |
145 |
> KDE ... I switched to WMaker, avoiding KDE2.0! Never looked back. |
146 |
|
147 |
I used CDE on Solaris late in the 90's and always hated it. I arranged |
148 |
with using fluxbox by that time, I also tried WindowMaker for a while |
149 |
on my privat machine. Then came KDE based on Qt and it did a lot of |
150 |
things in a way I liked - and I stayed with it since then, with some |
151 |
experiments using Ubuntu and it's Unity desktop (which I kinda liked |
152 |
for some ideas but mostly hated for it's non-configurability). |
153 |
|
154 |
> PS: yes, Windowmaker was and is what I was looking for, but KDE 1.1 |
155 |
> served ok until then. And I did look at KDE2-5 and Gnome1-3 in |
156 |
> various version, no, not for me. *bleargh* |
157 |
|
158 |
Well, Plasma 5 is for me, but visually stripped down a lot, and |
159 |
configured mostly for flat colors, no window borders, and with subtle |
160 |
shadows and almost no colors (except important spots on the screen). It |
161 |
looked a lot like Win8 or Win10 for me before those were distributed, |
162 |
with some usability ideas "borrowed" from OS X (yes, plasma 5.9 |
163 |
luckily brought back the global menu bar so I could unclutter the |
164 |
windows even more). |
165 |
|
166 |
KDE 3 by that time started to become a cluttered mess, pumped full of |
167 |
stuff you never need and visually becoming too distracting. That was |
168 |
the time when I started to try other desktops. Then came KDE 4 which |
169 |
had some nice ideas but was becoming a mess and migration nightmare, I |
170 |
lived with that and stripped away what wasn't working correctly, or |
171 |
replaced it with alternatives (mostly web-based). Now, since some |
172 |
months, Plasma 5 has come into real good shape. And thanks to |
173 |
Chrome/Chromium I can run many web-based apps like normal desktop apps |
174 |
(with their own native looking windows instead of in browser tabs). |
175 |
|
176 |
[1]: Storage, CPU coolor, and graphics card has been upgraded |
177 |
since ;-) |
178 |
|
179 |
-- |
180 |
Regards, |
181 |
Kai |
182 |
|
183 |
Replies to list-only preferred. |