Gimp is a really good program, there is no doubt about that.
But it would be nice if people do not always ask for program that there are on other systems, but would sometimes deal with the programs that already exist. Wonderbrush is hard for me to understand because i have not enough expirience with working with layers, but this is where people could start with simple tutorials instead of asking for alternatives. I think Wonderbrush is worth a look and people who are familiar with layers would get ahead quickly.
There was a old port of gimp back in beos times, but it needs x11.
Iāve read some good things about Wonderbrush. Never really used it because itās not available (as far as I know) on 64bit Haiku which I mainly use. I do have a VM with 32bit Haiku around, will take a look at it.
On the whole ānative vs. ported appsā topic: I understand the arguments for both sides, itĀ“s really nice to use native apps that are well integrated with the operating system. On the other hand I have to say Iām a big fan of cross-platform apps. I use Linux, OSX (or whatever it is named at the moment) , Windows, and Haiku. Depending on where I am and which computer I have at hand. So I have to learn how to use the application only once and can use it on all my computers. And can use and edit the files that Iāve previously created.
To sum it all up, I think it its not about native vs. ported but its good to have both, the more the better.
Any particular reason you only run 64bit Haiku? You know 32bit Haiku has PAE so you can actually use much if the ram in a 64bit system though less per application.
Iām developing a video editor for Haiku, each frame @1920x1080 uses 8Mb of RAM (images do get uncompressed), or 240Mb for 1 second worth of video. For 4K videos, memory requirements are *4. With only 2Gb available for 32 bit applications, you only have 3 seconds worth of video cached, which makes scrubbing an unpleasant experience. I will not be doing a 32 bit version of the editor since itās pointless, especially considering that for the last decade you cannot even buy a box with less than 8Gb RAM. And I dont expect anyone to use 720x576 or similar resolutions.
amazon .com: 1-24 of over 5,000 results for Electronics : Computers & Accessories : Computers & Tablets : Laptops : Computer RAM Capacity: 4 selected: ālaptopā
Not only there are PCs with 4GB RAM or less, built in 2018 and recent years, but some of them canāt even be upgraded because the manufacturers made it technically impossible. And 720p is not unusual at all. People have phones and digital cameras that shoot at that resolution. I donāt think they all need video editing, but certainly some do.
Video editing needs many RAM so it is ok is there is a minimum range set. If you buy a Editor you need to have the right Hardware too. I does not can do it everyone right
As in Linux and Windows the king was Xbox360 controller and hardware mapping using its driver, i would make it one of the supported hardware if talking about gamepads.
Iirc, ps4 dualshock 4 pad could be used in Linux through this driver too.
Joystick/gamepad support works. SDL uses the native drivers. So if it works in SDL it will work elsewhere.
If your particular device doesnāt work, please submit a bugreport.
Well, itĀ“s probably not the most technical reason, especially as my main haiku machine has only 2GB of RAM. But 64bit Haiku seemed cleaner and easier for me to use because I donĀ“t have to remember to type setarch x86 before compiling anything. Also with the libraries in haikudepot, you always have the libraries double, for gcc2 and the modern gcc (7 at the moment).
But as I said I have a 32bit Haiku VM because I wanted to test TrackGit, which atm only compiles with gcc2. So Iām going to boot up that vm and take a look at Wonderbrush.
Does anyone know if thereās a list of apps only available on 32 bit Haiku that need modest code rewrites and recompile on 64 bit?
Are these purely on the ports site, or are there some apps considered ācoreā or āfeaturedā in Haiku Depot that are missing on the 64 bit version?
Being new here, and only running on 64 bit, Iām not sure what the above answers are. Creating modest modifications to apps and getting them to recompile in 64-bit sounds like something I could do on the train to London when bored thoughā¦
Steam running on haiku? I would not ask for anything else in life ā¦ I have haiku a good few years and I can say with joy that of all the systems I have used it has been the best.
A way to get a list of software thatās not available on 64bit is to grep through the haikuports recipes for ā!x86_64ā and ā?x86_64ā (adjust your haikuports path):
Of course, then itās a matter of finding out whatās the issue. Is it a dependency missing for 64bit thatāll have to be tackled first? Or is it just a matter of patching a few locations in the code? The fun beginsā¦
Thanks for that. Looks like there a lot (350 ports)ā¦ I wonder if ?x86_64 means doesnāt support though - there are a number of recipes with just that in the architecture line.
There are 55 recipes that explicitly have !x86_64. Includes postgres, abiword, gdb (! v7.7, but 8.1 is the latest), tuxracer (surely a priority? ;o) ), archiver, artpaint, jammin, projectconceptor, sgebrush, ffmpeg (weirdā¦ v0.10.16) and llvm (v6.0.1 - the latest recipe).
Looks like some of the 55 just have one of the several version recipes that donāt do 64 bitā¦ So the find/grep mechanism doesnāt necessarily give the status of the latest recipe. It also of course doesnāt tell us if the recipe that exists is for the latest version of the library/app available.
Iām wondering if itās worth writing a quick bash script to extract the SOURCE_URI from the highest version number port recipe file for each package, then listing the remote folder (or git repo) above the source download file, and determine the latest version number, then give a report on which ports are the latest or not.
ā¦ useful? (Have I just volunteered myself for a job?)
So I thought I was on a winner for this. Some sites, like gnu.org, you can list the source packageās parent folder and therefore grep its content to determine if thereās a more recent version.
The problem is, not a lot of packages allow listing of the parent folder, or the parent folder is just a website - not an ftp like folder listing.
So for GNU hosted packages or git folders itās possible to automate discovery of the latest version, but not for more packages that are just hosted at a random URL.
The HaikuPorts wiki has a link to Repology where you can see if thereās a newer version of a package. They offer an API and the HDS provides the version of a package which a talented and industrious web coder could use in collaboration with some cunning scriptingā¦
OTOH, people interested in using some library or porting an app depending on some version of it, will speak up if they need a newer version. Then they either try to update the recipe themselves or open an issue at haikuportsā¦