Alex Schuster posted on Sat, 13 Nov 2010 23:57:41 +0100 as excerpted:
> Duncan wrote:
>
>> Alex Schuster posted on Sun, 31 Oct 2010 20:51:12 +0100 as excerpted:
>
>>>> I still have dual monitors in stacked config, [total of] 1920x2160.
>> 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.
With my work style and the space available, stacked landscape works best,
with the bottom monitor as I described, my "work" monitor, while the top
one is auxiliary/overflow windows, and of course the top third of it the
big sysmon panel, mostly full of yasp-scripted plasmoids. But sometimes,
if I'm viewing something full-display (both monitors), the horizontal
division at the half-way point is simply in the wrong place, and flipping
the normally stacked landscape pair on their side and doing the necessary
xrandr orientation switching, so it's side-by-side portrait orientation
and the split is now centered vertically instead of horizontally, just
until I'm done with that task, helps.
>> (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.
I like cats, but their dander definitely doesn't like me! I'm terribly
allergic to it, to the point that I now carry antihistamines with me, and
if I'm visiting and notice that they have cats (or if I start itching
regardless of whether I see cats or not, as that's the stage before the
full blown thing hits and I generally end up sick for a couple days), I
take one (or a half or third of one), preventively. I've noticed that if
I get it BEFORE the reaction really sets in, I can take a third or a half
of one and be fine, but if I wait, sometimes as little as 15 minutes
longer (maybe we're watching a movie and I don't want to interrupt, or
something), I'm sick a couple days and it usually takes 2-3 full
antihistamines layered on top of each other (overlapping effective time)
to get things back under control, after which I can cut back to just a
single dose again, as the overlaps expire.
But I can and do still really enjoy the I can has Cheezburger plugin for
the comicstrip plasmoid! My virtual cats! =:^)
Meanwhile, on the bigger ones I've decided to wait and see what's
available over Black Friday and the Christmas season. I really want 42"
LEDs, 1080p of course, but they're running $600-700 each low end, $1200+,
likely plus tax and/or shipping depending on where/what I buy, for two,
which is about $200 more that my budget allows. LCDs (CCFL backlit) are
available for $400-450 each, but they're crap until about the mid-$500s,
at which point I might as well pay the $50-ish extra and go full LED, thus
getting the better quality of LED and not having to pay for the extra
energy use twice most of the year. (It's Phoenix, where it's not entirely
uncommon to run the A/C an hour or so mid-day even in January, and the
lows run 35C/95F in August, so the A/Cs are on 24/7 then, so the extra
energy used to run CCFLs is paid for twice, once to run them, once to dump
that excess heat outside with the A/C, so the common Energy-star-5 rating
of the LED units REALLY makes a difference, here!)
But it seems the (CCFL backed) LCDs are being phased out in favor of the
LEDs, and I strongly suspect that the price of both will continue to drop
over the medium term. If I don't see a deal I can't pass up (roughly
defined as $350/unit for non-crap LCDs or $500, /possibly/ $550/unit on
LEDs) on one or the other over the holidays, I suspect I'm likely to in
the after-Christmas clearance and pre-Super-bowl sales in January. If
that doesn't happen, I'm almost certain it will by /next/ Christmas.
(There /is/ one potential wrench to be thrown in the gears, what China
does with its rare earth exports between now and then, that could up the
price on stuff like this, but given how much is already made in China in
which case it'd be in a finished product before export and it shouldn't be
a /big/ issue.) But by January my budget may well accommodate that extra
$200, even if prices don't come down -- as long as they don't go up.
Meanwhile, I want them as close together as possible, and I won't use the
speakers at least on the top one, so given that the speakers are often
most of what's in the extra height on the bottom bezel, once I figure out
that I like them suitably well that I'm likely to keep them, I'll likely
(literally) hack the speakers out of the top one, allowing me to
(literally) hack the bezel down in size, thus shrinking the distance
between monitors (and the total height) by 2-3 inches. The other
consideration for LCDs is venting the additional heat when one is so
closely docked to the other and the heat from one is effectively rising
into the other. That's a big reliability concern for LCDs, while LEDs are
lower energy/heat enough that it's not really a factor. That's actually
what's giving me the flexibility to do 42", without which, I'd probably
have to stick with 37" or 40".
> 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?
LOL! Typical geek thinking. =:^)
>> So by then I was actually running TRIPLE stacked monitors,
>> all 17" IIRC, at 1024x768 each.
>
> :-)) Doesn't sound too neck-friendly though.
Well, yeah, but considering that the top one was mostly status monitors, I
didn't actually spend a lot of time looking at it, but rather glanced at
it from time to time, it was effectively two working monitors, with the
third one just there to get everything I wanted constantly displayed out
of the working monitors. (Again, that's basically the same thing I do
now, but with the bigger/higher res monitors, it's only one working, and
the other split in half between aux and the status monitors.) And two 17"
stacked isn't /that/ big a field of view to be staring at for long periods.
>>> 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. =:^)
BTW, the long screenshot with a whole row of them running is all of them
running...
> 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.
Yeah. My solution does a mv and syslog-ng sig-reload as part of the local
service script, which of course is after *, so last. That effectively
gives me a boot log (plus the run-log of the previous session if it
crashed instead of normal shutdown). And I do the same thing, except
without the syslog-reload since it's shutting down momentarily anyway, at
shutdown/reboot. The boot log is moved to /var/log/boot/ by the startup
script and the run log to /var/log/run/ by the shutdown script, with the
date attached as part of the name. So while it's not one per day, it's
one run log (plus the separate boot log) per session, and since I do
kernel testing and the like, sessions don't tend to last over a week or so
anyway, so it's reasonably well divided up, and it does indeed allow me to
look back and find things based on date, much easier. So I know what
you're talking about, for sure, tho session resolution works well enough
for me, better than arbitrary date likely would, in many cases.
> 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.
Drive state? Temps? I effectively do that using smarttemp, logging the
result. I could do similar with smartmon, but monitoring some of the
health stats, but haven't bothered. Tho if I did I'd certainly script a
conditional checking the drive temp and shutting down if they got too
high, as I lost a drive a few years ago when the A/C went out on a summer
day when it was > 113F/45C outside... let alone inside... let alone in the
computer I'd left operating, which was probably still circulating 55C+ air
around as the drive died at I'd guess at least 75C.
> I did not yet install [yasp-scripted], 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 didn't do that, but I did manually cleanout the plasmoidrc file,
deleting a few orphaned sections, etc, when clearing up the plasma-keeps-
adding-more-activities bug, here.
> 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.
Yeah.
BTW, 4.5.3 seems to have solved the plasma randomly crashing when
interacting with the comicstrip plasmoid, bug. I've not had a single
plasma crash since upgrading, IIRC. Nice! =:^)
> 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.
Well, one of plasma's problems is that it runs everything in the same
process. Apparently, along with everything else, that was just too much
for it.
> I found a workaround, the file is shorter now, and plasma takes much
> less memory. Problem solved!
Of course, using tail --follow, fed to a yasp-scripted script, avoids the
issue entirely, since you only get the configured number of lines of
output.
FWIW, to keep control a bit tighter on access to /var/log/messages, when I
setup yasp-scripted to tail it, I setup a script that does a tail -100 on
it, to be run as root. Then I configured sudo to allow my user to run
that script (passwordless) with no parameters, which should be a
/reasonable/ permission lockdown, I think/hope (at least given that I'm
specifically allowing the user to view the last 100 lines of /var/log/
messages). Then the yasp-scripted command can invoke that command thru
sudo, piping the output thru tail again to cut it down to the specific
number of lines I have space for, thru cut to cut down the columns to the
specific number I have space for... and then posting the result in yasp-
scripted.
The two hints being, (1) if the command invoked by yasp-scripted gets too
complicated, put it in a script and invoke the script with a much simpler
command, and (2), similarly, if a privileged command needs run, put that
in a script and setup sudo permissions to allow that specific script
invocation, thus remaining as conservative as possible with the security
implications.
[kwin's window group tabbing feature]
> 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.
I'm not sure I care about it that much, since I don't use the feature.
But I'm too tired right now to think straight enough to make a proper
decision (or to check how I have my votes allotted now, etc). I'll have
to think about it when I'm less tired.
> 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.
I don't use kontact, but do use akregator and kmail stand-alone, both in
the "almost full-screen" mode I described... For news (including these
lists, viewed and posted to as groups thru gmane.org), I use pan instead,
as back a decade or so ago when I tried knode, it was missing some feature
I found vital, that pan had. FWIW, I've been a regular on the pan lists
for nearly that long and believe I'm long ago the senior active list
member.
> The comic plasmoid went to desktop2, and did not even crash once since.
As I mentioned above, I've not had a crash since 4.5.3, which seems to
have fixed the issue. =:^)
> Amarok and dolphin at the right are a little small each, but when I use
> them I just maximize them vertically.
mpd (using qmpdclient when I'm in kde) for music here, as I didn't like
where amarok headed with kde4, and wanted the ability to have the music
continue uninterrupted regardless of whether I was in X/KDE or not. I do
miss amarok-for-kde3's visualizations, but not enough to want to deal with
amarok's extremely heavy dependencies again (especially now that akonadi
works well with sqlite and I've thus been able to remove mysql again),
plus amarok for kde4 had done away with visualizations when I left it,
while adding all sorts of stupid features I didn't really use or want, so
it was simply not a good fit for me any more. Not that it really /ever/
was, given the dependencies in kde3, as well, even if I tolerated them for
the visualizations, etc, at that point.
And for file management I divide my tasks into sysadmin type tasks (even
as a user, config file editing, moving files in general around, etc),
where I use the ncurses based mc in either a text VT or a konsole window,
doesn't matter, and user type tasks (almost entirely media file handling),
for which I tend to use gwenview. So while dolphin's on my system and it
does popup by default when I click on a dir in a folderview or the like, I
don't really tend to use it that much, except very transitorily to access
some function not particularly convenient directly from a folderview or
quickaccess plasmoid.
>> (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.
=:^)
> 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.
You may be pleasantly surprised at quad-core. I didn't expect it to make
that much of a difference over dual-core here, either, but it did. One
reason is because while dual-cores allows one to keep working when one
gets hogged for whatever reason, more cores allow one to be deliberately
running a CPU hog (like building packages =:^) and THEN get a runaway
process, and STILL not have a real problem with responsiveness.
Also, four cores really does seem to make a difference in general latency
and therefore responsiveness as compared to two, both under load and even
unloaded. Apparently, the Linux scheduler really takes advantage of those
extra cores to schedule mouse interrupt handling, etc, on the first
available core. Thus, the mouse laggies pretty well disappear with quad-
core, while they're still evident at times on dual-core. At least, that
has been my impression. What surprised me was just how much of a
difference it made, AND that it made it equally effectively BOTH under
load and not.
Or to put it another way, you should be able to dial back your kernel
preemption options and tick rates when you go to quad-core, over dual-
core, because the system simply won't need it as much, since the latency
to free scheduling slot on one core or another is always low enough that
it doesn't matter so much any more. Latency goes down due to more cores,
thruput goes up due to less kernel overhead, and the system gets more work
done in less time, without sacrificing perceived responsiveness to do it.
What's not to like?! =:^)
But OTOH, I can identify with the budgeting issues, and am at about the
same place here, only at a bit different level, as my computer's 2003
vintage, no PCI-E (only PCI-X), only USB-1 built-in (USB-2 on an expansion
card but can't boot from it), etc. But it does what I need it to do and
by now I know the hardware and related kernel config very well, so I'd
have a lot of work and a learning process ahead of me if I were to
upgrade, and what's there with the upgrade simply isn't worth it to me at
this point. (Now next year may change that, as the switch to EFI from
BIOS should go mainstream about next year, and along with it comes a drop
of a whole slew of legacy BIOS issues, etc, faster booting, where the
kernel's new parallel booting along with reasonable parallelizing
initscripts has the boot of the whole system AFTER the BIOS cycle taking
fractions of the time it takes for BIOS init, so cutting that BIOS init
time by something like 80% DEFINITELY sounds worthwhile!)
>> 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.
Yeah. That's exactly opposite the conventional wisdom of dropping the 60
default to 20-ish. It surprises a LOT of people, but as you see, I have
my reasons... and it actually works, too! =:^)
>> 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. =:^)
>> 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.
As I said, it works. The system has enough memory it doesn't swap a lot,
even with swappines=100, and with swap striped over four drives, swap
speed is actually tolerable, such that even reasonably heavy swapping
doesn't bring the system to its knees for the periods many people are
unfortunately familiar with.
And I really /hate/ to see all that precious disk cache I've accumulated
get dumped! So swappiness=100 really does make sense here. =:^)
> 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.
Indeed. Maybe it's that which fixed the comic plasmoid crashes, not kde
4.5.3. <shrug>
>> 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.
I've been thinking quite strongly of switching to firefox by default. My
bookmarks are all in konqueror, but that's easy enough to deal with if I
have to. But what's stopping it for the moment is that for some reason
apparently related to one of the extensions I run, firefox won't initial
start correctly in normal mode. So I wrote a script that launches it in
safemode, pauses momentarily, then kills that and restarts it in standard
mode. The start in safe mode fixes the problem temporarily and normal
mode works just fine... until I shutdown firefox and restart it again,
then it's back to failing unless I run it thru the script that automates
starting it in safe mode first...
Obviously, that's not something I want to have to wait on, several times a
day (it's only a couple seconds, but they do add up), so I'm holding off
on firefox as default until that's fixed. But with firefox 4 coming along
nicely according to reports, a day or two ago I realized that as with the
crashing comicstrip plasmoid thing, I might find an upgrade "magically"
fixing the issue one of these days -- if not as a firefox bugfix, perhaps
simply due to the extension churn that seems to come with such firefox
major-version upgrades. =:^/
>> 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.
That too, but since the middle mouse button is on the wheel (at least
here), I was never able to verify for sure whether I had accidentally hit
it while scrolling, or not. Regardless, I'm **VERY** glad to have the
thing fixed, as it was frustrating as I'll get out!
> 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)
Interesting. I'm running about as stable as they get, ATM, typically a
week between reboots, no issues, and it'd be more than that if I wasn't
kernel testing, etc.
>> (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.)
... And with the switch of the activities to widgets wording in the
virtual desktop setup applet (which I'd not spotted until you mentioned
it), 4.5.3 seems to have brought us that one step closer...
> 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.
I think it makes the most sense for people who really do use their laptop
in multiple locations/senarios, work related stuff at work, traveling home
on the train watching a movie, at home doing non-work browsing, etc, and
doing demos or troubleshooting when at a client's. Think of that linked
to a GPS or network location sensing logic, so it's automatically open to
the apps you use in that context, every time you open the lid!
But as with you, it doesn't seem to make all /that/ much sense for me,
either, tho of course the most interesting uses are often the ones we
can't predict until we stumble upon them, and this technology will
certainly open up lots of new opportunities for doing just that, so who
knows?
> I run [revdep-rebuild] from time to time, but since the preserve-libs
> exists, it is seldomly needed
Also, --as-needed in LDFLAGS helps a LOT (especially if lafilefixer is run
regularly, or as I've done with a single exception for libtool itself,
*.la files are install-masked)!
Meanwhile, I've been rather unhappy about how the preserved-libs stuff is
going. I'd rather let revdep-rebuild handle it in most cases, as having
packages own files they don't create upon rebuild can be problematic, and
there's various other issues. But even with FEATURES=-preserved-libs, in
fact, apparently /because/ I have that off in some cases, a lot of
installs force-keep a library around, mentioning in the log what specific
library I need to tell revdep-rebuild to look for now, since the files
still there and revdep-rebuild thus can't spot the problem automatically.
THUS, THIS THING IS BREAKING A PREVIOUSLY PERFECTLY FUNCTIONAL AND
AUTOMATED REBUILD SYSTEM, forcing me instead to manually read the logs and
delete the files that shouldn't be there anyway as they belong to OLD
versions of the package, so revdep-rebuild can again automatically spot
the outdated links and rebuild the affected packages, without me having to
worry about jumping thru hoops detailed in the package logs. I can see
being a bit cautious for things like gcc libs, etc, but there's definitely
a whole lot more of these things I'm having to deal with than the number
of really toolchain critical libs on the system, as demonstrated by the
fact that I can almost always simply manually remove the file and let
revdep-rebuild handle the detection and rebuilding automatically, as it
SHOULD be doing in the first place and as it USED to do just fine, before
people started trying to solve a problem that with certain noted
exceptions, doesn't exist on a sane system with --as-needed (now the
default), anyway.
> 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.
I, OTOH, would consider such micro-version testing and downgrades, when
necessary, almost routine... and buildpkg makes it so easy! =:^)
> But now that everything still works, I'm curious if I should try some of
> the more fancy flags.
Yeah, /now/ you can, if you want. I've not felt the need here, tho, which
is unusual... unless somewhere some part of me suspects there's likely to
be more issues with trying that this time, than usual...
> There is the 'blur' effect which ate half my CPU cycles, and I did not
> even notice a difference.
Hmm... "blur" didn't seem to do anything either way, here. And I'd read
about it so knew what it was supposed to do and specifically looked. I've
concluded that it must be disabled (or not yet implemented at all) in this
target hardware version (r600/700 series), which is possible, as the
r300-500 series driver is a bit more mature in some ways, possibly
including this one.
>> 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.
That's frustrating, as I've found the xorg.conf.d changes very refreshing
indeed. =:^)
> [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!
> 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.
FWIW, I'm running -1.10.0-r3 now, no problems at all. I'm not sure what
fixed it, but it's nice to not have to worry about those crashes! =:^)
> [superkaramba] Well, maybe soon.
> On the other hand, I'm quite satisfied at the moment.
Agreed, on both counts. The only way that I think superkaramba might do
better than the multiple yasp-scripteds is that it might reduce resource
usage and/or speedup the redraws since it's all a single plasmoid. I
can't argue with that for sure, but won't know until I try it.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
___________________________________________________
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.
