We have added AI-powered assistance to Fleet! This initial implementation contains several new features that work with the help of a generative AI via OpenAI API. Fleet is a product where we experiment quite a lot, both with its architecture and UX, and we want to hear your feedback.

Here are the initial AI-backed features that you can try in Fleet 1.19:

1. Inline AI prompt. Just press Cmd+./Ctrl+. or invoke ‘Generate Code’ in any place in any code file and write what you need. Fleet AI will insert its best attempt at the proper code, which you can accept or regenerate.
   
   
2. Generate commit message. Have Fleet AI describe the changes you made, review them, and commit them. Keep your teammates happy!
   
   
3. Explain commit. See a commit with some significant changes you want to know more about? Fleet AI Assistant is good at explaining.
   
   
4. Generate documentation. Whenever you see a piece of code that would benefit from documentation, add it or ask Fleet AI to help.
   
   
5. AI chat. Fleet AI Assistant prefers programming topics and knows quite a bit. Try it! Fleet has added a new AI Chat tool window type and keeps track of your chats so you can return to them later.
   
   
6. Explain code. Code can sometimes be complex at first glance. Fleet can help you wrap your head around it, and you can even learn a trick or two. Select a piece of code and invoke ‘Explain Code’. Fleet will open a new chat window and will give you an explanation there. You can ask additional questions if you need to, and the chat will be saved for future reference.
   
   
7. Assistance in the terminal. Can’t remember the terminal command for something? Open the terminal, hit Cmd+./Ctrl+., and ask the assistant. No need to leave the IDE or read all of the --help.
   
   
8. Copying to the terminal. Whenever Fleet AI Assistant provides a Shell command in its answer in chat, the command can be copied to the terminal with one click. Just press Enter to run the command.
   
   

More features are coming in future updates!

How it works

To make it as easy as possible to try the new features, we are opening preview access to our new JetBrains AI service. It is a facade that transparently connects you, as a product user, to different large language models (LLMs) and enables specific AI-powered features inside many JetBrains products. The JetBrains AI service currently hosts OpenAI and a few models created by JetBrains, with more models planned to be integrated later. Support for IntelliJ-based IDEs and ReSharper is also coming soon.

This approach gives us the flexibility to integrate more models in the future and gives our users access to the best options and models available. The AI-powered functionality appears right inside the tools you are already using and is natively integrated, allowing you to save time and energy accessing features as needed. 

Please note that JetBrains AI service may not be available for everyone immediately. We will let a certain number of users in and once the maximum capacity is reached the rest will be joining the waitlist. We’ll be gradually inviting more people to try the product in the coming weeks.

How we handle your code and data

We understand the importance of transparency in handling your code and data. JetBrains does not read or store your data, nor do we use it to train our models. Here’s how it works: Fleet sends the data to the LLM models and service providers, such as OpenAI, to receive results. In addition to the prompts you type, Fleet may send additional details, such as pieces of your code, file types, frameworks used, and any other information that may be necessary for providing context to the LLM. For more information please read the Terms of Use for the JetBrains AI service and/or our Privacy Policy.

How to try the new AI-powered assistance

Fleet 1.19 will open a dedicated AI Chat tool window after starting. From this tool window you need to log in to the JetBrains AI service. You can log in with your JetBrains Account or create a new account easily. After logging in, you’ll have access to all of the features mentioned above.

Some features are available in the editor and others in various parts of the UI, such as the Git history. Don’t forget that Fleet allows you to find and run many actions in its Actions palette. You’ll also find AI-backed actions like “AI Chats History”. While exploring in Fleet, look for stars ✨, which indicate AI-backed features and actions in the UI.

But wait, there’s more!

We know you are probably excited to try the above features right away, but there are some other important changes included in 1.19 that we want to highlight.

In response to the high number of requests, we’ve added the option to use npm and Node.js run configurations. This update significantly simplifies the process of building a project, running tests, and performing other necessary tasks. Configuring npm or Node.js has become considerably easier.

We received feedback that it was hard to find matching text in the preview when browsing search results. We addressed this problem by adding nice bright highlighting. Now it is much easier to zero in on the most relevant information.

The ability to add rust-analyzer settings to Fleet’s settings.json file was implemented in Fleet 1.19. Add any items described in the rust-analyzer’s manual to your home or project settings.json file to customize the rust-analyzer.

Actions such as renaming, creating folders, copying, and other changes can now be executed on collapsed directory nodes in the project view. We hope this enhancement improves your productivity and streamlines your workflow.

We’ve added new functionality to improve your Python testing experience. With the latest update, you can set a targetType, supporting module descriptors, and paths. Multiple targets are also now supported, enabling you to run tests in specific files or directories more smoothly.

We rolled out an update that makes Python interpreters in settings easily distinguishable. With this improvement, you can quickly identify and manage your Python interpreters at a glance.

This is a big update with a lot of important improvements to Fleet. We hope you like it! See the full release notes for the complete list of changes.

Please report any issues to our issue tracker and stay tuned for upcoming announcements.

To download the update, check your Toolbox App and install version 1.19.

P.S. Plugins support and plugins API is a work in progress. We hope to have news to share with you soon.

JetBrains AI FAQ

1. Will the AI-powered features be available in the IntelliJ-based IDEs and ReSharper?
   Yes. Please stay tuned for updates.
   
2. How much will AI Assistant cost in JetBrains IDEs?
   The AI assistant is currently free to use during the preview phase. We’ll be providing the licensing and pricing model at a later date.
   
3. What LLMs exactly are used by JetBrains AI?
   All third-party service providers and their models are listed on this dedicated page. In addition to this, there are some models created at JetBrains.
   
