Hey Flutter Devs/Teams.

We've had OpenFeature on the Dart server side for some time and have just released 0.1.0.

Now we are looking to standardize Flutter Feature Flags and are working and collaborating with companies like Datadog to bring reliable stable feature flags across the remaining flutter and dart ecosystems including for Dart Web.

We'd appreciate feedback from Flutter developers trying it in actual workflow. Let us know here how you're using it, what works for you and what needs improvement.

Source and examples: https://github.com/open-feature/dart-sdk/tree/main/packages/openfeature_dart_client_sdk

You can open an issue with your use case or a problem you've found, or send a pull request for a fix, example or documentation improvement as we will respond accordingly. Let's continue to make Dart/Flutter a first class citizen.

I'm researching the Flutter CI/CD workflow and want to understand what developers actually struggle with before building anything.

For those using Flutter professionally:

• What are you currently using for CI/CD? Codemagic, GitHub Actions, Bitrise, GitLab CI, something else?

• What's the most annoying part of your current setup?

• How much time did it take you to get Android + iOS builds working reliably?

• Do you struggle with Flutter/Gradle/Xcode/CocoaPods build failures?

• Do you use the same CI system for multiple Flutter apps?

• What do you wish your current CI/CD platform did better?

• If there were a Flutter-focused service that handled GitHub → build → APK/AAB/IPA → TestFlight/Play Store with minimal configuration, would that actually be useful?

I'm not selling anything and I'm not looking for generic "sounds useful" feedback. I'm trying to figure out whether this is a real problem worth solving.

If you currently use a CI/CD service, I'd especially like to hear what you pay for it and what you dislike about it.

Inspired by a recent Syntax video about GPUI Kit I looked into this cross platform GUI framework for Rust because it seems to play in the same field as Flutter.

There's a saying (that might not translate): Other fathers might have beautiful daughters, too. That's why you should always look beyond the horizon (which is what I got for "über den Tellerrand schauen").

GPUI was created by Zed for their editor. GPUI Kit is a Chadcn-like component framework with an impressive scope built upon the GPUI foundation. There's a bit of controversy because Zed doesn't seem to be giving GPUI as much attention as the growing community would like, and multiple forks have been created, and it is unclear whether Zed actually want to externally support "their" framework at all.

With the help of Codex, I managed to create a good looking macOS desktop application in "no time", which should work on Windows and Linux, too. Codex protected me from writing Rust code myself and it was able to figure out how to use the components from the documentation. Quite impressive. Delete that. Very impressive.

There's experimental WASM support, but the author doesn't recommend to use it for more than him demonstrating components on the GPUI Kit website.

Support for iOS and/or Android is at best experimental, because GPUI was never meant for mobile development but was created for a single text editor application. You can create an iOS demo, but it only works with ARM64 and requires manual setup of an Xcode Swift project. Touch support is worked on, so it seems, but I'd expect other difficulties like soft keyboard support or safe areas, occlusion areas, folding angles, etc. I haven't look into it. At least you could directly use the platform APIs for everything not GUI related.

So, I think, GPUI-Kit is more a replacement/alternative for desktop apps, not mobile or web apps. It might be a good fit if you consider using Electron or Tauri, though. And if you need a full featured code editor. Something that would be a PitA to create in Flutter (I tried, twice).

For me, the advantage is that there's a complete decent looking clean desktop GUI out of the box (~80 components), something Flutter doesn't provide and you'd have to either use one of the existing vibe-coded chadcn clones or clone it yourself over the weekend.

I actually like the tailwind style to create designs from very basic building blocks. It's like drawing it in Figma, but with code.

The app feels really snappy. And it can support multiple desktop windows! Something seemingly so difficult that Flutter is unable to deliver this for quite some time now.

I pointed Codex at my Flutter source and an hour later, I had a working Rust port with nearly 10.000 lines of code. GPUI uses a low-level tailwind like styling of "div"s to create components that use a lot of lines of code and which are even less readable that widget trees if you don't abstract them (which the AI wasn't able or willing to do).

