waddlesplash | 28 May 04:26 2016

Prototype of new Mandelbrot app


I've been working on a rewrite of the Mandelbrot app in my off-time
for a while now, and it's at the point where I'm looking for feedback.
It's a complete rewrite from the ground up of the old one. At the
moment, it supports various different fractal sets and palettes, and
looks much nicer than the old one, as well as supporting rendering in
HD, but it only runs on one thread, and it could use some

You can see screenshots and download a prebuilt binary here:
The source code is here:

Thoughts, comments, etc. welcome, of course.

Sean Burke | 17 May 15:17 2016

Re: Dial widget

Dear Sirs,

Love Haiku but How do cancel the daily emails? 

Thank You


Dario Casalinuovo | 17 May 00:34 2016

Re: Dial widget


On Mon, May 16, 2016 at 10:40 AM, PulkoMandy <pulkomandy <at> gmail.com> wrote:

> I can understand this perspective in regards to an input knob widget, which
> is the worst type of skeuomorph and should generally be avoided.

Thing is, skeumorphic controls *do* have their place.  Look at most audio apps - lots of softsynths and effects use "realistic" control panels.  Whether that's a good thing or not is debateable, but it's what the expensive commercial stuff does so it's what a lot of people want.  My view is that it should look like something you want to play with - you could just use a grid of numbers and sliders to program your softsynth but then you might as well be sitting there doing your accounts.

I don't agree with these people then.
for audio, on-screen knobs are useless.

I could agree too that they might be useless, while not in all cases. I don't think Haiku should commit the same error of it's predecessor of being a geeky os. Customers matter IMO.

Don't expect anyone to use what you provide just because the Haiku devs are saying it's the Right Thing™.

I don't think everything should always be completely reasonable from a design point of view or that preferences should win vs a user need. Others already pointed out more than one reason for why the widget should be provided.
> However when it comes to a gauge/meter display widget, although it is a
> skeuomorph in some regards, it is quite diffrent as provides a lot of
> information at a quick glance. For instance, modern digital car dashboards
> still have gauges, even if they could easily display information in some
> other digital native manner.

Even with LCD dashboards (some of the buses I work on have LCDs bigger than my laptop screen) display things as analogue gauges, because it's easier to get a visual "read" on whether it's showing more or less than you want.  If the pointer is up *there* then you're doing 40mph, you don't need to read something that's flicking between 39/40/39/40/39/40 all the time and distracting you.

Yes, I did not suggest using plain digits for this. My point is using an horzontal or vertical bar rather than a "rotating" dial.

I don't see the point here. Someone might want to use knobs, others a slider then why the decision should be to avoid providing one instead of both?

Generally, the potential here is to losing credibility among other platforms.
Richie Nyhus-Smith | 16 May 11:30 2016

Re: Dial widget

How on earth did I double reply ?



Richie Nyhus-Smith | 16 May 11:26 2016

Re: Dial widget

> Right, but the overlap with our BProgressBar is still a concern. I think it would be better to work from BProgressBar and extend or subclass it to allow a circular display, rather than doing an entirely new class. I'm still not convinced it would be that useful, as it would show the same information and probably use more space in most cases.

BDial is based on "AnalogClock", so I assume "AnalogClock" (plus other clocks) and gauges/meters would call on it for help with their display.

Julian Harnath | 16 May 10:57 2016

Re: Dial widget


On 16.05.2016 10:40, PulkoMandy wrote:
> I don't agree with these people then.
> for audio, on-screen knobs are useless.