4. I was put on a waiting list. How soon will I get access?
   We’ll be sure to notify you via email as soon as JetBrains AI is available for you to try. We want to make sure that the service provides a solid experience for our users. In the upcoming months, we will start gradually inviting people from the waitlist. We can’t provide an exact date for when you will gain access.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

It’s been a while since we published updates about C# support in Fleet. In that post, we shared our plans to deliver new features for our C# support to improve your experience as a .NET developer.

We’d like to give you a quick update regarding which to-do list items have been completed. As a reminder, most of these new features are available only in Smart Mode.

To download Fleet, please install the JetBrains Toolbox App. You will see Fleet in the list of available tools.

Solution View

Let’s start with a vital feature for C# developers – the Solution View.

Solution view tool window

If you open a solution (.sln file) or a .cs file from the Files view when Smart Mode is enabled, Solution View will be automatically focused. 

It shows you the solution structure you’re used to observing in your IDE of choice, including a list of projects in the solution, solution folders, and project dependencies (both NuGet and other projects from the solution), but hiding technical subfolders (like bin and obj folders).

Now let’s look separately at some additional features inside the Solution View that will simplify your daily .NET routine. 

Build / Rebuild / Clean actions

Right from the Solution View, you can now build, rebuild, and clean your solution by calling the context menu for the solution node. For a project node, the Build Project action is also available to you.

Creating a new project

You can add a new project to a solution by calling the context menu on a solution node in the Solution View. It provides some basic functionality like specifying the name of the new project, providing a project folder to save the project, and setting a type of project with a list of predefined types.

The UI and UX for this new dialog are still under construction and are subject to change.

Open Solution

Fleet can’t determine which solution to open if there are either several .sln files in the open folder or several .sln files available in the subfolders. In this case, you can use the Open Solution action to specify which solution to work with. At any point, you can use this action to select another solution and add it to Solution View.

If you want to close a particular solution, select the solution in Solution View and call the Close active solution action.

Unit Testing

Unit testing is also a critical feature, as being able to run and debug your unit tests is essential in the development workflow. We’ve now added Unit Testing functionality for C# to Fleet. Out of the box, Fleet supports the most common unit test frameworks: NUnit, MSTests v2, and xUnit. 

Run unit tests for different scopes

You can run unit tests right from Solution View. A new Run Unit Tests action is available in the context menu for a solution node, project node, and any C# file. 

If you’re used to seeing a green run icon for your unit test methods and classes in the code editor, we’ve got you covered! You can run your tests right from the gutter margin, which can be useful if you want to run only a particular unit test or a set of tests inside a class.

Debug unit tests

The green “run” gutter icon is the most straightforward way to start debugging any unit test you want. Set a breakpoint in the unit test’s code, click on the icon,  select Debug in the menu, and Fleet will attach the debugger to your test.

Run configurations for unit tests

If you run or debug unit tests, a new Run Configuration will be created and launched with a live presentation of the test execution reflecting the structure of the launched tests. There are three node statuses in the tree when the execution is complete: Passed, Failed, and Ignored. 

You can click the icons on the toolbar to quickly filter tests with a specific status. 

When a test has failed, the Log pane shows the exact message from the assert method and a link to quickly navigate to the failed unit test. Also, for the ignored unit tests this pane shows a description of why the test was marked as Ignored

You can also rerun the Run Configuration with the test by clicking the Rerun icon on the toolbar once you’ve fixed the failed test (or the code tested by the test). Even if you’ve closed the Run tool window, you can still rerun the Run Configuration for the unit test via the Run applet on the main Fleet toolbar or the Run | Run & Debug action from the main menu. 

Navigate to test source

Executing Navigate to test source from the context menu on a node in the unit test tree navigates you to the source code so that you can quickly get an idea of the test’s purpose. Double left-clicking also allows you to navigate to a unit test source.

Better support for projects with multiple target frameworks 

In the bottom right corner of the text editor, there is a new selector which allows you to select the target framework for an open file, which adds more context for the code analysis engine. 

A similar selector exists for files belonging to a shared project, helping you select the proper context for this file.  

Setting up Solution Properties

Now you can set up project properties for a whole solution via the UI to configure MSBuild to compile and build your projects properly:

• Configuration, generally Debug or Release.
• Platform, generally AnyCPU, x64, x86, or ARM64.

You can find them in the Solution Properties section on the Configure Workspace page.

New shortcut keymaps

We have added two additional keymap schemes. Now, you can choose either the Visual Studio scheme on Windows or the Visual Studio Code scheme on Windows, macOS, and Linux.

Broken Run Configurations

From time to time, everyone needs to demolish something that was implemented incorrectly and start rebuilding it from scratch. That’s what happened here – we’ve reworked the format for .NET Run Configuration to make it more convenient and unified, minimized duplicated properties (like properties that are already specified inside the launchSettings.json), and added useful ones like targetFramework and solutionPath. 

If you have already installed the Fleet 1.18 update, all of your old custom .NET Run Configurations have stopped working and you will have to update them manually to support the new format depending on their types.

“dotnet-launch-settings” type

If your custom Run Configuration has the dotnet_launch_settings type, you should do the following:

• Rename it to dotnet-launch-settings.
• Remove the exePath, commandName, and commandLineArg properties, which will be highlighted as errors on the run.json file.
• If you’re working with a solution rather than a single project, you must specify a solutionPath property.
• Optionally, specify the targetFramework property.

“dotnet” type 

If your custom Run Configuration has the dotnet type, you should do the following:

