今日已更新 203 条资讯 | 累计 33243 条内容
关于我们

标签:#epic

找到 6 篇相关文章

AI 资讯

The storefronts are coming to Linux: Epic, GOG, and the tipping point

For most of Linux gaming's history, the story has been the same: Linux users want to play games, game companies don't care about Linux users, and the community builds its own tools to bridge the gap. Valve changed that with Proton and the Steam Deck. But the storefronts held out. Epic, GOG, and Microsoft all stayed away from native Linux support, leaving their games accessible only through community-built launchers or not at all. That's changing. Three things happened this month that point to a tipping point. Epic Games is building a native Linux launcher In a Discord AMA reported by GamingOnLinux on August 14, 2026, an Epic Games developer confirmed that a native Linux version of the Epic Games Store launcher is coming "soon." Not for the preview release of the upcoming store overhaul, but after that. The developer's exact words, screenshotted from Discord: "Soon <-- but not for the preview release. As you can imagine, we need to do more than simply have a build of the launcher that can run natively on Linux." This isn't a vague promise from a community manager. It's a developer in an AMA saying the work is happening. Epic was also recently hiring a Security Engineer to champion Linux anti-cheat, which suggests broader plans for Linux support beyond just the launcher. The context matters. Epic has been the holdout. Tim Sweeney has historically been dismissive of Linux as a gaming platform, and Epic's anti-cheat (BattlEye, Easy Anti-Cheat) has been a recurring blocker for Linux compatibility even when games would otherwise run fine through Proton. A native launcher doesn't solve the anti-cheat problem, but it signals a shift in how Epic views the platform. GOG is working on a Linux version of GOG Galaxy GOG separately confirmed to GamingOnLinux that work is in progress on a Linux version of GOG Galaxy. No timeline, no details, just confirmation that it's happening. GOG is a smaller player than Epic, but they matter for a different reason: they're the DRM-free storef

2026-08-19 原文 →
AI 资讯

Why I Built Yet Another JavaScript Date Picker

Every developer has had this moment. You need a date picker, so you start searching. You find one that's perfect... until you realize it requires React. Or Vue. Or jQuery. Or an entire date library just to select a few dates. After trying several solutions, I kept asking myself: Why is such a common UI component often more complicated than it needs to be? So I decided to build my own. Meet RollDate . The Goal I didn't want to create "another date picker." I wanted to build something that I would actually enjoy using in my own projects. The goals were simple: Infinite scroll Zero framework dependencies Simple API Modern UI Mobile-friendly scrolling TypeScript support Easy customization Good documentation Why Scrolling? Most date pickers rely on clicking tiny arrows or dropdowns. On mobile devices, this often feels awkward. I wanted something closer to native mobile pickers, where changing the month or year is just a smooth scroll. That became one of RollDate's core ideas. More Than Just Picking a Date While building the component, I realized different projects need different selection modes. So instead of maintaining separate components, RollDate supports: Single date selection Date range selection Multiple date selection The API stays the same regardless of the mode. new RollDate ( " #date " , { selectType : " range " }); Optional Time Picker Many date pickers force you to install another plugin if you need time selection. I wanted it built in. RollDate supports: 24-hour mode 12-hour AM/PM mode Configurable minute steps Enable it with one option. new RollDate ( " #date " , { enableTime : true }); Dependency-Free One of the main design goals was keeping the library independent. No React. No Vue. No jQuery. No Moment.js. No Day.js. Just plain JavaScript. That means it works almost anywhere: Vanilla JavaScript React Vue Angular Svelte Astro ...or any framework capable of using DOM components. A Better Developer Experience I care a lot about developer experience. That's

2026-07-23 原文 →