A positive point for circular knob controls is screen space vs control 
accuracy. I think that's also a main reason why they are popular in 
audio software, besides the "model physical interfaces" thing. Audio 
tools often have lots of parameters to control. If you add dozens of 
sliders, the window gets very big and/or crowded. If you make the 
sliders smaller to get in more things, you lose accuracy.
Knobs in audio software are usually implemented like the volume knob in 
SoundPlay: when you click on it, you control its value by moving the 
cursor linearly. (There has been software out there with knobs that 
actually require you to move the mouse pointer circular to change them, 
but that's indeed quite bad IMO ;-)
So the knob is more used like an "invisible slider": you still get the 
accuracy of a large mouse movement range, you can still see the current 
value immediately, but it doesn't take up lots of space.

See e.g. this screenshot: 
Each of the circular things in the lower part is such a knob control. 
Imagine how crowded the UI would look if each one would have to be a 
large-enough slider. Oh, and the UI style is the opposite of skeuomorph ;-)


PulkoMandy | 16 May 08:28 2016

Re: Dial widget

As far as I know, none of these were integrated. There are several reasons for this, but the main one is that this kind of circular widget is not very intuitive to handle with a mouse. Horizontal and vertical sliders accomplish the same purpose and are easier to handle.
We are trying to build a coherent look and feel, so several widgets for the same function is something we try to avoid. If one application decides to go with a non-standard widget, it is the app developer decision to do so, and they can include the source of these controls in their app if they need to.

Adrien Destugues / PulkoMandy
Richie Nyhus-Smith | 14 May 08:57 2016

Dial widget

Hi all,

Was the dial widget that was created for GCI a few years back ever up streamed to the Haiku source code?

I think this is the latest version:

Equivalent class from Qt for reference:

While the class might not fit with Haiku's design philosophy overall, it might be quite useful to TuneTracker and other developers working on similar software.


Pete Goodeve | 2 May 08:17 2016

Ogg audio and mimeset


I just noticed that if one imports an audio ogg (vorbis) file that doesn't yet
have a mimetype, it gets assigned as 'video/ogg', which confuses things like
the Sounds Preference.

I see they both have the same Rule in Filetypes, but only the audio version has the extension '.ogg'.  I don't
know anything about the format, so I've no idea
if there's some rule that could distinguish, but it'd be nice if it could get it right
without having to correct it manually...

	-- Pete --

Luposian | 5 Apr 10:51 2016

Re: Documenting your package

On Apr 5, 2016, at 1:27 AM, Thomas Mueller <mueller6723@...> wrote:

>> man and info are not so Haiku friendly, though.  You have to use the ***x command-line
>> programs to read them, so they do need their own hierarchy. (I wonder if it would be
>> worth giving them mimetypes, and preferred apps, so a user *could* click on the file
>> to read it?  You could even then have links to those pages from the main doc folder for
>> that app  [I actually long ago set up a xicon script that you can drop a man file on to read].)
>> I guess I can live with .../documentation/packages as long it is a clear standard, documented
>> somewhere.
>        -- Pete --
> I believe you need "man" to read man pages, but reading an info page with "info" is an awful nuisance, I
always do something wrong and need q to escape.
> I could read an info page better with "less" than with info!
> KDE's Konqueror did a good job with info pages, at least in Linux Slackware 13.0.  Otherwise, there is
pinfo, which I find is not in haikuports.
> pinfo is text mode with interface rather like Lynx web browser, much nicer than the command-line "info".
> Tom

Can't we just translate all documentation to a standard format, like plain ASCII or HTML or PDF or a
cross-platform format that anyone can read without terminal commands or such?  Why continue to do things
in such an archaic CLI fashion, in 2016, concerning, of all things, documentation?

Pete Goodeve | 3 Apr 08:28 2016

Irritating WebPositive quirk

Not sure where tickets for W+ go, so I'll whine here.

The recent releases of W+ have the irritating feature that
it inevitably opens with the last accessed page, which is almost
*never* what I want.

What's worse is that I have some desktop icons like "Wikipedia"
which are actually bookmarks to invoke W+.  They invoke OK,
but then the app opens another window, with the previous access,
smack on top of what I *want* to read!  Driving me crazy...

Any way I can correct this?  If not, can somebody please put
in an option as soon as possible?


	-- Pete --