cosmogatokat, I agree with you. It is a good icon and fits perfectly with a flat icon theme:
On a 3d icon set, be it isometric, or other perspective does not match so well the HIG.
That is why there are Icon Sets 
Regards,
RR
I really prefer the original one and i use that software a lot. 
Really dont want to re build it with the originalā¦ but if you want to make me do it then is sadā¦ and i ask you are using Godot engine? cause i live in it.
I Added support for seing āCommitsā (right click on the repository)" in my application āIssuesā. So you can now follow Haiku commits directly on your desktop if you want to. There are no settings yet for how long the message can be - I will add an option for truncate it in the future (and maybe hiding avatars aswell).
For the brave ones: https://github.com/Konrad77/Issues
Just download and compile it. Should work on 32bit and 64 bit.
There is no shared cache for images right now so there will be many network requests even if the same person is the commiter/issue author.
11 Likes
Is a very ugly icon, please, dont use it, it is my principal program, i need a lot godot engine, but i really hate that ugly icon
Good day,
@cosmogatokat, no need to worry, at least just yet.
The fact that I am trying to port Godot 3 to Haiku does not mean that I will succeed. Iāve tried twice already, two failures. And adapting Godot icon to Haiku icon guidelines is secondary.
That said, IMHO, I think that a consistent interface should be consistent all over, and the icon theme is only a part of it. Be it the case that Haiku supports changing icon themes each icon theme designer would create icons that match the icon theme. Not sure if in Haiku one can change only one icon, but I presume so, though I havenāt tried yet.
So just relax and donāt worry about Godotās icon for now. If can get Godot working on Haiku 64 it will be already a great success. And that is what is important for now, at least for me.
Donāt expect a Godot port on my side in the next months, moreover, taking into account that 3.1 is around the corner. I still need to learn a lot about Haiku, porting apps to Haiku, and Godot, before the port can be achieved with at least, some quality and stability that offers some real usability. Godot on Haiku 64 right now is unusable, so the task is a hard one, and I am no expert on anything.
Regards,
RR
Right now, iām working on a native wallpaper changer app, itās not yet nowhere near usable, as a newb i didnāt know what i was getting into and the amount of work needed for such a small app, but that doesnāt discourage me.
Just to let others know iām working on this.
2 Likes
My native video editor (called Medo) can now import sound and show a visualisation of the sound buffer. Still need to analyse the sound buffer in order to filter out the peaks/spikes, since it impacts the visualisation buffer. Audio tracks will have non destructive effects, just like video effects.
Iām still searching for a good audio mixing library, but they all insist on piping data to the sound card and streaming, while all I need is in memory mixing of small sound buffers. Looks as if Iāll have to do this on my own. At launch Iāll only have the basic audio effects (fade, filter, amplify, maybe a couple more) as well as the usual trim / move.
PS - the screen shot shows only a couple of video effects plugins that have been loaded - there are a lot more available, Iāve just culled them from the development build since they take time to load/parse. At this point in time, Iām only interested in audio.
12 Likes
That looks pretty neat!
Iāve started collecting notes for a potential future MediaKit2, with the goal of having it be able to be powerful enough to serve as the media engine behind professional video editing software. But yeah, for now, I donāt think our regular MediaKit facilitates this well. You can probably instantiate a āMixerNodeā somehow, but Iām not quite sureā¦
1 Like
The mixer node (and mix-a-lot sample code) are the last step before the sound card driver, I havenāt found a way to pipe itās output back to user code. Doing my own mixer shouldnāt be a big deal.
Re: media kit updates, I only require the decoding and encoding capabilities and they work OK for my requirements (seek/reads do occassionally fail, but retrying seems to work - go figure). The design of the MediaKit seems to cater for live node insertion, so ideal for real-time streaming. For off-line uses (eg. video editing) itās overkill. A bit more sample code should be sufficient for most developers.
Bit of history, from the BeOS Bible book and some original BeInc marketting media, there are pictures/videos of a real time video mixer. Those requirements were most likely the inspiration of the MediaKit redesign in Genki (BeOS 4.1). Dont know what happened to that product (was that the Roland Ediroll 7?)
Well, you need to do real-time āstreamingā for the preview pane, right? And the MediaKit design in general starts to make less and less sense the more you use it; itās kind of overkill for everything in a sense. Hence the need for a redesign.
Perhaps the approach Vulkan takes would be wise, first a flexible future proof API that is perhaps overkill in every way, then an easy to use one on on top of that or various that cater to different use cases. And doing so in a way that compiles down to a single thin layer would be admirable. Something that Vulcan doesnāt really do afaik.
Being portable to other operating systems might also be a goalā¦ though perhaps with less available features.
Hardware acceleration is definitely a consideration also. Back when BeOS was written this probably meant a DSP coprocessor directly attached to the CPU though.
The mixer is a regular media node and you can create more instances of it and pipe them however you want. The game kit used to do that, IIRC. And you can easily do it in Cortex as well.
I am not working on anything specific for Haiku - but I write a LOT of ruby code, 98% of which is on rubygems.org in form of gems. I can adjust all this code to work on Haiku too, which may not make any huge impact but may make a little change. I also try to document my code as much as possible, at the very least in how to use it.
The biggest problem I have right now is ā¦ find good documentation in regard to Haiku.
The other thing - perhaps since there is now a package manager on Haiku, it may help to sort of organize projects in a central manner on Haiku, on top of what people already use elsewhere.
I give you a silly example for this but it works.
Do you know the game wesnoth? Itās an open source game, quite ok if you donāt mind turn-based strategy games. They have add-ons in the game (via a widget); and an add-ons manager.
Precisely something like this could be nice for Haiku, like ā¦ you have the official package manager, but you also display some widgets within Haiku itself (optionally when the user clicks on any of these), to also highlight and showcase third party apps like mentioned here.
This would require setting up some minimal infrastructure though, perhaps some central format, a yaml file or a json file, to describe such a project. Also add some tags so that people know what it is (video, audio, graphics, games etcā¦ things like that so that it can be found).
This would help people find these applications. A filter-system for searching should also exist - all the UI here can be minimal too. Even beta-ish.
User rating may also be useful at a later time, aka how good an application is. (This could be reset or re-checked every year or two, to provide accurate information.)
I am pretty sure that this would help people more pro-actively discover things. Otherwise it is hard to find stuff. Googling takes too much time really.
One has to start somewhere.
PS: I think adding a package manager was a good idea; hopefully it is also documented extensively.
One can start a 3rd party repo to host own hpkgs. One can create recipe at haikuports too. One can just host his hpkg in a webserver without repo.
Iām well against an āalternativeā packaging format or info-databank, because it makes a mess, dependency-wise.
A hpkg already nicely defined, battle-tested, and easy to make. It can provide addons, so i would propose use .hpkg for that kind of task.
But still a question: why canāt you use the Depot for this?
Iām working in a gcc / g++ proxy that removes non-haiku compatible flags & libs (aka -pthread -rdynamic) before calling the real gcc / g++, and also adds haiku ones (like -lnetwork)
Could use a config file to override both add/remove lists, incase of other needs.
It adds overhead (obviously) but lets you compile vanilla sources, without adding patches for them. Or at least not needing to edit makefiles / gypi files for this.
For example, compiling redis now goes as download, make deps and make redis, untouched from github 5.0 branch download.
6 Likes
That could be very useful! Great work 
Hi all,
Iām the author of Genesis Commander, and after 14 years Iām thinking on continuing it. I really like the beta.1 version, and Haiku deserves a native commander. At least I should fix some bugs. But first of all, I should set up a computer for the developmentā¦ Hmmā¦
Best regards,
Zsolt
13 Likes
Join to #haiku-hun at freenode 
Ćdv Ćŗjra itt!
1 Like