Will Stephenson | 1 Jul 10:03 2009
Picon

KDE browser work team

Hi all

i'm following up my blog with some action and want to get an idea who else is 
interested in making web browsing inside KDE instead of on top of KDE work 
again.  I personally don't have any browser coding experience but have an idea 
where we should be.  I'll start following up here with a few possibilities.

BTW, is this the right list, should we do this straight on kfm-devel?

Will

Aurélien Gâteau | 1 Jul 10:35 2009

Re: Repositioning the KDE brand

nf2 wrote:

> * System (or Platform, or infrastructure) technologies like ioslaves
> or kwallet: While KDE has been the "market leader" for a long time,
> comparable technologies have caught up or have even become "cooler".
> Therefore KDE could benefit from "incorporating" them. The "Platform"
> should move to the layer below KDE - things that are eager to be
> shared by everyone. You won't love me for that, but honestly: That
> part of the world should be ruled by GLib and GObjects...

I don't think anyone with experience in Qt and QObject would like to
rewrite his work with GObject. I had to work with this and it was really
painful. At least in plain C. It's probably nicer when using higher
level languages.

Aurélien

Harri Porten | 1 Jul 10:51 2009

Re: KDE browser work team

On Wed, 1 Jul 2009, Will Stephenson wrote:

> i'm following up my blog with some action and want to get an idea who else is
> interested in making web browsing inside KDE instead of on top of KDE work
> again.  I personally don't have any browser coding experience but have an idea
> where we should be.  I'll start following up here with a few possibilities.
>
> BTW, is this the right list, should we do this straight on kfm-devel?

I think anyone remotely related to Web browsing work in KDE is subscribed 
to kfm-devel. I am very curious to hear about your ideas.

Harri.

Evgeny Egorochkin | 2 Jul 14:44 2009
Picon

Re: Repositioning the KDE brand

On Wednesday 01 July 2009 06:57:53 nf2 wrote:
> Cool article! Sounds more than just a marketing concept to me... Some
> thoughts...
>
> * Desktop: What has been the initial idea of having multiple desktops?
> Freedom of taste. To have different views (or frontends) into the
> *same* system. I really like the term "Workspace", because it makes
> this even clearer.

Yeah, but there's still no consensus on what this "same" system should look 
like, although there's some progress.

> * The term "Desktop-Environment" emerged when more and more "system
> technology" was pulled in, which created different frontends for
> *different* systems. In my opinion a very unlucky development.
> Fortunately, with newer technologies  (like network-manager, HAL,
> D-Bus...), those mistakes have not been repeated.

In the meanwhile, you can see that for every system tech component that 
becomes shared, another unshared one appears engulfed in the same flames like 
it's not needed or rather needed implementing 10% of the functionality(without 
any provisions for substantial improvement later on).

> * I like the idea to find a name for marketing the core libraries, but
> i think "Platform" is still too close to "Environment". "KDE toolkit"
> would be clearer. Because that's - what i believe - what it should
> become in the long run: A convenience and portability-layer for
> writing rich and beautiful GUI applications - but phasing out
> system-technologies. Something like Qt enhanced.

(Continue reading)

Enrico Ros | 1 Jul 10:30 2009
Picon

Re: KDE browser work team

On Wednesday 01 July 2009 10:03:40 Will Stephenson wrote:
> Hi all
> i'm following up my blog with some action and want to get an idea who else
> is interested in making web browsing inside KDE instead of on top of KDE
> work again.  I personally don't have any browser coding experience but have
> an idea where we should be.  I'll start following up here with a few
> possibilities.

Hello, thanks for caring! This topic has been up for years [1].

I'd like to suggest a public poll, directed to both users and developers. 
Based on the poll results we could choose the best action for improving the 
browsing experience on KDE.