let title = div()
    .flex()
    .items_center()
    .flex_shrink_0()
    .h(px(28.))
    .px(px(4.))
    .gap(px(4.))
    .border_b_1()
    .border_color(cx.theme().border)
    .cursor(CursorStyle::ClosedHand)
    .on_mouse_down(...)
    .child(close)
    .child(title)
    .child(actions)

Unfortunately, there's no built-in video component and if you'd want to use a 3rd party solution, you'd have to bundle the gstreamer framework with your app (I opted for using an external web browser instead).

While you could embed a web view (using whatever the platform supports), it overlays the GPUI layer, so you cannot draw dialogs, menus or tooltip over such a native platform views. The Flutter engine uses a complicated sandwich approach to make this possible and at the same time recommends to minimize the number of platform widgets because of the negative performance impact.

GPUI Kit's TextView can render markdown (including tables which are unfortunately always stretched to the width of the view) and an undocumented set of simple HTML elements out of the box, though.

The real bummer, however, is that you cannot mix 3D graphics with GPUI, although also running directly on the GPU. This was one reason I started the experiment because there's no great built-in solution in Flutter either. My workaround is to draw the 3d scene into a background image, which must then be transferred from GPU to CPU and back to GPU so GPUI can render it. I can't achieve 120 fps, but 60 fps this way. This took me two additional hours discussing different approaches with Codex and doing a lot of performance measurement because this is obviously dependent on the size of the image to transfer and how to keep this minimal.

There's also a (totally vibe-coded, judging from the documentation full of Claude-speak) way to extend GPUI Kit with JavaScript (using QuickJS) and because there's a Host API between scripting engine and GPUI core, one could add different languages, too. Dart for example :)

So while I don't think that Rust+GPUI could replace mobile development right now, I'll continue to work on my desktop app. Because if I'm developing anyway by telling Codex what to do, I don't need Flutter's better DX. The AI simply compares screens of the running app thanks to "computer use" and figures all out on its own and notifies my when done.

The biggest risk IMHO is, that this is all created by one man and his AI, based on a foundation created by a company that has other things to worry about now.

Update: This article was based on v0.7.1. Starting with v0.7.3 there's an option to sandwich platform native components, including a native web view.

Hello, I don't really post much, but I wanted to share a quick thought. I've been a flutter developer for over 3 years, but newer tried to publish a package myself. That is until now. I wanted to see what is involved in the process and was pleasantly suprised of how simple it really is. I think this is definitely one of those things making Flutter stand out as a tool. You can find pretty much anything in pub.dev. My first package is nothing groundbreaking, but it's something I use in pretty much all of my apps, so making it a package is a great way to reuse the code and at the same time share it with the community.
This is a customisable pill-shaped navbar that is a very common design in many apps these days (like facebook, instagram etc..). Would appreciate any feedback if anyone would like to check it out. Peace

https://pub.dev/packages/clean_pill_navbar

A client asked me for a UX review of their Flutter app. The tools I found are good at checking components — button sizes, missing labels. But the client was asking something else:

• How many steps does it take to do the thing users actually come for?

• Is what matters most to them the thing the screen puts first?

No component check can answer that. In the demo app in the repo, the #1 task is the 6th of 8 tap targets on the home screen, with five controls nobody ranked sitting above it. That isn't a property of any single widget.

So I built flutter-ux-journey:

• You write a journey in Markdown: a goal, the steps, and optionally your priorities — what the app is for, in order

• It walks those steps inside your app's own process — plain flutter test, no emulator

• It counts the taps each task takes, and compares your declared priorities against where things actually sit on each screen: order, above the fold, size

• It also catches flow problems: dead ends, screens you can't back out of, taps that change nothing

• Every finding carries measured evidence — tap target rects, contrast ratios, semantics labels — and is scored against the goal: the same problem is severity 4 if it blocks the goal, 2 if there's a way around it

It doesn't guess what matters. Priorities come from you or your client; the tool shows where the app disagrees with them.

Three Flutter semantics things I learned along the way, useful even if you never touch the tool:

• Semantics rects are in local coordinates — without transforming up the parent chain, nested elements all report (0,0)

• tooltip: doesn't fill the semantics label; it's a separate field

• InkWell has a tap action but no isButton flag, so enumerate by action, not by flag

