In this week's KDE Commit-Digest: Fortune-teller and Keyboard Layout applets for Plasma, KNewsTicker resurrected for KDE 4.0 as a Plasmoid. Rewrite of <canvas> tag support in KHTML. Various new language syntax highlighting in Kate. Internal database storage work in Digikam. More playlist handling work, and support for Magnatune "streaming membership" in Amarok 2. OpenDocument loading of charts in KChart for KOffice 2. Various graphics fixes and a user handbook for the Bovo game. Kolourpaint is now fully ported to Qt4. Continued work on the Eigen 2 library. Further porting away from KDEPrint to the printing facilities provided by Qt4.
Dot Categories:
Comments
As more languages are added (a good thing tm), maybe it's time to Kate find a better way to allow the user to change the syntax highlight.
Now it's a very big menu with some types of languages and in each type a new menu with a big list of options. I dislyke the usability of menus with a big number of items, bu K menu is reduced to a minimum in Ubuntu as I add more sub-menus (for example internet->browsers or graphics->editors).
Maybe using a new window with list fields for selection is a good idea (I don't recall how it's called in Qt, but in html whould be a select field with rows enought to address all types and items).
Just a idea.
Why, what's the point?
How often does the user need to change the syntax highlight(it's decided by filetype in the waste majority of cases anyway)?
What would the *actual* impact usability wise be, to not use todays menu with many entries(other than your dislike for such menus)?
My guess the answer on those questions would be very seldom and minimal, supporting my "what's the point" rather nicely. Any so called usability improvement should at least be undertaken on places where it actually matters, not where they are not only baseless but irrelevant.
Well, for example, in quanta (I don't recall if it's the same for kate), after creating a new php file, you have to close and reopen it or change the highlight.
Yes, it's not often used I do agree, but you see, you should read well the text and see that a SUGGESTION isn't the same as demanding a new feature. Anyway, in case you didn't understood the point is to avoid big menus, once they are bad (and don't forget sompe people still uses 800x600 resolution).
well, file a bug for quanta
I quite offten have to change the syntax highlighting as I use kate at work and don't have control over the file extensions of the files I edit. I quite often have to open XML files that don't have a .xml extension and then I need to change to the XML highlighting.
And an incremental search bar to find your language without having to decide whether it is best classified as scientific, markup, scripts, or sources :)
Let's be cracy, let's add a searchbar to *every* menu at the toplevel. So any application can gain a usability-boost by default. Or probaly, it would be more wise, to use a separat windows to search through every menu, which make into something like kickoff or raptor, but for application-internal commands. On the long run, this gives the chance, to integrate something like a commandline, per window ;)
While perhaps you meant to be sarcastic, I think this is an excellent idea, for which I provided a mockup some months ago on kde-look:
http://kde-look.org/content/show.php/TBC+-+Searchable+menus?content=53580
A complex application like Kate has over 80 first level menu items. Something like KDevelop has probably even more. Finding something by scanning through each of these is insane, and for less commonly used options, you can't remember which menu it is in.
The only problem I see with that suggestion is that the search bar takes up space from the toolbar where I might want icons for my favorite actions. Would it be possible for the search bar to be half size when not in use, and have the search bar expand when you type in it?
>> The only problem I see with that suggestion is that the search bar takes up space from the toolbar
The search bar is not on the toolbar, it is on the menu bar. Also, did you look at the third screenshot? The search bar is not visible (it's just an icon) until you activate it.
There should'nt be a separate menubar.
But there is :) And that won't change until someone proposes a new interface concept (the Ribbon still has the equivalent of a menu bar, it is just a "tab" bar instead).
> While perhaps you meant to be sarcastic
Well, partly ;)
It's not easy to implement such a feature in a good manner, and i thing it won't be a service, to add half eaten features to only a handful apps. There to many of them in kde already ;)
IMHO it would be better to overthink the whole concept of menu and toolbar as an interface, an develop something more like microsofts ribbons from office 2007.
>> It's not easy to implement such a feature in a good manner
I can't think of any reason why not. It's just simple filtering on all the QActions that the menu knows about.
>> IMHO it would be better to overthink the whole concept of menu and toolbar as an interface, an develop something more like microsofts ribbons from office 2007.
Microsoft's ribbon does nothing to solve the problem of "I know what I want, but I don't know where it is". Yes, the organization of actions in their menu has improved over previous implementations, but the general UI organization of "actions within groups" is the same, and you need to still look through each group to find what you want if it isn't already visible or obvious where it might be.
>> It's not easy to implement such a feature in a good manner
> I can't think of any reason why not. It's just simple filtering on all the
> QActions that the menu knows about.
So? What about dynamic-generated menus or contextmenus for example? Or without a menuentry, but a hotkey or toolbar-button? There are to much holes to fill, for a simple scanning-solution. But well, ok, at kde there is a tendecy for such half eaten thinking :-/
> Microsoft's ribbon does nothing to solve the problem of "I know what I want,
> but I don't know where it is".
Because, that's not there question. The great think about ribbons, is the scripting-ability and that they get rid off the overaged separation between menu and toolbar (or you could say: small icons and big icons). Of course, there ist more then enough space for development, after all it's from microsoft ;)
>> What about dynamic-generated menus or contextmenus for example?
Depends on what kind of dynamic generation you're talking about. There is no problem with dynamically generated menus if they are generated with respect to content. If the menus are generated when the user clicks on it, then that could be a problem. It really depends on how extensively this is used. For menus such as a list of bookmarks, it is not important, since we don't need to necessarily search those anyway (would just clutter results).
>> Or without a menuentry, but a hotkey or toolbar-button?
If you have an action in the toolbar that's not in your menu, your application is fundamentally broken.
>> There are to much holes to fill, for a simple scanning-solution. But well, ok, at kde there is a tendecy for such half eaten thinking :-/
Of course everything is not trivial, but technical challenges can be overcome. Actually Micorosft had an addon to the Ribbon that provided search capability at one point. http://www.istartedsomething.com/20070124/scout-office-2007/
>> Because, that's not there question.
Exactly. That's why the Ribbon is flawed from that perspective. The ribbon is great as a menu replacement (although it has its own set of problems), but it doesn't make any fundamental leaps towards providing a better way to find things in an application. Anyway, a search doesn't impede your ability to access functions the same way you always did. It's merely a supplement.
This looks very similar to "Quick Access" in Eclipse, which is very useful. It lets you find not only menu items but settings and other things as well.
Colour selection for Web colors or at least a possibility to display the associated colour would be great
First, kudos to all khtml dev's, you already did a big job.
I should say that im really happy to see khtml in development and I personally, do not like to see webkit as rendering engine for kde, why use forked khtml while we have khtml in active development?
but i really want to know that what are the plans for khtml's future.anything that dev's are planning to support and are already working on it? for example wysiwyg, better js debugging output, supporting html5 and/or css3 or...
Thanks
All of those are on the table. There is a foundation for a better JS debugger in trunk, but it's not clear we'll have enough time to debug it before 4.0.
all of them? even wysiwyg? Oh My...
You guys Rock!
and sure im not talking about 4.0, its almost clear that what we have in 4.0...
(Today was the release date in last schedule, we all waited for today for a long time)
WRT to editting we've discussed it a bit; the infrastructure is there,
but obviously right now we have to focus on bugfixing. I can't commit or
anything to it, but it seems doable w/a reasonable amount of effort.
If I had to make a bet, I think we'll see Webkit in Qt becoming KDE's renderer. Trolltech are putting some resources into it, and it's sensible to see it in the common toolkit.
Not trying to bug anyone, but it sounds to me like it just makes sense to move to webkit when it is ready.
Assuming kde developers have commit access, it would allow many communities to share the load of webengine development. Apple, Nokia, Gnome, Trolltech, and KDE can all use and develop the webkit engine. Every group can take advantage of the shared core of development and develop a common project. Not to mention (as broken of an idea that it is) websites that look for the browser string to change the content it displays would work much better with a minorly sizable marketshare of webkit, compared to the unknown khtml.
Last week there were comments about not wanting to be unpaid apple employees, but currently for khtml everyone is in effect unpaid KDE employees. While cooler, it does not actually change the goal, to provide what is best for users (the best possible html rendering engine). While it might be decided that khtml is the best way to achieve that goal, I think it makes sense to at least look into migrating to webkit as an alternative. With Trolltech putting resources into integrating webkit into qt, it makes even more sense.
So kudos for improving khtml but please don't discount using webkit just because the apple folks were jerks early on. It sounds like some other organizations have managed to move past that and also the NIH'ed'ness.
Go SadEagle Go! I love your work in KHTML ;) and also kudos to other KHTML devs.
Ok, I know some people love khtml, but I think keeping it is a bad thing in the long run (that dosen't mean keeping it for 4.0 is bad, but we should think hard about webkit).
A comunity of developers is being built around webkit, with major players as Apple and Nokia. Staying out without a good motive (trowing away code is sad, but IMHO not a very good reason if this result in a better thing in the end) seems to me a bad idea, because merging code from webkit isn't easy.
Notice I stated this is my personal opinion and I really don't know all the details on policies fro access to webkit CVS and acceptance terms for patches, so I could be very wrong, so please, don't start a flame war here, that not my intention, I just want to discuss it as adults (not saying kids can't have fun either, heeheh).
so let me ask:
khtml is KDE's HTML Rendering Engine that is under very nice development, then why should kde switch to webkit?
I think its all because of the names of 'Apple', 'Nokia' and 'Adobe', if these were three smaller companies, people were not going to look for webkit in kde...
if you want something that webkit has, and khtml hasnt, go to bugs.kde.org, open a new bug and tell you want it, then vote for it
for example: i want opacity support! ;)
Well two reasons I personally would use:
- plataform independance. Good even for mobiles, khtml is KDE-only
- safari is better than konqueror in html rendering in my ver humble opinion
- one thing I really dislike about open-source projects is the duplication of effort. For example: why can't ubuntu use Suse's Yast? Even more than now it have a gtk front-end.
The world would be a dull place if we all became the same don't you think? Besides, if you can tear yourself away from 'buntu, Oracle's RH clone uses Yast I believe.
--i cannot undesrtand, use webkit in kde because webkit is cross-platform? when you have kde it means that khtml is there with you
--so fill a bug report if you see a bug, but i cannot confirm this, also for example khtml has support for css3 selectors, i mean it is under active development...
--duplication is what apple did, they forked khtml because of their policy, why they just didnt commit to khtml?
They did much more than just fork. They expanded the entire platform for their needs and more.
Why didn't the GTK team just add to khtml without moving to WebKit?
Me thinks having broad inroads into potential clients and ability to also move GTK+ to OS X was another consideration why it made sense to expand GTK+ to OS X.
Probably because they would rewrite whole damn thing rather than use anything with name starting with 'K'.
Platform independency is a good thing for spreading the renderer to other targets, such as handheld devices/cell phones (which is one major factor in the interested in Apple's fork). It's not so hot when it comes to running well on a specific platform. For instance, handling images on X11 requires /a lot/ of care, to avoid alpha-blending if not needed, to cache things on the server, to cache scaled versions, to pretile certain images, etc. KHTML has collected quite a collection of optimizations of the sort.
"Platform-independent" code for such areas will likely run quite well on OS X, and quite poorly on X11. And we know where most of our users are.
(And, actually, KHTML has ran on handhelds well before apple's fork ever did, thanks to Konqueror/Embedded)
So, the problems reside with Qt and X11: especially the design tradeoffs for the X11 client/server model versus OS X WindowServer and Quartz?
From my checkout of WebKit trunk on OS X, Gtk and Qt seem to be growing steadily.
What's stopping all your optimizations and interface abstractions from being under their own branch in WebKit, besides not having commit access?
It looks like that the "the official KDE web rendering team" has an other opinion about that:
http://zrusin.blogspot.com/2007/10/khtml-future.html
Thanks for posting that.
Some good points, and help my belief that khtml will die for good - thanks for while it lasted, but I prefer firefox to it - and be replaced by webkit.
khtml does not need to die for kde apps or the kde workspace to use webkit. khtml can happily continue to develop even if kde by and large ends up using webkit, or if OSVs choose webkit for final integration.
the whole "khtml must die or webkit must be shunned" is a false dichotomy. khtml can continue on as is regardless of what the rest of KDE does.
actually while i think safari or gecko engine etc... is a lot better than KHTML
i STILL think it is VERY good, in fact very IMPORTANT, that KHTML continues
I'm against Webkit, because it doesn't support proper text-shadows.(with which you can do very nice glow- and metal-effects)
For a comparison view my website in Konqueror and Safari: www.iamwhoiam.net/max
(and don't bother with the text, it's just a placeholder)
And I'm not sure about that, but I think I read that Webkit is much bigger than khtml.
btw: I don't know for what you need opacity, but for the background you could simply use a transparent png.
as i said im against it too, opacity was just an example, its already there for khtml in kde4.0...
Oh, right.:)
so in a choice between "canvas/wysywig editting/web 2.0 site access (think: facebook)/works-on-QGraphicsView" and text shadows ...... you pick text shadows?
Uhm. We have canvas. And facebook works. And editing can be done... but I am 100% sure Apple will always have nice text shadows.
Not here. e.g. you can set more than one text-shadow like this:
text-shadow:0px 0px 7px #ffaa00, 0px 0px 3px #ffffff;
but Safari only shows the first text-shadow.
> canvas
that's right, i saw those commits recently ... does it have full, properly working support for the entire kit and kaboodle? (serious question there: I haven't had a chance to try it out yet)
> facebook works
it does work *much* better in the latest 3.5.x than earlier releases, but it's still not perfect. it's like maps.google.com; it works *pretty* good, but not perfectly (most common buggaboo on google maps is how sometimes certain map squares won't fill in... permanently). i haven't tried these sites out very heavily with khtml in kde4 as the khtml there has only recently become usable for me (porting breakage sucks, i know =), but it's that difference between "works .. mostly" and "works, absolutely." that drives KDE users to alternatives like firefox. i experience this _constantly_ among the userbase and it's really unfortunate.
the things i listed are the sorts of things people actually notice and care about, as opposed to text shadows ... which was the point of my comment =) if we're going to get all hyper-aligned over things, let's at least do it over sane reasons.
> editing can be done
can be, yes. but then everything can =)
As for full support of canvas... We do not do all HTML5 stuff, but then the stuff we don't support Safari doesn't either, IIRC (getImageData/putImageData). And the reason I didn't put those things in is because I think they're insane. Which means I'll probably have to implement them anyway, but I'll at least postpone the insanity. (There is also the data: URL conversion, which is of even more dubious value and requires some security paranoia). A few problems we have are limitations in Qt, such as lack of 2-radius radial gradients, and setting of repetition on pixmap/pattern brushes. It also doesn't help that path intersection in Qt sucks. Which I should file a bug report about (see below ;-) )
And as for Facebook.. Well, you know what I say about bug reports? The only problem I know of with FaceBook is that it's basically a DoS on our selector code; and yes, the partitioning by classname code in Apple's tree does handle it a lot better.
Unfortunately, my preferred solution of beating up web designers who think 3000 clause CSS is good is not within bounds of the law.
Uhm. We have canvas. And facebook works. And editing can be done... but I am 100% sure Apple will always have nicer text shadows.
Well.. maybe Webkit is the better solution, but from my point of view it isn't, because khtml worked perfectly fine for me, and webkit works perfectly fine, except for the text-shadow. And I think (maybe I'm wrong) that using Webkit would mean giving up control. e.g. could you ever change the license without Apple's permission?
We can't change the license w/o Apple's permission anyway, since we have merged many things. And one really can't change the license of anything in KDE with any sort of history without asking hundreds of people. This is really a non-issue.
ok, I was wrong then. So it's just the small personal text-shadow-thing I dislike about Webkit. :)
The only thing that bothers me is that Apple seems to have more rights on the code than the people who actualy started it.