VisualStudio Code on Haiku

XAML was an interesting idea but doing anything with XML is doomed to fail. It’s the worst possible SGML format there is (even worst than HTML). Please, please, don’t start something new based on XML. Let’s just let it die in peace… :slight_smile:

Something lightweight but powerful, developed at Adobe and used internally are the Adam & Eve libraries for declarative layout: Adobe Software Technology Lab: ASL Overview
(part of the Adobe Source Libraries - ASL). I think this would fit with Haiku much better that anything based on XAML/XML.

I see two main use cases here for devs:

  1. Kernel & driver development
  2. Application development

They are quite different workflows and need different setups & tools. I would love to hear @PulkoMandy’s opinion about what tools & setup he recommends for development (and not just him, but all seasoned Haiku devs who have an opinion).
(Obviously devs have different preferences and these would be merely some (useful) suggestions brought forth from years of experience).

1 Like

What do you think exactly is different about kernel and drivers? There is no black magic involved, it is C++ code just like userspace. I use exactly the same tools.

In my case it’s a very old-fashioned setup, based on vim. I have a few plugins, mainly YouCompleteMe that provides code completion. This requires some manual setup work to generate compile_commands.json from the jamfiles (I have patched Jam to allow this). My config is not clean at all, it’s a setup I drag from one computer to another for more than 15 years now. I have a probably outdated backup of it here: https://github.com/pulkomandy/.dotfiles/tree/master/.vim but don’t expect it to make any sense.

Really I don’t think the main problem for kernel/drivers and more generally system development is your choice of IDE however. Consider the fact that to test changes that affect the whole system, you will need to reboot a lot to test your changes. Doing this natively from Haiku on a single machine is annoying. So you have two options: do it from Linux and test your changes in a virtual machine. Which is complicated if the VM does not emulate the hardware you’re writing drivers for. Or, use network booting and two machines: compile your code on one, have it act as a remote_disk_server, and use that to network-boot the other machine to test your changes on.

It doesn’t matter which IDE you use for this.

When testing applications the setup is a lot simpler: compile your app and run it. Any IDE or even just a text editor and Terminal can do this. If you’re looking for one to contribute to and improve, you can join Adam and KapiX on their work on Paladin and Koder, respectively. This seems to be the most advanced native solution at the moment. I never tried Koder and the only case where I used Paladin was to convert old BeIDE projects to makefiles so I could go back to my usual command line based environment. I don’t think this is the kind of setup people are looking for here in this topic, which is why I have not jumped in to advertise it. I have nothing to contribute to this discussion about tools I don’t use.

3 Likes

Thank you, contrary to your expectations, I think it was useful (for me at least). I agree that the editor is not as important, we tend to debug a LOT more than we write code so having a good working debugger can speed up development a lot. This is where I think the two workflows are different - in the debugging/testing. (You can use the same editor in both cases indeed).

I’ll give Paladin and Koder a try and see which one suits me better.

1 Like

They work together. Paladin is just a project manager (essentially a GUI for jam or make), and uses a standardized protocol to communicate with a text editor. Currently the text editor can be either Pe (an older one from BeOS) or Koder (a new one, promising but still missing a few features from Pe). Other editors could be wired to use that same interface too.

This approach is in line with some of the ideas of how native Haiku apps could work: by having a consistent operating system and API, we can easily make complex apps share data using documented protocols, letting users build their work environment by assembling multiple smaller tools. This also provides more room for innovation in some ways (replacing a smaller component without redoing everyhting else).

5 Likes

This approach is in line with some of the ideas of how native Haiku apps could work: by having a consistent operating system and API, we can easily make complex apps share data using documented protocols, letting users build their work environment by assembling multiple smaller tools. This also provides more room for innovation in some ways (replacing a smaller component without redoing everything else).

Amen to that! I subscribe 100% to that philosophy! I’m glad that I found this community, there aren’t a lot of devs out there with the same mindset.

1 Like

Well… from the example on that page…

layout clipping_path
{
    view dialog(name: "Clipping Path")
    {
        column(child_horizontal: align_fill)
        {
            popup(name: "Path:", bind: @path, items:
            [
                { name: "None", value: empty },
                { name: "Path 1", value: 1 },
                { name: "Path 2", value: 2 }
            ]);
            edit_number(name: "Flatness:", digits: 9, bind: @flatness);
        }
        button(name: "OK", default: true, bind: @result);
    }
}

A Xamlish version would be:

<clipping_path>
    <view style="dialog" name="Clipping Path">
        <column child_horizontal="align_fill">
            <popup name="Path:" bind="{Binding path}">
               <popup.items>   
                  <Item name="None" value="empty"/>
                  <Item name="Path 1" value="1"/>
                  <Item name="Path 2" value="2"/>
                </popup.items>
            </popup>
            <edit_number name="Flatness:" digits="9" bind="{Binding flatness}" />
        </column>
        <button name="OK" default="True" bind="{Binding result}" />
   </view>
</clipping_path>

The only part that is a bit sketchy is the bind attribute, I think it should probably be the “display value” (so, Value or Text or something like that) in some cases and a “Clicked event” on the button. But word for word using Xaml, this is what it would most likely be. And there is like, zero difference - apart from the Adobe stuff is bespoke and non-standard and the Xaml is basically Xml with extra binding magic. I think the syntax is not really going to blow anyone’s mind and I don’t see any advantage to the version Adobe was specifying (in 2004 - did they ever actually use this?)