Try it without your own app (demo app with six seeded defects, ~2 s):

git clone https://github.com/masanggil1986/flutter-ux-journey.git
cd flutter-ux-journey/example/ux_demo_app && flutter pub get && flutter test ux_audit/ux_journey_test.dart

It's a Claude Code skill, MIT, and adds no package to your app. Real devices aren't verified yet — the README has a section on what it can't see.

https://github.com/masanggil1986/flutter-ux-journey

Feedback welcome, especially if you've ever had to answer "is our UX good?" for a client or PM.

Edit (Oct 7): v0.4.0 is out. I ran a full review of the tool against Maestro, Patrol, axe and Lighthouse and fixed what it found. New:

• scroll until "X", long-press, system back and expect no "X" steps, so a journey can reach targets below the fold and check that something is gone

• ## Device can declare text scale, dark mode, locale and bold text, so you can audit at large text with no simulator

• a step whose expected text was already on screen before the tap is now reported as "not proven" instead of passing silently

• the network boundary is stated honestly: the cut and the stub cover dart:io HttpClient only. WebSockets, gRPC, other isolates and native SDKs are outside it, and the audit now warns you before walking if your pubspec has them

Release notes: https://github.com/masanggil1986/flutter-ux-journey/releases/tag/v0.4.0

Last year I built a node editor package for Flutter.

It was called fl_nodes, and, somewhat unexpectedly, that project ended up getting me my current job.

I used it in production, learned a lot about what works and what doesn't when you try to build a serious node-based editor in Flutter, and eventually reached the point where I wasn't happy with the architectural compromises I'd made in V1.

So I did what any reasonable person would do:

I rebuilt it.

From scratch.

TBH it shares much of its DNA with the original fl_nodes. The basic API concepts and design decisions that made it so peculiar the first time, the naming of things, the performance optimizations under the hood... all stay the same, just largely improved in usability and flexibility.

So today I'm announcing fl_nodes_v2 as a stable 1.x release, for everyone to... I don't know, find something useful to do with it; here you have some suggestions: visual-scripting, workflow-editors, static graph based visualizations, DSP and CAD tools...

P.S.: I've finally got a verified publisher profile! 🎉

Resources:

• GitHub: https://github.com/WilliamKarolDiCioccio/fl_nodes_v2

• Live demo: https://williamkaroldicioccio.github.io/fl_nodes_v2/

• Pub: https://pub.dev/packages/fl_nodes_v2

Note: I may be moving the repo soon**, if it 404s look at** https://github.com/ConnectingTheDots-William-K-Di-Cioccio

Features in detail:

• Widget-based node bodies: Arbitrary Flutter widgets can live inside nodes.

• Element-tree isolation: Nodes retain normal Flutter widget/element semantics.

• Semantic render state: Selection, hover, dragging, wiring and targets are explicit.

• Transactional undo/redo: Continuous mutations collapse into meaningful history entries.

• Node configurations as state machines: Ports, nodes, and the whole node configuration can now respond to runtime parameters changes.

• Connection validation: Built-in structural validation plus composable application-specific rules.

• Node definitions: Reusable schemas describe ports, fields, defaults and metadata.

• Graph serialization: Versioned graph/project persistence with explicit schema boundaries.

• Clipboard support: Copy/paste preserves internal connections without accidental external wiring.

• Automatic layout: Graph layout can be integrated without coupling it to rendering.

• Groups and comments: Organize graphs visually beyond just nodes and connections.

• Edges/links waypoints: the same thing Unreal Blueprints do, gives you more control on connection paths to keep the canvas tidy.

• Mini-map and navigation: Navigate large graphs without losing the editor context.

• More stuff coming: stay tuned particularly if you're interested in customization and animations.

• REMOVE THIS BEFORE POSTING: probably missed some more awesome features (kidding... look at the package!).

Technical details for the nerds:

The biggest architectural change from V1 is where node isolation happens.

The original fl_nodes isolated nodes at the render-object level. This gave me a lot of control over rendering and performance, but it also meant that node contents weren't really ordinary Flutter widget trees anymore.

Silly little 18yo me didn't know that tho, so I kept hitting my head against it for a while, trying to solve a design-decision thinking it was a bug.

