This week, new tab widgets are in Konqueror, news on KAudioCreator, MDI support goes into KDE, and more functions and
templates are added to KSpread. Also, many bug fixes have been made to KMail, Konqueror, and KWin. Read it all in the latest KDE-CVS-Digest.
Dot Categories:
Comments
I don't get it. Juts turn off all the options you don't like and use the light widget style. The sleek, no-clutter CLI that you describe is then right there in front of you, so what's the problem?
Look at the screenshot by binner. There is an X on the side like mozilla. The x in the tabs don't waste any space anyway since they just take the place of the favicon on hover.
unfortunately i find the new close tab method annoying at times, since it sometimes accidently press on the icon of the website on the tabwidget to select it (which closes it of course) and crashes konqueror coincidently too :)
it looks ugly anyway so i would rather close them using right click -> close tab :)
also the red color text on the tabs when there is some loading looks a little out of place with the colour scheme. i dont know what you could do about that though...
anyway cvs continues to be very stable and nice so keep up the excellent work people!
ps: keramikII has some nice little additions
Instead of the red, maybe steal the animation from Mozilla?
While hiding the site icon? And how to display the "unread" state (without hiding the site icon)? In my opinion it's better to display both states with colors rather one with an animation and the other with color.
overlay?
While often a great idea I don't think overlay makes much sense here, the size of a favicon is imo way too small for this purpose, and additionally it doesn't help anyway if the favicon's look itself is not know yet to the user.
Well, the little star from new window/tab/file icons may fit. I am not sure the icon loader handles overlays this small, though.
Using colours for this is almost inherently flawed. What if someone uses a different colour scheme? Even if it's configurable it's too much bother. What if someone is colour blind?
It will be either dropped, configurable or use color scheme colors like the newest version. And AFAIK color blind people can differ black, red (appears as brown to red/green blind) and blue.
Khotkey 2 is still not merged in. Is it so buggy that people gave up?
You please do it, please, please, please.
> Is it so buggy that people gave up?
By no means... CVS is still a work in progress.
When eclipse has to deal with a number of tabs, it adds a sort of combo box on the side
which allows the user to pick a particular tab by name, which is a lot more fun that trying
to go "left, left, left, oops too far, right, right". It also has a previous and next tab capability.
I'd love to see this kind of thing for konqueror.
Konqueror already has previous/next tab functionality. I have no idea what you talking about the eclipse though.
Eclipse has previous and next tab capability in the toolbar, in a nice convenient place.
Believe me, eclipse does their tabs in a very, very nice way.
How about screenshots and more detailed descriptions of its behavior?
Thanks derek Kite and Kde developers!!!
Also, I think the Eclipse idea is pretty cool, amybe you should add it as a wishlist item to add as a prefference.
Speaking of tab features, here are some cool ideas at KDE-LOOK.org: http://www.kde-look.org/content/show.php?content=6319 its rough, but if at least #6 would be implemented that would be awesome.
> http://www.kde-look.org/content/show.php?content=6319
Pretty good ideas! I think all of them are pretty much possible with the new tab widget.. I just hope that there are enough developers free enough to implement them all.
> http://www.kde-look.org/content/show.php?content=6319
Pretty good ideas! I think all of them are pretty much possible with the new tab widget.. I just hope that there are enough developers free enough to implement them all.
I read that when you hover a close buttona ppears directly on the tab. This seems very bad usability wise, what if I click to select a tab where the close button is supposed to appear? Wouldn't that close the tab. I don't think i want that, especially since there is already the mozilla way to close tabs. Is there a way to disable it?
Also, can you edit the tab toolbar likea normal toolbar so i can for example remove the add new tab and close tab button if i want and just use the extra toolbar in Konqueror. god, i really hope this is possible. I ahte having diifferent buttons taht do the same thing.
> I read that when you hover a close buttona ppears directly on the tab. This seems very bad usability wise, what if I click to select a tab where the close button is supposed to appear? Wouldn't that close the tab.
I haven't tried it out personally yet, but the way I beleive it works is that the close button only pops up after a "hover time".. that is, a delay. This is to avoid mistaken clicks.
Btw, is middle button closing ever going to be implemented? Or has it already? It's the thing I miss most from Moz's tabs.
> Is there a way to disable it?
See http://lists.kde.org/?t=105426566900002&r=1&w=2
Apparently no GUI option yet.
> I beleive it works is that the close button only pops up after a "hover time".. that is, a delay.
It didn't have a delay initially but now has for trial.
> is middle button closing ever going to be implemented? Or has it already?
No, see http://bugs.kde.org/show_bug.cgi?id=59172. Middle button is pasting under Linux/Unix and that is what it does in Konqueror and Mozilla's Linux/Unix versions too.
No. In mozilla-firebird for windows the default behavior is to close tabs
with the middle button. To make it work in GNU/Linux just do the following:
1. Open Firebird, type "about:config" as the url.
2. Search for the option "middlemouse.contentLoadURL", set it to `false'
3. DONE!
I miss this in konqueror, I really really really miss it. Hope there is/will be a
way to configure that.
heavyvoid
What about fixing this _annoying_ flickering-toolbar bug...???
http://bugs.kde.org/show_bug.cgi?id=39234
Thanks voting for it!
and I've got more:
http://bugs.kde.org/show_bug.cgi?id=57189
http://bugs.kde.org/show_bug.cgi?id=58040
http://bugs.kde.org/show_bug.cgi?id=59113
please vote :-)
I beleive the second is already fixed in CVS.. can anyone confirm?
I beleive the second is already fixed in CVS.. can anyone confirm?
I have KDE 3.1.2.
#57189 on my 400MHz K-6 III, it is running in Konqueror with 3 other tabs and using:
20 to 30% of CPU.
I'm also compiling the updates on KDE_3_1_BRANCH on a console.
I have no problems.
Should I assume that it is fixed and close it WFM?
--
JRT
the image loading bugs are the ones that bother me mostly, i saw mosfet was working on atleast the .gif issue ... right ?
i have 512 meg ram but my konqueror regulary gets OOM killed when i load big .jpg's or .gifs.
the kview part has the same problem (i use it instead of the standard image part because of zoom functionality), and especially when zooming i get OOM kills (guess because the pixmap is scaled in memory instead of just repainted)
OK, I'll vote for that because it is a general problem which is more annoying on a medium speed system 400MHz K-6 III.
Flickering is the result of unneeded screen redraws. This issue should receive more attention -- eliminating them not only eliminates this anoying problem but should result in an increase in performance.
--
JRT
Where did you get the idea that the flickering is a result of an unneeded redraw? It is a needed redraw, the flickering always occures when you change the view. When changing the view you also change the kpart/embedded KDE app which again has to update the toolbar with its own set of merged icons. Just open eg. a web site and a calendar file like at http://www.apple.com/ical/library/ in separate tabs, switch between them and see what merged toolbar buttons are and how "unneeded" the redraw actually is.
My suggested fix (as mentioned in the report) is delaying the redraw instead showing it in "real time" for avoiding the flickering.
Excuse my imprecise English.
I should have said redundant redraw.
Do you also feel that redundant redraw is good?
--
JRT
Well, code could be added to compare the formerly merged toolbar buttons with the newly merged toolbar buttons and only do a redraw when they actually differ, but I don't know whether this is actually improving anything. The flickering would then only appear when the old and new buttons differ. I tend to think that this additional code is worse that just doing the redraw in the end since the redraw flickering issue has to be fixed elsewhere anyway.
The flicker isn't a unnecessary redraw that occurs I think-- it's just the erasing of the background several times I beleive.
Redundant redraw is a general problem in many (if not all) desktops.
However, I note that simply redraws something won't cause flicker.
It is necessary to first erase it and then redraw it to cause flicker. Clearly, code that does this could use a little improvement.
And, yes this bug should be moved to the code that actually draws the icons.
--
JRT
Sure, but that would only help when the buttons dont change... cleaner solutions would include a) speeding up the redraw, there is no reason why it has to flicker or b) wait/hope for a backbuffered, Quartz Extreme-like X11solution which should make it easy to hide the flicker.
I don't think that speeding up the redraw will remove the flickering since the flickering is afaics a result of showing in real time how the dynamical old toolbar buttons are getting unloaded and the new ones merged in.
Yes, but who says that it is neccessary to redraw the toolbar after unloading the old kpart? That may be a Qt-related problem (when you remove a widget the parent will be redrawn automatically), but still a solvable problem... QWidget would need a "dont redraw unless you get an exposure message" flag.
I think the quickest way to do this to use QWidget's (whatever toolbar ptr's)->setUpdatesEnabled(false) before switching views, and setUpdatesEnabled(true) after the toolbar has been merged in. Hope that the merging code uses QWidget::update and not QWidget::repaint.
Can anyone tell me if the new KTabWidget will allow custom buttons to be added next to the New/Close buttons? If not, then there's no point in my using them.
You only need QTabWidget of Qt 3.2: http://doc.trolltech.com/3.2/qtabwidget.html#setCornerWidget
Thanks for the link, it was helpful, but unfortunatly it shows that no, I can not add an extra ( third ) widget at this time. ( Sorry, I should have explained that better in the first post )
Ever heard of nested QWidgets?
Ever heard of being polite?
Ever heard about looking at the source or asking politely before ranting?
How primitive!
*sigh* And we wonder why the KDE community is considered obtuse. Obviously Binner didn't think my question impolite, else he wouldn't have answered. I even said "Thanks" and "it was helpful" in my initial reply. This was not polite? I apologise. Perhaps you, in your trolling, anonymous wisdom can enlighten me, nay, the entire community on polite conversation?
Of course I've heard of looking at the source. When you were in school, did your teacher tell you to research every question you wanted to ask her? The point is that if you don't want to help, then DON'T. The world will still revolve around it's axis without your dull wit. Unless, of course, you're just trolling for a reaction, in which case I humbly suggest you go play on Slashdot.
Ehem, I beg you to differ. Binner gave you a hint how you can add "add an extra ( third ) widget at this time", by his short answer it should be obvious that it's obviously possible to have "nested QWidgets" which would allow you to do what you want. But that time you didn't say "Thanks" and "it was helpful" but "Ever heard of being polite?" so don't be surprised about similar answers with a similar tone.
"Ever heard..." IS impolite.