• If you’re working with a solution rather than a single project, you must specify a solutionPath property.
• Remove the exePath property, which will be highlighted as an error on the run.json file.
• Optionally, specify the targetFramework property.

We’d love to hear your feedback

We look forward to hearing your thoughts about Fleet in general and its C# support in particular. This will help us shape the product. Here are several feedback channels for you to use:

• Our issue tracker. Feel free to submit your reports there.
• You are welcome to send your thoughts or issues to us at ​​fleet-support@jetbrains.com.

We are pleased to announce the release of Fleet 1.18. This update brings numerous new features and improvements to the product. Keep reading to get a brief overview of the major changes in this release:

• The highly requested feature of using Prettier on save (and on reformat as well) has finally made it to Fleet! You no longer need to manually reformat your code – just let Prettier take care of it for you. The click of a button transforms your code into a work of art!

• You can say goodbye to the hassle of re-indexing your project whenever you accidentally close the app. We have just implemented a safe quitting feature that will save you from the frustration of accidentally exiting the app! You can configure the warning in the preferences menu.

• In this version, when you are reviewing changes in your code, you can scroll through different parts of the diff at the same time, allowing you to compare and analyze code changes more quickly and easily. Effortlessly navigate between different sections of the code changes and analyze them side-by-side without losing your place (and patience) in the review process.

• We know that testing can sometimes feel like a labyrinth. But fear not, because Fleet has got your back! The 1.18 version introduces in-tree test reruns, which lets you restart a test, a test case, or even several selected nodes with ease. Plus, the same tree structure is preserved and updated with reruns so that you can easily navigate your testing journey. At the moment, support for the JPS, Python, and PHP projects is implemented.

• Fleet has just added code expression evaluations to the debug console, which will make your debugging experience even more efficient and enjoyable! The debug console uses notebook-like rendering of code expression evaluations, and execution has been split into re-runnable cells. The input component of a cell uses a regular editor, so it supports most Fleet editing features.
  

  The output component of a cell displays the code expression evaluation result using a tree structure similar to what the debug variables panel uses. It also contains a footer with evaluation elapsed time information and an action link to reevaluate the input expression. To make things even better, the output presentation remains after suspension resumes and even after the process stops, so you will not lose evaluation results as long as the console is opened.

• We’ve been working hard over the last few months to improve our C# support. Let’s have a look at what we’re delivering in this update.
  

  The long-awaited C# Unit testing is finally here with support for the most common unit test frameworks: NUnit, MSTests v2, and xUnit. Now you can run and debug your C# unit tests inside Fleet right from the code editor or Solution View.

For those with more than one target framework in a project, we’ve added a new selector that allows you to select the target framework for an open file, adding more context for the code analysis engine.

Now you can set up project properties, namely Configuration and Platform properties, for a whole solution via the UI to configure MSBuild to compile and build your projects properly.

If you’ve ever created a custom run configuration in your .NET solution, a few things are required to get them working again due to breaking changes in dotnet_launch_settings and dotnet configuration.

A separate blog post will cover these updates in detail, so stay tuned!

• Fleet now includes the option to extract variables in Python, Go, and PHP! We hope that this will make accessing and working with variables in your code more efficient and convenient than ever before.

• A list of installed (bundled) plugins is now available; therefore, it became much easier to discover the technologies that are used.

• Have you ever wanted to commit just a part of your code changes but didn’t want to go through the inconvenience of separating them into different commits? With the partial commit option, you can now select specific changes in separate files using the code diff viewer and commit them individually, without affecting the rest of your code changes. We hope it will save you a lot of time and effort and will help you to keep your code changes organized and streamlined.

• You reported that you struggled to disable code interlines and wondered where to find the setting. We’ve added a couple of aliases to make this setting more discoverable, making it easier than ever to disable the code vision feature from the editor.

• Previously, when installing a package manager like npm or yarn, it was hard to guess the state of the process. Is it being installed, or has something gone wrong? An execution interceptor was added so that you can now see the output in the console and easily understand how Fleet handles your command.

• Apart from this, the team has been working tirelessly to squash the bugs that were reported by our users. In particular, we have successfully fixed the bug that had been causing the caret position to be lost during file reformatting. With this fix in place, you can now reformat your files without any interruptions to your workflow or the need to constantly adjust your caret position. The pesky bug that prevented text search from finding terms in files located in ignored directories was fixed as well! Now file content in ignored directories can be easily searched if the directory is selected as the search scope.

These are the most important updates for Fleet 1.18. See the full release notes for the complete list of improvements and more details about the latest updates.

Please report any issues to our issue tracker and stay tuned for upcoming announcements.

To download the update, check your Toolbox App and install version 1.18.

P.S. Plugins support and plugins API is a work in progress, but, as mentioned above, the list of installed (bundled) plugins is now available and visible to everyone.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

Fleet 1.17 is now available, and it comes with a host of improvements and valuable new features:

• You can now rename your workspaces in a snap! This means that there are no more generic workspace names that leave you scratching your head and regretting your choice later. Plus, it’s super easy to do, and you can change your mind and rename your workspace as often as you like!

• It’s commonly accepted that 5 hours of debugging can save 5 minutes of reading documentation. Keeping that in mind, we introduced a much-requested debugger for the Rust applications in Fleet. Please try it out!

• We’ve worked a lot to improve code folding, and you can now fold much more than just code, even multiline comments and imports! This means no more endless scrolling through lengthy import statements or bulky comment sections. You can easily collapse and expand them! We hope this update will make your code more manageable and your life a bit easier.

• Good comments make great code clearer. Sometimes, you also just need them to temporarily remove a part of the program. If you previously missed the ability to use proper comment style in the JSX files, this has now been fixed in Fleet 1.17. The correct style is now used when it’s necessary to comment a block of nested code:

