KDE-CVS-Digest for June 20, 2003

Saturday, 21 June 2003  |  Dkite

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.

Comments:

K3b vs Nero... - Mystilleef - 2003-06-21

Hello, 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! :-) Regards, Mystilleef

Re: K3b vs Nero... - bob - 2003-06-21

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!

Re: K3b vs Nero... - Datschge - 2003-06-21

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.

800x600 - gray - 2003-06-21

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?)

Re: 800x600 - David Walser - 2003-06-21

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.

Re: 800x600 - lrandall - 2003-06-22

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.

Re: 800x600 - Peter Backlund - 2003-06-22

Just go to settings->show document header, and disable it. you may want to turn off the media player as well.

Re: K3b vs Nero... - Pawn - 2003-06-22

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 :(

Re: K3b vs Nero... - Lee - 2003-06-22

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.

Re: K3b vs Nero... - ccp - 2003-06-30

Hear, hear! 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. Cheers, Carlos Cesar

Re: K3b vs Nero... - Stefan Heimers - 2003-06-22

> Actually, many people in poor countries still > use 800x600 resolution In rich countries too, for example my old iBook here in Switzerland ;-)

Re: K3b vs Nero... - Alex - 2005-03-13

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.

Re: K3b vs Nero... - Boudewijn - 2005-03-13

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.

Re: K3b vs Nero... - ca - 2005-03-14

Where do you get glyphs that are big enough?

Re: K3b vs Nero... - Boudewijn Rempt - 2005-03-14

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.

Re: K3b vs Nero... - cbcbcb - 2003-06-23

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.

Re: K3b vs Nero... - mr. Anonymous Coward - 2003-06-23

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.

Re: K3b vs Nero... - Rayiner Hashem - 2003-06-25

.nrg is in ISO format. Just rename the file to .iso and it'll work.

Re: K3b vs Nero... - czara1 - 2004-08-29

No it's wrong !!!!

Re: K3b vs Nero... - Sander Jonkers - 2004-09-21

Convert NRG to ISO with nrg2iso from http://gregory.kokanosky.free.fr/v4/linux/nrg2iso.en.html

Re: K3b vs Nero... - Evan "JabberWokky" E. - 2006-10-25

Thanks... it's also in kubuntu (and friends), so an apt-get install nrg2iso works fine.

Re: K3b vs Nero... - AC - 2003-06-23

>>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..

Missing commits / DIGEST ? - Tim Jansen - 2003-06-21

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?

Re: Missing commits / DIGEST ? - Derek Kite - 2003-06-21

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. Derek

Re: Missing commits / DIGEST ? - Eike Hein - 2003-06-22

Derek, 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. :)

Re: Missing commits / DIGEST ? - Derek Kite - 2003-06-22

You lost me there. Do you mean from when I upload the draft version to when I announce the finished one? Derek

Re: Missing commits / DIGEST ? - Eike Hein - 2003-06-22

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?

Re: Missing commits / DIGEST ? - Derek Kite - 2003-06-22

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. Derek

Re: Missing commits / DIGEST ? - Eike Hein - 2003-06-22

Ah :). Imaginary problem solved, then. Thanks!

Re: Missing commits / DIGEST ? - LMCBoy - 2003-06-22

Derek, in lieu of a DIGEST CVS keyword, can we just CCMAIL you in the log if we think something is worthy of the digest? regrads, Jason

Re: Missing commits / DIGEST ? - Derek Kite - 2003-06-22

Good idea. It should catch my attention :-} Derek

Whoo! - Alex - 2003-06-21

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!

Cool stuff! - Mario - 2003-06-21

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

Re: Cool stuff! - MxCl - 2003-06-21

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.

Re: Cool stuff! - Mario - 2003-06-21

Sorry, i don't know how to code. But, how could I not notice it, 10% sounds like a big decrease in image rendering.

Re: Cool stuff! - MxCl - 2003-06-22

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. Thanks, Max

Re: Cool stuff! - pat - 2003-06-22

using konqueror from cvs (kde 3.1.90),i just tried the link u provided on your bug report http://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. cheers, pat

Suggestion - Alex - 2003-06-21

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

Re: Suggestion - Datschge - 2003-06-21

Alex, I see you just keep doing it: please stop posting long links here.

Re: Suggestion - Anonymous - 2003-06-21

AOL, http://tinyurl.com

Re: Suggestion - Alex - 2003-06-21

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 =)

Re: Suggestion - ac - 2003-06-22

Why? I'm just curious; what's the problem with "long links"?

Re: Suggestion - LMCBoy - 2003-06-22

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 for KDE libraries - Ian Ventura-Whiting - 2003-06-21

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.

Re: BC for KDE libraries - MxCl - 2003-06-22

Do you have any links for information about this? What are the penalties for using such a system?

Re: BC for KDE libraries - Ian Ventura-Whiting - 2003-06-22

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.

Re: BC for KDE libraries - Debian User - 2003-06-22

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... Yours, Kay

