http://kmeleon.sourceforge.net/files/kmeleon1.02beta2.7z

Changelog:

GRE Update to 1.8.0.7RC

Chg: Cleaned preferences, mrulist, nickname and windows size code.
Fix: #241 List the plugins under Preferences - Plugins alphabetically.
Fix: #584 Default popup size influenced by parameters.
Fix: #837 <input type=*> treated as <input type='text'> for context menu
Fix: Tweaked site icon support.
Add: Upgrade system to reset cache files and for other upgrade operations
Add: Add accelerator text in menu automatically using accels.cfg
Add: Show password button in password manager.

@Dorian - I installed this version simply by unzipping the program to a folder in Program Files and double clicked on the K-Meleon executable. It uses the presets found in the "Documents and Settings .... Application Data ... K-Meleon ..." folder. It works just fine. Is there something I need to do further if this is not the proper way of installing it?

@Terry, (though i am not Dorian)
That is how zipped RC, dev versions etc. are installed.
No further action needed when it works fine.

I personally install in extra new folder and use traditional k-meleon profiles location in
case anything goes wrong.

Thanks, guenter. Since this was the first "full" redo of 1.01 and it worked so beautifully, I just wondered if I had done something wrong. I was more used to .9 installs that could get so painful since almost everything had to be reset from scratch.

All has improved much :-)

p.s . i like others used to collect our changes in user.js
( which we copied to new browser ).

Thanks! But OMG: Some of my menus are now three times as width due to a) all accelerators visible and b) using non-english names for them (I had no idea what some things were called in German, e.g. "Umschalt++ (zehnertastatur)" instead of "Shift&+" like I had set it to)... Is there a way to disable this feature to return to the previous state? In right-click context menus I hardly ever need accels.

zehnertastatur?? is that num pad? Mmh this shouldn't be there.
I can make an option to remove them completely, is keeping the old behavior needed?

Yep, that's num pad (it's the description for "SHIFT VK_ADD").

Mmh, on the one hand it's surely good to expose all possible accels to the user. On the other hand it's much clutter that's presumably not needed for users that know their shortcuts. So maybe an option to keep the old way and another one to get rid of the shortcuts in the right click context menu, but show all in menus (but stick to the shortest possible accel text please *g*) could be useful IMHO.

Bug in the beta: Opening bookmark / hotlist groups is broken, only the first site gets loaded (so I switched back to 1.01 for now).

may I suggest to improve the ns bookmarks plugin slightly, so that the "Addlink"-command also asks where to put the link, just as the "Add"-command behaves? I tried to change it myself in the sources, but failed to get the plugin compiled with mingw/gcc :-(

Thanks in advance!

Rolf

So "accels" are keyboard shortcuts? I don't see why displaying them on context menus is a good thing, seeing as a context menu in itself is already kind of a shortcut.

Shortcuts are always quicker than context menu. The advantage of the modification made with b2 is that modifications of accels are directly reported in menus.

After, having displayed shortcuts in menus is just a way to learn or remember shortcuts... to use it later

A+

I agree with Alain. It is the nature of accels being displayed in menus that you don't need the accel anymore, when you see it, because you are just one mouse click away from what you want to do. But the sense and the purpose of accels being displayed in menus is to allow users to learn about these accels.

From my point of view, it does not make sense to distinguish between context menus and the main menu. Context menus can contain unique commands that are not available anywhere else. And these commands can have accels.

So simply add a switch to show/hide accels in all menus.

Internet Explorer und Mozilla Firefox both don't display any keyboard shortcuts in their right click context menus. Thus the size of the context menus is pleasently small.

And please, don't get me wrong: I think it's useful to display all possible accels in the menu. But an accel "description" that's twice the width of the menu entries isn't that great. ;-)

So, with short accel names, the only switch that is probably needed is for accels in right click context menu on/off. What do you think?

It's impossible to know if a menu is contextual or not with the current parser.

maybe possible?
make them "help bubles / descriptions" appear on mouse over for a while longer
or some other delayed trigger? or maybe a macro/pref switch that toggles them?

That way ppl that know them will click before the descriptions appear or toggle it
and learners can force the help description to show.

@ra, for me its better to have the long helps then generate FAQs
(just in case we get many new users;-)

It's impossible to know if a menu is contextual or not with the current parser.

:-( There goes the switch for accels in context menus... Is it a complex thing to distinguish between them? Would a pref. for old style / new style (with new = automatically display all accels) be easier?

Maybe have icons next to most used

Oh goodie a beta - here I go again!

I like accels in menus, good way to be reminded of key commands I have forgotten or ought to be using instead of freezing my hand off on the mouse (winter is coming).