• Emmet support was enabled by default in Vue and React projects, which should make your coding experience with JSX, HTML, and other files faster and more efficient. Please use Emmet if you have not until now!

• We noticed excessive memory utilization on a project’s opening and closing and have now fixed this issue.
• We updated the behavior of the tools panel so that it is closed automatically when there are no active tabs.
• The issue with code vision interlines was addressed. When disabling the interlines in the settings, they no longer leave a space between lines.
• Completion when Smart mode is disabled has been updated to be less noisy, so focusing on the more important things should now be easier.
• Previously, when trying to connect to WSL and the path of the project contained spaces, it caused error 127. This has now been fixed.

These are the most important updates for Fleet 1.17. See the full release notes for the complete list of improvements and more details about the latest updates.

Please report any issues to our issue tracker and stay tuned for upcoming announcements.

To download the update, check your Toolbox App and install version 1.17.

PS. Plugins support and plugins API is a work in progress.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

Fleet 1.16 has brought a lot of bug fixes and other updates to the product and the build that’s just been released is yet another step on our path toward the public release.

Before you download it, let’s take a look at the updates in this version.

• Code foldings support was added to Fleet, making it possible to collapse specific blocks of code.

• Path aliases support was fixed in Vue projects.

• Significant VS Code keymap improvements were made. We fixed essential key assignments in every operating system.
• Indentation is now automatically detected. By default, indent type and size are detected by the file content.

• The run gutters were added for run configurations in the run.json file. There is now an option to run configurations right from the file.

• It’s now possible to invoke a blame in a diff view for a commit.
• Occasional JDK detection was removed from non-Java projects and you shouldn’t see an irrelevant notification in the projects where it isn’t required.
• The minimum width and height of the completion popup were limited so it isn’t possible to make irreversible changes in this setting.
• Apart from these improvements, a number of bugs were fixed, including the following: the right Alt key on macOS now functions correctly, accepting a completion option doesn’t result in jumping anymore, the Close all tabs button once again works as designed, and starting Fleet using the Open in IDE button doesn’t cause a crash.

These are the most important updates for Fleet 1.16. See the full release notes for the complete list of improvements and more details about the latest updates.

Please report any issues to our issue tracker and stay tuned for upcoming announcements.

To download the update, check your Toolbox App and install version 1.16.

PS. Plugins support and plugins API is a work in progress.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

• Part I – Architecture Overview
• Part II – Breaking Down the Editor
• Part III – State Management
• Part IV – Distributed Transactions
• Part V – The Story of Code Completion
• Part VI – UI With Noria

In Part V of this series, we discussed code completion, which is just one of Fleet’s services. Now it’s time to talk about something as big as our very own declarative UI framework for JVM, Noria. We built Fleet with Noria. Let’s look at the ideas behind Noria, the main concepts, and other exciting features.

Where it all starts: A Noria window

How is a UI built? First, we have a display with graphical capabilities that is able to present an application’s state and is also responsible for making our UI a GUI. We may also have one or more input devices, such as a keyboard, a mouse, or a touchpad, to deliver commands and control the application’s behavior. In these settings, an application is effectively an event loop responsible for reacting to events initiated by users and other computer system components (timers, a file system, a network, and others). Primarily, reactions are visible changes in what is displayed on the screen.

In addition to being an event loop, a GUI application usually has some kind of window, an area of the screen it is responsible for, and some drawing capabilities in that area. A window is normally provided by an underlying operating system or a window manager on top of it. An operating system may provide a graphics API or delegate drawing to a graphical framework.

Fleet is both a GUI application and a JVM application. It runs on all major operating systems, including Windows, macOS, and Linux. Fleet relies on the Java AWT/Swing framework to get a window from an operating system, but it doesn’t use the Java platform for managing its GUI components besides one JFrame and JPanel on top of it. Fleet doesn’t use the JVM’s screen drawing capabilities, either. Instead, it employs Skia, a native 2D graphics library that is available to JVM applications via the skiko-awt binding library, which JetBrains develops.

The following diagram presents a combination of the aforementioned frameworks and libraries, resulting in a screen area fully managed by our home-grown UI framework – a Noria window:

Everything you see in a Fleet window is a Noria component. Panels, tabs, buttons, tooltips, text editors, terminals, diff views, and docker views are managed by Noria and are constantly changing as a result of Noria’s event loop reactions.

You might ask, “Why Noria?” Why invent a new UI framework when we have so many brilliant UI frameworks out there begging to be applied for creating highly responsive GUI applications with a modern look and feel for all major desktop platforms at once? Well, that’s not entirely the case. Let’s refer to the history of those UI frameworks and see whether we had such options to choose from when we started developing the product that eventually became Fleet.

A brief history of UI approaches

Ideas and approaches to GUI frameworks (not GUI itself) can be traced back to the 70s, when a team of researchers at Xerox PARC, including Alan Kay, developed a graphical environment for the Smalltalk programming language. From the early days of UI frameworks, their developers had a clear focus on architectural matters. It wasn’t a simple task to organize an application over an event loop with many UI components on the screen, as well as factoring in unpredictable user actions and their corresponding UI reactions, and not end up having an application that would be a complete mess from an architectural perspective. One example of finding such an approach is detailed in some notes by Trygve M. H. Reenskaug, where he reflects on the inception of MVC, a notable Model-View-Controller architectural style, which was a set of ideas to provide a structure for GUI applications.

