Konqueror's Javascript Continues To Improve

ElitusPrime writes "Konq's Javascript support may have been regarded as weak in the past, but 3.0 is a huge improvement. As an example, DHTML Lab has just released a Konqurer supported version of their popular HierMenus product. These cross-browser, backwards compatible pop-up menus are very complex, using all sorts of Javascript and DHTML tricks. Konq now supports them out of the box!"

Comments

ha!

[wrinkledshirt]

Now there's an april fools joke.

Re:ha!

[flewp]

Konq now supports them out of the box!

It must be a joke, I bet Konqueror doesn't even come in a box.

Mirror

[Alan_Thicke]

Here is a mirror.

No april fool this time :)

[CoolVibe]

The KDE3 Konq _did_ get a workover. Read the mailing list archives. KDE3, when the stable version comes out (probably when it's a .1 release, KDE hasn't been that good with .0 releases), is going to be really _really_ good.

I'm glad to hear it's looking this good :) Go KDE!

And as for anonymous coward still being switched off... I don't seem to mind much.

Are these guys stoned?

[brunes69]

I went to that site in the latest Konq CVS, and the menus worked great. But then I went on to read about this company.. 29.95 for the use of some simple DHTML menus on only 5 pages?!@?!? Higher license fees for mroe pages??!?! I could code my own implimentation of this in 5-10 mins! These guys are seriously whacko.

Re:Are these guys stoned?

[Jerf]

I could code my own implimentation of this in 5-10 mins!

Then please do so. Post a link.

The Hiermenus are not "simple DHTML menus". They are extremely capable menus that work with an unprecedented set of browsers and capabilities, with good ease of use. They have been through multiple versions over the last few months, and are probably the best argument for the difficult of useful DHTML currently in existance. (This is how hard it is to create cross-platform menus, fer pete's sake... can you imagine creating a grid control?)

As simple as they may seem, they required an unbelievable amount of time to create because of the immense number of browser incompatibilities that exist on the their target platforms. Example: I once implemented my own menus, back when there was Netscape 4.2 or so, and IE 4 was reasonably new.

Several months after we'd rolled these things out, I got a call from upstairs, saying the menu looked wierd on their machine. "What version of Netscape are you using?" "4.5". (Numbers in the post are made up, because I don't remember the exact version, but the point holds.) "That's wierd, it looks fine on my machine."

Come to find out that in Netscape 4.5, but not Netscape 4.43 or Netscape 4.52, the code that decided how large a 100% height DIV was changed slightly, was causing (incorrect) shrinkage on their system, and was causing a background image to show up way too many times, making it ugly. Eventually I just let the bug stand, and to this day, if you hit the site with the wrong version of Netscape 4, the menus are ugly.

These things multiply the more browsers you add into the list of supported browsers, and that list is long for hiermenus. While we may wish they were free for hobby sites, purchasing a license in a more formal environment (not necessarily even corporate) is giving you hundreds of hours of dev time at a very cheap price. It's literally cheap at twice the price.

They are not wacko. The wackos are those who in a corporate environment look at them, make the same call you did ("I could code that in an hour!"), and proceed to blow thousands of dollars worth of time to save themselves 30 bucks. (Money, people, money. Learn about it. There are few things as valuable as a technically-savvy person who understands business!)

Re:Are these guys stoned?

[Inoshiro]

Drop-Down Menus: Use Sparingly

Summary:
"Drop-down menus are often more trouble than they are worth and can be confusing because Web designers use them for several different purposes. Also, scrolling menus reduce usability when they prevent users from seeing all their options in a single glance."

And I really agree with them. Don't use menus at all. Save your end users' valuable time (and time is money) by just hiring someone sane to develop a simple page. Like Google's page -- everyone can use it :)

Re:Are these guys stoned?

[befletch]

The Hiermenus are not "simple DHTML menus". They are extremely capable menus that work with an unprecedented set of browsers and capabilities, with good ease of use.

And if you want more than just capable menus, check out Tibet, a full client-server architecture for the web. These guys started by using JavaScript to fix the bugs in various browser JavaScript implementations, and then proceeded to build class libraries, debugging tools, client-side page templates, and a full IDE. All in JavaScript. And I'm not making an April Fools joke.

Also, the code is dual-licensed, commercial and open source.

The code is beta at the moment, and there is much work to do, but this is a seriously ambitious undertaking.

And no, I don't work for them or otherwise benefit from this heading-towards-off-topic post.

This can't be serious...

[lkaos]

A Personal License is available for any non-commercial Web site that is less than 5 pages. The one-time licensing fee for a non-commercial Web site is U.S. $29.95.

For the DHTML code that is already in my browsers Window? I didn't sign any EULA by loading the page so what stops me from just modifying the code to my own purposes (and obsfucating it to avoid copyright stuff)?

I don't think this is an April Fool's joke, I just think this guy is smoking crack if he thinks he has any hopes of making money off this.

BTW: The only real news today was that someone wrote a JavaScript menu that works in Konqueror? I usually don't complain about article weakness but come on.

Re:Why is it every time I use KDE

[foonf]

within ten minutes the font has changed itself to arioso system wide?

When the font configuration data gets reset, or it can't find the default font (such as, if you are using bitmap helvetica as your font (which is the default), but using Xft rendering which does not support bitmap fonts), it goes to whatever is alphabetically first among the fonts it is aware of. Sometimes it ends up being Arial, which is ok (although its usually the wrong size), on my computer it typically chooses an absolutely horrid looking font called "Agate".

Not stoned

[Julian Morrison]

What are you paying for?

=> the programmer time you don't have to waste reimplementing the wheel

