Will there be tabbed browsing be possible in the new version of k-meleon?

Guru,

A couple of people are working on plugins for tabbed browsing. It won't be part of the release but if they get something working soon, it should be fairly easy to add it on.

Andrew

where do i find those plugins?

Please read the reply again. It says "are working on," not "have written." They're not released. I'd guess that when they are released (at least in beta) you'll be able to find them in the Resources section of this web site.

The mentioned plugin might be my experiment announced in this thread:
http://sourceforge.net/mailarchive/forum.php?thread_id=858010&forum_id=2617
It fakes a layered set of windows by keeping all but one of them invisible. Until anyone tries it and tell whether this can be a good enough approach, if just some of the known issues get fixed, I have no immediate plans to work on it further. (i have never used tabs before and only wrote the plugin out of curiosity)

Another approach is the patches by Brian. They add tabs to the core of K-Meleon.exe, which could give more control than a plugin. Nor this experiment received any comments though.

Join the developers mailing list if you wish to help test either. Without tests and some interest it can take a while before any reach beta.

/Ulf

As long as those patches require compilation by end-user there will be proabably zero testers outside the developers circle.

Brians .exe, IIRC didn't work (for me at least) with other regular beta files so I doubt anyone actually could test that one too.

I was under impression that developers were adressing those issues. No doubt there is public interest but unless Joe Average can actually run those things (just run, not use on regular basis) there can't be any useful testing done.

i can use computers quite good but i don't have a clue about programming and implemeting features . hm but i would test the beta with the implemented tabbed browsing for sure because its a cool feature in a cool program

Hi Folks,

just a little comment:

It would be _very_ nice if KM would be able to do tabbed browsing.

Before changing to KM, i used Netcaptor (a plugin for IE) which has this function implented perfectly.
I have to say, its the only thing I miss since I walk over to KM.

I'm not a coder, so I can't help developing, but I would be very happy if your work will have a positve ending.

By the way, did anyone know why I can't start a java application from the toolbar, integrated by a macro? Allways get an error message. Its a stand-alone application, so normaly deativated java in KM shouldn't disturb, I guessed.......

Thanx for an answer!

Hi,

KM is great.. just the basic features that a web browser needs, build on a strong basis (gecko) using a windows-native enviroment (MFC).

The features I miss the most are in fact the TABs (seems to get popular, only IE does not have it) and a kind of download manager.

Great work!!

Peter,

We have a plugin for the new beta that achieves the effect of tabs.

Hi K-Meleon Team,

please make the latest builds available to everyone!
I really honor Your efforts to create a good software and
to find most bugs before going public; but I would
bet that the current Beta is already better than 0.6.

Thanks a lot!

Check out the archives in the developers list. Anyone is able to download the latest build (currently 431), though since it is built for developers it is only available through the developers list.

]http://kmeleon.sourceforge.net/contrib.php

There are many new features, but also some bugs.

I am a Mozilla user in general and have become addicted to tabs. My main gripe with K-Meleon is that it doesn't have tabs. I have been using the test build (431) for a few days now. While I really like the browser in general (VERY SNAPPY!), I really don't think that layers are a good replacement for real tabs. It just doesn't feel right and looks amateurish. This is just a vote in favor of implementing real tabs (I understand that there is no way to fit it into 0.7).

P.S. I haven't noticed any MAJOR issues using 0.6.5 (431). It might be worth it to publicize the build. A lot of people seem to think that K-Meleon is dead. This is a great browser that really shows off the speed of the Gecko rendering engine. I think it would get a lot more support if people could see that it was still being developed.

Roy, I beg to differ.

In versatility current layer plugin with general KM menu & hotkey system is miles ahead of Mozilla tabs. My current popup menu looks like this:
http://aab.spin.ee/img.misc/kmeleon/km-layers-are-nice.png

Now, lets compare it with Mozilla tab menu:
http://aab.spin.ee/img.misc/kmeleon/moz-tabs-are-not-nice.png

"New tab" vs "New layer" are both sensible to have as first options.

