Like before, there's only one window for each folder, and the folder window remembers its position, size, and display properties. What's new is just that you can view sub-folders inside a folder window without opening a new window.
Re:They should stick with C
on
The GNOME Roadmap
·
· Score: 3, Informative
Evolution 2 will not depend on Mono, and Ximian have assured the GNOME community that they have no plans to make future versions of Evolution depend on Mono until Mono is part of the GNOME Platform - something that is also very unlikely to happen.
Qt is not the place to start C++ if you want to learn C++ rather than Qt. You'll be shown Qt C++ language extensions that won't work in non-Qt projects, and you'll be shown unusual Qt- or KDE-specific build tools rather than standard GNU build tools. It's not as bad as learning C++ via Visual Studio and MFC, but it's not C++.
> No, but unfortunately it's currently the best
> solution for programming large desktop
> application.
Everybody's heard me say it before but I like to repeat it for the record: Many of those who _really_ like C++ _really_ dislike QT because of it's lousy use of C++. See the gtkmm FAQ for particulars.
1. Choice is a good thing. People want normal C++ syntax and semantics so we give it to them. This allows code that uses 2 libraries to use a consistent memory management model with the classes from both.
2. Unusual memory management should be easy to recognise. In gtkmm 1.2 widgets whose memory is managed by the container must be explicitly manage()d, and in gtkmm2 widgets which must be managed by the runtime system are accessible via reference-counting smart pointers.
3. On the contrary, it makes perfect sense for a button to be deleted when its parent window is deleted. QT deletes it at the same time as gtkmm, but makes life difficult by forcing you to use a pointer and new() instead of a member instance.
You must be thinking of GTK+, not gtkmm, as one of the main differences in gtkmm is the use of C++ class method names instead of those pseudo class prefixes in the C function names.
A GUI toolkit, like any library, should allow its objects to be created on the stack or on the heap. QT does not. I don't see that as a feature.
Re:Qt has better documentation
on
GTK-- vs. QT
·
· Score: 1
This is misleading. It is very easy to subclass gtkmm widgets to change their behaviour and contents. Very low level stuff is possible but rarely necessary.
Re:wxWindows (slightly OT)
on
GTK-- vs. QT
·
· Score: 1
A few months ago we made added a vast amount of reference documentation to gtkmm.
Your experiences 3 years ago are irrelevant to a discussion of the situation today, as are your wilfully uninformed imaginings.
Re:GTK+ C++ wrappers, more experiences
on
GTK-- vs. QT
·
· Score: 1
That is not true. All of the GTK+ 1.2 widgets have been fully wrapped for at least 1.5 years now and the GNOME widgets have been fully wrapped for 6 months. The APIs have been completely binary and source stable ever since.
Well, you wouldn't get far with QT without using signals, so your point isn't very relevant.
The QT api is far from elegant. I believe that's because it wasn't developed in the open. Even now there's no public mailing list on which the developers discuss its development. Also, because the licencing seems (I'm not 100% sure of this) to protect them from any threat of forking, they will never make any major changes such as ditching their language extensions.
Regarding MFC, anything would be better than that.
QT uses a modified version of the C++ language. You cannot compile QT code without first running it through the moc preprocessor. Are those alarm bells ringing for you yet?
During his GUADEC2 keynote he said that he doesn't use any GUI desktop. And his famously strange behaviour in front of the GNOME hackers at GUADEC2 was all the more insulting because he'd seen GNOME for the first time a few hours before.
I'm not certain that this is what you mean, but if you are writing a templated *class* you can use the *typename* keyword to get at the type in the template declaration. You can then use that typename as an argument in a class method.
Incidentally, MS VC++ doesn't require this - it lets you use a regular typedef. But strangely, I only found out about it from reading the MSVC++ documentation after I couldn't get the typedef to work with egcs.
Why aren't these companies getting punished for their abuse of the patents system? When their patents are shown to be invalid, they should have to compensate the companies who lost out because they couldn't use the technology.
This kind of law (or test case) would protect the competitiveness of the marketplace just like anti-trust and anti-dumping laws.
Slashdot Mirror
Please please please please use the GNOME Logo from this century on Slashdot:
http://live.gnome.org/LogoGuidelines
> How is this new "spatial tree" spatial?
Like before, there's only one window for each folder, and the folder window remembers its position, size, and display properties. What's new is just that you can view sub-folders inside a folder window without opening a new window.
Evolution 2 will not depend on Mono, and Ximian have assured the GNOME community that they have no plans to make future versions of Evolution depend on Mono until Mono is part of the GNOME Platform - something that is also very unlikely to happen.
Qt is not the place to start C++ if you want to learn C++ rather than Qt. You'll be shown Qt C++ language extensions that won't work in non-Qt projects, and you'll be shown unusual Qt- or KDE-specific build tools rather than standard GNU build tools. It's not as bad as learning C++ via Visual Studio and MFC, but it's not C++.
You can mount an sftp, smb, ftp (and others) server on your GNOME 2.6 desktop. That is thanks to gnome-vfs.
Nautilus is much faster in GNOME 2.6. And it was faster in 2.4 than 2.2, and faster in 2.2 than 2.0.
There are also several specific performance improvements in particular GTK+ widgets, and the GNOME Help system has had an incredible speed up.
Linux kernel 2.6 also makes a very noticeable difference, with it's pre-emptive schedule that gives priority to things that the user is doing.
I see no reason to jump to that conclusion.
GTK+ is not a moving target. It's had API stability for a long long time.
>> Not everyone likes C++
> No, but unfortunately it's currently the best
> solution for programming large desktop
> application.
Everybody's heard me say it before but I like to repeat it for the record: Many of those who _really_ like C++ _really_ dislike QT because of it's lousy use of C++. See the gtkmm FAQ for particulars.
1. Choice is a good thing. People want normal C++ syntax and semantics so we give it to them. This allows code that uses 2 libraries to use a consistent memory management model with the classes from both.
2. Unusual memory management should be easy to recognise. In gtkmm 1.2 widgets whose memory is managed by the container must be explicitly manage()d, and in gtkmm2 widgets which must be managed by the runtime system are accessible via reference-counting smart pointers.
3. On the contrary, it makes perfect sense for a button to be deleted when its parent window is deleted. QT deletes it at the same time as gtkmm, but makes life difficult by forcing you to use a pointer and new() instead of a member instance.
You must be thinking of GTK+, not gtkmm, as one of the main differences in gtkmm is the use of C++ class method names instead of those pseudo class prefixes in the C function names.
A GUI toolkit, like any library, should allow its objects to be created on the stack or on the heap. QT does not. I don't see that as a feature.
This is misleading. It is very easy to subclass gtkmm widgets to change their behaviour and contents. Very low level stuff is possible but rarely necessary.
A few months ago we made added a vast amount of reference documentation to gtkmm.
Your experiences 3 years ago are irrelevant to a discussion of the situation today, as are your wilfully uninformed imaginings.
That is not true. All of the GTK+ 1.2 widgets have been fully wrapped for at least 1.5 years now and the GNOME widgets have been fully wrapped for 6 months. The APIs have been completely binary and source stable ever since.
So you see, I'm qualified to compare the APIs, though of course I'm biased.
Well, you wouldn't get far with QT without using signals, so your point isn't very relevant.
The QT api is far from elegant. I believe that's because it wasn't developed in the open. Even now there's no public mailing list on which the developers discuss its development. Also, because the licencing seems (I'm not 100% sure of this) to protect them from any threat of forking, they will never make any major changes such as ditching their language extensions.
Regarding MFC, anything would be better than that.
QT uses a modified version of the C++ language. You cannot compile QT code without first running it through the moc preprocessor. Are those alarm bells ringing for you yet?
During his GUADEC2 keynote he said that he doesn't use any GUI desktop. And his famously strange behaviour in front of the GNOME hackers at GUADEC2 was all the more insulting because he'd seen GNOME for the first time a few hours before.
Note that RMS doesn't use any desktop or GUI. He doesn't even use GNOME.
And now illegal to use without giving your private key to the UK government.
This bill makes it a crime to use encryption and keep the keys to yourself.
If a US citizen communicates with a UK citizen, then visits the UK, does he get put in jail?
If a UK citizen living in the US uses encryption does he get put in jail when he goes home?
I'm not certain that this is what you mean, but if you are writing a templated *class* you can use the *typename* keyword to get at the type in the template declaration. You can then use that typename as an argument in a class method.
Incidentally, MS VC++ doesn't require this - it lets you use a regular typedef. But strangely, I only found out about it from reading the MSVC++ documentation after I couldn't get the typedef to work with egcs.
Why aren't these companies getting punished for their abuse of the patents system? When their patents are shown to be invalid, they should have to compensate the companies who lost out because they couldn't use the technology.
This kind of law (or test case) would protect the competitiveness of the marketplace just like anti-trust and anti-dumping laws.