There was no clear way to apply an MVC style, which led to many attempts to reformulate it using other terms (for example, MVP – Model-View-Presenter). Every UI framework that claimed to support it provided some specific way to do that. Those ways didn’t have a lot in common besides several generic things, including the following:

• Relying on the object-oriented features of programming languages.
• Separating the business logic from the presentation (except that, unfortunately, presentation may require some logic, too).
• Observing changes via the Observer pattern (and experiencing related code readability issues, because it may be too hard to figure out what’s going on in the program from reading sources that heavily exploit this pattern).

There was also another line of development, an attempt to simplify an architecture by structuring it into a form, with a set of controls on that form, and with all the logic that connects the application state to components of that form. This idea, popularized by Borland Delphi and Visual Basic in the 90s, led to a generation of Button1Click developers who were happy to develop large applications without thinking about architecture. This approach was always heavily criticized by object-orientation-inclined researchers and practitioners, but, frankly speaking, sometimes it was too difficult to distinguish between the complete messes produced by either no-architecture or strict architectural guidelines.

Martin Fowler explored these 2 lines of development for UI frameworks in this brilliant excerpt from his (unfortunately, unfinished) book Further Patterns of Enterprise Application Architecture.

And then we’ve got PHP. Developing web applications in PHP following its inception in the middle of the 90s became an exceptionally pleasing experience, extremely easy to fire up and get straight to production. PHP popularized template processing, an approach when you mix logic (instructions of a programming language) and presentation (HTML tags) in one piece of code – a sordid crime according to MVC purists. No other programming language has ever received so much backlash from developers. Just google “PHP hate” to get an idea. The “Guards of Clean Code Heaven” still hate PHP for this (and maybe also for opening the gates to the industry to many new developers who were raised unaware of the only “right way” to develop software).

Well, let’s not judge programming languages but try to see exactly what this new idea was and where it would lead us. How we see data is intimately linked with how we manipulate it. With PHP, we no longer had to separate logic and presentation. After all, most of the logic is in the presentation anyway because it’s the users who manipulate the presentation, not some abstract data that can’t be seen or touched. PHP made it clear that we needed components – active entities with their own look, reactions to user actions, and other behavior. Components may be composed of other components, and they can effectively interact with neighboring components through some shared state. For example, a list of items in one component can deliver change signals to another component whose content depends on the selected items in the first component.

Ajax (Asynchronous JavaScript and XML) took this idea even further, with web components as the main building blocks of web applications. These web components combined backend and frontend logic while mixing them with the presentation. Good or bad, this idea brought us the current web and web development experience.

In the early 2010s, React introduced a brand new world of UI development. Frontend developers may argue about which is better, React or Angular, and which state manager should be used, but now they are used to the idea of active UI components. They even apply their web technologies to developing desktop applications (though the resulting experience doesn’t always provide perfect responsiveness, look, and feel).

One thing we should praise React for is that it made declarative programming and reactive programming the mainstream. These previously hidden techniques were rarely used in production programming languages, but with React they began to dominate in many areas of software development, including, most notably, UI frameworks.

By the end of the 2010s, we started to observe the same approaches to UI pervading UI frameworks for mobile systems, Apple’s SwiftUI and Google’s Jetpack Compose being the most prominent examples. We didn’t have to wait long to see the same trends in UI frameworks for desktop systems. In the early 2020s, we have the beautiful Compose for Desktop, based on Google’s Jetpack Compose and brought to you by JetBrains. When we started working on Fleet, however, Jetpack Compose didn’t exist, and thus Noria was born.

Incremental computations

Interestingly, Noria is not a UI framework at its core. Instead, it’s a platform for incremental computations. Imagine a large multi-part mathematical formula with interdependent components that sometimes have to be recalculated or trigger the recalculation of dependent components – not unlike a spreadsheet. Noria shines at computing and recomputing these sorts of formulas. The main principle here is to avoid any unnecessary computations and to recompute only the parts required to produce the final result.

What about the UI, then? Well, it’s also such a formula. It has a tree-like structure built of components and subcomponents. Those components may also have other dependencies besides being a part of another component. This makes a directed acyclic graph (DAG) of dependencies. A change of state in one of the components also triggers a change in another component that depends on it, directly or indirectly.

In general, incremental computations support skipping some calculations if we can determine that their expected results won’t change. In terms of UI, we avoid touching (and redrawing) components that don’t require any changes.

Suppose that we are about to make a move in this simple game of Tic-Tac-Toe:

BEFORE	AFTER

We have a grid with cells. Which cells should be changed when we click (add an X) in the top-right corner? The cells in the first row will need to be redrawn as it becomes the winning row. None of the other cells changes, though, so we’d better refrain from redrawing them. To implement the required logic, we structure our components and computations as follows:

• A 2D grid contains the cells and offers a way to describe the layout with rows, columns, padding, etc.
• Each cell has information about its content (whether there’s an X or an O in it) and the possibility of being a part of a winning row, column, or diagonal, and it can be redrawn when the state of these Xs and Os is changed.
• Clicking on the top-right cell should change its content (and trigger redrawing), but it should also trigger checking whether the game is over and changing the corresponding settings of the winning cells.
• Changing the settings of the winning cells should trigger the redrawing of them with a cross-through yellow line.

Thus, reacting to a user action (clicking on a cell) leads to partial recomputation of the grid and the redrawing of some of its cells while keeping others intact. Noria provides us with everything we need to handle such behavior, including:

• A declarative Kotlin DSL to describe the layout of components as a tree structure along with tree-structure dependencies that enable event propagation.
• onClick-hooks for components that implement immediate reactions.
• StateCells to express the out-of-tree-structure dependencies responsible for triggering recalculations of neighboring nodes.