"Reload tab" vs "Close layer". First of all - why does Mozilla have reload option here at all? Do you really reload pages from tab menu? I mean - think about it. If you're in the middle of a document you just right-click and reload or you use reload button up there. Or hotkey. Having 4 ways to do something within an inch is overkill. It's stupid. It pollutes the UI. Is it really ergonomic to go up there, pinpoint appropriate tab and choose reload from there? There must be a quicker way

"Reload all tabs". I admit, it might be useful to some people although I have never-ever used it in my entire tabbed-Mozilla browsing career.

"Close tab". Oddly placed, very oddly. Have you ever thought why virtually every application has "new" and "exit" in different ends of menu - on as very first and other as very last option? It's because those are most easily accessible points in menu. In a menu of, say 10 items, most accessible are first few (2-3, because eye catches those easily) and the last one (again, an eye has visual aid to quickly locate item in the bottom). Worst are items in between first few and last one. Thats why many applications have section breaks in menus - for easier visual navigation. There are two problems with Mozilla tab menu in this respect: firstly though it places one most commonly used option in top of the menu it doesn't place other most commonly used option in bottom. Secondly, having 3 section breaks in menu with 5 items is... well... thoughtless. It doesn't help, it confuses. Why there is section break between "close tab" and "close other tabs" but no break between "reload tab" and "reload all tabs"? Well, they just havent pondered over that matter (of tabs and their logic) yet, I think. "Close tab" should be last item in the menu and "Close other tabs" one before it.

As for my menu not having "close other layers" then it's because I don't need it. But it is there should you need it (layers(CloseAllOther)).

Now consider my menu having layer list under right-click and Mozilla having it in "Window" menu. Which one is more easily accessible and why? You proabably know it. It's the same reason that most applications put common operations in context menu. It's because it makes them quickly accessible. When moving mouse around the screen there are certain areas that are more easily and quickly accessible than others. Those two main areas are either those in very close proximity to current position (within an inch when you have move mouse very little) and areas against outer border of viewable (mouse-movable) area (because you can hit those areas quickly with just moving your mouse there, you don't have to worry about stopping your hand movement in midway). Application menus *are not* more accessible or even equally accessible than context menu or taskbar/wharf/dock. Mozilla window menu is clumsy compared to KM context menu.

Yes, I can customize Mozilla menus and I have done that. But it's just so much more complicated that I don't bother with each new build. And most users never bother since they just fear to "mess something up" because "it's so complicated with jars and xul stuff". In KM it's simple. Just edit text file and you're done.

I'm no certified usability expert but neither are Mozilla engineers. And I was one of those people who was complaining for the lack of tabs in KM . But KM layer system coupled with flexibility and ease of customization is winner over Mozilla tabs. For me there are two usability flaws with layers: lack of good distinction between active and inactive layer buttons and fixed button width (should be dynamic with fixed minimum width). However, Mozilla classic skin has exactly the same problem with distinction so basically for me Mozilla tabs have exactly one advangate over KM layers: dynamic width. Thats about it.

You may argue about every point I made but then again - you didn't make any points why tabs are better and "more professional" than layers. I'd be happy to hear that

Sven,

I never used the layers plugin as I saw no usefull purpose for it, and the bar just wasted UI space. That was until I saw how you placed the layers in the context menu. Now that is cool!

Now I am going to start using it, but with the bar disabled of course.

I just love how there seems to be endless ways to customize K-Meleon for you needs, and they just keep adding to it . . .

The reasons I have for preferring tabs to layers are a little difficult to explain. They mainly have to do with the feel that layers provide. Layers do a good job of mimicing (sp?) the functionality of tabs. I'll do my best to explain it.

1) It uses the wrong widget. While the button "works", it isn't the correct widget for the operation being performed. By having a button performing as a tab, the GUI feels "wrong" right away.

2) When I change layers, the whole window flickers, not just the view area under the tab. Subtle, but noticeable.

3) When I open a new layer, the Windows animation performed is that of opening a new window. Also subtle, but noticeable.

