Trolltech has announced the release of Qt 3.3.4 which is a maintenance release including many bug fixes and optimizations. The final Qt 4.0 release is now anticipated for late second quarter of 2005 with two
interim beta versions to be released in March and May.
Dot Categories:
Comments
And the best one:
QIconView
Make it possible to move selected icons short distances
(i.e. to a position where there is a selected icon).
This finally solves #35203
To nitpick, this is only the third most hated bug.
Great!!!!
BTW: It might not have been the most hated bug on bugs.kde.org
but it was definitely my very personal "most hated bug" as it made
the organization of ones desktop icons basically impossible.
It'll help half the problem, but it probably won't stop the icons rearranging themselves every time I log back into KDE. :-/
You shouldn't experience this anymore with KDE 3.4 I think.
I hope that's the case, because it still happens on the beta.
I've largely dismissed this as an "out of my control" issue which I've come to accept.
It should be ok in 3.4, see bug report #91575.
Just deactivate snap to grid, doesn't look as neat but at least the icons will stop rearranging.
Unfortunately this doesn't always help. AFAIK its a bug
during login where collisions are checked and "corrected"
before the icon texts are wrapped. For details see the report.
Then why is the report still open?
Your friendly bugzilla nagbot
qt-copy has not been updated yet?
It is a QT update we are waiting for to get the option to configure extra mice buttons in KDE, right? Anyone seen anything of it? Imwheel must die.
wheels work fine 'out-of-the-box' w/o imwheel. suse 9.x and fedora 3 tested.
with the old qt btw...
Wheels aren't the problem. The problem is mouses with extra buttons on the side. Qt/KDE only handles 5 buttons on a mouse right now, and that includes up and down on the wheel, so you can't make back/forward or other buttons without having imwheel or some other program that converts the mouse clicks to X key combinations (on my system, it converts one to Alt-left and the other to Alt-right for back and forward while web browsing).
Being able to set shortcuts for these buttons in KDE directly would be much better.
xmodmap is your friend, no nead for extra programs ;)
His point is that KDE doesn't seem to have a friendy GUI for configuring extra mouse buttons, e.g. binding actions and key combinations to them, and doing so on a per-window/application basis even like imwheel or Windows allow you to do. It's a usability issue.
How would you go about to do this in KControl?
Simple, map the mouse-events with X11-keys, and then configure those keys in khotkeys in kcontrol.
What's the xmodmap command to remap a pointer button into a keycode? It's not in the man page.
To answer my own question...
You can't do anything with xmodmap to remap a pointer button to a keycode. The only alternative I found was to use xbindkeys to execute something like "xvkbd -xsendevent -text '\[XF86Back]'" on a click.
At this point, one has to ask how this is any better than using imwheel.
Even if a solution were possible with plain xmodmap, it still requires hacking around with text configuration files. KDE has a gui for all sorts of keyboard remapping options, I don't see why mapping extra mouse buttons should be any different (once it's possible). Mapping mouse buttons to keycodes is not a good solution.
One last question: the KHotKeys allows gestures to be activated by buttons 2 - 9. How is this possible while general mapping of 7 - 9 button mouses isn't?
I couldn't get xmodmap to do 'hold windows key, press other key, release windows key'; it would always press one, release, press other, release. I don't know whether this is because of my own incompetence or a limitation in xmodmap, but either way, imwheel does work.
C++ is a terrible pain in the ass compared to Java, Python, C# and D for many reasons, but by far the most frustrating thing is the absence of a garbage collector.
Trolltech should create one to make C++ compete with the new, better and easier to use languages now in the spotlight.
If you want a garbage collector for C++ then use one, there are a number around eg. http://www.hpl.hp.com/personal/Hans_Boehm/gc/ that said, if you keep track of your object lifetimes decently this is really a non-issue. Garbage collectors are useful, but for well designed code they're hardly a big issue.
Rich.
And I take it Qt will work well with the garbage collector. Is that correct?
Anyway, even if the code is well designed, it's still an annoying and unecessary complication to manage all the low level memory stuff and I think a Garbage Collector should be default.
Then you are dumb.
Garbage collectors BY DEFAULT would completely unhinge the expected performance of manually managed memory, dipshit.
Someone should moderate this guy off this site. His posts are repeatedly rude.
Sorry, but you are at the same time stupid and rude.
* Garbage collection does simplify things. Qt´s parent-deletes-child does too, but often when you are using multiple libraries from multiple vendors, figuring out the object-lifetime policies of each is quite a chore.
* Garbage collection has a almost negligible impact on performance. Unless you are writing a really time-sensitive piece of code like, say, a driver where you have a required maximum time for a code path (and trust me, most drivers don´t do this either), you simply won´t notice.
The second issue is even more true if your garbage collector is not simply a reference counter, but something like mark and sweep, and specially so if you can do delayed garbage collection. I think Boehm´s gc does that. Obviously, if you delay deletion until you are outside the time-sensitive sections, the performance may even be better than if you manually delete the objects (not usually, but it *might*).
Manual garbage collection is simply another kind of premature optimization.
No garbage collection has a negligible algorithmic cost. The actual performance cost is often quite bad depending on the used method. The need to make regular sweeps of all memory means that the common practice of swapping unused parts from memory to disk works very poorly with garbage collected programs. Using garbage collection in something as KDE would be a disaster.
But consider the managed code scenario, where you've frequently executing chains of destructor methods to delete things. Not only is there the overhead of calling an often virtual method, but there's the fact that free() is usually quite an expensive call.
Garbage collection frees you from this; it doesn't entirely undo the performance hit it caused by the GC checks, but it does mitigates it. Also garbase collection prevents memory leaks. Good GCs can offer good performance for desktop applications. For libraries, I'm not so sure.
--
I should point out that another solution to destructor/free() problem is to create and manage your own memory pools. Instead of freeing an object you just return it to the pool, and reclaim it when you want it again.
When GC release the memory, it must call destructor/free()
or at least free it back to the pool.
So, your point is really pointless. =P
The main problem with GC like it can be seen in Java
is sluggish performance.
It works nicely in "stupid" scenario, but as soon as
you are working with large memory hungry application, GC collapse.
I think that Qt like VCL are using Parent to Child deletion ownership is the right thing to do.
It works great, it's efficient and it makes sense.
The parent knows when it's deleted; therefore, it can safely delete its children.
Moreover, it's a nice design pattern that works well.
If you are dealing with other kinds of weird pointer stuff then they exist stuff like QGuardedPtr and similar.
The major problem with GC is that you cannot plan ahead of time deletion
and force deletion when its actually needed.
Unless for trivial cases, GC algorithms cannot know what you want to do
and implement a good algorithm for every corner case.
Also, GC especially in Java, don't know that a huge sub-pool or circular dependancy subtree can be safely deleted.
For instance, let the following "simple case" scenario:
Parent to child
A->B->C->D->E
plus the following internal pointers:
E->C, D->B, E->B, D->C
I want to delete B and everything down the road (C,D,E).
Most GC won't be able to safely delete B,C,D,E completely,
because of circular dependancies.
Hint, this won't work:
B = null;
System.gc();
But this works:
delete B;
// Assuming that the child destructor don't delete twice circular pointer.
If you think that's too "simple" imagine a lenghty
circular linklist of 16KB buffers, with pointers all over the place.
OR
Imagine few 1024x768x16 Image Z-buffer in Java and wonder
why 512MB of RAM is insufficient to run the application
and that it runs out of memory after few minutes...
even though you do:
buffer = null;
System.gc();
Of course, you can say that's not the proper way to do it,
you should implement your own memory pool saving algo in Java...
but the above "should work" if your GC is sooo bright.
Seriously, I think that having parent/child ownership is the way to go.
BTW, if you think malloc/free are inefficient you can always override them
with #define's and implement some custom memory pool mechanism.
Have a nice day!
Sincerely,
Fred.
QUOTE BEGINS:
When GC release the memory, it must call destructor/free()
or at least free it back to the pool.
QUOTE ENDS
A regular free() needs to perform a lot of work each time free() is called, whereas a GC only needs to perform a lot of work once per GC cycle.
In total they need to perform the same number of effective free()'s, but the GC has more information and can make smarter decisions about how to free things and about memory layout after the free()'s, etc.
Now, I'm not saying you shouldn't be able to give the GC hints, but allowing force delete and the like means that you lose a lot of the built-in safety of the language.
You are wrong. All modern garbage collectors are not fooled by circular references. There are well-known algorithms to solve that problem; they work quite well. You say you cannot "force" deletion when it is "actually needed". When is it actually needed? When there are no more references to the object; except for circular ones. Which is exactly when GCs delete it!
Your little example with the Z-buffer is wrong. If you really removed all references to the Z-buffer, then Java would have deleted it, without you needing to call "System.gc()" (which is a sign of desparation and bad programming). Since you didn't remove all references to the Z-buffer, Java kept it. Would you rather do it in C++, where your program would crash instead after trying to use the Z-buffer that you deleted? Perhaps Java should provide a tool to figure out what is still referencing an object, to make debugging this situation easier. But GC is still better, because it is safer. In C++ this situation is a security hole and a crash bug; in Java it merely makes things slow.
The main problem with GC like it can be seen in Java
is sluggish performance.
You are wrong in this point, Java has a sluggish performance because:
- The framework used for the UI is terribly slow, and suffers from some bad design desicions.
- The VM has a lot of cool optimizations taken from Self (http://research.sun.com/self/), but I think that is a big ball of mud. The VM is bloated with a lot of things (like security management, modifications to support generics, an ugly support for metaprogramming, etc, etc), so the memory management is very complicated in Java, hence is slow compared with other OO languages like Smalltalk.
The problem with GC in C++ is that objects doesn't have a common memory format, so making a GC in C++ is complicated and error prone.
Take for example Smalltalk (don´t look at Java or .Net for examples, those languages are really legacy, the only think that makes them "modern" or cool is marketing). In Smalltalk the objects in memory are really simple, so the VM is very fast, and can do complicated things (like "hot" code replacement or metaprogramming) very simple.
C++/Qt fans are gonna to hate me, but if you want a nice programming enviroment dont't use C++...
I see QT like a low level framework for UI, I know that QT has a lot of things (like strings, collections, etc), but even them C++ is still a pain in the ass.
Is better to use some other language (like Smalltalk for example ;-) ) and let the "dirty" things (like drivers, or OS related functions) for C/C++ or assembler, there isn't any noticiable speed loose with this change.
For those who think that: "high" level language = slow and bloated processes, them look at this http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Introducti...
They made a system with graphics, GC, a VM that worked on a... Apple Lisa.
Regards,
Diego.
PD1: Sorry for my english, is pretty bad :)
PD2: If you dind't notice I'm a Smalltalk fan... so as a KDE fan, I'm wishing some integration from one of the best smalltalks (VisualWorks, http://www.cincomsmalltalk.com/) with KDE.
With generational GC, this concern is mitigated. The entire memory pool is swept very rarely if at all, allowing disk swapping to work as intended.
I was just doing some quick googling on the subject, and it appears that some of the most advanced GC algorithms that also compact memory may actually improve performance over manual management. Compacting memory helps keep the working set in the processor's cache, reducing nasty cache misses.
--
Simon
I don't think any GC in wide use performs compacting aggressively enough to have a significant benefit in this area. I imagine that in the general case measuring all memory accesses, figuring out how to compact things, and actually compacting them in memory (requiring copying each moved object and updating all references to that object, for good compaction) would outweigh the performance gain. Perhaps a novel research GC might do it, but I don't think any general-purpose ones do.
However, GCs can improve performance when using large numbers of small objects, since they do memory allocation/deallocation in large batches instead of every time an object is made/destroyed. Also, if GC replaces a complex manual memory management scheme such as reference counting, it can perform better (of course in addition to massively reducing code complexity, which has many many benefits).
"I don't think any GC in wide use performs compacting aggressively enough to have a significant benefit in this area."
Well this guy is claiming exactly that using C# and Microsoft's runtime:
http://blogs.msdn.com/ricom/archive/2005/01/05/347361.aspx
http://blogs.msdn.com/ricom/archive/2005/01/07/348691.aspx
--
Simon
The garbage collector in Python has been benchmarked. It adds 4% overhead. I would hardly call that "quite bad".
http://www.arctrix.com/nas/python/gc/
"Using garbage collection in something as KDE would be a disaster."
The user probably wouldn't even notice it was there.
--
Simon
But I can assure you that the developer would.
I also read that Python 2.4's garbage collector produces less than 3% overhead.
And on the other hand it gives the developers 10%-20% productivity gain, so they don't care anyway.
Well, I write Qt programs on a gc environment, and I don´t.
Oh, sure, it may be more noticeable if Qt itself was gc´d but really, 4%? 3%? That´s noise. All gentoo users get more than that slowdown by compiling on the background anyway, and they love it ;-)
Does Trolltech have any plans on officially supporting bindings to languages other then C++?
Unfortunately, I don't think so. It would be great to have up to date Python bindings though :)
The Python bindings(Qt) are probably one of the most up to date 3rd party bindings out there, for any project. The bindings are always released shortly after Qt, and because of their autogeneratedness the small delay is nearly all test related. But Phil Thompson usually don't release the bindings for Qt betas, a policy I for one agrees with. Why bother with beta bindings to a beta toolkit.
So you're saying Python Qt supports Python 2.4 and Qt 3.3.4?
PyQt supports Qt versions 1.43 to 3.3.3 and Python versions 1.5 to 2.4. PyQt will normally work with newer versions of Qt and Python without change. If changes are required then these are normally added to snapshots within a few days.
On the aKademy i heard they where concidering Java and C#/mono as possible languages to officially support bindings for.
When trolltech decides, i go and master that language. Java never was really cross -desktop (platform) on the GUI, it just look like shit on every platform. Mono/GTK# is becomeing a good alternative, yet it also doesnt use native widgets on each platform/desktop.
I'm still a bit on hold regarding managed code.
Did they say anything about Python?
"On the aKademy i heard they where concidering Java and C#/mono as possible languages to officially support bindings for."
They did talk about experiments about how to integrate Qt with .NET, with callbacks to allow C++ virtual methods to be overriden in C# and so on. As far as I know they aren't developing or supporting the development of language bindings for the complete Qt api at present.
It's very difficult to sell a java GUI toolkit like QtJava, if the competition is entrenched and give away their stuff for free as they do with Swing or SWT.
"When trolltech decides, i go and master that language."
I think dynamic languages like python, perl and ruby work particularly well with Qt and all have very good bindings - PyQt, PerlQt and QtRuby. So I wouldn't wait for trolltech to tell you what to do - if you master the Qt api in one language you can easily switch to another because they are all pretty similar.