Under the hood, Noria does not trigger recalculations when they are not needed. That’s standard behavior for any incremental computation platform. A Noria user writes a function describing the whole UI in a declarative way. This function is called every time something happens. But Noria knows precisely what was changed from the previous run and what wasn’t, and it decides which parts of the UI tree need recalculating.

Declaring UI components

Let’s look at some code examples and get a feeling of what it’s like to work with Noria.

The Tic-Tac-Toe component mentioned in the previous section can be described in Noria as follows:

val grid = Grid(3) { state { GridCell() } }
val gameState = state { GameState() }

clickable(onClick = { grid.checkEndOfGame(gameState) }) {
 vbox {
   grid.gridRows.forEach {
     hbox {
       it.forEach {
         cell(it, gameState)
       }
     }
   }
 }
}

We have a grid with cells and a game state responsible for the next turn and end-of-game status. Note the 2 state functions in the first 2 lines. They are responsible for creating additional dependencies: Updating their content triggers the recalculation of components that read them.

Every cell is responsible for rendering its content and reacting to user clicks:

private fun UIContext.cell(gridCell: StateCell<GridCell>,
                           gameState: StateCell<GameState>, ...) {
 val gs = gameState.read()
 val cell = gridCell.read()
 clickable(onClick = { ... }, propagate = Propagate.CONTINUE) {
   decorate(backgroundColor = ...) {
     layout {
       render(Rect(Point.ZERO, Size(size, size))) {
       ...
       }
     }
   }
 }
}

Technically, cell is an extension function for the UIContext class, which implements the machinery behind Noria. The cell reads some state, thus expressing its dependence on that information. Noria uses this dependency while deciding whether it’s necessary to re-render this cell.

Noria components can be as simple as the following text label with a tooltip:

withTooltip("Tooltip text") {
   uiText("Point on me")
}

They can also be quite sophisticated, like a text editor or other panes and windows that you regularly see in your Fleet instance.

Noria provides all the essential components for implementing desktop UIs and other obvious UI framework capabilities, including:

• Laying the components out.
• Constraining and setting boundaries.
• Rendering visible parts and providing support for scrolling.
• Defining focus traversals.
• Implementing overlays (such as a tooltip in the example above or error messages next to your erroneous code fragments).

Every time you run Fleet, Noria machinery is working hard to deliver the best UI experience possible.

Summary

Fleet is implemented with Noria, a home-grown UI framework for the JVM. Noria allows us to describe UIs in a modern declarative way using Kotlin features. It is based on the incremental computations core, responsible for expressing dependencies between UI components and minimizing needless re-renderings. 

Noria is by no means revolutionary. It only takes modern design ideas, applies them to UI frameworks, and adds some Kotlin flavor to them. But what we’ve learned so far is that developing your own fundamental UI frameworks works and can actually be a lot of fun!

The Fleet Below Deck series is far from over. We still have a lot of details about Fleet internals to share. Stay tuned for more!

• A quick evaluation of expressions similar to IntelliJ IDEA was added to Fleet. Now you can point at an expression in the code to evaluate it.

• Opening files directly from the macOS Finder was fixed. Now it shouldn’t be a problem.
• We worked on Rust support improvements in Fleet 1.15; in particular, we fixed infinite analyzing and resolved the issue with garbled text in the documentation popup.
• ToDo highlighting was added, making it much harder to miss them.

• Quotes and parentheses in JSX are now autoclosed. As a result, working with the extension should be a smoother process.
• HTML syntax highlighting now works inside PHP files.

• The Tailwind CSS language server was bundled, so there is no need to install it separately.
• The Keymap search was improved, and the result no longer excludes action names.

• Several updates to the Git integration were delivered. This includes the highly anticipated option to group by directory as well as the option to revert from the Git section of the Files tool context menu.

• Values from debugger variables can now be copied for any purpose.
• The parameter to set the font weight was added to Fleet, which can now be customized depending on your preferences and monitor characteristics.

• And some more news about fonts! Stylistic Sets and other OpenType features are now available for the JetBrains Mono font. By adding them, you can tune the font according to your needs. Please find the complete list and instructions on enabling OpenType features here.

• Working with symbolic links in Fleet has been significantly improved. Now the Git status is correctly shown for files in symlinked directories on both Windows and Linux. Refactorings for these directories (including cross-file usages) now display correctly on Windows, but Linux is still a work in progress.
• Formatting the file on save was added to Fleet. The IntelliJ IDEA formatter is run automatically upon file saving.

These are the most important updates for Fleet 1.15. See the full release notes for the complete list of improvements and more details about all of the latest updates.

Please report any issues to our issue tracker, and stay tuned for the upcoming announcements.

To download the update, check your Toolbox App and install version 1.15.

PS. Plugins support and plugins API is a work in progress.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

• A bug that caused code syntax highlighting to flicker during rename refactoring has been fixed. The highlighting should now be preserved.
• The ability to have up to 2 side panels on each side of Fleet’s main window has been added. It makes Fleet UI more flexible and provides more options when you need them.
• UI sharpness with fractional scaling has been improved, e.g. with high DPI on many Windows systems and when UI is zoomed to a non-integer factor.
• A new editor.centerEditorHorizontally option has been added. This centers the editor horizontally. To use this option set it to true in settings.json. This can be particularly useful on wide screens.
• Python: a bug that caused Fleet to constantly consume a single CPU core with some Python projects has been fixed. 
• Java: a problem where setting Maven home did not work, specifically on Windows, has been resolved.
• Node.js: a bug where the specified Node.js executable was not used for running JavaScript has been fixed.
• Kotlin: lexer and parser have been updated to the latest Kotlin 1.8.0 version. Read more about what’s new in Kotlin 1.8.0.