4) The fixed width thing you already mentioned.

BTW, I wasn't saying that the Mozilla GUI was better (it isn't). The Mozilla GUI has all sorts of things I hate and it is SLOW. I have been using Mozilla since 1.0. I only just tried the test build of K-Meleon last week. I simply feel that a K-Meleon implementation with real tabs would seem more polished/professional than the layers solution. My intent was not to attack the developer of this feature. I was just providing some feedback because I feel that this project has a lot of potential.

"BTW, I wasn't saying that the Mozilla GUI was better (it isn't). The Mozilla GUI has all sorts of things I hate and it is SLOW. I have been using Mozilla since 1.0. I only just tried the test build of K-Meleon last week. I simply feel that a K-Meleon implementation with real tabs would seem more polished/professional than the layers solution. My intent was not to attack the developer of this feature. I was just providing some feedback because I feel that this project has a lot of potential."

In the past there has been, dare I say it, some *heated* debate over the subject of tabs, so much so that some people were stomping up and down (figuratively speaking) *demanding* that tabs be implemented into K-Meleon (some people do tend to get a little over-zealous when it comes to issues like this sometimes). The bottom line (namely the stance from the developers point of view) is, they will not be implementing tabs, for different reasons (general dislike of them etc.), however they did throw open the gauntlet to any talented individuals who, if they so desired, to program tabs, or say, come up with a comparable plugin, which is how the "layers" plugin came into existence. It may not be perfect, it certainly has a ways to go, however it's better than nothing. ;-)
So, yet again it all comes back to, if anybody can code something better, then nobody's going to stop them...

Roy,

I was going to ask you what you would like to see different in the layers plugin but I see others have already asked that.

Either way, we appreciate the feedback. I don't think Sven interpreted your comments as an attack on the developers. It was just a good, healthy debate on the specifics. Those are exactly the kind of debates I like to see here as opposed to some of the trivialality that passes for commentary. Plus, I know that Ulf, who is coding the layers plugin, has practically begged for feedback so your comments are worthwhile, even if there is disagreement in implementation.

Again, the comments are good and we appreciate you taking the time in making them. Let us know where else you see we can make improvements in K-Meleon.

Ask and ye shall receive:

Ulf's latest checkin:

Feature: Makes the button width adjust dynamically to the toolbar width.

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/kmeleon/k-meleon/layers/

Thanks for the insight. I wasn't aware of the "political" history around tabbed browsing. Given that they HAD to be implemented as a plugin, layers are a pretty inventive solution. That said, it is a shame that the developers aren't interested in developing tabs. They don't clutter the GUI unless they are used and a LOT of people like them. I don't see the negatives beyond code complexity. Though they are certainly not beholden to me (I'm just a lazy user freeloading off the hard work of others), I hope the developers have a change of heart. Oh well ... sad.

Roy,

Yes, there is a long history involved. Maybe in the future, tabs might make their way into the main code. Heck, Ulf might just do that coding. But however it is made available, a lot of people are either going to want them or not want them. I think that's why its gone to the direction of a plugin. It gives users the control of whether they want them or not. You'll find that's one of the most important issues with K-Meleon: User control of functionality.

Not to be misinterpreted - I'm not attacking anyone, especially someone actually supporting the idea of tabs/layers

Andrew,
thanks for pointing that out. I've been having trouble with my mail server for several days now and have been unable to follow devlist (being too lazy to look it up in the web). I'll go and try new plugin immediately.

Roy,
good point there about widgets. However, the way layers are implemented (as good as I, not developer myself, understand) differs somewhat from the way tabs are imeplemented. Think of Opera. Opera has MDI browsing (which is *not* tabs). It uses buttons just like KM layer plugin to switch between windows. KM layer plugin still creates separate windows but keeps other windows hidden so you just don't see other windows. Look at devlist archives for longer explanation by Ulf himself and posts about renaming or not renaming layers plugin to something else (like tabs). At the moment it is not deliberately called tabs to make distinction and I think we should keep that as long as it behaves differently than regular Mozilla tabs.

Back to Opera. Is Opera solution cumbersome too?. But thats what they came up with and people have gotten used to it. The problem is that I can't think of any good widely used widget to switch between layers or MDI windows, which in this case have almost identical behaviour (except that layers can't be windowed inside parent). You open you favourite MDI word-processor. You work with several documents at once. How do you switch between them? I bet that your word-processor has no graphical widgets for that operation. You have to select them from menu.