The poll could have questions like:

 - what's your role in the KDE community? (beginner user, ..., advanced dev.)

 - which browser do you use primarily? (don't know, konqueror, firefox, ...)

 - do you have problems with your browser? (no, 10% of sites, 20% ...)

 - do you use other browsers? (don't know, konqueror, firefox, ...)

 - how did your browsing experience changed in the last year? (the same, 
improved, worsen)

konqueror users:
 - would you like to change the default rendering engine? (no, yes/webkit, 
yes/gecko, ...)
(Continue reading)

David Johnson | 1 Jul 18:42 2009

Re: Repositioning the KDE brand

On Wednesday 01 July 2009 01:35:33 am Aurélien Gâteau wrote:
> I don't think anyone with experience in Qt and QObject would like to
> rewrite his work with GObject. I had to work with this and it was really
> painful. At least in plain C. It's probably nicer when using higher
> level languages.

To amplify your point: QObject (and QMetaObject) is the basis of Qt 
introspection and communication. Qt already uses the GLib event loop by 
default. QtCore is solid, robust, small, and perfectly appropriate for 
"platform" level code.

--

-- 
David Johnson

Albert Astals Cid | 1 Jul 20:52 2009
Picon

Re: KDE browser work team

A Dimecres, 1 de juliol de 2009, Enrico Ros va escriure:
> On Wednesday 01 July 2009 10:03:40 Will Stephenson wrote:
> > Hi all
> > i'm following up my blog with some action and want to get an idea who
> > else is interested in making web browsing inside KDE instead of on top of
> > KDE work again.  I personally don't have any browser coding experience
> > but have an idea where we should be.  I'll start following up here with a
> > few possibilities.
>
> Hello, thanks for caring! This topic has been up for years [1].
>
> ... poll idea ...
>
> The poll should be advertised in blogs, kde-look, dot, etc. And in the end
> the statistical analysis will be the "voice of the community" and could be
> really useful for having consensus on the curse of actions.

Repeat with me "You can't force volunteers to work on what YOU want"

Now start working on a Webkit KPart or stop trolling. 

Albert

>
> Enrico
>

Ariya Hidayat | 1 Jul 21:26 2009
Picon

Re: KDE browser work team

When I reread the original closing sentence from Enrico, it does not
imply that the consensus will be used to force developers to work on
that.

But then, my English is just so so...

--

-- 
Ariya

Alexander Neundorf | 1 Jul 22:34 2009
Picon

Re: KDE browser work team

On Wednesday 01 July 2009, Will Stephenson wrote:
> Hi all
>
> i'm following up my blog with some action and want to get an idea who else
> is interested in making web browsing inside KDE instead of on top of KDE
> work again.  I personally don't have any browser coding experience but have
> an idea where we should be.  I'll start following up here with a few
> possibilities.

Great initiative !
(...but unfortunately I don't have time for working on yet another thing)

Alex

P.S. I didn't put it in a blog comment, so just here a short remark: until 
maybe 2 years ago I was using konqy exclusively, since then I have to use 
firefox more and more, because the sites just don't work (some work again): 
google mail, zimbra, now even some blogs in planet kde, and the number is 
increasing

Stefan Majewsky | 1 Jul 22:47 2009
Picon
Picon

Re: KDE browser work team

Am Mittwoch 01 Juli 2009 22:34:41 schrieb Alexander Neundorf:
> I didn't put it in a blog comment, so just here a short remark: until
> maybe 2 years ago I was using konqy exclusively, since then I have to use
> firefox more and more, because the sites just don't work (some work again):
> google mail, zimbra, now even some blogs in planet kde, and the number is
> increasing

How exactly is the problem of website incompatibility tackled? Do the KHTML 
devs just curse through the bugs and work on whatever bugreport sounds 
feasible and elaborated, or do you tackle the problem systematically?

I'm asking because I think we could improve things dramatically if major sites 
worked better. Of course, it's not nice if a site of a little restaurant does 
not work, but it is a disaster if Digg or Slashdot does not work (and these 
indeed seem to be broken, according to comments on my blog). I could imagine 
some web-based database where defective sites can be voted up by those who 
want to use them, and bug reports can be linked to them to give the developer 
an overview of which bugs need fixing (by far not every user votes for bug 
reports), but I do not know whether this is what developers need. Perhaps the 
developers are already quite efficient, but just too less. RFC?

Greetings
Stefan

Gmane