• 1 Post
  • 70 Comments
Joined 3 years ago
cake
Cake day: June 12th, 2023

help-circle



  • I use jetbrains IDE since years, and I did some really strange stuff with them.

    I used clion with experimental GCC builds and crashed the IDE multiple times. Opened a bug. Got fixed.

    We found a bug in their Datagrip Sybase DWH integration. I met some of their team at a conference a week later, talked with them about the bug in person, got fixed during the day.

    Sure, bugs may take a while, but thei get fixed.

    And to AI. Cursor should be able to connect to jetbrains IDEs from the outside.

    There is no other, universal, IDE stack that can come close. Ok, maybe if you are willed to invest weeks in an emcas or neovim setup








  • Oh, someone said something against Firefox.

    As someone who donated regularly to the Mozilla foundation: adding AI in a browser is a stupid idea, always will be and alone the fact that Firefox spends time and resources in this feature means, they have to earn that money again.

    I will not donate anymore, as long as they develop WI features for Firefox.

    Vote this and this comment down as much as you like but fact is, that money must come from somewhere, and the biggest source of income is still selling Google the default search engine spot and outer questionable sources.

    This is not sustainable and a bad day for user choice.




  • Other stuffis not part of OpenRGB and never will be. Maybe you should have a loook at the project yourself, mainly read the contribution document.

    What is your issue? Avoiding fragmentation? Yeah me to.

    Currently,I do want to control my mouse, I need a different software that collides work OpenRGB.

    This is not fixable by trying to force stuff into OpenRGB the maintainer clearly does not want (he said so).

    After we have a working lib, with at least feature parity, I will try to convince the current maintainer of OpenRGB to outsource the device handling, and focus on the features he wants to build.

    EDIT and I don’t want to compete with OpenRGB, I want to focus the currently fragmented world of Linux peripheral development in a singular place, so every tool can use it. Ad a library, not a GUI application that just is another project that will die because it gets unmaintanable.

    So, please, have a good look at the contribution documentation and the bug tracker. Look for yourself, or try to introduce macro support or other stuff into this project. I have done so in the past.

    And to be clear: If the author and maintainer says he don’t want to have this feature, I completely understand.


  • This will not be a fork of OpenRGB. While I plan to take a huge chunk of it (the reversed generiert device protocols) the library itself, is all written from scratch.

    And, as mentioned, OpenRGB has issues. Besides the listed, technical, issues it has also design and maintenance issues:

    While OpenRGB heavily depends on Qt, and is written in C++, ur is full of plain C constructs. This is intentional, have a look at the README.md. raw pointer juggling, lifetime issues (therefore, segfaults) and most importantly:

    Making it a dependency would not aolfe any of the feature issues. A device, provided by OpenRGB, still has no support for macros, OpenRGB does all the device communication, so no way to add it.