In this week's KDE CVS-Digest (old layout):
Digikam does black and white tonal conversion. KPDF implements history and KTTSD (screen reader) support. KMail adds graphical emoticons.
KNotes implements read-only support. Konqueror shows document title and favicon in location bar autocomplete. amaroK supports the Akode engine.
Dot Categories:
Comments
Thanks for the news!
I can't wait till I get my hands on the next beta, preuerrably through a livecd D
Wasnt beta2 meant to be released yesterday? :(
Tagged, not released. Release maybe next week.
Lots of great news in the digest! I saw blogs about more new and exciting things added this week such as:
http://www.kdedevelopers.org/images/e3760da08ad6e1ba4a5862246e867490-837...
http://www.icefox.net/gallery/phpquickgallery/?gallery=2005%2FSystem+Pre...
http://developer.kde.org/~danimo/screenies/webdavfolder.html
in which you will see the new about screen that has been added to konqueror, kontact and kmail, the new and very interesting proposal for kcontrol in kde 4.0 (by Benjamin Meyer) and a movie (recorded by Daniel Molkentin) to show how to connect to a WebDAV folder (and the remote:/ protocol is shown too).
Have fun!
Addition: I just saw autoscrolling in search and mass colored highlighting in kpdf too
Yuck, that's one ugly preferences interface. Is this gonna replace kcontrol? I like kcontrol in it's tree view. :(
Come one, this new interface is way better for everybody.
It's basically a rip off from macosx, plus the added benefit that
the search bar finally has the place it merits, that is proheminent
and right on the front, since it's the only usable and quick way to find
things when the amount of information grows too quickly.
And if you want a tree view, add settings:/ in Konqueror's sidebar.
treeview is very nice
If you like this interface more just because the search bar is best located, I find that a non-sense reason to replace the current one. I mean, let's just make the search bar in a better position in the current interface then.
Take a closer look it IS a tree view, just with a far better layout. The new GUI has much more potential (the way the search function works out) and it's easier to find things otherwise as well -- you can see the fine details and the big picture at once! Not to mention the fact that it'd be much easier in this to have a really smart searching function that could be asked questions by novice users. To top it off, integration of third party modules would seem more orthogonal!
> Take a closer look it IS a tree view, just with a far better layout.
Just because the icons are larger doesn't make it "better".
Currently, I can go through many different settings without much hassle because I CAN SEE THE TREE AND THE SETTINGS AT THE SAME TIME.
As far as I understand, the new layout will always use the whole window or (even worse) spawn new windows for settings, so that will become impossible.
Although I agree that the search function is displayed a lot better now, I don't need any big icons and I would prefer the old treeview a lot more.
You can't please everyone, but this new one will please a lot more people than the current one. It is just lovely to use, BenMeyer did a good job.
Anyway, you'll still be able to use the old one, it's just a frontend to KCMs, like the new one is.
All they did is make the tree take up the whole window, so that way its much harder to use. In the new interface 4 groups of modules almost take up the whole screen, and I have TEN groups (which I think is the normal amount), so I see this thing as requiring a scrollbar and being full screen always... This will be a pain for everyone that thinks OS X's system preferences is horribly designed, and also designed to show you the minimum amount of settings they can get away with.
If this replaces KControl, it will be very bad for KDE I believe. KControl may not be perfect, but its better than the mess an OS X style control center would bring.
This new kcontrol does not solve the main problem in KControl : the unused modules, which we cannot make disappear (vaio laptop, laptop batteries, etc.)
Gerard
This is an already addressed issue and worked on (by Frans Englich, IIRC). Obviously it will be finished for KDE4 (or at least, let's hope :)
Actually they could integrate together neatly - KSnapshot provides a DCOP interface with just this in mind.
Cheers
Rich.
It is great that Kurt Pfeifle took the time to add lots of What's this-help texts. But even if his hope comes true one day and 80% of all widgets have an help text, it will still be a guessing game - "Let's see.. maybe there is a detailed help text for this widget?"
There is just no indication in the ui which tells the user if the long way to the top right corner and back is worth it. Wouldn't it be possible to let the What's-this-button light up if the user moves over a widget which has a help text? Or include a questionmark icon into the regular tooltip as a hint that there is more detailed information?
Also, if the user wants to explore the what's this-help texts, the interface should help him by highlighting all the widgets with help text when in What's this-mode.
It would be much less frustrating to get no detailed information if you know that it doesn't exist right away.
> There is just no indication in the ui which tells the user if the long way to the top right corner and back is worth it.
Will be in KDE 4. Qt 4 snapshots include the necessary base.
Imho, there shouldn't be any indication. Either the information should be entered properly by the app's creators, or the what's this option shouldn't be supported or even there at all. Developers shouldn't be able to sit on the fence if they don't provide what's this support. It should be obvious, because the button is missing.
and if there are 15 discrete possible targets and only 12 of them have WhatsThis entries?
unfortunately we have to deal with reality (not all developers of all apps will get 100% WhatsThis coverage, or put WhatsThis everywhere they should such as text labels as well as their associated widgets) which leads to these sorts of quandries.
so even when there is a WhatsThis button, the user is still left with the question: what can i click on?
Well, that's the problem. There SHOULD be 100% coverage. I mean, it's not a gargantuan task, to describe your interface in a few words while constructing it. I've done it myself with no trouble. The only time I end up with less than 100% coverage is when I get lazy, and that shouldn't happen at the released software stage.
You can try to make up for it all you want, but the fact is, it's simply an inconsistent and frustrating nightmare for users. Either do a good, usable interface, or hack together something quickly, but don't try to do one and pretend it's the other.
> There SHOULD be 100% coverage.
i agree. but for whatever reason (mostly HR issues) we don't have 100% coverage. "all" we need are dedicated people writing WhatsThis entries to turn our current reality into the utopia you describe. you obviously feel pretty passionate about this.
> I've done it myself with no trouble.
brillian! as someone who's evidently quite good at this, maybe you can channel some of the previously expressed passion into helping solve the lacking documentation that makes things "inconsistent and frustrating ... for users".
> Either do a good, usable interface, or hack together something quickly, but
> don't try to do one and pretend it's the other.
well, it's possible that it isn't "quickly hacked together" AND things like WhatsThis aren't complete. as a software developer, you should know that's quite often the case. i don't think your statement is particularly fair to those working on this software you are likely using. but, you can certainly help improve the situation so that it becomes a moot point. =)
I think there should be feedback when the what's this cursor is active. For example the widget under the cursor could be highlighted if there is a what's this text. An alternative would be to make the cursor the indicator.
Rich.
yep. this is possible with Qt4. in fact, the TT guys added this upon request just so we could do such a thing. =))
Whoaaaaah!
This was a really, really useful addition for me. I took the time (must have been more than an hour) to click myself thru all the new whatsThis help blobs about kdeprinter. What an amazing piece of software the whole of kdeprinter is I only am realizing now (having been a user of kde printing since 3 years!
The new whatsthis additions let kdeprinter shine even more (even if most of its functions are due to the underlying CUPS system).
I guess there are a lot more KDE applications out there that could well bear with some of this kind of polishment.
Now off to study the tutorial by Aaron Siego that was mentioned above, maybe I will now convert myself into a whatsthis contributor. Where is an area in need of additions?
I must agree here!
What I like most are the "Additional hints for power users" at the bottom. I think this is a very efficient way to attract guys like myself to read on, and scare my mom away. (Yes, she is using KDE too, and she reads the whatsThis items of kprinter now, and she frequently lurks on the dot even).
Hi, mom ;-)
This opens many possibilities.
f.e. kill images/flash (banners) for a site
This was one of the few things firefox had but konqueror was lacking.
go konqi go:)
Add DOM editing primitives to domtreeviewer.
It is now possible to
- add/change/rename/remove attributes
- insert/delete/move elements
on arbitrary existing documents.
Another item that can be ticked off on the feature list :-)
CCMAIL: [email protected], [email protected], [email protected]
FEATURE
> This opens many possibilities.
> f.e. kill images/flash (banners) for a site
> This was one of the few things firefox had but konqueror was lacking.
This has nothing at all to do with DOM editing. You could already do this very easily in KHTML using the plugin API ( I have a plugin that does a simmilar thing - changes all links in the page to use the Coral caching proxy ) - just no one has written a plugin to do it.
DOM editing refers to having a WYSIWYG HTML editor.
Dead again after a short live...?
Is there a blog or website or Mozilla-bug that informs about progress?
you have to grasp that mozilla code is horrible and hard to work around. send tokens of food, sex and or money and it may happen faster. even better check out the CVS and go nuts. nothing gets what you want faster than doing it yourself.
Is it just me or you're actually replying to yourself? ;D
ac = anonymous coward
I have been checking the component "Ports: Qt" under bugzilla.mozilla.org and that seems to be a fine way to check progress. It appears from this that progress is slow or stalled (very few active developers on the task as far as I can tell).
It would be a real shame if we lost the change of a Qt port of Mozilla and/or Firefox. AFAIK it's the only non-Qt application I and a lot of other people I know use, and it currently integrates badly with KDE (file associations, printing, etc).
Keith
Myself being unable to use that hellish bugzilla advanced search interface, could
someone please post the relevant bugnumbers?
http://tinyurl.com/3v85u
Looks like changes are being committed as recently as this month. They look swamped and I'm sure they'd appreciate help, even if it's just finding duplicates and finding old bugs that have already been resolved (many of the older Qt bugs are from previous attempts to port Mozilla to Qt and may no longer be applicable)
It is really nice to see Konqueror and Kwrite applications speak (of course using festival text-to-speech engine).
Thank you KTTSD and KDE Accessablility developers for wonderful applications.
KTTSD can read out clipboard, web pages in konqueror, selection (selected text), and notification (information and error dialog messages).
I agree, great work by the KDE accessibility team. I can't wait until kontact, kopete, kword and other apps get fully integrated with kttsd.
I think KTTSD should be rename to KITTY (KDE Is Talking To You)!
KITTY is brilliant! :P
loving it!
Kate & Kitty :) A good duo indeed!
YES!
I second the name change! :)
+5!
I wish KDE drop this stuff until there some information how to setup HAL and DBUS and go with an own kded-module for KDE 3.4!
linux's udev is such a nice thing and HAL makes it unnecessary complicated :-/ It prints tons of lines into the logs in verbose mode, no error messages, but it does not work. HAL and DBUS documentation is nealy a vacuum on freedesktop, HAL-CVS does not like DBUS-CVS... This stuff looks overengineered and is crap!
Compare it with the kdebluetooth-plugin waiting in kicker that you plug in a bluetooth-dongle - that's nice!
Bye
Thorsten
media:/ uses HAL only if you have it installed and set up. otherwise it uses more traditional means. so it's not like you won't have media:/ if you don't have HAL. this is good news for those who don't like HAL or who are on an OS that doesn't have it. =)
Yo Aaron, Minor Deity of Cool Stuff and Nifty New Kicker Tooltips,
Just a silly question: will there be something like a right-click menu entry on media:/ items where you can 'Add an action to run when this media is plugged in'? Will there be defaults for whole classes of media (like, for all cameras or USB keys or webcams)? That would be Way Good(tm), and I like things that are Way Good(tm). :)
An even better idea, I think: offer an API for apps to register themselves as willing to handle this or that device class when the device in question is plugged in. That way, you install, say, Konference, it registers itself as handler for webcams, and it handles your webcam automatically when you hotplug one. (It should probably leave it be if the webcam was already plugged in at boot though.)
How feasible would that be? Could it be doable in a desktop-interoperable way (ie, based on D-BUS rather than an in-kded solution), perhaps?
not for 3.4, no. this functionality is slated for the next release, however.
No problem, I'll just delay my worshipping you a little, no big deal there. :D