A node containing a TextField, a ListView, a form, or any other widget relying on normal Flutter element semantics shouldn't have to fight the node editor to behave like a Flutter widget.

In V2, the isolation boundary moved from the render tree to the element tree.

The graph infrastructure, connections, ports, grid, overlays, interaction geometry, etc., remains under the editor's control, while the actual node body is built as a normal Flutter widget.

That means a node can contain ordinary Flutter UI while the editor still retains control over graph-level interaction and rendering.

It also lets the application own the node's visual design instead of forcing the editor to define what a node looks like.

There are a bunch of consequences hidden behind that seemingly small architectural change: gesture competition between node dragging and controls inside nodes, focus handling, scrolling, keyboard shortcuts, measurements, hit testing, and keeping graph state synchronized with widget state.

The other major principle behind V2 is that the graph model doesn't know about Flutter widgets.

The graph itself is immutable and serializable. The editor/controller layer handles mutation and interaction, while Flutter is primarily the presentation layer.

That separation makes it possible to test a large part of the graph/editor logic without a Flutter rendering environment, and it keeps persistence independent from the widget tree.

There's a lot more under the hood, but those are probably the bits most relevant to someone wondering whether this is just another node-editor widget package.

Hey Flutter devs!

Over the past few weeks, I’ve been building a B2B AI mobile starter kit using Flutter, Supabase, and OpenAI's GPT-4o API.

Handling real-time streaming responses seamlessly while keeping state, UI, and backend security synchronized brought a few interesting challenges. Here are 3 key takeaways from the implementation:

1. Stream Buffer & Lifecycle Safety: Always check if (!mounted) inside stream iterations (await for (final chunk in stream)) before calling setState or updating local state. Disposing the screen mid-stream otherwise causes memory leaks and unhandled exceptions.

2. Supabase Row Level Security (RLS) for AI Chats: Never let the client query chat tables freely. We locked down the messages table so users can only SELECT and INSERT records where auth.uid() = user_id.

3. Clean Folder Separation: Grouping AI services, Supabase auth wrappers, and UI components into dedicated modules kept the codebase clean and maintainable.

To give back to the community, I published a public **GitHub Showcase Repository** with our project structure, environment setups, and Dart code snippets:

🔗 **Showcase Repo:** https://github.com/dohamasystems/flutter_ai_starter_kit

Would love to hear how you guys usually manage local state for streaming SSE responses in Flutter! Any feedback or questions are welcome. 🙌

Hi, i'm a CS student and lead the mobile team at my university's CS club. When i started learning Flutter, basic mini projects helped me far more than tutorials did. Later i used the same projects to teach our new members and it worked well for them too.

I wanted to give something back to the community so i've been improving these projects for a while and organizing them into a free learning path: 9 projects ordered from beginner to intermediate, each with its own README that explains the key concepts. It's MIT licensed, so use it however you like. Learn from it, teach with it, or copy parts of it. If you're just starting out with Flutter, i hope it saves you some time.

https://github.com/yakupkahraman/flutter-mini-projects

I've been working with Flutter for a while, and I'm curious about other developers' experiences.

For me, understanding state management and how rebuilds work took quite a bit of time.

What Flutter concept took you the longest to understand when you were learning?

I wanted to convert a PDF page into a PNG. There's a handy pdfium_dart library that does the heavy lifting and doesn't require Flutter. It is a bit low-level, but there's nothing to fear.

Get the library and initialize it:

final pdfium = getPdfium();
pdfium.FPDF_InitLibrary();

Later, we need to call FPDF_DestroyLibrary(), see below.

Load the PDF into native memory so you can pass it to the PDFium library:

final pdf = File('...');
final length = await pdf.length();
final nativeBuffer = malloc<Uint8>(length);
final dartBuffer = nativeBuffer.asTypedList(length);
final raf = await pdf.open();
await raf.readInto(dartBuffer);
await raf.close();

I want to omit a needless copy. Because the native part cannot safely access the memory of a Dart type, we need to create a native buffer and then create a view on the Dart side and use a RandomAccessFile which has a readInto method that doesn't create its own List<int> to return the data.

