I am sure most of you have seen the news by now that Qt is switching
from GPL to LGPL licensing. Does this increase the chances of a Qt Chrome on Linux instead of GTK or has too much work already been
completed on the Linux GUI?
On Wed, Jan 14, 2009 at 9:15 AM, andrewg <droi...@gmail.com> wrote: > I am sure most of you have seen the news by now that Qt is switching > from GPL to LGPL licensing. Does this increase the chances of a Qt > Chrome on Linux instead of GTK or has too much work already been > completed on the Linux GUI?
It's great news, but I don't think it changes much for Chrome, offhand.
That said, patches to add Qt support would be interesting to see.
It definitely seems possible to have Chromium ports for both Qt and
GTK. That said, we need to focus our attention on getting one of the
two working and working well.
Like Dan said, external contributors are more than welcome for patches
towards a Qt port.
On Wed, Jan 14, 2009 at 6:17 PM, Dan Kegel <daniel.r.ke...@gmail.com> wrote:
> On Wed, Jan 14, 2009 at 9:15 AM, andrewg <droi...@gmail.com> wrote:
>> I am sure most of you have seen the news by now that Qt is switching
>> from GPL to LGPL licensing. Does this increase the chances of a Qt >> Chrome on Linux instead of GTK or has too much work already been
>> completed on the Linux GUI?
> It's great news, but I don't think it changes much for Chrome, offhand.
> That said, patches to add Qt support would be interesting to see.
On Wed, Jan 14, 2009 at 9:15 AM, andrewg <droi...@gmail.com> wrote: > I am sure most of you have seen the news by now that Qt is switching > from GPL to LGPL licensing. Does this increase the chances of a Qt > Chrome on Linux instead of GTK or has too much work already been > completed on the Linux GUI?
I'm no lawyer, but it appears there was already an exception list[1] for the GPL-licensed code that would've covered us anyway? So I believe this LGPL thing has no affect on us, except in its potential broader implications for the space of other software in the future.
I, too, would be happy to review patches for Qt support.
On Jan 14, 11:44 am, Evan Martin <e...@chromium.org> wrote:
> I'm no lawyer, but it appears there was already an exception list[1]
> for the GPL-licensed code that would've covered us anyway? So I
> believe this LGPL thing has no affect on us, except in its potential
> broader implications for the space of other software in the future.
> I, too, would be happy to review patches for Qt support.
I'm no lawyer either, but I am pretty sure the GPL would have required
Chromium to be released under the GPL as well, instead of its BSD
license (unless all of the contributors had a commercial license to
Qt).
On Wed, Jan 14, 2009 at 9:50 AM, andrewg <droi...@gmail.com> wrote:
> On Jan 14, 11:44 am, Evan Martin <e...@chromium.org> wrote: >> I'm no lawyer, but it appears there was already an exception list[1] >> for the GPL-licensed code that would've covered us anyway? So I >> believe this LGPL thing has no affect on us, except in its potential >> broader implications for the space of other software in the future.
>> I, too, would be happy to review patches for Qt support.
> I'm no lawyer either, but I am pretty sure the GPL would have required > Chromium to be released under the GPL as well, instead of its BSD > license (unless all of the contributors had a commercial license to > Qt).
Ah, my misreading -- that page doesn't apply to the "Open Source Edition". I do remember reading about BSD-licensed software needing to make licensing exceptions to link against Qt.
(I apologize for my misinformation; I never looked into Qt too closely exactly because of these licensing shenanigans.)
When Dean and Evan say that they don't mind reviewing patches for Qt ports, what we are saying is that
we don't mind having two UI versions of Chromium on linux?
How would this work in the long term? UI tests times 2? you get to
choose what Chromium to install?
Apologies if this was already discussed long time ago.
If somebody asked me that they want to contribute a port of chrome on
Windows UI using MFC, I would say no. I just don't see the cost/
benefit.
Personally, Qt seems now the stronger toolkit, but I really don't have
a clue about linux development.
-cpu
On Jan 14, 9:55 am, Evan Martin <e...@chromium.org> wrote:
> On Wed, Jan 14, 2009 at 9:50 AM, andrewg <droi...@gmail.com> wrote:
> > On Jan 14, 11:44 am, Evan Martin <e...@chromium.org> wrote:
> >> I'm no lawyer, but it appears there was already an exception list[1]
> >> for the GPL-licensed code that would've covered us anyway? So I
> >> believe this LGPL thing has no affect on us, except in its potential
> >> broader implications for the space of other software in the future.
> >> I, too, would be happy to review patches for Qt support.
> > I'm no lawyer either, but I am pretty sure the GPL would have required
> > Chromium to be released under the GPL as well, instead of its BSD
> > license (unless all of the contributors had a commercial license to
> > Qt).
> Ah, my misreading -- that page doesn't apply to the "Open Source
> Edition". I do remember reading about BSD-licensed software needing
> to make licensing exceptions to link against Qt.
> (I apologize for my misinformation; I never looked into Qt too closely
> exactly because of these licensing shenanigans.)
On Thu, Jan 15, 2009 at 10:37 AM, cpu <c...@chromium.org> wrote: > When Dean and Evan say that they don't mind reviewing patches for Qt > ports, what we are saying is that > we don't mind having two UI versions of Chromium on linux?
> How would this work in the long term? UI tests times 2? you get to > choose what Chromium to install?
I figured it would be unsupported.
> If somebody asked me that they want to contribute a port of chrome on > Windows UI using MFC, I would say no. I just don't see the cost/ > benefit.
Here's an analogy. Say I argued we should only target GTK because it runs on Windows just fine, so we'd be able to share UI test code between Windows and Mac. You'd (hopefully) say it'd be terrible because it's non-native.
That's the situation between GTK and Qt these days. The OS underneath is the same, but running apps targeting one in an environment targeting the other in terms of user experience feels much like GTK apps feel on Windows.
Unfortunately we don't have the resources to target both, but if someone else is willing to provide the patches I'm willing to review them.
> That's the situation between GTK and Qt these days.
> The OS underneath is the same, but running apps targeting one
> in an environment targeting the other in terms of user experience
> feels much like GTK apps feel on Windows.
It doesn't have to any more. Qt 4.5 can use the current Gtk theme
and it will adjust the button order and other UI features to match the
current Gnome/GTK
settings. I believe it can also use the native Gtk file dialog - if
not there are certainly
hooks that would permit it to be implemented. Maybe not absolutely
perfect but
certainly nothing like Gtk on Windows.
Regards,
Robert.
On Jan 15, 7:04 pm, Evan Martin <e...@chromium.org> wrote:
> On Thu, Jan 15, 2009 at 10:37 AM, cpu <c...@chromium.org> wrote:
> > When Dean and Evan say that they don't mind reviewing patches for Qt > > ports, what we are saying is that
> > we don't mind having two UI versions of Chromium on linux?
> > How would this work in the long term? UI tests times 2? you get to
> > choose what Chromium to install?
> I figured it would be unsupported.
> > If somebody asked me that they want to contribute a port of chrome on
> > Windows UI using MFC, I would say no. I just don't see the cost/
> > benefit.
> Here's an analogy. Say I argued we should only target GTK because it
> runs on Windows just fine, so we'd be able to share UI test code
> between Windows and Mac. You'd (hopefully) say it'd be terrible
> because it's non-native.
> That's the situation between GTK and Qt these days. The OS underneath
> is the same, but running apps targeting one in an environment
> targeting the other in terms of user experience feels much like GTK
> apps feel on Windows.
> Unfortunately we don't have the resources to target both, but if
> someone else is willing to provide the patches I'm willing to review
> them.
On Jan 16, 7:21 pm, robertknight <robertkni...@gmail.com> wrote:
> It doesn't have to any more. Qt 4.5 can use the current Gtk theme
> and it will adjust the button order and other UI features to match the
> current Gnome/GTK settings.
Well, yes. At least it tries hard (even if the result is not always
what you would expect :) Also, I applaud Nokia for the license change
(it was long overdue).
But one thing to consider is that even "Qt apps" don't really
integrate nicely into KDE: I recently wondered why one random
application I tried would integrate so badly into KDE. In the end I
learned it was a "pure" Qt4 app and not a KDE4 (Qt plus kdelibs,
plasma, etc) application :( On the other hand, full KDE apps take a
*long* time just to start up on non-KDE desktops because they first
start all kinds of KDE background services...
The same has been true for pure GTK vs GNOME (libgnome, libbonobo,
gnomevfs, ...) apps in the past, but it looks like GNOME finally
managed to get rid of all the extra dependencies to get a cleaner
platform (and has to link against less libraries). Both desktops are
evolving really nice IMHO, but I think KDE's inability to directly
control Qt will be a problem for them in the future.
I not an expert (yet ;) in Qt and WebKit, but wouldn't it be easier to
port to Linux and Mac with Qt?
It's pure c++, it has WebKit integration already, and with new 4.5, it
uses Cocoa on Mac.
http://www.qtsoftware.com/about/news/qt-4.5-beta-previews-64-bit-on-mac "Qt 4.5 will allow Qt users to step up to the new Cocoa Framework
with little more than a recompile to take advantage of 64-bit
architecture for maximum application performance and gain better
access to new Mac OS X features introduced in Cocoa"
Qt is really powerful and fun to work with framework. I hope there
will be strong community around Qt port. I'll try myself to play with
it, it will be fun, although I'm a student and I still have a lot to
learn about programming.
> On Sat, Jan 17, 2009 at 4:29 AM, kojot <kojot...@gmail.com> wrote: >> I not an expert (yet ;) in Qt and WebKit, but wouldn't it be easier to >> port to Linux and Mac with Qt?
> Not really. Very, very little of Chrome involves Gtk or Qt. > - Dan
FWIW, the changes I've made in the browser over the past few months
(MagicBrowzr) should have made it possible for the front end to be
written in any number of native toolkits. Our first test is going to
be Cocoa on OS X.
On Thu, Jan 15, 2009 at 11:04 AM, Evan Martin <e...@chromium.org> wrote:
> On Thu, Jan 15, 2009 at 10:37 AM, cpu <c...@chromium.org> wrote:
>> When Dean and Evan say that they don't mind reviewing patches for Qt >> ports, what we are saying is that
>> we don't mind having two UI versions of Chromium on linux?
>> How would this work in the long term? UI tests times 2? you get to
>> choose what Chromium to install?
> I figured it would be unsupported.
>> If somebody asked me that they want to contribute a port of chrome on
>> Windows UI using MFC, I would say no. I just don't see the cost/
>> benefit.
> Here's an analogy. Say I argued we should only target GTK because it
> runs on Windows just fine, so we'd be able to share UI test code
> between Windows and Mac. You'd (hopefully) say it'd be terrible
> because it's non-native.
> That's the situation between GTK and Qt these days. The OS underneath
> is the same, but running apps targeting one in an environment
> targeting the other in terms of user experience feels much like GTK
> apps feel on Windows.
> Unfortunately we don't have the resources to target both, but if
> someone else is willing to provide the patches I'm willing to review
> them.
On Thu, Jan 15, 2009 at 2:04 PM, Evan Martin <e...@chromium.org> wrote:
> On Thu, Jan 15, 2009 at 10:37 AM, cpu <c...@chromium.org> wrote: >> When Dean and Evan say that they don't mind reviewing patches for Qt >> ports, what we are saying is that >> we don't mind having two UI versions of Chromium on linux?
>> How would this work in the long term? UI tests times 2? you get to >> choose what Chromium to install?
> I figured it would be unsupported.
>> If somebody asked me that they want to contribute a port of chrome on >> Windows UI using MFC, I would say no. I just don't see the cost/ >> benefit.
> Here's an analogy. Say I argued we should only target GTK because it > runs on Windows just fine, so we'd be able to share UI test code > between Windows and Mac. You'd (hopefully) say it'd be terrible > because it's non-native.
> That's the situation between GTK and Qt these days. The OS underneath > is the same, but running apps targeting one in an environment > targeting the other in terms of user experience feels much like GTK > apps feel on Windows.
> Unfortunately we don't have the resources to target both, but if > someone else is willing to provide the patches I'm willing to review > them.
That isn't really the situation for Qt though. Arora is a good example of how Qt can intigrate very well in Gnome. Using the gtkstyle theme qt uses the native GTK theme to render widgets, detecting Gnome it will automatically select that theme, use Gnome shortcuts, and Gnome styled icons. Lastly using QDesktopServices it will ask Gnome to perform actions like open this folder and does not explicitly use Konq. The same can not be said of a Gnome app these days. Some screenshots of Arora in different desktops show off the visual integration: http://code.google.com/p/arora/wiki/Screenshots. And there are file dialog hooks, I don't know if the gtkstye uses the Gnome file dialog, but it can. Qt has put a lot of time and effort into working well on KDE and Gnome so application developers don't have to.
But I guess it all depends upon what you want it to do for you. For Chrome the browser applications there are definite advantages. For chromium the webkit rendering engine there might be stuff that can be shared with QtWebKit (or at least used as comparison or copy) such as clipboard, fonts, paint etc. Using Qt and taking advantage of that fact that Qt already has a working an tested (insert feature here) for X11 that can integrate with Webkit is a win.
> That isn't really the situation forQtthough. Arora is a good
> example of howQtcan intigrate very well in Gnome. Using the
> gtkstyle themeqtuses the native GTK theme to render widgets,
> detecting Gnome it will automatically select that theme, use Gnome
> shortcuts, and Gnome styled icons.
just theme something never make an application nativ. NEVER!
If the application needs Qt - You need Qt on your system an so it
can't be nativ on a GNOME Desktop.
On Feb 14, 4:16 pm, vincenzo <v.pupi...@gmail.com> wrote:
> > just theme something never make an application nativ. NEVER!
> > If the application needsQt - You needQton your system an so it
> > can't be nativ on a GNOME Desktop.
> >Qtis still not possible.
> Oh yes! And if the application needs GTK+ you need GTK+ on your system
> and so it can't be native on a KDE Desktop!
> GTK+ is still not possible! Use only xlib please! :-)
You're both wrong.
Any distro conforming to the Linux Standard Base Desktop specification
are required to have BOTH GTK+ and Qt. Although most distros don't
follow the letter of the law here, it is not unreasonable to assume
that a Linux system with a graphical desktop has both Qt and GTK+
libraries installed.
On Sun, Feb 15, 2009 at 12:42 AM, jefferai <jeffe...@gmail.com> wrote:
> On Feb 14, 4:16 pm, vincenzo <v.pupi...@gmail.com> wrote:
> > > just theme something never make an application nativ. NEVER!
> > > If the application needsQt - You needQton your system an so it
> > > can't be nativ on a GNOME Desktop.
> > >Qtis still not possible.
> > Oh yes! And if the application needs GTK+ you need GTK+ on your system
> > and so it can't be native on a KDE Desktop!
> > GTK+ is still not possible! Use only xlib please! :-)
> You're both wrong.
> Any distro conforming to the Linux Standard Base Desktop specification
> are required to have BOTH GTK+ and Qt. Although most distros don't
> follow the letter of the law here, it is not unreasonable to assume
> that a Linux system with a graphical desktop has both Qt and GTK+
> libraries installed.
On 17 Gen, 19:45, "Ben Goodger (Google)" <b...@chromium.org> wrote:
> +1
> FWIW, the changes I've made in the browser over the past few months
> (MagicBrowzr) should have made it possible for the front end to be
> written in any number of native toolkits. Our first test is going to
> be Cocoa on OS X.
> -Ben
So, different native toolkits for each platform.
But while Windows has mfc and Osx uses cocoa/carbon, i wonder what is
"THE" native toolkit for linux (?)
Or, if you prefer, why did you choose gtk over qt (at least) on linux?
It's very strange, since google earth uses qt...
I'm not understanding the animosity shown toward GTK in this thread
thus far. A majority of GNU/Linux distros are now using GNOME as the
default desktop, I use and nearly every Free Software user that I know
IRL uses and prefers it. I'm not going to bad mouth QT, I used it
predominately a couple years ago in the 3.2 days and used it up until
the betas of 3.5.
All I want is a fast browser and I for one am happy about the choice
to use GTK, not only because I use GNOME but also because I've noticed
quite a bit of difference between loading QT in a non-QT environment
vs loading GTK in a non-GTK environment, GTK is faster. Try loading
Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany
from KDE and it's apparent. Dolphin is a very fast application,
pretty darn slow to load in GNOME, Thunar is comparable directly, fast
as hell to load in either environment.
All I know is that there shouldn't be this kind of hate in the Free
Software community.
On Feb 19, 7:02 am, inaneframe <inane...@gmail.com> wrote:
> I'm not understanding the animosity shown toward GTK in this thread
> thus far. A majority of GNU/Linux distros are now using GNOME as the
> default desktop, I use and nearly every Free Software user that I know
> IRL uses and prefers it. I'm not going to bad mouth QT, I used it
> predominately a couple years ago in the 3.2 days and used it up until
> the betas of 3.5.
> All I want is a fast browser and I for one am happy about the choice
> to use GTK, not only because I use GNOME but also because I've noticed
> quite a bit of difference between loading QT in a non-QT environment
> vs loading GTK in a non-GTK environment, GTK is faster. Try loading
> Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany
> from KDE and it's apparent. Dolphin is a very fast application,
> pretty darn slow to load in GNOME,
Dolphin is a KDE application, it relies on the kdelibs and probably
kded and maybe another kde-session-daemon.
A Qt application does not have these dependencies. Try staring Skype,
VLC or Google earth from Gnome and you will see that they load fast
and integrate well, if you use the cleanlooks or QGtkStyle. They will
run as single process, and no not need to have even kdelibs installed.
Qt != KDE... Qt libs != kdelibs.
I'll just repeat (since these threads seem to be linked from many
places) - a Qt version for Linux is not impossible, it just requires a
dedicated set of folk to work on it and maintain it. The design of
Chromium is such that N front ends are possible. The team is most
familiar with GTK and so that's where they'll be focusing their
energy.
On Wed, Feb 18, 2009 at 9:59 PM, inaneframe <inane...@gmail.com> wrote:
> I'm not understanding the animosity shown toward GTK in this thread
> thus far. A majority of GNU/Linux distros are now using GNOME as the
> default distro, I use and nearly every Free Software user that I know
> IRL uses and prefers it. I'm not going to bad mouth QT, I used it
> predominately a couple years ago in the 3.2 days and used it up until
> the betas of 3.5.
> All I want is a fast browser and I for one am happy about the choice
> to use GTK, not only because I use GNOME but also because I've noticed
> quite a bit of difference between loading QT in a non-QT environment
> vs loading GTK in a non-GTK environment, GTK is faster. Try loading
> Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany
> from KDE and it's apparent. Dolphin is a very fast application,
> pretty darn slow to load in GNOME, Thunar is comparable directly, fast
> as hell to load in either environment.
> All I know is that there shouldn't be this kind of hate in the Free
> Software community.
Just to add to what Ben said earlier in the thread, the Cocoa
front-end is progressing quite well even though the Win UI is very
different from Cocoa in terms of the interaction models and how the
toolkits are designed (C++ vs Objective-C). The Model-View-Controller
design of the shared code is proving that we can slap just about any
UI we want on top of it (so far).
This bodes well for some other group doing a Qt version. Just wanted
to provide something tangible to the "it should be possible" argument.
On Thu, Feb 19, 2009 at 5:55 AM, Ben Goodger (Google) <b...@chromium.org> wrote:
> I'll just repeat (since these threads seem to be linked from many
> places) - a Qt version for Linux is not impossible, it just requires a
> dedicated set of folk to work on it and maintain it. The design of
> Chromium is such that N front ends are possible. The team is most
> familiar with GTK and so that's where they'll be focusing their
> energy.
> -Ben
> On Wed, Feb 18, 2009 at 9:59 PM, inaneframe <inane...@gmail.com> wrote:
>> I'm not understanding the animosity shown toward GTK in this thread
>> thus far. A majority of GNU/Linux distros are now using GNOME as the
>> default distro, I use and nearly every Free Software user that I know
>> IRL uses and prefers it. I'm not going to bad mouth QT, I used it
>> predominately a couple years ago in the 3.2 days and used it up until
>> the betas of 3.5.
>> All I want is a fast browser and I for one am happy about the choice
>> to use GTK, not only because I use GNOME but also because I've noticed
>> quite a bit of difference between loading QT in a non-QT environment
>> vs loading GTK in a non-GTK environment, GTK is faster. Try loading
>> Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany
>> from KDE and it's apparent. Dolphin is a very fast application,
>> pretty darn slow to load in GNOME, Thunar is comparable directly, fast
>> as hell to load in either environment.
>> All I know is that there shouldn't be this kind of hate in the Free
>> Software community.
