[kde-linux] Kget "My Downloads" [Is this MS Windows?]

[Kevin Krammer]

On Sunday, 2013-04-21, Duncan wrote:
> James Tyrer posted on Sat, 20 Apr 2013 13:14:17 -0700 as excerpted:
> > On 04/19/2013 10:11 PM, Duncan wrote:
> >> I think that kget may be a holdover from the dialup connection era.
> > 
> > Don't see what it has to do with dial up, but rather
> > file_length/connection_speed.  I am out in the country and have only 150
> > KiB/sec and long files still exist.
> 
> You're correct, but it's more than connection speed.  It's also the shut
> down (and/or turn off the network connection) when done options and etc,
> that used to be commonly used with dialup, but aren't so commonly used in
> the (nearly) always-on, always connected, era. 

Only if we consider wired connections, wireless and especially "mobile 
broadband" are still prone to connection loss, highly variable connection 
speed and connection quality.

It is a bit like dial-up helpers such as KPPP having a huge renaissance when 
"modems" in the form of UTMS USB devices came around.

> Well, a lot of freedomware is originally written by "kids" in college.
> When they graduate and get a family and a job... often times they quit
> contributing so much as they simply don't have the time any more, and the
> next generation of college kids takes their place.

It is not necessarily inexperience of the developer in matter of development, 
thought that is often the case, but can also be a matter of inexperience in 
the problem domain at hand.

It is often necessary to create a first generation implementation through 
approximation, gradually learning about new use cases or limitations, etc.

> Among other things, the base underneath kde has changed significantly.
> Qt5 in particular is far *FAR* more open than qt4 was, as it's truly a
> community project now.  KDE, being the biggest freedomware qt user and
> one of the biggest qt users period, has thus had a rather larger
> influence on qt5 than it did on either qt4 or qt3 -- and the influence it
> had on qt4 was already not negligible.

Indeed.

> There's an interesting dynamic developing between qt5 and kde5/
> frameworks, then.  Parts of what was kdelibs because they formerly had to
> stay separate, are moving down into qt5, where they have a much broader
> community base of support, including a number of businesses now built
> around qt, so while qt's more open than it ever was, these bits that were
> kde are getting more full-time professional development and support than
> they ever did, as they're now part of the broader qt5.

Also true.

> Meanwhile, qt5 itself is *MUCH* more modular, shipped as a collection of
> mostly optional modular libraries built around a central core.  So where
> with qt3 and qt4, if you had qt installed, it was generally assumed that
> you had it all installed, now, each of these modules (except for core)
> will be optional, depended upon and installed separately.

Actually no. While Qt3 was an all encompassing library, the modularisation 
(both on library level as well as on packaging level) already happened with 
Qt4.
The change for Qt5 does not affect developers working with Qt or users using 
Qt based applications, it is mostly a change for developers working on Qt, 
e.g. separate libraries having independent continuous integration runs, making 
builds less likely to fail due to an unrelated commit to a different library.

> And, it's worth noting that qt5 in general NO LONGER IMPLIES GUI!  Qt5-
> core is designed to be usable in and depended upon, perhaps with a few
> non-gui modules (qt5-sql, say) as well, by CLI apps as well as GUI apps.
> All the GUI stuff is designed to ship in the optional GUI-related modules.

That was also already true for Qt4.

> The practical effect is that in the 5th generation, the lines between kde
> and qt will be blurred quite a bit, as both will be heavily modularized,
> with pretty much everything being optional, individual kde and qt-only
> apps and libs depending on individual kde and qt libs and modules only as
> necessary, without the monolithic assumptions of the 4th generation.

Similar to Qt4 this is also not entirely true for KDE libraries based on Qt4.
While some libraries had unnecessarily dependencies between each other, they 
were mostly separated already but just not packaged as such.

Part of the frameworks 5 initiative is to make it more obvious for packagers 
on where to draw package boundaries, but of course there is no way to enforce 
that should some of them opt to ignore those hints.

> And qt5 already has preliminary wayland support, with kde-frameworks
> wayland support being planned as well.  If you watch, there's occasional
> blogs on the subject from kde's kwin and plasma folks, among others.

My personal guess is that libraries by KDE are not very much affected by the 
switch at all. Some things that do have X11 dependencies will likely be 
seperated and paired or augmented with a wayland implementation.
This guess is mainly based on the fact that most libraries are already being 
used on systems without X11, e.g. Windows or Mac OSX.

We can read a lot of wayland related development on blogs from Plamsa or KWin 
developers because these applications are the main integration points with the 
windowing system and thus have the tightest dependencies.

> commits to xorg are likely to drop off dramatically.  That said, the BSDs
> are having some trouble keeping up with some of the DRM, KMS, etc
> assumptions of wayland, and xorg may well end up being a primarily BSD
> technology in say five years' time.

I haven't followed this closely enough to make more than an educated guess but 
I think that the assumptions to speak of are not directly related to wayland 
itself but rather its reference implementations, i.e. weston and libwayland.

My take is that the BSDs will just come up with their own implementations of 
both client library and compositor for the wayland protocol, not only because 
of assumptions in the more linux centered reference implementation but also 
because opening the possibility to use different licensing terms.

> Status?  Of course qt5 is out, tho I expect kde-frameworks will require
> 5.1 or 5.2 by the time it comes out (much as kde 4.0 required qt 4.2 or
> 4.3 or whatever, 4.0 wasn't enough).

Requirement will be at least Qt5.1 due to needing some of the "upstreamed" 
classes such as the KSaveFile replacement, etc.

With Qt5.1 targetted for a release date around May this year, there are hopes 
to be able to do a technology preview somewhen around this year's Akademy, 
i.e. early/mid July.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-linux/attachments/20130421/83e03c92/attachment.sig>