I think the premise of your question is incorrect. It assumes Haiku cannot be both useful for legacy compatibility and innovative in building new features and services on top of this base.
Personally, I won’t be spending any time worrying about 32 bit support or BeOS app compatibility in what I do in the OS day to day. (Although I’m sure people will want the Paladin IDE to be able to build 32 bit BeOS compatible apps…)
Whatever we add though will have a maintenance overhead so we need to be sure it’s worth the effort. Certainly ensuring existing groups’ efforts work well together rather than duplicate functionality is a good thing (Think Koder and Paladin IDE here - I have no real interest in adding YetAnotherCodeEditor to Paladin).
I’m sure there are a group of functions that we could add to an API on Haiku to benefit all app developers and users of those apps. As an example, someone mentioned adding scripting support to apps for Hey. Well, is there a way of making that much easier so it’s “on by default”? (E.g. automatically export all Menu Items as scriptable integration points, or similar for BMessages being sent to apps)
Replicant samples and recipes may also be a good way to expose value-add services to users without a lot of additional code bloat and associated maintenance cost.
Building all this in to the Paladin IDE so an app developer just has to write purely unique code for their app would be good. So I write a clock and notification app, but automatically I have replicants for a clock and upcoming events, and hey scripted commands for adding/listing/getting/removing events.
Define your protocol for remote controlling an editor, and people writing text editors will have to implement it if they want their app to be taken seriously. Probably other apps will make use of the feature and it will become a standard thing expected from any text editor.
This is how we build an Haiku ecosystem, and also why it is hard to fit ported applications in it.
There already is an “on by default” export of all controls of every window for scripting. But it is a pain to use. Scripting an app by locating windows, buttons and menus is not the best way to go about it. The point of scripting, ideally, would be that you get direct access to the application internals and “business logic” and manipulate this.
For example, you should be able to say “hey text editor, open file.cpp and put a red, wavy underline at line 100, colums 20 to 35. And scroll the view so that part is visible to the user”. You should not be doing this by invoking menus programatically (in fact there may even not be a menu at all to do that).
Likewise, “hey web browser, open a window at (100, 100, 600, 400), hide the navigation controls and show just the manpage for strcmp”. And later on “hey web browser, close that window you opened earlier”.
Note how I used generic “text editor” and “web browser” in these examples. The idea is you would find the preferred app for sourcecode (resp. URLs) and send it generic commands without worrying about how its menus and buttons are laid out. This means if you replace WebPositive with NetSurf, or Pe with Koder or Gvim, things still work as expected. Likewise if you update to a new version of the apps with a reworked UI.
We have the tools to achieve this, yet no one has really put them to good use yet.
Yeah perhaps I should have been more clear. I actually meant ‘export the event handler behind the menu item’, rather than perform some evil UI location dependent x,y co-ordinate based click faking.
We have this already. Literraly, the command line would look like “hey application invoke item 3 of menu 5 of window 3”. It’s not x/y click faking, but this is still not what’s needed. There is no way to access menus by names (I think they don’t even have a name, only a label which is locale-dependant so unusable for this).
Controls and windows do have a name so that’s slightly better, but still not enough for something generic that can work by sending the same message to different interchangeable applications.
Right gotcha. So really what we need is a way to name and describe an incoming event that is handled by the app, along with its invocation options. That mechanism could then be used by menu items as well as hey integration, and possibly also invoked via a standard BMessage mechanism. So a slight separation from what we have now.
Dare I say it, kinda like iOS app development works. There you can define an integration point in Swift with an annotation, and then it’s automatically visible in the visual development IDE to use.
I might try and mock this up at BeGeistert just to see how it ‘feels’ from a programmers standpoint.
It’s reachable using the “hey” command line tool but also usable with BMessages from one app to another.
The problem is while we have the whole protocol already defined, very few apps actually make use of it. It’s about time we start actually doing things with it.
Heh that’s what I deserve for not reading the legacy documentation…
So thinking of Paladin and Editors, we could define a standard protocol suite suite/vnd.Haiku-ValidatingEditor that had a “HighlightProblem” command. This command would have a FileRef specified, a Line Number specifier, and a ProblemDescription property that could be set by Paladin should a file fail compilation.
In Pe/Koder/GVim, this file window would be given focus, the cursor and view moved to the line, and an error flag set on the line with a popup description.
This could be implemented by any editor, and could be used by any compiler/code checking tool.
Is my understanding correct?
My last question would be, the documentation on the page you sent says that suites are discovered from live running apps by sending a message. Is there a more static way to discover these? I.e. are the suites supported discoverable from the app binary or another file distributed with the app? Is a ‘library’ of suites built up by the OS anywhere (E.g. from installed hpkg file introspection)?
If not, would it be useful to have a Macro to say “This next function should be exposed as a command in a suite for this app”, which generates such metadata for use by a scripting tool. (Or does this already exist somewhere???)
Apart from the integration discussion above, on the topic, seems like there is a Haiku package contradiction with python (iirc), as the python package is for gcc2, pyqt for python 2.7 is for gcc7 (x86) , so you couldnt invoke QT apps from the bundled python2.7 or you will trigger the infamous __tls_get_addr bug
I am able to do so in my tests, because i installed my custom python2 version for x86 so I can work with it, but…
Gotta upstream this to the haiku depot version(s).
Experienced this bug being on default arch on 32bits, when trying to run wcgbrowser with pyqt. I’m testing this to compare its browser backend (qt) with Webpositive. @PulkoMandy I didnt think of using Web+ in kiosk mode, but having something like this browser does (it’s python code) for kiosk configuration (whitelisting, autodisabling popups, …) may worth it in the long future.
Talking about python 3+, I tried several times to install python 3.6 from the repositories and it always stops at around 95% (my guess). Am I the only person having that problem? I am living in China, therefore weird things can happen in regards to connection speed, but I can see the download progressing in the progress bar.
Yes, that’s the idea, define a “standard” protocol, and then have multiple editors implement it.
Currently the discovery is only dynamic, which indeed is not perfect. What I was thinking is that you would ask the MIME database for an app handling the text/sourcecode MIME type, and expect that application to handle the matching scripting protocol. But that would just be a non-enforceable agreement between application developers. Maybe we need something stronger. In that case, exporting the scripting structure as a symbol with a known name would allow to detect it by load_image and peeking at the data structure.
Adding a metadata entry to packages certainly is possible. How would that one be used? I guess the Paladin package would REQUIRE “scripting:validating_editor” to make sure at least one such editor is available?
So after doing some research, some months ago I decide to dome some Python development, mainly because GodotEngine’s GDScript is “based” on Python, thus it seems like an optimization of processes, “learn once, use multi”.
I made my first Software ever a couple of months ago, using Glade and Gnome-Builder, and built it as a Flatpak, coding in Python and using meson integrated inside Gnome-Builder. It took me a whole lot amount of time to get it done.
Now, I decided to use that “knowledge” in Haiku too, so I checked the Python bindings at:
I did a bit of experimentation with the python bindings a few weeks ago. The repo didn’t work for me too, didn’t find any packages. Maybe because I’m on 64bit Haiku.
Anyway, so I tried to download the source files and compile them myselves. But the “Downloads” link doesn’t work.
What you do have to do to get the sources is go to “Files” and click on the commit number, currently f2fd4a5a04. You get to a page where you can download the files as tarball or zip.
Then you just have to unpack the sources and compile them. As far as I remember it was just a simple make and make install. I think it installs somewhere under non-packaged.
I didn’t dig into the Haiku API for python yet but I ran some of the samples and they did work well.
Hope that works for you, if you run into any problems feel free to ask
BTW, does anybody in the Haiku community have contact with the guys that did the python bindings? Maybe the code could be put on HaikuArchives or mirrored there. And then integrated into HaikuPorts.
Thanks @BlueSky, (I’m on 64b too) I will check the procedure this weekend and post any outcome.
I agree with having the bindings on the Archives and Ports too.