1 Like

I also use vim exclusively for work, however I recently was given a task to configure VSCode for some projects to make it easier for windows users in the company I work at to build and work with our code. The vim keybinding plugin for VSCode is surprisingly good and I found that I enjoyed the file browser pane and integrated debugging. I know you can get file browser panes for vim (never really bothered myself as I just use multiple terminals and grep/find to get to what I am looking for) but I am not sure there is any really well integrated debugging plugin.

When it comes to using other editors I wouldn’t personally be interested unless there is a good vim keybinding plugin because it’s already too deeply embedded in my muscle memory… anything else would slow me down. I also can’t see how WIMP substitutions for some features I use in vim, regex substitution for example, can ever be as fast or powerful as they are with an editor like vim. It’s a shame that VSCode is written in such an obtuse framework/language because I’ve not seen another editor where the vim bindings are so good that I can basically just treat it as vim with extra GUI sugar.

1 Like

A parser is a parser. If the language it parses is out of line, we’ll replace the parser with an equivalent. My suggestion of using XML was just an example. GXI doesn’t use XML but uses a Rust-like syntax. I would like to avoid C-like and Rust-like syntax for an external parsers and XML parsers have ready-made parser generators like eXpat and others.

The main gist of using a language for GUI rather than a plugin library is that the primitives can be combined to make a single entity for GUI layouts. The compiler for such a language can optimize the tree in ways that C++ compilers can’t.

Re:VS Code vs. Paladin and Koder
I’ve tried both and when programming in Rust, VS Code’s integrated debugging plugins with the red squiggly lines under the errors speed up development time drastically. Koder’s got syntax highlighting only and that is not enough. I’m not even sure if Scintilla can support the integrated debugger squigglies even though Scintilla is used in quite a number of IDEs including Koder.

Patches welcome. After discussing things with Adam the conclusion was that it’s better to implement LSP support in the editor, and have Paladin feed it proper paths. Of course when that is in place, those can be provided by the user manually, so it can work standalone.

Scintilla can do pretty much anything you can imagine and more when it comes to code editing: Scintilla Documentation
Someone needs to tell it what to do though.

3 Likes

Beeing able to write the gui in the code is the main reason I like to code on Haiku. BLayoutBuilder works fine, why do you need a new syntax for that?

Using object-oriented containers enforces encapsulation on code that would benefit from being able to combine all the gadgets into an integrated irregular grid for processing all clicks with 3 array lookups per click in constant time. Compiled GUI code can make things faster as the SixtyFPS GUI linked in my earlier post indicates. The syntax of 60fps is Rust-like as is GXI but I’d prefer to keep the syntax of the GUI layout resource neutral to the host programming language if at all possible, so an editor doesn’t need to have a separate output format for each programming language binding that it would have otherwise.

Where are you getting this from? How does using gui in code enforce /anything/ about the design?

I honestly do not understand why you want a seperate langauge for GUIs, you have not really demonstrated any need for it.

@nephele I’ll start a separate thread for it once I get the diagram created. I’ve got a job interview tomorrow and want to prepare for that instead.

Re:Scintilla indicatiors
Indicators are supported in Scintilla already. It must just need a plugin system to allow it to function.

If you feel very productive one day or two, maybe tree-sitter could be good fit for Koder.
https://tree-sitter.github.io/tree-sitter/

1 Like

I suggested Xaml because it is a fairly standard and robust way to define a UI. Xaml in modern usage is generally compiled, so under the hood it would probably boil down to a layout class. Using a mark-up is just a way to serialize/deserialize the data and make the UI not tied to code. This makes changing the layout not about generating a lot of extra boilerplate code as that is all done via the support code generated by the compiler. I mean, one should then never need to do much other than declare the UI and hook up the event callbacks and data. You can do that in code behind or using a pattern like MVVM… doesn’t really matter.

I have no idea what @SamuraiCrow is talking about. I guess lack of experience using the BeAPI? I mean, the API is already heavily threaded, so I don’t know what “SixtyFPS” is adding…

UI Layout languages are for people unable (or unwilling) to code so they can click-together the UI. That’s really all there is to it. How you turn the UI file into actual code classes (on compile time or run-time) doesn’t change this by any stretch of the imagination.

No. Xaml, as a case in point, is a mark-up, but no one really uses a visual designer anymore. We generally use hot reload. So we need to understand and be able to write Xaml, we don’t use a designer. I have never used a designer, save for preview, and you do that even if you hand write code. But honestly, hand written code has a much bigger turn around time, because you need to compile the entire app.

when “every platform” doesn’t include Haiku, or any of the platforms I care to use. and I like Haiku precisely because it is different, and I don’t want imported “cross-platform”
platforms on top of my OS, especially when C++ does cover all the platforms - and keeps the development effort with the developer and NOT pass it on the user of their applications.

1 Like

I’m a code based UI creator too but I can’t share your opinion. Nearly all the people I’ve seen so far want a graphical UI designer and not touch code, no matter if XAML, YAML or whatever. But that can depend on what development team you are looking at.