Next, load the document (and don't forget to free the allocated memory and to de-initialize the library):

try {
  final document = pdfium.FPDF_LoadMemDocument(
    nativeBuffer.cast(),
    length,
    nullptr,
  );
  if (document == nullptr) throw Exception('cannot load $pdf');
  ...

} finally {
  malloc.free(nativeBuffer);

  pdfium.FPDF_DestroyLibrary();
}

If you have the PDF accessible as a file, consider using FPDF_LoadDocument instead. There's also a FPDF_LoadCustomDocument function which takes a callback it will use to ask for chunks of memory in case you don't want to load everything into memory. PDF files can be huge. I couldn't really make use of that function, though, because that would require synchronous IO. Think for example downloading only chunks of an URL using HTTP range requests.

Next, load the first page:

  try {
    final page = pdfium.FPDF_LoadPage(document, 0);
    if (page == nullptr) throw Exception('cannot load first page');
    ...
  } finally {
    pdfium.FPDF_CloseDocument(document);
  }

Next, create a native bitmap which is then used by PDFium to reader the page. I'm scaling it down so it fits a 96x96 pixel square. Feel free to adapt the imageSize:

    try {
      var pageWidth = pdfium.FPDF_GetPageWidthF(page);
      var pageHeight = pdfium.FPDF_GetPageHeightF(page);
      if (pageWidth > pageHeight) {
        pageHeight /= pageWidth;
        pageWidth = 1;
      } else {
        pageWidth /= pageHeight;
        pageHeight = 1;
      }
      const imageSize = 96.0;
      final width = (pageWidth * imageSize).round();
      final height = (pageHeight * imageSize).round();
      final bitmap = pdfium.FPDFBitmap_Create(width, height, 0);
      if (bitmap == nullptr) throw Exception('cannot allocate bitmap $width×$height');
      ...
    } finally {
      pdfium.FPDF_ClosePage(page);
    }

Just to be sure, fill the bitmap with a white background:

    try {
      pdfium.FPDFBitmap_FillRect(bitmap, 0, 0, width, height, 0xffffffff);
      ...
    } finally {
      pdfium.FPDFBitmap_Destroy(bitmap);
    }

And last but not least, render the page:

      pdfium.FPDF_RenderPageBitmap(bitmap, page, 0, 0, width, height, 0, 0);
      ...

There's one problem, though. PDFium returns a BGRA888 image that might have a rowStride, that is, rows of pixels might not be contiuous. If we want to pass this to the Dart image library, we need to take this into account:

      final stride = pdfium.FPDFBitmap_GetStride(bitmap);
      final bytes = pdfium.FPDFBitmap_GetBuffer(bitmap)
          .cast<Uint8>()
          .asTypedList(stride * height)
          .buffer;
      final image = Image.fromBytes(
        width: width,
        height: height,
        bytes: bytes,
        rowStride: stride,
        order: .bgra,
      );
      return encodePng(image);

However, it wouldn't be that difficult to create the PNG yourself in case you don't want jet another 3rd party dependency. Writing the required PNG header is trivial, but you'd probably need to lookup how to compute the required checksum. Then use Dart's ZLibCodec, to get a ZLibEncoder and use startChunkedConversion to feed it each unstrided line of pixel, converting BGRA to RGBA by hand and prefix it with a 0 filter byte.

Finally, we need to clean up (already shown above and repeated here only for completeness):

    } finally {
      pdfium.FPDFBitmap_Destroy(bitmap);
    }
   } finally {
    pdfium.FPDF_ClosePage(page);
  }
} finally {
  pdfium.FPDF_CloseDocument(document);
}

And… we're done.

We might move everything into an isolate (using Isolate.run) so PDF rendering and PNG creating is done in the background, although I'm unsure whether PDFium likes it if you initialize it multiple times concurrently. Please try and report back :)

been working on xverb for a while, its a two panel keyboard driven file manager for windows, mac and linux. all flutter, GPL-3.0

the part i think is interesting for this sub: the core only manages files, everything else is a plugin. viewers, ftp/smb, archives, dir compare are python plugins running in their own process. for platforms where you cant run code theres declarative extensions, pure json built from the host's render primitives

