As the first beta has been delayed to finish more PIM features, we're proud to present the second alpha release of KDE 3.2. The first alpha was already seen as a very strong release and the second one is even better with 1374 bugs closed in the last 31 days. The major changes are the import of KSVG and KPDF into the KDE distribution, along with a major rewrite of the window manager. You can download the new release here. The are currently no binary packages, but you can of course use Konstruct to build it. Please give this one a good testing as we'll be moving to the beta phase next.
Dot Categories:
Comments
> since many people are complaining about it, assigning a default shortcut at least would be positive
Already done in CVS.
Did clee's excellent patches to the context menu make ti in? His patches removed a lot of redundant and useless things from the cotnext menu such as 'Stop Animations and Set Encoding entries taken out, as well as rearranging the order of the link-related menu items.
I REALLY HOPE THIS MADE IT In, this is perhaps one of the best things that could be done to that crazy context menu. If you remvoe the 'View Source' than there is definitely no arguement for 'Stop Animations' and 'Set Encoding', these aren't even context sensitive, view source at elast was context sensitive to the frame it was in. Come on, you got to be kidding, I've never sued these features and nobody I know has, they don't belong in the context menu!!!
More here: http://www.kdedevelopers.org/node/view/194
If you agree, please say so here too: http://bugs.kde.org/show_bug.cgi?id=53772
The patches indeed are great. I don't see "View Document Source" the same way, but the resulting menu is good enough even with them. Are the "Image" and "Link" context menus editable in the same way? They don't seem affected by the patches, they have some items that are removed in the "Frame" menu.
So ar ethey in CVS or not?? Is there still a 'Stop Animations" and 'Set Encoding" option in the context menu for example?
Set Encoding will likely stay, just not for links or images. It'll only appear if you click on the background.
Stop Animations will likely be removed before b1.
I really hope that will stay. I'm currently building Alpha2, but I don't remember it being missing from Alpha1.
Set encoding is probably the item I use most fron the context menu - more then "save as" or "view source". people in Europe and North America just can't appreciate how important it is - one of the only two reasons I don't use Mozilla (or derivatives) as my main browser is because it lacks this in the context menu (the second being its mind boggingly slowness).
won't be in the context menu, good riddance, it doesen't belong there.
However, neither does set encoding, that's also rarely used and should notbe there.
> However, neither does set encoding, that's also rarely used and should notbe there.
No that's used a lot in non-East/Central European Languages.
er, I meant non-West/Centeral European Languages
What!!
You want to remove "stop animation"?
This is the feature I prefer in konqueror as a web browser!
I generally like to have the animated gif in web pages, but sometimes you have one that is horrible or load lots of CPU, and I am happy to have a quick entry in the menu to stop it.
It looks like in current HEAD "Stop Animations" was removed from context menu without adding it to the menus or toolsbar by default.
> It looks like in current HEAD "Stop Animations" was removed from context menu without adding it to the menus or toolsbar by default.
I guess somebody could add it to a menu, but remember it's still in Konqueror's preferences under Web Behavior.
That's good, it didn't really belong tehre, I think it should be in the 'View' menu or be part of waht the 'stop loading' option does. Anyway, are you saying that now it's \not in Konqueror at all?
I think it shouldn't be in Konqueror at all until it gets flash support, since users might think its buggy when tehy click stop animations and the flash animations keep on flashing...
it's in the prefs
I think what would make more sense there is if it were truly context-sensitive i.e. it only appears in the context menu when the mouse is over an aminated pic.
That way you can disable individual animations, which you cannot do at the moment.
Yes, that would be a good feature for KDE 3.3. It'd of course need someone willing to implement it :)!
"Set Encoding" is very usefull for cyrillic pages,
where konq often uses wrong encoding,
and I hope "Stop Animation" will not be revimed too from the context menu.
View source isn't something very used except by developpers and by people who can understand it. Since it's not the case for the vast majority of computer users, then it should not be present in the context menu. Anyway, it's rarely necessary to view a web page source when it's properly rendered.
View source is a huge factor in katering to the web development types. since Konqueror currently (and probably for a long time to come) requires some tweaking to work properly with very dynamic web sites (which are becoming more and more common these days), and you want Konqueror to support all these web sites - the you must cater to the web developer.
Mozilla currently has the best web development experience, with JavaScript console, debugger, dom-inspector and cookie manager (that can manage cookies' content). while Konqueror has some of these (kudos for the beginning of a java script debugger !), it falls behind even IE with its support for web developers and frankly not having "view source" in the context menu could be the last nail to drive web developers away.
While in most cases "View source" can be achieved by keyboard shortcuts and using the "View" menu, having it on the context meu is essential when debugging dynamic multi-frame sites.
I'm doing most of my web development on Mozilla even if its almost unusable (speed-wise) on my computer, simply because Konqueror lacks the developer support I need. as a result adapting sites to Konqueror is slower and messier (includes a lot of shotgun debugging and 'fix-type, reload' cycles) which under most circumstences just isn't worth it.
The way to go is give more developer support in the browser - not less - because that's the way you win browser wars: developers cause users, bad developer supports drive users away. Microsoft has implemented it nicely in IE and now Netscape/Mozilla had learned the lesson. when will Konqueror developers graduate ?
> While in most cases "View source" can be achieved by keyboard shortcuts and using the "View" menu, having it on the context meu is essential when debugging dynamic multi-frame sites.
Do you use any of the alphas? "View Frame Source" is in the frame submenu. Too many people commenting about alphas without using them :(
> While in most cases "View source" can be achieved by keyboard shortcuts and using the "View" menu, having it on the context meu is essential when debugging dynamic multi-frame sites.
Hmm, stop being so fatalist. Web developers are not going to stop testing in konq because of this. Just like they won't stop testing in things like Safari or Epiphany, both of which also don't have it. It's still in the menus. It still can be assigned a shortcut key. It isn't in the context menus anymore because most ordinary users just won't use it-- and they shouldn't have to use it.
It's not like if we are removing the feature all together. Most current browsers only put it there for historical reasons. Viewing source is a debugging tool. The context menu is most definatly not a place for debugging tools. What do you propose next? putting the javascript debugger in the context menu?
"and frankly not having "view source" in the context menu could be the last nail to drive web developers away."
Yeah because it's SOOOOO difficult to assing a shortcut for it or access it through the view-menu!
"While in most cases "View source" can be achieved by keyboard shortcuts and using the "View" menu, having it on the context meu is essential when debugging dynamic multi-frame sites."
Too bad that most people use Konqueror for regural web-surfing and not "debugging dynamic multi-frame sites". If everyone had the entires they wanted in the context-menu, it would be so huge that it wouldn't fit the screen! For most users, "view source" is useless, so it was removed. Get over it.
"Yeah because it's SOOOOO difficult to assing a shortcut for it or access it through the view-menu!"
The context menu is better because you can view the actual source, no matter if it's a frameset or a normal page. With a "shortcut" (this is no longer a shortcut) you would see a useless frameset and then have to use the contextmenu anyway to view the frame source.
So, on one hand every demands that context-menues must be less cluttered. The developers listen and start removing less used entries, and everybody whines that "Yes, remove entries but not THAT entry!".
If you remove entries from the context-menus, you are going to step on some toes. You just have to step on as few toes as possible
"So, on one hand every demands that context-menues must be less cluttered."
Not everybody demands that. The vast majority of users doesn't care wether a context menu has 10 or 20 entries as long as the ofen used ones are on top.
I always see "the average user finds that confusing", never "I find that confusing", it's *always* the self-proclaimed usability experts that demand removal of stuff they don't like, never the users themselves.
7 +- 2 choices/items is what the human brain usually can get grasp of just by glancing at them. More and you have to stop and read them through. The latter is not acceptable because context menus should enhance your flow and not hindering it.
And please remember that usability is a professional work also. A very important one often overlooked by programmers. A lot of projects have failed just because of bad design and no firm grasp on who the end usersa are.
Take a look at the UIs of some professional apps. They generally have context menus with a small number of items. Mathematica, for example, has 10 items in its main context menu. Maya has two types of context menus, reguler and radial. Reguler menus have about half a dozen entries. Radial ones have more, but they are arranged in sub-sections in a circle around the cursor, so there are no more than about half a dozen in each spatial location. Its not a matter of new users being confused! Its a matter of efficiency. The workflow of these professional apps is incredible, partially because of good UI design. Making menus that can be used by glancing, rather than reading, is a part of that good design.
Like another reader wrote before:
"Do you use any of the alphas? "View Frame Source" is in the frame submenu. Too many people commenting about alphas without using them :("
You don't get it, right?
On many webpages a frameset isn't obvious.
So far, I had to check one menu (the context menu), both framed and non-framed sources could be viewed here.
Now it got inconsistent and you have to check two different places. (The menubar and the context-menu)
This takes longer, it's inconsistent and unintuitive.
If you're smart enough to be a web developer or somebody who knows how to use View Document Source, you can probably tell if a site is using frames.
The problem with the frame menu is that it can't be added to the main menus in any reasonable fashion. View Document Source can.
I don't see your problem.
Just assign a key to "view frame source",
(I use Ctrl-Shift-U, for instance)
Then, on a page with frames:
- left click the area of your interest
- press the key combo
works like a charm for me
(Besides, as others have pointed out,
the option *hasn't* been removed)
And, in case there aren't any frames on the page
nothing will happen. Just press the key combo
for "View page source" then.
how do u assign a key combo to view source?
As usual, "Settings/Configure Shortcuts..."
please could u explain further? is that an option in windows xp, ive got 2000
and I really don't think I hid it that well. so here it is spelled:
- Removing features that make web developers life easier will cause web developers spend less time working with Konqeuror (unwanted effect no.1).
- Spending less time with Konqueror will cause web sites to be less compatible with Konqueror [1].
- Having less web sites that support Konqeuror means that less users will choose it as the browser of choice (They'd always have Mozilla based browsers).
so - making the browser less "web-developer friendly" will make sure that it will also be less "luser friendly", so removing the view source shortcut from the context menu will ultimatly cause more "simple" (non developer) users to stop using Konqueror as well[2].
Q.E.D
[1] ooohh! I can do this neat trick with Mozilla! lets see if IE can supprot it ? why, yes it does! ok - let's put it in. Who wants to check if konqi does it as well ? nobody? shacks, I'll guess we'll just let the users find out then.
[2] not like I invented something new here - this is how Microsoft beat Netscape, which was my whole point. Its a common enough mistake to think that they did that because they gave the browser away for free integrated in the OS. the real reason that they won, as any person who'se been in the real web development market in the last 5 years can tell you, is because they made life easier to the developers, and as a result harder for Netscape users. I don't mind downloading a 7 MB browser, or getting it on a free CD, but I won't install it if using it means having less accessability to web sites.
"- Removing features that make web developers life easier will cause web developers spend less time working with Konqeuror (unwanted effect no.1)."
Adding features that regural users want (for example: less cluttered context-menus) would increase the userbase alot more.
And how has this feature been "removed"? You can't assing a shortcut-key for it? You can't use it through the view-menu?
And why couldn't those web-developers write standard HTML for crying out loud?!?!
"so - making the browser less "web-developer friendly" will make sure that it will also be less "luser friendly","
Hate to break this to you, but the world does not revolve around "web-developers". For vast majority of users, "view source" is unneeded for most of the time.
And calling users "lusers" is just a tad elitist.
Hell, regural users kept on insisting that KDE needs less cluttered context-menus. And now that they are being cleaned up, people whine even more. You can't please everyone. But it seems that there are more people who want cleaned-up menus than there are web-developers who insist on having "view source" in the menu. Just because it's not in the context-menu does NOT mean that it's not there. If the developer is so lazy that he refuses to access it through alternative methods (view-menu, keyboard-shortcut) that really is his problem, not KDE's.
1. "View source" not in the context menu is useless in frames.
2. You can't make the type of dynamic web sites people expect today with "standard HTML" - you have to use modern DOM2/CSS2 and non-standard extensions, which are browser dependant. even the standard stuff does not have full or even partial support the same way in all browsers.
In an ideal world you'd be right. unfortunatly, we are not living in an ideal world.
Actually if you go above CSS1 in the current line of browsers, Mozilla is going to be about the only player that will support you. There is not alot of CSS2 yet.
If you are using frames, you are not using modern web design standards. Frames are obsolete and are the work of the devil anyway. Get over it.
smeat!
1. Maybe that's why there is a "View Frame Source" option in the Frame submenu?
Are you using HEAD, or one of the Alphas?
> - Removing features that make web developers life easier will cause web developers spend less time working with Konqeuror (unwanted effect no.1).
Please stop acting like if this feature has been removed. It hasn't, and never will be.
I have a few friends who are web developers, and their favorite browser is Safari (yeah, they are Mac users).. guess what? Safari doesn't have View Source in it's context menu either. I don't see flocks of web developers abandoning Safari. I don't think somebody who has never used Konqueror will even notice either.
You've obviously never used Safari.
If you right-click on the document background in Safari one of the only two context menu items is 'View source'.
I think that this is a fairly strong argument for including it, personally. But others obviously don't agree with me.
Oh well.
DUDE, WE AGREE WITH YOU.
We are clamoring for it. PLEASE ADD IT BACK.
Oh please...
First of all, the frame source can still be viewed through the context menu.
Second of all, you can assign shortcut keys to both "view document source" and "view frame source".
I don't see your problem, and i happen to be a (web) developer. I guess i work differently from you, considering i rarely need to view the document source, and i never use frames so that is one problem less as well.
> [1] ooohh! I can do this neat trick with Mozilla! lets see if IE can supprot it ? why, yes it does! ok - let's put it in
Heh, sounds like a real good way to develop quality software... :)
> The way to go is give more developer support in the browser - not less - because that's the way you win browser wars: developers cause users, bad developer supports drive users away. Microsoft has implemented it nicely in IE
The right way is not to make web developers optimize their pages to a special browser and lock them into it like Microsoft did. The right way is to encourage web developers to use and adhere non-proprietary HTML standards.
That would be nice if it would work that way - "the nice thing about standards is that there are so many of them to pick from".
Different browser implement different subsets of the standards, and Konqeror is a weird half-breed: it implements a subset of the standard W3C standard APIs, a lot less then Mozilla, and also some of the non-W3C standard IE extensions. what you get is a browser that while providing most of the capabilities you need to design a really neat web site, does not fully support "standard" (i.e. Mozilla based) techniques, nor "non-standard" (i.e, IE based).
As a result, I have to write "cross-platform" code that detects Mozilla, IE and konqueror and uses the right call for each.
While the lowest common denominator is constantly slowly rising, it is always far below the curve, and to get the most effect from your dynamic website you need to make the code specialized. currently its much harder to do for Konqueror then for the competitors, and I'm not surprised to see that most interesting uses of DHTML in the wild won't work on Konqueror.
"while Konqueror has some of these (kudos for the beginning of a java script debugger !), it falls behind even IE with its support for web developers and frankly not having "view source" in the context menu could be the last nail to drive web developers away."
Exactly. And without anybody testing Webpages for Konqueror all Konqueror users will suffer.
Developers are the most important users. Any platform alienating developers will die sooner or later (mostly sooner).
"Developers are the most important users"
Cough...Cough... Sorry. Swallowed some water there.
Without a userbase - any userbase - a developer is just developing for him(her)self.
AND ... the "web developers" are not the same as the konqueror developers. I doubt these changes will drive the konqueror developers away.
AND ... I'm a developer and I feel alienated from Microsoft (and have for 5 to 10 years) - does that mean they are going to die mostly sooner? Well it will have to be later now since sooner has already happened.
You have to understand, "View Source" was not removed, and never will be removed. It's entry in the default shipped context menu was removed. The feature remains in KHTML. It is implemented as an "Action" and you can add it to the context menu with a text editor if you want! Just edit the .rc file. You will find that you can do lots of cool things like that with KDE apps. You can also assign a keyboard shortcut to the action, saving yourself having to use the mouse even.
All these problems about what should be in the context menu would probably be reduced to nothing if the menu was configurable. A bit like toolbars usually are. One could then choose a nice subset of all available actions and all this "flaming" would be done with.