But that’s not all. See the full release notes for more details about all of the latest updates.

Please report any issues to our issue tracker, and stay tuned for the upcoming announcements.

To download the update, check your Toolbox App and install version 1.14.

PS. Plugins support and plugins API is a work in progress.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

• ‘Git Sync’ was renamed to ‘Git Pull & Push’, so it is more transparent and predictable what to expect when using this action.
• Now when hovering over an element with a warning/error, you can see both the warning/error message and the documentation if it is available.
• A Go to Declaration shortcut similar to one in IntelliJ IDEA was implemented. Now you can use Ctrl/Command + Click to find usages or definitions of a symbol.
• The problem with editing keymaps was fixed. Now you can modify a keymap using the UI even if the changes in the user.json were made previously.
• Important update for the i3wm users: after this update, the IntelliJ keymap shortcuts can be used to move Fleet to a different workspace.
• Fixed wrong items on top of code completion lists (FL-14232)
• Completion performance for the Gradle/Maven projects was improved.
• Python: the built-in terminal now automatically activates the project virtual environment if it is present. The feature is available in smart mode.
• JavaScript/JSX: Improved code completion suggestions (FL-16667)
• Go/Python: Improved matching of local variables in code completion lists (FL-15126)

We hope you’ll like these improvements! ​

See full release notes for the details about all the changes.

Please report any issues to our issue tracker, and stay tuned for the upcoming release announcements.

To download the update, check your Toolbox App and install version 1.13.92.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

• Fleet now supports C++ projects with compilation databases. In smart mode, things like error highlighting, C++ code completion, parameter info, code documentation preview, and Rename refactoring are available.

• Initial support for Svelte has been added and we’ll be improving it in future updates together with the WebStorm team. Please try it out and share your feedback.

• We’ve added the Solution View, which is vital for C# developers. It becomes available when you open a solution (.sln file) or a .cs file from the Files view when Smart Mode is enabled. The Solution View shows you the solution structure you’re used to seeing in your IDE, including a list of projects in the solution, solution folders, and project dependencies (both NuGet and other projects from the solution), but hides technical subfolders, such as bin and obj folders. You can now build, rebuild, and clean your solution, as well as add a new project to the solution, right from the Solution View. Just use the context menu for the solution node in the Solution View.

• Basic support for TailwindCSS has been added. To make it work, install the TailwindCSS language server separately using: npm install -g @tailwindcss/language-server. The language server will be bundled in future versions.

• Structure View and Goto Symbols in File (Cmd+Shift+O / Ctrl+Shift+O) now work for JSON and YAML files.

• HTML tags are renamed automatically when an opening or closing tag is edited.

• ‘Quick Fix’ list options (Alt+Enter) are now filtered as you type.

• Launcher CLI for installing Fleet on a remote machine no longer has the --no-intellij option. Fleet workspace will now download the backend automatically if it’s necessary and Smart Mode is enabled. This is a breaking change, so make sure to download the latest version of the launcher by following the Install section in the docs. There is no support for earlier versions of Fleet, as we are still in Preview.

• The selected Python interpreter will be preserved for any workspace after Fleet restart.

• Smart Mode served by the IntelliJ engine now consumes less memory by default. If the engine detects that the allocated memory is insufficient, it will increase the amount automatically. It is also possible to configure memory allocation manually in the workspace’s settings.json file.

See the full release notes for details about all 80+ changes and let us know how it works for you.

To download the update, check your Toolbox App and install version 1.12.97.

Join the JetBrains Tech Insights Lab to participate in surveys, interviews, and UX studies. Help us make JetBrains Fleet better!

We’d like to tell you more about C# support in the Fleet Public Preview, including which features already exist and our plans for the future. If you are curious about the new developer experience Fleet aims to bring and want to try something new, give it a try.

To download Fleet, please install the JetBrains Toolbox App. You will see Fleet in the list of available tools.

While installing, you can check out this short Fleet overview video and browse the documentation to make getting started easier. Don’t forget to register for Space if you want to try cloud dev environments with Fleet in addition to local environments.

C# support in Fleet

Why is it “C# support” instead of “.NET support”? Because as of right now, only C# support has been implemented, meaning no Razor/Blazor, VB.NET, or F#. 

C# support in Fleet is based on ReSharper’s code analysis engine, the same as in Rider. However, we don’t consider Fleet to be a full-fledged replacement for Rider. C# support in Fleet provides essential functionality and covers basic needs, such as quickly navigating through code and making small, simple changes. It’s not designed to have any complicated or deep integrations with enterprise technologies, Xamarin, or game engines like Unity. Therefore, we see Rider and Fleet coexisting for the foreseeable future.

One limitation to keep in mind is that Fleet supports only projects targeting .NET 5.0 and above. 

Start doing C# development

How do you start doing C# development in Fleet? That’s right – by opening a C# solution! As Fleet supports many languages and technologies, it operates with universal workspaces, a directory with all of the files you need. This means that you need to open a directory that contains a .sln file of your solution or a .csproj. Select File | Open, navigate to a folder with a .sln or .csproj file, and open the folder. 

Tip: Don’t have a solution at hand? Follow this guide to create a new one. Unfortunately, at this stage, there is no simple action to create a project via Fleet UI.

In the Files view, you will see all of the files and subfolders located in the selected folder. As it’s a file system view, it doesn’t filter out certain technical subfolders or files, unlike the Solution Explorer in Rider or Visual Studio. We are working on prototyping the Solution view, which will significantly improve the experience of working with C# solutions. 

