Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

2008/5/31 Duncan <1i5t5.duncan@×××.net>:

> Beso <givemesugarr@×××××.com> posted
> d257c3560805310208o5e6df42as66e855ae009f937c@××××××××××.com, excerpted
> below, on  Sat, 31 May 2008 09:08:38 +0000:
> > the same goes for me, a kde user. i really need some gnome apps like pan
> > or firefox and just for it i need a big deal of gnome deps. and you
> > should understand what i'm saying, since you're also an experienced pan
> > users.
>
> Well, to be fair, pan and firefox/iceweasel only require GTK+ and perhaps
> a couple misc dependencies that GNOME also needs.  They certainly don't
> require all of GNOME or even most of its core.  I know, as I have both of
> them merged here, but don't have GNOME merged.  That's like saying
> anything depending on qt depends on KDE.
>
> Every so often I've toyed with the idea of switching to klibido, maybe
> knode or something else for text (thus my excitement when I read
> something implying klibido was a whole substitute for pan, now, seems
> not, unfortunately), unmerging pan, hoping to be able to kill GTK+ with
> it.  However, if iceweasel/firefox needs it as I think it does now that
> you mention it, that's not likely to work unless I decide I can also live
> without iceweasel... which actually might be reasonable once again if
> webkit continues to grow in popularity.  The only thing I've /really/
> needed it for the last few years is doing taxes, and if khtml/webkit
> eventually works properly for that...
>

well, firefox 4 would go with webkit and qt4. there's an announce from the
firefox project director. gecko is unmantainable and veryyyy slow, so the
only one who will continue to use it would be iexploder. also the new qt4
utils and the ability to build an app that runs cross platform with much
less work would be quite interesting. and now maybe also openoffice would
think about switching to it.


> > i'll try to look into it after
> > i understand well the package, and if noone takes it i'll take on to
> > port it to qt4 and cmake build system. i'm now starting to work on qt4
> > and this could be an interesting challenge and could help me improve my
> > skills with it.
>
> Hopefully klibido follows to KDE4.  It'd be a shame to see it stuck on
> KDE3, after all the work that has gone into it and as sparse on the
> ground as real binary news harvesters seem to be.
>

i really hope so. it's good to have it around.


> >> Doing an emerge --pretend paludis, it doesn't have /that/
> >> unreasonable a list of new merges, and a good share of the ones it
> >> /does/ have are simply null-package virtuals, already filled by newer
> >> gcc versions[.]
>
> > and that some tools like pcre (always needed by paludis) is now not
> > needed only by it. as i've said before, mainly xorg has pushed in these
> > deps (of course the use flags also helped a lot).
>
> For pcre, certain other packages have been using it for awhile.  pan
> does, and I it, so it didn't show up on my dependency list.  (You
> mentioned xorg, it depends on it too now? I guess it really /is/ getting
> around!  I wouldn't have known since I have it merged for pan.)  Point
> about eye of the beholder...  But based on a post (yours I think) I see
> since I posted the grandparent, it seems the newer gcc does indeed take
> care of what might have been quite a stack of deps.


yep, gcc or xorg. i don't remember which of them, but the 4.2.x branch
surely pushes quite some deps needed by paludis. i'm not sure if xorg do
pushes some too, since i've done the emerge paludis after the 2 emerge -e
system and the xorg emerge.


> > also, i'm now trying to do as you've said with pan and the cached
> > articles, but i find it somehow long to do. maybe it's because i'm not
> > used to it. so for the moment being i've gone back with klibido.
>
>
> Well, it's not that it's longer... it takes that time to download the
> posts either way... but it does seem to take longer since you download
> them all before starting to work on them.
>
> There's to it tho that make it not seem so bad.
>
> First, depending on what you are downloading and from where (groups), it
> may be possible to train yourself to setup a smaller group download
> first, then the larger group, scheduled after the small group.  For some
> things (mainly single part binaries), that works reasonably well, as the
> shorter group may be mostly downloaded by the time you get thru sorting
> thru and deleting the stuff you do NOT need to download on the larger
> group, then scheduling the rest of it for download.  That way you can
> switch to the shorter group, and with it mostly or all downloaded, go
> right to work sorting and saving what downloaded.  If it works out right,
> by the time you finish that, the larger group (or some portions thereof,
> see below) will be done.
>
> Second, you can download text groups first, then binaries, then read and
> reply to the text groups giving the binaries a chance to get partly done
> before you switch back to them.
>
> Third, there's nothing saying you have to download the whole group at
> once.  In the first round (with only headers), at least on some groups,
> you can download samples, preview stills or clips, then decide if you
> want to download the whole series.  If not, delete the series right there
> and go on.  If you want to download it, setup the download to cache right
> then and there, and go on.  By the time you've worked thru the group and
> setup the last of the downloads, the first will hopefully be done or
> close to it.  As the downloads to cache complete, the icon will change
> from download to in-cache, so you can see what messages were in jobs that
> have already completed downloading.  Thus, you can go thru and process
> the downloaded series while others are still downloading.  Of course, you
> may have to flip the sort order between subject/author/date/scored a bit
> to get the series together and make it easy to go thru them, but a binary
> news junkie will probably be accustomed to doing some of that already.
>
> Fourth, while it can be hard to discipline yourself to do so, at least
> initially, you can also train yourself to setup the new downloads at the
> END of your working session, before you go to work or to bed or do family
> or friend stuff or whatever.  Then it downloads while you are doing
> something else, and you come back and have everything nicely ready for
> your NEXT session.  Do your sorting and saving and whatever (without
> checking for new messages yet), delete the now garbage headers and
> cache, /then/ grab new headers, select what you want to download deleting
> the rest, set it downloading, and your session is finished.  Again, when
> you get thru sleeping or working or whatever, you'll have another fresh
> batch of downloads already stored locally.  No waiting for the downloads
> to finish, as you let the computer do that while you're away doing other
> things!  Of course, this works better on a desktop you leave where it is,
> than on a laptop you disconnect to take with you when you are finished.
> Still, even with a laptop that's normally on the go with you, you gotta
> sleep sometime, and you might as well let it be downloading while you do.
> Admittedly, tho, this takes discipline, as once you decide you want the
> files, it's hard to wait until the next session to actually go thru them.
>

it's a little too complicated to me. i'm usually using pan just for browsing
the newsgroups and read some text articles. what i'd like to download i'd
take the nzb and use klibido. the problems with klibido stopping to work
sometimes, drives me mad and continues to bind me to pan, since it's the
only other nzb capable around with a decent interface, else i'd have already
switched fully to knode+klibido.


-- 
dott. ing. beso