Re: BC for KDE libraries - Charles Samuels - 2003-06-22

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: C++: class Foo { 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: C++: 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).

Re: BC for KDE libraries - Androgynous Howard - 2003-06-22

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.

Re: BC for KDE libraries - Tim Jansen - 2003-06-22

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...

Re: BC for KDE libraries - Sad Eagle - 2003-06-22

As Androgynous Howard already described, it doesn't work like this, since it really look more like this (in a single inheritance case, let's not talk about MI :-) ): struct Foo { Foo_vtable* vptr; int data1; int data2; //.. } struct Foo_vtable { int base_offset; someFunctionPtr1 typeID; someFunctionPtr2 virtualFunc1; someFunctionPtr2 virtualFunc2; ... } Adding more virtuals becomes a problem when there is a class that inherited off the base and added a new one. The traditional way of doing that would be for the child to create a virtual table that has additional slots at the end. If the parent puts something else in these locations, funny stuff happens, of course.. The size issue of course exists if you add more data members. But it can also exist even when the allocation size of the object doesn't change. Consider this: struct Base { char v1; char v2; char v3; }; Here, sizeof(Base) == 4 on most platforms due to alignment/padding. So can you safely add a char v4, since it'd still allocate 4 bytes? Nope. If you had a struct Child: public Base { char c1; }; Many C++ implementations (I believe including g++-3.x) would pack the new value into the padding of the parent class, so making the base class use it is not a very good idea... Anyway, the point of all this: Most (all?) C++ ABIs are designed for performance, at the expense of making binary compatibility difficult. Therefore there are generally no easy answers -- just a lot of discipline plus some tricks...

Re: BC for KDE libraries - somebody - 2003-06-24

Since KDE is C++, and C++ doesn't really allow this (because of virtual function tables, etc), it would be difficult to do this. But, another language, objective-C, does this quite nicely, using messages for doing method calls. The way a message works is through a proxy function, which just browses the object's message table, and calls the right method. It's pretty cool, just check it out at apple's site. IMHO it's much better than C++.

KDE.ORG Design Adoption - Alex - 2003-06-21

I remember reading a few months ago that the design adopted by KDE.org will replace the design which many KDE websites like: http://www.kde.org/areas/people/ http://i18n.kde.org/ http://artist.kde.org/ http://dot.kde.org/ http://events.kde.org/ http://kdemyths.urbanlizard.com/ http://www.koffice.org/ http://www.kdevelop.org/ http://printing.kde.org/ http://women.kde.org/ http://developer.kde.org/ http://www.kdeleague.org/ http://enterprise.kde.org/ http://promo.kde.org/ do not us and have not even adopted the color-scheme. This is not even the complete list of website snot using the new design, it is a shame to see such inconsistency so many months after the new design became ffective and I am wondering if there si stilla plan to bring a level of consistency between the different designs KDE.org sub-sites have adopted. I really hope this issue is taken seriously because it is really hurting KDE's image as a consistent desktop. People will think that if the sites are this inconsistent so must be the desktop. Thanks, I hope this issue will get resolved quickly =) BTW: I will help, but I am leaving for 2 months starting tommarow so I can't help yet.

Re: KDE.ORG Design Adoption - annma - 2003-06-22

http://women.kde.org has its own design and will not be ported to the new one. For the other sites you list, very often webmasters are also developers and they cannot find time to port the website. I guess the dot has always had a style different from www.kde.org I suggest that when you are available again (in 2 months), you cvs co the www module, you subscribe to the kde-www mailing list and you port those websites locally. Then you can make a tarball and send it to someone from the mailing list. :-) In my opinion, events and promo must be the first to be ported.

ui/qt/kde question - Carlo - 2003-06-22

I don't know anything about the structure of the kde libraries or qt, and so I really don't understand bugs like this one: >Christian Loose committed a change to kdesdk/cervisia >Implement BR 59644: Change key shortcuts for cvs add and >cvs remove to Insert and Delete. Now you can use the plus and >minus keys to fold/unfold the tree view like in most other KDE >applications. Shouldn't such controls like a treeview and their behaviour be part of kdelibs/kdebase, shared by all kde applications and only be overridden when necessary? Allows this signal/slot mechanism no inheritance or so? To me (having no clue about qt) it looks like a sample of bad design. Please enlighten me! :-)

Re: ui/qt/kde question - Roie - 2003-06-22

The +/- keys are indeed shared between all apps using the treeview control. The problem was that in cervisia, + and - were overridden to perform other functions, and therefore could not be used to expand and collapse the tree. These other functions were now remapped to the Ins/Del keys, so that +/- are again available for expanding/collapsing the tree.

Re: ui/qt/kde question - Carlo - 2003-06-22

Thanks for the explanation. I had a second look at the diff and have to concede that this was a pretty dumb question. It was too early in the morning, I suppose.

Binary Clock Screenshot - Benjamin Meyer - 2003-06-22

http://www.csh.rit.edu/~benjamin/binaryclock.png