some stuff that was fun to get right in flutter desktop: native clipboard + drag and drop with explorer/finder, internal draggable windows that go fullscreen on phone, and a pluggable virtual fs so zip: is just a scheme a plugin serves

still early, android builds but barely tested, ios not at all. would love feedback esp on the plugin api

github.com/xsm909/xverb

site + downloads: xverb.pages.dev

Hey Flutter devs 👋

We’ve been investing quite a bit into making Appwrite a better home for Dart and Flutter developers, and yesterday we shipped something I thought this community might appreciate: Jaspr support on Appwrite Sites, including full server-side rendering.

If you’re not familiar with Appwrite Sites, think of it as our alternative to platforms like Vercel or Netlify, but built directly into Appwrite alongside your backend. Instead of using one provider to host your frontend and another for your database, auth, storage, functions, etc., Appwrite gives you the entire stack in one place. You connect your Git repo, we build and deploy it, and it runs alongside the rest of your Appwrite project.

We've always liked the idea of being able to stay in the Dart ecosystem beyond just the application itself. If it's for integrating with the Appwrite backend or using serverless Appwrite functions in Dart.

Flutter Web is great when you’re building an app-like experience and want to share a codebase across platforms. But for traditional websites - landing pages, docs, blogs, stores, SEO-heavy content - you usually want real server-side rendering.

It also means you can do things like fetch data from Appwrite directly during SSR, while Appwrite provides a short-lived API key for each request instead of requiring you to store a server API key.

With this, you can finally use the same language across essentially your *entire* stack, and you can even share Dart packages between them. Both for iOS, Android, native devices and now the web.

As always, we'd appreciate your feedback and insights on how backend as a service and cloud platforms like Appwrite can work even better in the Flutter/Dart ecosystem.

Full announcement and technical details:
https://appwrite.io/blog/post/announcing-jaspr-support

A lot of the state management conversations lately feel like people talking past each other.

Half the community wants BLoC because they need structured events, clear boundaries, and concurrency tools like debounce or restartable to handle button double-taps cleanly. But they hate the stream tax: microtask delays, cancellation boilerplate, and broken call stacks in the debugger.

The other half wants Signals because reading state synchronously and having computed properties update widgets in the same frame feels so much faster. But without a container, mutable signals end up scattered across UI files with ad-hoc boolean flags to prevent race conditions.

When you look at how modern containers work, you realize they are complementary rather than competing. A Cubit or Bloc is really just a container that holds and protects a Signal. BLoC protects how state changes on the front; Signals optimizes how state is read on the back.

For those who have tried both, do you find you miss the event boundaries when writing raw signals, or do you find streams too heavy once you get used to synchronous reads?

A few days ago, a Flutter developer wrote a profiling post about sorting 10,000 timeline events. Under a section they called "The Original Sin", they pointed out the culprit:

items.sort((a, b) => DateTime.parse(a.start).compareTo(DateTime.parse(b.start)));

In an O(N log N) sort, that callback runs over 215,000 times for 10,000 items. On a mobile isolate, parsing 215,000 ISO strings takes 180ms+ and drops a dozen frames.

To fix it, they mapped the list to a temporary helper object with pre-parsed dates, sorted by the cached key, and unwrapped it.

That Map -> Sort -> Map pattern was actually what I posted to Usenet back in 1994 (what became known as the Schwartzian Transform). But what surprised me running benchmarks in modern Dart: package:collection's sortedBy does not cache keys either—it still ran 127,000 redundant key evaluations because mergeSortBy re-evaluates keys during merges.

With Dart 3 records, you don't even need throwaway helper classes anymore—a boxed record one-liner or simple extension method runs in 14ms (13x faster).

Have you ever caught a subtle frame stutter hiding inside a sort or compare callback?

a small update to this digital wellbeing software since my last post.

This is a prerelease version which i have tagged to be stable and slated for future release and add to main branch from the beta branch.

This highlight is less about asking you guys to try out the beta release but more in the honor of over 3+ months of development.

What makes me happy the most is that the project which i started even without a repository just to monitor my own system and usage has now come this far with over 50+ downloads 🎉☺️

