An hamburger menu would feel very alien in the Haiku interface. Let’s leave that to GNOME people. They did this because they are trying to support touchscreen devices, and there you need big menus and buttons. And then it wastes space, so you need to hide them behind a button.
Haiku is designed to be used with a mouse or some other precise pointing device (stylus, lightpen, trackball,…). As a result it is perfectly fine with small buttons and menus.
Sure, but it doesn’t make the menu bar wasted space less wasted space.
We have our hamburger menu since years in Deskbar without looking that alien to anyone, as soon as people find out that clicking on the leaf open a menu…
I think the Web+ menu could similary move in a sensible, precise pointing device compliant way on the right of the tabbar, near the add tab and tab dropdown buttons. Using the web+ small icon for instance…
That the place where people used to Chrome or Firefox would looks for a menu these days, without bringing hamburger foreign UI in Haiku UI…
I already looked at those. I am a little busy with my University exams. So, I am doing my contribution, in parallel with my exams. I will be completely free in a few days and then I will get back to my core work. 
I do not think so!
Idea of having all menu under one button it is not new, and it is good to have such possibility in apps GUI. And “hamburger”!? what?! It is just “Menu” (I not forged ‘Haiku’!).
I did not invent the term “hamburger menu”. This is how this button is called:
As Wikipedia puts it: “Compared to other computer menus, a hamburger button increases interaction cost and pay out in less space usage of the screen.[7]”
I think in our case, the interface is already compact enough (it was largely designed for 640x480 or 800x600 displays in BeOS days), and the extra interaction cost (one extra click to get to the menu + time parsing the resulting menu) is not worth it.
Also note my use of words, I just said it would feel “alien” because we do not use it anywhere else. There are two aspects to this: making it look more native, likely by using a different icon or symbol, and considering wether it can be useful also in other places. “alien” does not necessarily means it is a bad thing, just unusual and maybe a little unexpected. Spaceships are great 
And todays 1920×1080 screen actually can be much smaller than those displays!
And one button menu can be worthed, interaction cost can be minimized by just little bit tweaking menu arraignments (or not).
☰ used even in this site. It is useful.
The hamburger icon, no. But the leaf in Deskbar is a hamburger button, just with another visual.
Actually, I always thought the Be/Haiku menu was very similar to the Apple menu… or maybe the original Start menu.
Do I understand this right, WebPositive, Haiku’s web browser, can’t render UI elements on Haiku’s own web site, because it would need a font that isn’t included in the package? “FontAppalling”?
WebPositive has made some progress and is closer to functional, and that’s great to see. The burden of a browser that can manage with the modern web is huge, and might be the thing that makes or breaks Haiku as a usable alternative for a lot of people. In its favor, compared with any browser I tried on FreeBSD, WebPositive seemed to be much more economical with memory.
But of course it has to work. Failing to carry cookies into a new tab, for example, is not working.
For someone who doesn’t want to just fix bugs but would rather work on UI, how about support for the keyboard? Find out what selecting something with depressed should do, and make sure WebPositive does that, etc.
^ This.
I much rather spend the 24 pixels (or whatever, it’s < 3% of my screen height) for the menu bar height, if I can see the available menu options with one glance and without having to aim and click on an icon first.
Apps that need every pixel available or go for the immersive experience should have a full-screen mode. As e.g. Web+, ShowImage, MediaPlayer have.
You get a point here, indeed.
It also works better with focus-follows-mouse mode. I have a 12" display laptop and Haiku perfectly fits QupZilla, Telegram and Tracker window, along with Clipdinger and Filer replicants on one workspace. Usually I drag’n’drop something from Tracker to either QupZilla or Telegram to upload/share files. With focus-follows-mouse I want to make as less clicks as possible, so hamburger button introducing an additional click would not be good for that workflow =)
While as I mentioned the UI philosophy ought to take a back seat to making things work … I have to say, I’m one who likes to make every pixel available for content, as opposed to wasted on UI.
WebPositive on my 1024x600 netbook screen is, just by eye, maybe a little less than 80% content. I can live with that, but if I could see an obvious way to improve it, I sure would go for that. (Of course 80% is maximum; any reduction in window size to accommodate other windows on the screen, will come at the expense of content.) By “content”, I mean web pages; that’s why I run WebPositive, and it will work best for me if it has room to do a good job of that.
I would like WebPositive to have some privacy-related features:
And the following - although it will certainly be a much greater task than the above:
Yes, all of these privacy features would be nice to see.
A total stable version of webpositive withouth so many crash is better than new skills, it sounds cool but at first it just should wint o qupzilla which is more stable than the native webbrowser…
If the only things you could accomplish in 3 months would be rendering and bug fixes, that’d be great.
Features are nice. Feature wise, WebPositive already far outclasses the application, NetPositive, it seeks to replace. This is nice. For R1, I for one, would rather see a stable browser that renders well. Let the features creep in later.
Well in most regards it does though Net+ was crazy fast back in its day (versus IE of the same era) and I kinda liked the toolbar to the right of the URL field and just the general simplicity and cleanliness of Net+. I’m looking forward to PulkoMandy’s eventual full merge of changes he said is currently backlogged.
I agree with this on a conceptual level. Bugfixes should take priority over new features.
However, in practicality I don’t think that always makes sense. Certainly not in the scope of this thread. I doubt we will attract many people to GSoC if we tell them all they can do is fix bugs. And with the current list of WebPositive bugs on Trac it will take many summers to complete.
Don’t get me wrong, I think fixing bugs can be part of it – just not their entire focus. Let them have some fun and add a cool new feature or two while they are at it. Also, adding new features may give them a deeper understanding of the code which will in turn make it easier to fix bugs.
Truth. My comment did come across more absolute than I intended.