Text editor mode

By default, Fleet will open a solution in “Text editor” mode, which is snappy and loads all of the solution files very quickly. This mode provides full-text search, file search, “go to symbol” in a file, a UI for basic Git operations, typing assistance with auto-indenting, basic syntax highlighting, and basic code completion to make simple and quick fixes in your code.

Smart mode

Enable Smart mode whenever you can. It converts Fleet from a text editor to a complete IDE powered by ReSharper. The features provided by this mode are covered in the next section.

Tip: The very first time you enable Smart mode, Fleet downloads the C# language service, based on ReSharper, from the JetBrains servers and installs it. This can take some time.  

Available features in Smart mode

If you’ve used ReSharper or Rider before, then you already know what kinds of assistance you can expect from Smart mode in Fleet. Let’s have a look at the features we already know and love! 

• Continuous code quality analysis and corresponding quick fixes with a preview of your code after applying the suggestion. The list of code inspections is the same as is in ReSharper, but some of the quick fixes for code inspections are not available yet.

• Navigation and find usages, including Go to Declaration. 

• Only the Rename refactoring is available. Other ReSharper refactorings are not implemented yet.
• Code completion with full awareness of the projects in the solution. 

• File, live, and postfix templates. We hope you will like the new method Fleet provides for selecting file templates. 

• Code formatting and auto-indentation while typing. You can configure the settings in an editorconfig file right in your project.
• Quick documentation popup.
• Run configurations to run your application.

• Debugging with breakpoints, frames, variables, and evaluation panels.

• Collaborative development. You can quickly start or join a session to do code changes with your teammates. 

If you want to learn more about .NET support in Fleet, please visit our documentation. We’ve prepared a chart that displays the languages and technologies that Fleet currently offers support for.

Plans for the future

There is a list of features we are working on right now and will deliver in upcoming updates: 

• Solution View, which can help you observe the solution structure instead of just a file system view, and where you can open a particular solution or project.  
• Build/Rebuild/Clean actions for projects and solutions.
• Unit testing, including running tests right from the text editor. 
• A decompiler which will help you navigate to the code of third-party libraries.

In the more distant future, we are going to put more effort into bringing support for .NET web development and integration with cloud computing services.

We’d love to hear your feedback

We look forward to hearing your thoughts about Fleet in general and its C# support in particular. This will help us shape the product. Here are several feedback channels for you to use:

• Our issue tracker. Feel free to submit your reports there.
• You are welcome to send your thoughts or issues to us at ​​fleet-support@jetbrains.com.

Fleet is still in its infancy, and there is a significant amount of work ahead of us. However, today we’re announcing the first public preview of Fleet, which is accessible to everyone. The reason we’re opening up the preview to the general public is twofold. First off, we don’t think it’s right to keep everyone who signed up waiting any longer, but individually inviting so many people doesn’t really make sense for us. It’s easier to make the preview publicly accessible. Secondly, and most importantly, we’ve always been a company that has developed its products in the open. We don’t want Fleet to be any different in this regard. 

Before you download it, though, please review the rest of this post, since there are a few important things you should know.

What Fleet is

For anyone who may not have heard of it before, Fleet is our new distributed polyglot editor and IDE. It has been built from the ground up using our IntelliJ Platform on the backend and a brand new UI and distributed architecture. For more details check out the Fleet product page.

What to expect now

Since the list of technologies we’re planning to support is quite long, we’ve prepared a chart that displays the languages and technologies that Fleet currently offers support for, along with each one’s status. This should give you a good understanding of what to expect. 

However, we’d like to remind you that Fleet is still in its early days, and some things may not work as expected, even if they’re listed as supported. If you do encounter issues, we’d very much appreciate it if you could log them. The easiest way to do so is via the Send Feedback option in Fleet’s Help menu.

It’s important also to highlight that we’re not intending to replicate our existing IDEs. As such please do not expect to see the exact same functionality with Fleet that you would get with one of our IDEs, such as IntelliJ IDEA. Even as we continue to work on Fleet, not all of the features of our IDEs will appear in it. Fleet is an opportunity for us to provide a different user experience for developers. Having said that, we do want to hear your feedback on things you feel Fleet is missing, such as specific refactoring options, tool integrations, etc. Our existing IDEs will continue to be developed, and we have a lot of plans for them, including performance improvements, a new user interface, remote development, and more. Finally, Fleet also uses the intelligence from our existing tools under the hood, so none of these tools are going anywhere!

What is coming

In the coming months we’ll be working on stabilizing Fleet and addressing as much of the feedback we get as possible. At the same time, we’re working in the following areas:

• API support and an SDK for plugin authors – Given that Fleet has a distributed architecture, we need to work on simplifying the approach for plugin authors. While we guarantee that we’ll be providing a platform for extending Fleet, we do ask for a bit more patience in this area. 
• Performance – We want Fleet to be performant in terms of not only memory footprint but also response time. There are numerous places we can still improve performance, and we’ll be working on them. 
• Themes and keymaps – We know that many developers are used to their existing editors and IDEs and often miss their old keyboard bindings and themes when they move to a new one. We’ll be working on adding support for more themes and keymaps. We’ll certainly be working on Vim emulation, as well.

Getting started with Fleet

To download Fleet, you need to use the JetBrains Toolbox App. 

We are preparing a series of short videos that can help you get started. Make sure you subscribe to our channel. Even though the experience is pretty much the same regardless of the technology you use, we’ve divided them into separate videos based on language. Also make sure to check out Fleet’s documentation if you run into any issues.

We’re still at the beginning of a long journey with Fleet, and we hope you’ll join us for what will be a great adventure!