It's been a while.
Duncan wrote:
> Alex Schuster posted on Sun, 31 Oct 2010 20:51:12 +0100 as excerpted:
>>> I still have dual monitors in stacked config, tho I'm now running
>>> slightly shorter ones, standard US 1080p HD, so the overall resolution
>>> is 1920x2160.
>>
>> Cool, now this is huge! Um, are these monitors _physically_ on top of
>> each other, or side by side?
>
> _Physically_ =:^)
>
> With my last CRTs, I had a 22 inch and a 21 inch (~54 cm), both running
> at 1600x1200 (I tried 2048x1536 for awhile, but that was really
> stretching the capacities of the monitors and 1600x1200 was actually
> clearer, so that's what I ended up using), with one physically stacked
> on the other using a couple books as spacers (no stand on the top one,
> the bottom one with a level enough top to make it possible) to get the
> tilt right.
My first PC had its VGA monitor on top of my TV, physically. Nowadays,
when I can have a TV in a window on my desktop, virtually, this is no
longer necessary. Although this does not work yet, so I have the TV
besides the monitor.
> Of course, 21/22 inch CRTs weigh more than 50 lbs/25 kgs each and are
> quite bulky, so it was quite the sight to see!
Ouch! Send pics :)
> My current setup uses dual 22 inch (56 cm) LED backlit LCDs. They're
> "light as a feather" and very thin -- about 3.5 inch (9 cm) thick at the
> center but mostly about 3/4 inch thick (~2 cm).
>
> I'm using "ball joint" style mounts, actually three of them (not two),
> one on each end of a board mounting the monitors, with one in the center
> of the board mounting the board to the wall. So each one has
> independent tilt and rotate, with the wall mount enabling me to rotate
> the entire thing by 90 degrees if desired (plus further tilt), so I can
> switch from stacked monitors in landscape mode to side-by-side in
> portrait, if desired.
The latter sounds rather nice to me, that's what I just thought about
until I had read this paragraph.
> (I'm thinking about getting much bigger monitors, actually HDTVs at the
> same 1920x1080 resolution, 37-42 inch (94-107 cm), as big as will
> comfortably fit in the allotted space. These would again be stationary,
> since they're too big to rotate in the space allotted anyway as well as
> being rather too heavy and awkward to rotate at that size, but they'd
> very nicely fill my wall, and at that size, who /cares/ if they rotate!?
> =:^)
Not me. I'd liek this, too, but the budget is too limited here. It was
until last spring that I finally got a TFT. I had a big CRT running at
1600x1200, and I still miss the extra 120 pixels in vertical direction.
But 1920x1200 was too expensive.
The main problem with the CRT being gone was that the cat had to look
for another comfy, warm place.
>>> Likely as a result of the additional screen space the dual monitors
>>> gives me, I don't actually use as many desktops as I might.
>>
>> I might somehow live with only four then.
>
> Once you have the extra screen real-estate to work with, much as you
> mention with the multiple desktops, I don't believe you'll ever go back!
The problem I see with this setup is that I could no longer look over
the screen and out of the window... but maybe the top monitor could
display the output of a webcam turned to the window? Who would need a
window any more then?
> That old 19" had died by the time I switched to Linux in 2001. (I'd been
> thinking about it for awhile, but the mandatory activation in eXPrivacy
> pushed me over, ironically, given that it was supposed to be anti-piracy
> but would have pushed me /to/ piracy otherwise, since I wasn't about to
> allow MS to dictate whether I could run my desktop or not -- I've always
> said that MS was demonstrated as waaay too good a competitor to have
> even /thought/ about that sort of inconvenience for their user base,
> given they got where they were partly over earlier software requiring
> dongles, etc, because theirs didn't, so regardless of what they argued
> about monopoly in court, that move CONCLUSIVELY demonstrated by ACTION
> what they actually believed -- that they had a monopolistic lock on
> things so strong they could get away with abusing their customers -- but
> it was at that point I became an *eX*-customer!!) So by then I was
> actually running TRIPLE stacked monitors, all 17" IIRC, at 1024x768
> each.
:-)) Doesn't sound too neck-friendly though.
>> Oh, wait - I googled the yasp plasmoid, downloaded it, and found a tail
>> -f command in the yasp_scripts/systemmonitor.script file. So that would
>> be easy to change. Oh, there's a directory named duncan-yasp-scripts :)
>
> Yes, all the scripts in that dir are mine. =:^) I've updated mine
> locally a bit since, including adding one that adapts the previously
> existing syslog tail script that you found, to my own needs. (Altho
> here, I don't log-rotate the gentoo-default messages log by period, but
> rather, at boot and at shutdown, with an entry in /etc/conf.d/local that
> moves the files to boot and run subdirs. Then I clean them out
> manually, every six months or so. /var/log is a separately mounted
> filesystem, 1.5 gigs IIRC, so I don't have to worry about runaway
> logging using up all available space on the rootfs or something. But
> since I do boot and shutdown rotation, I don't have to worry about that
> --follow=name bit.)
metalog does the rotation, and I like to have one log per day, this
makes it easier for me to find things that happened a while ago.
> What's so great about yasp-scripted is that while it does require
> knowing a /bit/ about at /least/ shell scripting if /nothing/ else,
> since it uses the STDOUT of literally any command you care to run, it's
> as flexible as the number of commands one can run on the commandline!
> =:^) And if one's actually a programmer as well, so can design their
> own programs to run on the command line, not just script together
> preexisting commands, the flexibility is literally unlimited!
Sound really cool. I like shell scripting very much, it's astounding
what things you can do by combining some little commands. A little
example is another logging plasmoid that shows the output of a little
script that outputs the state of my four drives every ten seconds.
> I was suitably impressed, enough to not only create my own set of
> scripts, but to submit them to the author, so now they're shipped with
> the plasmoid as further examples. =:^) BTW, I also subscribe to the
> comment feed for the plasmoid, and along with the author, answer
> questions as I can.
> I'm not a programmer tho, only a sysadmin/bash-scripter, so I let him
> deal with that side of things.) Open source contribution, people
> contributing back according to the skills they have, at its best. =:^)
Well, maybe I'll join you there :) I did not yet install it, I first
wanted to do a little redesign of my desktop. That's done now. I had
removed plasma* and activitymanagerrc in .kde4/share/config, and started
with an empty plasma desktop. And things are much better now.
I think part of the problem was that with KDE 4.5.3 the option 'use
different activity for each desktop' in the virtual desktop settings was
replaced by 'use different mini-programs for each desktop'. So now I
have only one activity, while I had eight before. When I add lots of
activities, memory goes up, although not as high as it was.
I filed a bug and posted some updates while I changed my configuration:
https://bugs.kde.org/show_bug.cgi?id=256187
Things were fine, but then it started happening again. I was finally
able to track this down - it was the file watcher plasmoid I just
mentioned some lines above. It logs a file that contains the output of a
script that adds four lines every ten seconds, containting the state of
my hard drives. It had reached a size of 45M, and this is too much for
the plasmoid... I wonder why.
I found a workaround, the file is shorter now, and plasma takes much
less memory. Problem solved!
>> Even cooler is the feature I mentioned that allows to group windows
>> together.
>
> I've seen the window grouping feature mentioned, but apparently, it's
> not implemented in my chosen window decoration (kde2), so I don't use
> it. I did try switching to a dec that allowed it, but didn't find it
> all /that/ useful for my work flow, and found the limitations (likely
> early implementation bugs, to eventually be worked out) like the fact
> that kwin won't remember the un-grouped window size and return to it
> when a window is returned to un-grouped, rather more frustrating than
> the level of benefit it brought me, at least in the short term
> trial. So I returned to my old config.
I did not notice this as I never ungroup the windows. For the browsers,
it's just like having tabs not in a single row, but in three rows.
But you are right. I found https://bugs.kde.org/show_bug.cgi?id=217763 ,
you might vote for this bug if you like this to be fixed.
Oh, and I found it _really_ useful to workaround a problem with
akregator, which I just started to use. I want to use it as part of
kontact, but when I quit kontact, the open tabs of akregator are not
saved. When I was about to file a bug for this, I found out that this
works fine in standalone mode. So I simply group akregator with kontact.
BTW, I made some new screenshots:
http://www.wonkology.org/comp/desktop/2010-11-11/
The Music/Movie desktop was merged with the one that was for images.
Webcomics went partially into akregator, the rest into yet another
grouped browser. desktop3.png shows this, left is the kontact/akregator
combination, at the right the grouped browsers.
The comic plasmoid went to desktop2, and did not even crash once since.
Amarok and dolphin at the right are a little small each, but when I use
them I just maximize them vertically.
> If at some point my chosen window dec gets the grouping feature, or I
> move on to something else, I'll certainly try grouping again, and
> hopefully it'll remember the ungrouped size by then, but as of 4.5.0
> or 4.5.1, whenever it was that I tried it, it wasn't something I
> really found useful, so...
Well, then there is no need to use it. That's what I like about KDE4,
it's very flexible.
> BTW, when one's already configuring almost-maximized, it's simple enough
> to also check the "no border" option, thus eliminating the titlebar
> entirely. If almost-maximized is the same size as maximized minus the
> titlebar, no actual window space is lost. Effectively, then, one ends
> up with something that operates almost like grouped windows with the >
group maximized would operate, but with a twist, there's two or three >
windows, but one is full-maximized, the other two half-maximized.
I also like some windows to be borderless. Examples are mplayer, xosview
or rdesktop, which gains a little size this way.
> Perhaps that's another reason I didn't find grouped windows as useful as
> I might have, I came up with something similar on my own, but
> something that operated a bit more in line with my own work flow.
> (That was a fresh insight just as I wrote the above. Such insights
> are one of the benefits of discussions like this -- I get such fresh
> insights often enough while writing such replies to justify the
> definitely non-trivial time spent making them! =:^)
Yeah, me too.
>> Here: AMD Athlon 4850e dual core @ 2.5 GHz.
>
> If you're dual-core, that's additional reason you shouldn't be seeing
> such a slow-down -- single-CPU really does limit things. (FWIW, that
> switch to dual-socket back in 2003/2004 was really liberating in that
> respect, and the switch to dual-cores in the same two sockets made
> things even better. But beyond quad-core, at least until better use
> of real multi-threading designed for multi-core becomes much more
> common, going above 4 cores would I believe be about like going to 8
> gig RAM was for me, nice, especially on from-source distributions
> like Gentoo, but not something I actually use that much other than
> while compiling, etc. Above quad-core, I think most people will see
> more immediate effect by putting those additional transistors to
> other uses, bigger L2/L3 cache, arguably,on-board graphics, etc.
> Time will tell, I suppose, and we're already seeing it tho upto
> 8-core there's /some/ additional benefit to more cores, but even at
> that and certainly above that, until programming methods change, the
> extra transistor budget can IMO be better used for other things. But
> from experience, the update to quad cores is still a quite marked
> improvement that you can look forward to.)
More cores would be nice, especially for compiling with Gentoo. And also
for doing things in parallel. But the by far biggest improvement
probably was going from one to two cores. The desktop is much more
responsive now when an application hogs the CPU. But with this new
turbo-boost feature, more cores become interesting - without, peak
performance is slower for single-threaded applications.
But maybe not so much for me. I do not like to spend further money, and
I also built my system to be energy-efficient, it uses around 50W, and
is so silent you barely notice it is running. As long as quake3 runs
fast enough, and the desktop environment is fast, it's okay for me.
>> Wow, that's a difference. I have swappiness=20 already. I will try
>> compcache (compressed swap space in RAM, just read about that), let's
>> see what this gives.
>
> I haven't tried zram/compcache/etc yet, but I've been following
> developments with some interest. I'd be interested in your experience.
It did not work yet. There's a problem with current kernels, I get ioctl
errors. I did not put much effort into this, maybe I just have to wait a
little for this to be fixed. I'm still interested inthis, but currently
I have nearly no swapping, so it's not that important any more.
> Meanwhile, something I didn't mention earlier, as it's obviously not
> your problem, but it /does/ change the dynamics of swap and is one
> reason I use swappiness=100:
Oh, 100. Wow.
> I'm running four same-size hard drives, using md/kernel RAID. Most of
> the system is RAID-1, with stuff like the portage tree RAID-0, since
> I'm a bit squeezed on space (they're only 300 gig drives) so the 4X
> size increase over RAID-1 for that is useful, and it's easily
> downloaded again if the RAID-0 dies anyway, so redundancy isn't
> really needed.
>
> For swap, tho, I use four equally sized partitions, one on each drive,
> using the priority= option set equal for all of them. What the kernel
> does in that case is automatically stripe them as RAID-0, but without me
> actually configuring them as RAID-0. So I effectively get 4X drive
> speed on my swap. =:^)
I have two identical drives, the 2nd drive being only for backups. I do
incremental backups with rdiff-backup, and because I use LVM for
everything I can do the backup while the system is running, even while
installing stuff. I wrote a large script to automate this.
When my system drive started failing, I only had to boot from CD and
exchange the names of the two volume groups and reboot, and the system
was running fine again.
I also had swap on both drives or only on the 2nd one, but now I prefer
to have the drive spun down to avoid noise. The system drive is mounted
in some rubber bands to make it silent, the backup drive is not. There
are two also two more old PATA drives, but they are seldomly being used,
and also are spun down.
> When I set that up, I realized that it was now faster to read/write swap
> than it was to read data in from the mainly RAID-1 main storage, so
> swappiness=100 to encourage the system to actually use swap instead of
> dumping cache and having to read back in the data that it dumped from
> cache, made a lot of sense! =:^)
I'm impressend.
> But your case is definitely abnormal, because you've got a memory hog
> that's throwing everything off. I can't say for certain as your usage
> is enough different than mine to not be directly comparable, but a
> gig resident for plasma-desktop... I'm betting there's a bug you're
> hitting there SOMEWHERE!
Right, and I'm glad I found it. Memory usage was at 1.7G already.
And still, the system performed quite well. It used very little swap,
and if I started more stuff to force swapping, I did not notice it much.
Before, it felt as if it would swap out stuff that would be needed right
again. When I start my Windows in vmplayer, this is fast now, while it
took minutes before to start up. So there was another problem apart from
the file watching plasmoid one.
I also heard good things about Qt 4.7, it is said to be faster, and
maybe I see this effect.
>> I don't like flash, but I don't want to miss it either, so I have it
>> activated :-/ nspluginviewer often takes lots of CPU, so I kill it
>> regularly. The red circles with the white X inside on my desktop are
>> for this. I press this about a dozen times a day.
>
> That sounds like a hack I'd do. =:^) Actually, a few years ago, back in
> kde 3.5 era, when it was just beginning to use xorg's composite
> extension, for a release cycle or so there was a bug that I ended up
> working around in a very similar way. I forgot what it was called,
> but kde's composite helper would cause X to eat more and more memory
> (memory leak, the same issue I suspect you're experiencing
> elsewhere), until it would run into a ulimit I'd set and crash.
>
> But well before that happened, things would start getting wonky, and
> after I figured out what whas happening when things started going
> wonky, I'd hit the magic killall icon, triggering the script I'd
> setup to kill kde's composite helper and bring things back to normal.
>
> Great minds think alike. =:^)
:-)
I have to improve my 'killall nspluginviewer npviewer.bin' somewhat.
Chromium seems to handle flash differently, I have to also kill the
process that has the
--plugin-path=/opt/Adobe/flash-player/libflashplayer option.
Or I will just go back to konqueror.
> OK, you definitely have some sort of memory leak or the like with
> plasma-desktop 4.5.2, then.
>
> To help isolate the problem, did you change CFLAGS or gcc versions
> between 4.5.1 and 4.5.2?
No.
> Sounds like chromium is working well for you, then. =:^)
Sort of. But I think I will drop it, so I do not have to manage
bookmarks in two browsers. And I added some menu entries, like for
downloading videos with my download script.
[konqueror focus bug]
> Meanwhile, however, yes, I experienced what I believe to be the same bug
> myself. It's fixed, and oh, the relief! =:^)
Aaah, yes, THE RELIEF!
> In my case, the problem seemed to occur most frequently when I hit the
> middle mouse button, pasting into a text input box or the like. After I
> figured that out, I simply tried not to do that, thus making the problem
> at least survivable until the upgrade that fixed the issue.
I think I mostly experienced it when scrolling with the wheel.
>> I'm thinking about going back to konqueror, which I still like more.
>> But what I like about chromium is that it saves all open tabs when
>> logging out, and when I restart it, all is as it was before.
>> Konqueror does something similar in KDE4, when I log into KDE I am
>> asked whether I want to restore the last session. But it does not
>> work that well, and it would open konquerors additionally to the
>> ones saved in my session.
>
> Look for KDE's session management features to become MUCH more common
> (and MUCH less buggy in implementation) over time, as it's one of the
> *BIG* focuses of the plasma project at this time.
Finally. I am missing this since ever. Whatever system I used, the were
always some problems. Like certain applications that I had to position
mamnually where I liked them to be.
With KDE4, this works quite well most of the time. But sometimes saving
of a session fails. And for the folder plasmoids, they tend not to
remember their size and position. It usually takes some logout/login
cycles until they are remembered. I found this bug:
https://bugs.kde.org/show_bug.cgi?id=236768
Oh, and just antoher problem happened: KDE crashed (this happens on a
daily basis now, not sure what is responsible for that, I see nothing in
Xorg.0.log), of course that was aminute before I was about to save ma
session. At relogin, one konqueror was not opened. I did not notice this
and saved the session... now I have to dig aroudn in a backup of my
.kde/share/apps/konqueror (I guess) andlook for URLs.
> Their vision
> involves merging session management with activities, such that each
> activity will know the apps that were running in it, and
> automatically restart them when it is activated. (BTW, that's one of
> the reasons they don't want activities tied to desktops too strongly,
> their vision involves apps on all the desktops, with the session save
> and restore linked to the activity, not the desktop.)
Hmm, I read something similar I think. Don't know what to think about
this. And I don't know it this whole activity thing is something for me.
Looks to me this is more for people who do not use many virtual
desktops. But I think I will add another one just for fun, and who
knows, maybe I find useful applications.
>>> 2) I'm running gcc 4.5.1 here, with --as-needed in my LDFLAGS (it's
>>> there on Gentoo by default now, but that's a rather new change so if
>>> you've not done a full emerge --emptytree @world in awhile...).
>>
>> I'm using gcc 4.4.5 and have --as-needed in LDFLAGS, but while I do
>> @world updates quite often, I never used --emptytree on this system. I
>> Installed it in June when I went from i686 to amd64, using gcc 4.4.4.
>
> Well, if you installed with gcc 4.4.4 and are on 4.4.5 now, then unless
> you did it for other reasons, there's really no need to have done an
> --emptytree yet, since that's just a bugfix upgrade in any case. If
> you'd started with 4.3.x and were now on 4.4.x, however...
BTW, recompiling the whole system with 4.5.1 did not change much.
> I guess that answers the question I asked above about gcc version, tho.
> But changes in cflags might still be an issue. And while we're on the
> topic, what about revdep-rebuild? FWIW, I run it as part of the process
> after every upgrade. (I also always use --update --deep --newuse, and
> run --depclean afterward, as well.)
I run it from time to time, but since the preserve-libs exists, it is
seldomly needed.
> BTW, the thought occurs to me... if 4.5.1 was reasonably fine, but 4.5.2
> is so bad, for whatever bugged out reason, what's the possibility of
> going back to 4.5.1? If you use FEATURES=buildpkg, you likely even
> still have the binpkgs around, and can do the downgrade without
> having to recompile anything. (I'm on record multiple times as
> stating that FEATURES=buildpkg is my favorite underused portage
> feature, for a whole list of reasons I'll skip ATM, but they're
> certainly more than simply the rollback ability we're talking here.
> =:^)
Of course I have buildpkg enabled :) I guess in case of such a minor
downgrade it should be safe, but I'd still fear that some config option
were introduced in 4.5.2 that 4.5.1 did not yet have, and even more
obscure problems would arise.
> Seriously. 4.5.3 will hopefully have fixed the issue, or 4.6 if it's
> something inherent in where they took 4.5, and in the mean time, 4.5.1
> is still the 4.5 feature series, so unless there's another bugfix in
> 4.5.2 that you can't live without, why not revert, temporarily?
Because 4.5.3 is out :)
I have it runnng now, and there also were Qt and X.org updates. The
system fells much faster now.
>> But hey, why not, my system is running all the time anyway, so even if
>> it slows thinsg down, I can let it compile while I am sleeping. I heard
>> sone good things about th enew gcc, but thought I'd wait until it is
>> considered stable. But when your experiences are good, I'll give it a
>> try. So, I would add the graphite USE flag, and add -floop-interchange
>> -floop-strip-mine -floop-block to my CFLAGS? I just read that (again)
>> in a thread on gentoo-amd64, you were involved there, too :)
>> Not sure if I also should add the lto USE flag and add -flto to
>> CFLAGS as also sugestend in the thread.
>
> I'd recommend a bit of caution there, especially since you have an
> existing bug you're trying to work out. Yes, upgrading to gcc 4.5.1 is
> a reasonable thing to try (especially since gcc-config allows
> switching between gcc versions), and recompiling all of kde with it.
> But I'd be a bit cautious about trying new CFLAGS that may introduce
> new bugs. It seems you've got a load on your plate there already.
> As you no doubt noted from my post to that thread, I did a straight
> across switch, not changing any CFLAGS at all. It worked well for
> me, and I can always try the new flags later if I want to, but at
> least now I know for sure that any problems it might bring are
> related to the new CFLAGS, as the system builds and functions fine
> with the old ones. If you upgrade gcc and change CFLAGS at the same
> time, you do save an extra rebuild with the new CFLAGS if everything
> works, but if something goes wrong, you don't know which it was that
> caused it, the new gcc, or the new CFLAGS. So better to do one at a
> time. That's my experience and recommendation, anyway.
Yeah, I kept the flags as they were.
But now that everything still works, I'm curious if I should try some of
the more fancy flags.
>> ATI Radeon HD 3200
>
> Well, we know it's not the known Intel graphics issues, then... but
> there's (less severe) known Radeon freedomware drivers issues as well.
> But the latest graphics stack is said to resolve some of that, and with
> a single issue I'll describe below, there's a couple effects that
> don't work quite right or at all, but I can keep them disabled, and
> no further issues.
There is the 'blur' effect which ate half my CPU cycles, and I did not
even notice a difference.
> But back to your case. It's quite possible that later versions of
> xorg-server have fixed whatever it was you had trouble with. Also note
> that it's switching to udev from hal for input-hotplugging. The result
> is that you configure that in xorg.conf once again (instead of having
> to edit extremely obscure xml based hal fdi files, I'm DEFINITELY
> glad that's over with!), using a slightly different syntax than the
> previous input-device syntax used.
I only have my xorg.conf, never did anything with HAL there.
> Also, 1.8 adds /etc/X11
> /xorg.conf.d/ directory support. Basically, instead of a single
> xorg.conf file, you now can split it into multiple files located in
> this dir, making configuring MUCH easier! So if you can possibly
> switch to at least xorg-server 1.8, it's worth doing so. I'd try
> both the 1.8.2 and 1.9.1 that are in-tree. Hopefully one or the
> other works.
Well, I had tried 1.8 and 1.9, neither did work. I will try again when I
have some time.
>> I'm using tuxonice-sources-2.6.34-36. Oh, Tux On Ice. Another of these
>> things I put some time into, and that just don't work well. But this is
>> the wrong list for this.
>
> I'd also consider upgrading to 2.6.35.
By 2.6.34-36 I meant I use all sorts of kernels from 2.6.34 to 2.6.36 :)
> Note that the bug above does not
> affect 2.6.35 itself, but it DOES affect stable series 2.6.35.1 and
> beyond, and 2.6.36. Very possibly you won't have the bug, especially if
> you graphics are on PCI-E, not the AGP mine are, in which case
> 2.6.35.whatever or 2.6.36 will hopefully work for you as well. Of
> course, if you're on AGP and see that bug above, I'd certainly
> appreciate a second report of it added to my bug filing.
My card is on-board and probably not AGP. No problem here.
[comic plasmoid crashes]
>>> What I suspect but haven't yet verified is whether masking
>>> ~cairo-1.10.0, thus forcing a downgrade to cairo-1.8.10, suddenly
>>> resolves this bad comic- strip-plasmoid crashing issue!
>>>
>>> Perhaps you could try it and see?
>>
>> I did so and logged out and in into KDE. I tried all the comics,
>> including the 'Perls Before Swine' compic that never showed something
>> (BTW, could you try if this one works for you?), looked good. But then,
>> it finally crashed after some more playing with it. That is,
>> plasma-desktop crashed, not only this plasmoid.
>> BTW2, another annoying thing is that it doe snot keeps the size I give
>> it, and gets really small when I change the comic. I always view them
>> with the middle mouse button.
>
> So you were able to eventually make it crash, but it wasn't as sensitive
> to crashing as it seems with cairo-1.8.10?
>
> I guess I'll have to roll back cairo myself, and see if it helps me too.
> If it does, we're likely onto something!
Since I re-created the plasma stuff from scratch, I did not have a
single crash of the comic plasmoid. I will go back to the newer version
of cairo, and see if it will crash again.
>> Well, many many thanks for your large mail and the ideas! At least it
>> will give me an improved syslog monitor :)
>
> Yeah. If you find yasp-scripted even half as useful as I have, you'll
> soon find you don't want to do without it! =:^)
[superkaramba]
I also did not use it yet, although I heard about it a long time ago. I
had it installed once under KDE3, but I would have had to configure some
stuff, and did not take the time to do so. Well, maybe soon.
On the other hand, I'm quite satisfied at the moment. The tail -f
--follow=name thing would be nice, I added some comment to
https://bugs.kde.org/show_bug.cgi?id=203956 , maybe it will be changed.
And I would like the syslog plasmoid to have multiple tabs.
Wonko
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
