This week in KDE-CVS-Digest: CD burning application K3b begins to gain DVD writing functionality, continued fixes and improvements
to KWin, more on the binary compatibility debate, bug fixes, and more. Enjoy.
Very soon K3b will be slapping Nero's bald head in a mocking manner. It's a joy to see young apps mature in functionality, power and stability. It's synonymous to watching a young weak seedling grow into a formidable oak tree. Good job! :-)
what I don't like about K3b is that their logo bar in the middle takes up half of my 800*600 screen. Hope they'll remove that it's really annoying.
other than that, great app!
Any reason why you chose to use such a small resolution?
Besides that I agree that the logo bar should be possible to hide optionally for those who like to hide it for whatever reason, there's no wish report for it at bugs.kde.org so far though so one should create one.
I've old monitor. It works good, but it can display screen up to 1280x1024, but on refresh rate 60 Hz. So I select 800x600x85 Hz. What's wrong? IMHO KDE will use hardware resources in reasonable way. (In other words, why I need to upgrade so often?)
Well you can probably run at 912x684 at around 80Hz, which should still be confortable, and be big enough for any KDE app's fat UI to not be a problem.
Just btw the cvs version of K3B allows you to turn the logo bar off. It was a welcome option for me, as it will be to many others it seems. And yeah, K3B is great. When I used Windows I used Nero, and when I first started using Linux I was very unhappy till I found K3B, which is everything I ever wanted in a burning program.
Just go to settings->show document header, and disable it. you may want to turn off the media player as well.
Actually, many people in poor countries still use 800x600 resolution. And even college students that can't pay themselves a new monitor do.
So I think it's still too early to consider 800x600 outdated, and a smaller logo should be considered. Plus I happen to hate big logos taking so much screen space :(
it shouldn't matter WHAT resolution you run. GUI layout should be dynamic. And huge logos have no place in the middle of an app, anyway; that's what about boxes, docs, and websites are for.
The resolution I use is MY choice, and not the app's designer.
K3b Setup is the worst offender I've ever seen.
Please, use moderation with logos.
> Actually, many people in poor countries still
> use 800x600 resolution
In rich countries too, for example my old iBook here in Switzerland ;-)
Hey, I buy a new $3000 desktop every 1-2 years, but I see myself staying at 800x600 forever. Maybe it's because I've been computing in the 80x25-char console interface for a decade, but for me it's a matter of principle: you shouldn't need higher rez except for quality games (which I'm not into). When you spend 16 hours a day reading / writing text, higher resolution only increases eye strain.
So you still use a 8-pins dot-matrix printer for printouts, too? Not a snazzy, lovely 600dpi laserprinter? Because if the size of the glyph stays the same, the number of dots that make up the glyph are important.
Me, I've got a 1600x1200 15" panel on my laptop -- 133 dpi is nice, no laser printer quality, but every glyph looks printed compared to any screen I've used before.
Where do you get glyphs that are big enough?
As long as you don't lie to X11 by forcing it to use a wrong dpi setting, everything works out of the box. A 10pt font will have the right dimensions no matter what, if only the dpi setting is correct.
Those using old laptops can't increase the screen resolution. My laptop is 3 and a half years old and does 1024x768, but when I bought it many similar laptops were limited to 800x600.
Also, I find VNC (or Xnest) sessions can be more comfortable with a screen size of 800x600 because it fits within a 1024x768 screen.
Almost ontopic: Any ideas as of how to convert a Nero .nrg to something you can burn under 'nix? Preferably using k3b, of course.
Also, by the way: Why does k3b have to be installed in a specific directory (namely, the one kde is installed in) to work? This is mention in the last faq, but it doesn' t say why it is so. I would like to have k3b in /usr/local/k3b, and that doesn't work.
.nrg is in ISO format. Just rename the file to .iso and it'll work.
No it's wrong !!!!
Convert NRG to ISO with nrg2iso from http://gregory.kokanosky.free.fr/v4/linux/nrg2iso.en.html
Thanks... it's also in kubuntu (and friends), so an apt-get install nrg2iso works fine.
>>Very soon K3b will be slapping Nero's bald head in a mocking manner
First of _all_, people have issues with a 800x600 resolution issue here and you are talking about "slapping Nero's bald head".
yeah - very soon now..
Some people were complaining, again, that major features were missing in this report. Maybe it would be a good idea to have a keyword in the commit message like DIGEST?
Drop me a line if there is something I missed. It definitely is possible.
Another factor this week was my ISP mail server was borked for most of thursday, so there was at least a day's worth of commits that didn't even get looked at. I think there were 250 messages from kde-cvs when the mail started flowing again. They will be included in next week.
Again, complain vociferously if something is missing. Please.
when you add something to the Digest, could you add a small changelog to the top or the bottom of the page, or highlight new entries with a small icon in the table of contents and in the entries itself? Or post details in the comments section? Reason: I already read it and don't want to read everything again just to find out what's new in there. Yes, I'm that lazy! :)
Well - just a suggestion. :)
You lost me there. Do you mean from when I upload the draft version to when I announce the finished one?
Nope, sorry :). I'm referring to the exchange between you and Tim Jansen. According to Tim, the intitial publication of this weeks Digest lacked coverage about some neat things - you encouraged him to point 'em out to you so you'd be able to add them. For me as reader, that means there's a strong possibility that I missed something because I read an earlier revision. So maybe there's need for an in-document-changelog?
I won't add items to an exising digest. If there are things I missed, they will be included in the next week. The only things I change are errors or mis-attributions.
Ah :). Imaginary problem solved, then. Thanks!
in lieu of a DIGEST CVS keyword, can we just CCMAIL you in the log if we think something is worthy of the digest?
Good idea. It should catch my attention :-}
Thanks a lot dude! I thought there wouldn't be any for this week and I was dissapointed and now I just woke up and found one here =) THANK YOU!
I'm especially glad that K3b will get DVD support, that will rock!
THough its dissapointing to know taht Konqueror is now a whopping 10% slower at displaying JPEGS (the most widely used image format on the entire web!!!). THIS IS A MAJOR SLOWDOWN, I hope it will become faster.
Honestyly I couldn't even notice the problem in JPEG rendering, it looked the same in Mozilla and Konqueror to me.
Check out the bug report yourself.http://bugs.kde.org/show_bug.cgi?id=60000
It doesn't matter Mario, you probably wouldn't notice the difference in rendering time. Anyway the bottleneck is the network performance.
Check out the code, see if you can improve it.
Sorry, i don't know how to code. But, how could I not notice it, 10% sounds like a big decrease in image rendering.
10% is inconsequential if the rendering time is 12ms. I have no idea how fast JPEGs render, but I'm sure someone more knowledgable would confirm that it's fast enough not to worry about.
using konqueror from cvs (kde 3.1.90),i just tried the link u provided on your bug reporthttp://www.emutalk.net/showthread.php?s=&threadid=12952 and I can tell u it's displaying the jpeg at normal speed as far as I can tell it was just as fast as mozilla.
Would this be easy to do http://bugs.kde.org/show_bug.cgi?id=60202 it seems so easy and just makes so much sense. I really hope it will make it in 3.2.
Be sure to check out other wishlist/bugs of mine if you agree with me.http://tinyurl.com/ef3m
Alex, I see you just keep doing it: please stop posting long links here.
I am amazed everyday at what some people can come up with! That's a great idea.
Check out the new url! http://tinyurl.com/ef3m =)
Why? I'm just curious; what's the problem with "long links"?
they make the width of the page really wide, so you have to scroll back and forth to read every post...it's pretty annoying.
BC (Binary Compatability) for libraries has already been achieved with another operating system that was very popular a few years back, namely the Amiga Operating System. The Amiga's OS used a technique of using a jump table at the beginning of a library of which stayed constant with new routines being added to the end of the table.
This would be a great idea for the KDE libs, it would require breaking BC one more time, but after that no more.
Do you have any links for information about this? What are the penalties for using such a system?
The only problem was when some of the demo crews and some games decided to hit the amiga's hardware directly or use some "internal use" library code instead of using the published routines.
All programs that were written correctly (useing the published library routines) worked on all versions of the operating system. The people who developed the libraries could add extra (optional) parameters to library functions and were able to extend a libraries functionality by adding new routines that were linked at the end of the library jump table.
It was great, but it was before C++ came along.
For languages like C, it's perfect. Windows used to do it the same way, btw....
But KDE is exporting C++ interfaces, which have each their own virtual tables...
Such a thing is already done in KDE with the wonderful powers of ELF.
Where Amiga adds a "jump table at the beginning of the library", ELF makes a relocation table. Hence, KDE can add new functions without trouble. The problem is in fact that the size of structures when we add virtual methods.
Let me describe:
virtual void setValue(int c);
Same thing in C:
typedef struct Foo
void (*setValue)(Foo *, int);
so, now, sizeof(Foo) is equal to sizeof(void*), in the case of C; C++ may not necessarily add the virtual-table inline with the class object itself (so you might not get too much excitement by testing this out).
This means, that when you do the following:
Foo * foo = new Foo;
and in C:
Foo *foo = (Foo*)malloc(sizeof(Foo));
The compiler can identify the sizeof the class Foo at compile time (sizeof(void*)), so it actually writes
Foo * foo = (Foo*)malloc(4); (in a 32 bit process)
When someone adds another virtual to class Foo in libfoo.so, the sizeof(Foo) increases by a notch. That's no big deal, the problem when an application that uses class Foo, it calls malloc(4), even though it should be calling malloc(8).
That is the "fragile base class" problem which comes up whenever you use gnu C++ to create shared libraries. BeOS solved this problem by just adding some spare virtual functions to classes that they wanted to extend in the future. It is a hack, but it works to preserve binary compatibility.
And by the way, adding virtual functions does not increase the size of the object, it merely increases the size of the virtual method table. You can have an object with thousands of virtual methods that uses just a few bytes per instance.
Very interesting idea. KDE could use that as well.
Currently KDE is using the virtual_hook() methods in all classes that can be used to make non-virtual methods behave like a virtual...