What kind of native widgets you suggest here? I guess tab-like switching mechanism would be perhaps more intuitive but then again, it's not really tabs we're dealing with here and we already have Opera with button-like approach which seems to be working for lots of people. Not that we should stop looking, it's proabably that anyone hasn't had that Brilliant Idea (TM) just yet.

As for flickering and stuff - check devlist archives, it's known thing. On the other hand - on faster computers it's not visible so that affects fortunately only part of users. Proabably Ulf will tackle it someday.

Its nice to hear that I didn't offend anyone. Its nice to see a community that is can have a spirited debate without getting personal. I've seen other instances (on other discussion sites) where the debates quickly become namecalling matches, so I'm a little paranoid of that.

Andrew:
Thanks for the updates button bar, I'll try it next time I get a chance. While I agree with your stance on providing functionality only where it is wanted, I think that tabs already accomplish this with Mozilla. If only one window is open under the current window, no tabs are visible. Tabs only become visible if they are used. I just don't see the usability downside of having tabs available in the base application (there could be a preference to disable them).

Sven:
I hadn't tried Opera in a couple years, so I downloaded it and gave it another shot. I came away with the same impression I came away with a couple years ago. The tabbed browsing solution under Opera just doesn't work well for me (I actually prefer the K-Meleon way). In Opera, it looks like all windows are either separate on the desktop or under a single window. There doesn't appear to be an easy way to have both separate windows and tabs (and pop-ups behave strangely in Opera). Also, I dislike that with both Opera and K-Meleon, that the button bar is completely separate from the window area that it controls. When the hotlist is up, the button bar still spans the whole window. It is just my opinion, but I really don't like the Opera GUI (I know a lot of people do).

For examples of how I would like to see tabs implemented, look at:
http://galeon.sourceforge.net/ (I dislike the close X on the tabs and the hard edged theme)
http://chimera.mozdev.org/screenshots.html

As for the technical issues around actually using tabs, I don't know anything about MFC or Win32. (I'm a developer, but mainly in embedded and server side stuff) I like the tabs widget for this task. (I've never been much of an MDI fan. I usually prefer several standalone windows to an MDI interface) I understand what you are saying about these not actually being tabs, but the end result to the user IS tabs even if the underlying implementation isn't a tabbed panel. Tabs are used for switching between separate same-sized views within a sub-panel of a window.

My point about the flickering stuff was just that the method of implementation (layers of separate windows) was obvious from the way the GUI behaves which for me breaks the "tabs feel". And yes, my computer is very slow (you should see Mozilla. S...L...O...W)

> Secondly, having 3 section breaks in menu with 5 items is... well... thoughtless. It doesn't help, it confuses. Why there is section break between "close tab" and "close other tabs"

Because otherwise it's damn easy to accidentaly click "close (all) other tabs" when you ment to just close the current...
It is highly annoying and even with a section between them it happens sometimes (thus nowdays I only use the x in the right corner to close a tab).
BTW, the choise of NOT having a close all tabs in the Kmel contextmenu is a wise chose

> Now consider my menu having layer list under right-click and Mozilla having it in "Window" menu. Which one is more easily accessible and why?

Neighter. Keyboard shortcuts is and always will be faster. I use ctrl-t to open a tab in Moz eg.

One thing to note though, is that Mozilla tabs make the browser use less resources relative if the same number of windows where open. I guess there could be such issues with the current layer-plugin for KMel, since it spanws "real" windows?

Opps forgot to mention this too, the built in tabs in mozilla is a stripped down version of the Multizilla project. For the good stuff you have to go here

http://multizilla.mozdev.org/features.html