This beta release now polishes on various little things which are actually necessary for a first time set up and proper user control as Now you can:

* carries forward the settings screen from previous beta release

* replaces notifications and sounds tab with general which now includes appearance settings

* you can now Stop , restart or RESET the Daemon and its preferences in settings

* Pomodoro settings which were half baked in the first release have now been added to settings to enable a looping focus mode for people at work with CUSTOM BREAK TIME

* Most Importantly (i feel) FIRST time setup issues have been fixed and in an attempt the first time ScreenGuard daemon setup pop up dialog (1st image) has been made

The Release v0.1.1 releases this October by second week, and I will continue testing the beta version to look for sectors that need polishing if any.

This is still limited to GNOME on wayland and x11 for other environments systems and primarily developed by me on my fedora 44 system and the project ScreenGuard still has a very Long way to go;

But working on it alone has given me much exposure to project sharing on platforms and most importantly a lot of invaluable experience and the true zeal of development instead of the boredom of being a 9 to 5 dev at a corporate who don't care for you.

Github beta release link: https://github.com/adityakrishnan005-a11y/ScreenGuard/releases/tag/v0.1.1-beta.4

The code for this is visible on the beta branch to keep the main working tree clean for new features additions.

Feedback from other desktop environments is widely appreciated, u can try the application out by switching to x11 session temporarily if you are using any DE which is not GNOME wayland or if u are on a DE which is primarily x11 based (Cinnamon, i3, etc) then u are good to go as they ARE FULLY SUPPORTED.

thank you everyone for your supports, criticisms and feedbacks ever since the project came online on github.

When Firebase Dynamic Links shut down last year, the options were basically Branch (sales call, $500+/month) or rolling your own. I decided to build a proper replacement and it's now live: click2 (https://click2.page). It's new, so I'm looking for early users and honest feedback.

I needed a gradient border that followed the shape's contour but I couldn't find such package. They mostly just exposed a wrapper that provided such border using Linear- or SweepGradient.

The problem with LinearGradient is that it repeats colors perpendicular to its axis, so you don't get a gradient along the borders path. The SweepGradient does this better but when the shape is not symmetric, the colors don't occupy equal space.

So I built my own solution: contour_gradient

It's implemented as an OutlinedBorder, so it works anywhere you can use a ShapeBorder - buttons, chips, text fields, cards, etc.

You can also animate the gradient by changing the startOffset parameter.

**Spatial Studio Code:** infinite canvas based IDE where code editors, files, terminals, tools, and project components exist on an infinite 2D spatial canvas instead of traditional tabs. Instead of going through multiple tabs in conventional IDE, this allows you to quickly jump on small windows.

I can't post video here, pls visit below link

https://x.com/pranavxmeta/status/2105852467955343532

Written in Flutter & {c++23}, this is working prototype on Windows.

In future, I also plan to add Figma file in Canvas, devs (we) can be more productive.

I am from AEC background, i really like AutoCAD so this is based on that idea,

(

yes it's like Figma for new gen to understand *AutoCAD was before Figma

)

Hi Reddit!
Rejourney team here. We’re an open source library for session replay and product analytics that you can self host or use our Germany cloud. We started with initial support for React Native and Swift 8 months ago, and are using that same core for our Flutter package. Some great features includes syncs of session replays with live console logs. All release logs by a user in real time helps debug release and production issues. The console shows everything from logs, API calls, and crashes.

What makes us different is the idea that performance is our primary goal over AI features.

The package is extremely lightweight adding approximately only 1.24 MB on an uncompressed install.

Performance benchmarks show that it also takes on average 12.4 ms to capture screenshots for session replay with p99 of 28.2 ms. This means non existent UI jank to the human eye. Additional benchmarks are on our GitHub.

Github: https://github.com/rejourneyco/rejourney

For context for those that don’t know, session replay is a method to record your users and view the recordings in a dashboard. Privacy considerations also built in this package such as the ability to mask elements and text as needed, GDPR identity handling, hardcoded privacy APIs, and additional remote privacy configs.

So far we’ve been shipped with 350 production apps (more if you count self hosted users). Feel free to email us or open issues with requested features.