If they truly want "wide scale adoption" as indicated in the referenced article, they would be better off using LGPL or BSD/MIT type license. It's not like supporting a transmission format is rocket science, so GPL seems a bit weird choice for a license.
One of tomtom's specs says that:
GPLv2 permits to use software & library in proprietary programs
Personally I'd like to see the Uzbl features made available as advancements to existing browsers instead of creating a new one which has inherent GUI limitations.
This is written in python. If they bolted the functionality on ff/chrome, they would have needed to deal with js and c++. I guess it was just easier this way.
Just like folks at Apple realized with their OS X, we in the Linux world, need an alternative to X. I heard that Google Chrome OS will get rid of it entirely. I would like to hear from anyone who disagrees.
The result is an improved desktop experience; benchmarks on memory tight desktops show clock time and major faults reduced by 50 per cent, and pswpin numbers (memory reads from disk) are reduced to about one-third. That means X desktop responsiveness is doubled under high memory pressure.
Furthermore, memory flushing benchmarks in a file server shows the number of major faults going from 50 to 3 during 10 per cent cache hot reads.
And on next paragraph...
Linux foundner Linus Torvalds, first developed the operating system for his desktop and it rose to promince as a commodity Unix server.
Let them, if they want. The thing which anyone who is afraid of DRM, needs to remember, is that there is no such thing as a form of DRM that is unbreakable.
Especially on machines where you are able to get root privileges and replace any component of the OS (including kernel).
It pretty much shows Ubuntu 9.10 beating Snow Leopard most of the time.
Yay, we've come a long way. Unfortunately Karmic also displays a few significant regressions from Jaunty, hopefully someone is trying to do some profiling for those...
No, it cannot be "trivially integrated" with C code or another language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things.
That's why you should use the C side from the C++ side. I've had no problems at all using C libs from C++.
If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.
I'm more interested in productivity than "C++ standards conformance" (by which you probably mean using stl over homebrew containers).
I'm very suspicious about Gtkmm, as it doesn't seem to have a mindshare comparable to the C binding (actually it doesn't even come close). If even the Gnome community rejects it, why would outsiders pick it up?
I'd rather go with a toolkit where C++ (which is the language I'm using) is a first class citizen (like C in Gtk+). The bindings for Python are good enough for my needs.
Both GObject and QObject are non-standard object models because neither base language (C, C++) supports an object model that is suitable for GUI development.
QObject is not really "object model". Qt uses standard C++ objects, with some autogenerated.cpp files to provide for metaobject stuff. Everything still happens in confines of normal C++.
Also, the cpp files are autogenerated by moc, as opposed to having to write any of the boilerplate yourself.
GObject is harder to develop for, but easier to integrate into other software.
QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.
QObject uses syntactic tricks in C++ to make it easier to develop for in C++, but it's harder to integrate into, and extend, in other languages.
Yeah, but bindings somehow manage to exist. They may not be trivial or small, but unless you are the binding author yourself you don't need to care that much.
An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.
Qt app code is perfectly standard C++. C++ standard has nothing to say about whether one/some of the files to compile were generated by a tool (in this case, moc), or whether it reserves a few macros for "creative" use.
Qt works in practice much better than it looks on paper. Same can't be said for GObject - stable C ABI sounds great, but the development is still very painful and annoying and you start wondering whether it's all worth it. YMMV, some people still like it - I like to think C++ exists for a reason.
In what way is GObject driving people to Qt? That's totally irrelevant. There are fantastic C++, C#, and Python bindings (plus tons of other stuff like Ruby, Haskell, Java, and whatever else you can name).
I have heard only good things about PyGtk.
However, the "native" Gtk coding still happens in C. If the C++ binding was all that great, wouldn't people prefer it to the C binding? That doesn't seem to be the case; huge majority of Gnome core is written in C.
If C + Gtk (what we think of as "GObject" coding) was halfway decent, we wouldn't have things like Vala.
Wait, so does that mean there are no SWIG bindings for Qt? I just sort of assumed that for a big popular library like Qt, someone would have done a SWIG binding by now, simultaneously making it available in a whole bunch of languages..
SWIG doesn't really cut it for a C++ project with these size/performance requirements.
wxWindows does not have slots/signals nor meta objects and nobody misses them in fact MOC is the main reason wxWindows users are not switching to QT. To do lots of "casts" stinks in general also.
Python bindings should be designed to accommodate Python programmers, not C++ programmers.
I don't think we really want a big divide between Python and C++ programmers. The programming model of C++ Qt programming is not fundamentally broken, so it's not something that needs to be fixed more than what was already done. I'd like to see future breed of Qt programmers proficient wth both C++ and Python, not one over the other (Python isn't "dumb man's c++", it's "busy man's C++"). Both have their place.
Any friendly additions for python programmers can be done over the existing "raw" binding.
Sorry if my post came out as a whine, wasnt my intention. Of course anybody could do it in therory, but I'm not that guy.
My intention wasnt to slam the initiative, just a comment that so far its linux only, since that isnt the platform Im using, it just means that I have to wait a while until I can port my stuff to the Maemo platform.
You don't have to wait. You can use PyQt on all platforms already, and can switch to PySide when time is right. They are API compatible.
The point of PyQt is to remain faithful to the official C++ Qt API, making your skills & docs directly transferrable and code easy to port over in either direction.
PyQt has added a new, more pythonic API for signals, and PySide will do the same thing eventually. But it's essential that we retain almost-1:1 C++ mapping (though losing trivial stuff like QString).
Slashdot Mirror
It's a web app framework. Please click through the links.
I think Microsoft sees a lot of good work going on in the open source community and it wants to tap into that source of innovation.
Can we please kill the word "innovation" already?
I don't care about innovation, not should most people involved with software do. Ideas are trivial, implementation is king.
I think Pulse Audio's main problem though is that its a sound DAEMON (Akin to JACK, ESD, or Phonon.
Phonon is not a daemon, it's a library.
If they truly want "wide scale adoption" as indicated in the referenced article, they would be better off using LGPL or BSD/MIT type license. It's not like supporting a transmission format is rocket science, so GPL seems a bit weird choice for a license.
One of tomtom's specs says that:
GPLv2 permits to use software & library in proprietary programs
I don't know where they came up with that idea.
Personally I'd like to see the Uzbl features made available as advancements to existing browsers instead of creating a new one which has inherent GUI limitations.
This is written in python. If they bolted the functionality on ff/chrome, they would have needed to deal with js and c++. I guess it was just easier this way.
Just like folks at Apple realized with their OS X, we in the Linux world, need an alternative to X. I heard that Google Chrome OS will get rid of it entirely. I would like to hear from anyone who disagrees.
Nouveau guys seem to disagree:
http://icps.u-strasbg.fr/~marchesin/nvdri/fosdem1.pdf
From TFA:
The result is an improved desktop experience; benchmarks on memory tight desktops show clock time and major faults reduced by 50 per cent, and pswpin numbers (memory reads from disk) are reduced to about one-third. That means X desktop responsiveness is doubled under high memory pressure.
Furthermore, memory flushing benchmarks in a file server shows the number of major faults going from 50 to 3 during 10 per cent cache hot reads.
And on next paragraph...
Linux foundner Linus Torvalds, first developed the operating system for his desktop and it rose to promince as a commodity Unix server.
Let them, if they want. The thing which anyone who is afraid of DRM, needs to remember, is that there is no such thing as a form of DRM that is unbreakable.
Especially on machines where you are able to get root privileges and replace any component of the OS (including kernel).
Since it may not be obious to everyone what hugepages are, here's a link that may work out for you:
http://lwn.net/Articles/188056/
Start seeding those torrents!
No, wait...
7-zip compression
http://www.phoronix.com/data/img/results/ubuntu_karmic_leopard/9.png
(same for gzip)
Tachyon (game):
http://www.phoronix.com/data/img/results/ubuntu_karmic_leopard/24.png
(same for other raytracing stuff)
It pretty much shows Ubuntu 9.10 beating Snow Leopard most of the time.
Yay, we've come a long way. Unfortunately Karmic also displays a few significant regressions from Jaunty, hopefully someone is trying to do some profiling for those...
No, it cannot be "trivially integrated" with C code or another language. Anything that involves C++ involves dealing with global constructors, initialization order, new-vs-malloc, destructors, name mangling, exception handling, STL, template expansion, and RTTI, among many other things.
That's why you should use the C side from the C++ side. I've had no problems at all using C libs from C++.
If you want to program in C++, Gtkmm provides C++ programming support that is at least as good as Qt, it requires no preprocessor, and it is far more C++ standards conforming.
I'm more interested in productivity than "C++ standards conformance" (by which you probably mean using stl over homebrew containers).
I'm very suspicious about Gtkmm, as it doesn't seem to have a mindshare comparable to the C binding (actually it doesn't even come close). If even the Gnome community rejects it, why would outsiders pick it up?
I'd rather go with a toolkit where C++ (which is the language I'm using) is a first class citizen (like C in Gtk+). The bindings for Python are good enough for my needs.
actually it can do it already, done by Qt guys themselves, Qt can be integrated into glib mainloop and use GObject just fine
I think the original wish was to expose Qt api through GObject, which doesn't seem likely.
Both GObject and QObject are non-standard object models because neither base language (C, C++) supports an object model that is suitable for GUI development.
QObject is not really "object model". Qt uses standard C++ objects, with some autogenerated .cpp files to provide for metaobject stuff. Everything still happens in confines of normal C++.
Also, the cpp files are autogenerated by moc, as opposed to having to write any of the boilerplate yourself.
GObject is harder to develop for, but easier to integrate into other software.
QObject stuff can be trivially integrated to existing C & C++ code. Apart from the moc phase, nothing that special is happening.
QObject uses syntactic tricks in C++ to make it easier to develop for in C++, but it's harder to integrate into, and extend, in other languages.
Yeah, but bindings somehow manage to exist. They may not be trivial or small, but unless you are the binding author yourself you don't need to care that much.
An additional problem with QObject and Qt is that it doesn't even conform to C++ library standards very well.
Qt app code is perfectly standard C++. C++ standard has nothing to say about whether one/some of the files to compile were generated by a tool (in this case, moc), or whether it reserves a few macros for "creative" use.
Qt works in practice much better than it looks on paper. Same can't be said for GObject - stable C ABI sounds great, but the development is still very painful and annoying and you start wondering whether it's all worth it. YMMV, some people still like it - I like to think C++ exists for a reason.
In what way is GObject driving people to Qt? That's totally irrelevant. There are fantastic C++, C#, and Python bindings (plus tons of other stuff like Ruby, Haskell, Java, and whatever else you can name).
I have heard only good things about PyGtk.
However, the "native" Gtk coding still happens in C. If the C++ binding was all that great, wouldn't people prefer it to the C binding? That doesn't seem to be the case; huge majority of Gnome core is written in C.
If C + Gtk (what we think of as "GObject" coding) was halfway decent, we wouldn't have things like Vala.
Wait, so does that mean there are no SWIG bindings for Qt? I just sort of assumed that for a big popular library like Qt, someone would have done a SWIG binding by now, simultaneously making it available in a whole bunch of languages..
SWIG doesn't really cut it for a C++ project with these size/performance requirements.
wxWindows does not have slots/signals nor meta objects and nobody misses them in fact MOC is the main reason wxWindows users are not switching to QT. To do lots of "casts" stinks in general also.
What casts are you talking about?
But if I were to make a new project, personally, I'd certainly not use Qt but rather a much more modern technology.
Such as...
?
Python bindings should be designed to accommodate Python programmers, not C++ programmers.
I don't think we really want a big divide between Python and C++ programmers. The programming model of C++ Qt programming is not fundamentally broken, so it's not something that needs to be fixed more than what was already done. I'd like to see future breed of Qt programmers proficient wth both C++ and Python, not one over the other (Python isn't "dumb man's c++", it's "busy man's C++"). Both have their place.
Any friendly additions for python programmers can be done over the existing "raw" binding.
Sorry if my post came out as a whine, wasnt my intention.
Of course anybody could do it in therory, but I'm not that guy.
My intention wasnt to slam the initiative, just a comment that so far its linux only, since that isnt the platform Im using, it just means that I have to wait a while until I can port my stuff to the Maemo platform.
You don't have to wait. You can use PyQt on all platforms already, and can switch to PySide when time is right. They are API compatible.
Hell will freeze over before you'll see Qt embracing GObject. GObject is actually one of the things driving people to Qt.
The point of PyQt is to remain faithful to the official C++ Qt API, making your skills & docs directly transferrable and code easy to port over in either direction.
PyQt has added a new, more pythonic API for signals, and PySide will do the same thing eventually. But it's essential that we retain almost-1:1 C++ mapping (though losing trivial stuff like QString).
I'm just curious, so I ask. I have never had a need for it. Why is incognito mode so important to you? When exactly do you use it?
Surely you jest. Adult entertainment.
If you can make love to her, then she is a woman (provided that you know where you put your willy in)...
... or, if she uses the term "make love" for the act, she is a woman.