=> not having to face the horrible realization that you're losing customers because your reimplemented wheel only plays nice in IE version x.y, and breaks or looks ugly on anything else. And wedges the browser solid on IE version x.z

Re:Not stoned

[brunes69]

Er, DHTML menus are very simple to do. One small section of code will make a DHTML menu that will work in any version of IE since 4.0, and any version of Mozilla / Gecko based browser, and any version of Opera or Konqueror. It is very simple CSS. IE's imcompatabilitys are a misconstrued legend. As long as you siwch with the W3C DOM, most script written cleanly will work.

And adding a compatability layer for Netscape 4.x is trivial on top of that, that is the only area you'd spend your time, in Netscape 4 compliance. And even that would take no more than 15 mins. Are you saying it isn't worth 30 dollars (actualy alot more if you have more than 5 web pages) to spend 15 mins writing some code? If you're paying your web guy 130 dollars an hour maybe, by my calculations, it may not be worth it. But then again, you'd be bankrupt already for overpaying your employees so it wouldn't be a problem.

Re:Not stoned

[The Cat]

DHTML menus depend on no events but the onmouseover and onmouseout events, which are the EXACT same in every popular browser since Netscae 3.0

Sure, as long as they are registered in the HTML. But if you try to register them in Javascript, you have the W3C "AddEventListener" method, and then you have the MS "AttachEvent" method.

There is no reason you should have empty divs in your code to begin with. Why are they there?

Who cares? The standard supports it, it shouldn't be broken, and it worked in IE5 and IE5.5 but broke in IE6. Far as I'm concerned, if it works in Mozilla it should work everywhere else.

I have no idea what bug this is. Vertical scrollbar bug?

Use window.open to create a pop-up. Set scrollbars=no. Create a background image that is the same size as the window client area. In IE there will be an empty, useless vertical scrollbar on the right side. The only way to get rid of it is to set scroll="no" in the element (a mind-bogglingly non-standard field), BUT then it leaves a fat hole in the page where the scroll bar used to be, so you have to set "margin:0" in the style sheet as well.

That bug took weeks to research and fix.

It doesn't affect DHTML menus directly, but it is an example of why it is such a gigantic pain to do DHTML anything, and why web sites cannot get past HTML 2 after four generations of browsers.

Hopefully Mozilla will fix this.

Ultimate Dropdown Menu

[KodaK]

If anyone's interested: www.brothercake.com has a JS menu, UDM, that works very well cross-browser.

And it's free-as-in-the-guy-who-wrote-it-says-so. Gimme-credit-ware.

I use it on the main page and the web-store for navigation. It can be slow on some browsers, but it's actively developed and gets better every day. I just checked it with konq 2.2.1 and Opera 5.0, no problems. In mozilla it's slow as hell, but I haven't tried moz 1.0 yet.

Fitt's law?

[Wolfier]

Does anyone know if the Konqueror (or KDE in general) is improved regarding Fitt's Law adhesion? KDE usability would go all the way up if the rule is followed whereever technically possible.

Re:Building menuing into the browser

[lux55]

Very true. As web sites are more and more being referred to and thought of as applications, the need for an easy-to-implement toolkit to render and manipulate web-based GUIs is crucial. Something event-driven would be really nice too, so that maybe the screen-by-screen stateless interactions could be succeeded by more responsive methods and not require entire page reloads.

I see a lot of potential in the Mozilla browser architecture, specifically XUL, for providing something like this. XUL provides many of the more complex and more powerful widgets necessary to desktop applications, and as Mozilla is about to reach 1.0, with AOL even examining its rendering engine for their product, a standardized XUL could really boost web application possibilities to new heights.

This seems to be exactly where Java applets wanted to go, but failed due to its sluggishness, and it seems to be where Flash is trying to head also. I think we've all given up on Java in this space, but I'm excited to try the new Flash MX, with its built-in web widgets, and the new direction toward satisfying developer as opposed to designer needs. Because frankly, Flash 5 and under sucked if you were trying to develop anything but the tinyest applications.

XUL and Flash are two quite different approaches to the same problem, and each offer different benefits to developers. XUL is open, cross-platform, and can integrate with the client operating system as part of the actual browser, but currently requires Mozilla or Netscape 6, which is only a few percent of the web. Flash is much more widely available, plus a smaller download for users, and acceptably cross-platform (NS6 has Flash for Linux, etc.) for most developers, but it's still more of a vector animation tool than a GUI tool, and as such can present an awkward framework for developers to work with, and its not open (although the SWF format is).

Then again maybe things will change with the big web services push, or the "sematic web", or something new we haven't thought of yet (but some niece or nephew of Tim Berners-Lee has ;)).

Anyway, since there is really no point to this post, I'll wrap it up now. I just think it will be interesting to see where things head, and which technologies shine, in the next few years. Just compare 2002 so far with 1998, it's a very different Internet for sure.

Popups are evil

[Skapare]

Popups are evil. Well, evil if you dislike their behaviour in your desktop environment. And as we all know, they can be abused if the browser isn't very tightly in control.

I want to have control over my desktop. If I stretch my browser out to 800x600, then I don't want any popup to wander out of that range. The best way I see to do this is to implement the browser so that all dynamically created menus and popups are entirely controlled by the user, when the user choose to exercise that control. And they should be parented within the existing window unless the user allows or requests otherwise. Many kinds of DHTML do that now, but the way it should be is DHTML, Java, and Javascript cannot cause any new windows to every pop up outside of the existing window. If you have to bring up a menu, do it within the confines of the browser window itself. And this has to be part of the browser implementation, and not left up to the site to decide (as some will abuse this, we know). I haven't had the chance, yet, to try out all the new browsers around. Eventually I will, and hopefully some are going the good direction.