No Playlist Loaded

Choose a local playlist file or load a remote playlist URL.

GRID
QR X
QR Y
QR SIZE
0 FEEDS

MyAnythingList: Open Source Visual Media Walls From Plain Text

MyAnythingList turns a simple text playlist into a visual grid of links, videos, images, and QR codes. It is a single-file web application that can run locally, online, on public displays, in classrooms, on kiosks, or on personal computers without a server.

What it does

A playlist can contain ordinary URLs, YouTube videos, image links, QR code settings, layout variables, header and footer text, translated variables, and simple inline commands. The result is an interactive media wall that can be browsed, inspected, mirrored, translated, and exported as high-resolution thumbnails.

Why it matters

The project demonstrates human-directed, AI-assisted open-source software development: careful testing, clear documentation, language access, media literacy, public-interest curation, and reproducible configuration in a plain-text format.

A tiny open format for every screen, printer, classroom, shop, and community

Anyone can make a MyAnythingList with plain text: artists, teachers, journalists, printers, organizers, students, small businesses, museums, libraries, and families. It turns ordinary links into a portable visual surface for video walls, QR posters, interactive business cards, postcards, product sheets, event signage, public archives, and human-curated knowledge. The promise is simple: your links, your language, your layout, your file.

MyAnythingList: muros multimedia visuales de código abierto desde texto plano

MyAnythingList convierte una simple playlist de texto en una cuadrícula visual de enlaces, videos, imágenes y códigos QR. Es una aplicación web de un solo archivo que puede ejecutarse localmente, en línea, en pantallas públicas, aulas, kioscos o computadoras personales sin servidor.

Qué hace

Una playlist puede contener URLs ordinarias, videos de YouTube, enlaces de imágenes, ajustes de QR, variables de diseño, texto de encabezado y pie, variables traducidas y comandos simples en línea. El resultado es un muro multimedia interactivo que se puede explorar, inspeccionar, reflejar, traducir y exportar como miniaturas de alta resolución.

Por qué importa

El proyecto demuestra desarrollo open-source asistido por IA y dirigido por humanos: pruebas cuidadosas, documentación clara, acceso lingüístico, alfabetización mediática, curaduría de interés público y configuración reproducible en formato de texto plano.

Un formato abierto y pequeño para cada pantalla, imprenta, aula, tienda y comunidad

Cualquier persona puede crear una MyAnythingList con texto plano: artistas, docentes, periodistas, imprentas, organizadores, estudiantes, pequeños negocios, museos, bibliotecas y familias. Convierte enlaces comunes en una superficie visual portátil para muros de video, pósters con QR, tarjetas de presentación interactivas, postales, hojas de producto, señalización de eventos, archivos públicos y conocimiento curado por humanos. La promesa es simple: tus enlaces, tu idioma, tu diseño, tu archivo.

MyAnythingList: جدران وسائط مرئية مفتوحة المصدر من نص عادي

يحوّل MyAnythingList قائمة تشغيل نصية بسيطة إلى شبكة مرئية من الروابط والفيديوهات والصور ورموز QR. إنه تطبيق ويب من ملف واحد يمكن تشغيله محلياً أو عبر الإنترنت أو على الشاشات العامة أو في الفصول أو الأكشاك أو الحواسيب الشخصية بلا خادم.

ما الذي يفعله

يمكن أن تحتوي قائمة التشغيل على روابط عادية، وفيديوهات YouTube، وروابط صور، وإعدادات QR، ومتغيرات تخطيط، ونص للرأس والتذييل، ومتغيرات مترجمة، وأوامر مضمّنة بسيطة. والنتيجة جدار وسائط تفاعلي يمكن تصفحه وفحصه وعكسه وترجمته وتصديره كصور مصغرة عالية الدقة.

لماذا يهم

يوضح المشروع تطويراً مفتوح المصدر بمساعدة الذكاء الاصطناعي وتوجيه الإنسان: اختباراً دقيقاً، وتوثيقاً واضحاً، ووصولاً لغوياً، وتربية إعلامية، وتنظيماً للصالح العام، وإعدادات قابلة لإعادة الإنتاج بصيغة نص عادي.

تنسيق مفتوح وصغير لكل شاشة وطابعة وفصل ومتجر ومجتمع

يمكن لأي شخص إنشاء MyAnythingList بنص عادي: الفنانون والمعلمون والصحفيون والمطابع والمنظمون والطلاب والشركات الصغيرة والمتاحف والمكتبات والعائلات. يحوّل الروابط العادية إلى سطح مرئي محمول لجدران الفيديو والملصقات المزودة برموز QR وبطاقات العمل التفاعلية والبطاقات البريدية وأوراق المنتجات ولافتات الفعاليات والأرشيفات العامة والمعرفة التي ينظمها البشر. الوعد بسيط: روابطك، لغتك، تخطيطك، ملفك.

MyAnythingList: دیوارهای رسانه‌ای دیداری متن‌باز از متن ساده

MyAnythingList یک فهرست پخش سادهٔ متنی را به شبکه‌ای دیداری از پیوندها، ویدئوها، تصویرها و کدهای QR تبدیل می‌کند. این یک برنامهٔ وب تک‌فایلی است که می‌تواند به‌صورت محلی، آنلاین، روی نمایشگرهای عمومی، در کلاس‌ها، کیوسک‌ها یا رایانه‌های شخصی بدون سرور اجرا شود.

چه کاری انجام می‌دهد

یک فهرست پخش می‌تواند URLهای معمولی، ویدئوهای YouTube، پیوندهای تصویر، تنظیمات QR، متغیرهای چیدمان، متن سربرگ و پاورقی، متغیرهای ترجمه‌شده و دستورهای سادهٔ درون‌خطی داشته باشد. نتیجه یک دیوار رسانه‌ای تعاملی است که می‌توان آن را مرور، بررسی، آینه‌سازی، ترجمه و به‌صورت تصویر بندانگشتی با وضوح بالا صادر کرد.

چرا مهم است

این پروژه توسعهٔ متن‌باز با کمک هوش مصنوعی و هدایت انسان را نشان می‌دهد: آزمایش دقیق، مستندسازی روشن، دسترسی زبانی، سواد رسانه‌ای، گزینش محتوای عمومی و پیکربندی قابل بازتولید در قالب متن ساده.

یک قالب کوچک و باز برای هر نمایشگر، چاپگر، کلاس، فروشگاه و جامعه

هر کسی می‌تواند با متن ساده یک MyAnythingList بسازد: هنرمندان، آموزگاران، روزنامه‌نگاران، چاپخانه‌ها، سازمان‌دهندگان، دانشجویان، کسب‌وکارهای کوچک، موزه‌ها، کتابخانه‌ها و خانواده‌ها. این ابزار پیوندهای معمولی را به سطحی دیداری و قابل حمل برای دیوارهای ویدئویی، پوسترهای QR، کارت‌های ویزیت تعاملی، کارت‌پستال‌ها، برگه‌های محصول، تابلوهای رویداد، آرشیوهای عمومی و دانشِ گزینش‌شده توسط انسان تبدیل می‌کند. وعده ساده است: پیوندهای تو، زبان تو، چیدمان تو، فایل تو.

MyAnythingList：从纯文本生成开源可视化媒体墙

MyAnythingList 将一个简单的文本播放列表转换为由链接、视频、图片和二维码组成的可视化网格。它是一个单文件网页应用，可以在本地、在线、公共屏幕、课堂、信息亭或个人电脑上运行，无需服务器。

它能做什么

播放列表可以包含普通 URL、YouTube 视频、图片链接、二维码设置、布局变量、页眉和页脚文本、翻译后的变量以及简单的内联命令。结果是一个可浏览、可检查、可镜像、可翻译并可导出高分辨率缩略图的交互式媒体墙。

为什么重要

这个项目展示了由人类指导的 AI 辅助开源软件开发：仔细测试、清晰文档、语言可访问性、媒体素养、公共利益策展，以及用纯文本格式实现的可复现配置。

面向每块屏幕、每台打印机、每间教室、每家店铺和每个社区的小型开放格式

任何人都可以用纯文本创建 MyAnythingList：艺术家、教师、记者、印刷从业者、组织者、学生、小企业、博物馆、图书馆和家庭。它把普通链接变成可携带的视觉表面，用于视频墙、二维码海报、互动名片、明信片、产品单页、活动标牌、公共档案和由人类策展的知识。承诺很简单：你的链接，你的语言，你的布局，你的文件。

--> . UI data should reference safe named actions such as downloadLogs, showLogs, downloadThumbnail, or qrOverlay; it should not contain raw JavaScript. Future toolbar buttons, multi-level context menus, and diagnostic controls should be data entries rendered by the shared framework, not new hand-coded controls. Do not start this migration until standard UI functionality is reliable everywhere and the data-driven renderer can reproduce the stable beta exactly. E. Personal workflow reminder for future handoffs: after the stable public beta, Ken wants playlist translation engines for language-specific playlist/content versions and chat-transcriptor integration for saving daily chats into daily beta working folders. F. Future presentation-framework reminder: after the stable beta, consider a data-driven export/presenter layer that can turn a MyAnything grid into a sequential, chaptered, nonlinear PowerPoint-style presentation with an optional video-presenter stream. Treat this as a later framework project, not a change to make before the public beta is stable. MyAnythingList is a large single-file multilingual app. Many pieces are intentionally shared. Do not patch one visible control with one-off code when that control belongs to a shared system. Fix the shared handler once. UI / CONTROL FRAMEWORK RULES 1. There must be one basic control framework for standard app controls. Do not create parallel dropdown/listbox frameworks for one control, one menu, one language, one platform, or one bug. If behavior should apply to standard controls, fix the shared framework once so all controls inherit it. 2. Standard dropdown/listbox responsibilities are intentionally split but shared: v172 builds standard custom dropdown shells, v179 commits selections through the native select + normal input/change events, and v176 handles listbox wheel scrolling. Do not bypass these with one-off listeners. 3. All standard list boxes/dropdowns must use the same shared commit path. 4. Do not create special-case dropdown behavior for Download Format, Resolution, Aspect, Fit, Safe Area, Language, or future standard selects. If the legacy/app-owned Language shell needs work, preserve native select semantics and route behavior through the same standard control principles. 5. A dropdown selection must: set the native select value, sync custom UI label/list state, dispatch normal input/change events, and close cleanly. 6. If one standard dropdown breaks, assume the shared handler is the right repair location unless proven otherwise. 7. PC mouse wheel over an open dropdown/listbox must scroll that listbox itself using the shared wheel handler. Never add one-off wheel behavior for a single listbox. Standard dropdowns also require a shared small live-area tolerance around the button/list so tiny pointer drift does not collapse the menu; tune the shared v174/v023 close handler, never individual lists. 8. Toolbar flow rule: Current canonical order is Download Thumbnail -> Upload Thumbnail -> QR Overlay. Do not resurrect the older QR-after-download-only rule. Toolbar order belongs in source order plus one shared guard, not repeated relocation patches. Preserve this order with the shared/runtime flow guard, not by changing downloader/export behavior. 9. Handoff audit rule: before changing controls, search for duplicate control systems and remove or route duplicates through the shared framework. As of v18, the standard commit hook is data-mal-v179-unified-dropdown-select-commit and the standard wheel hook is data-mal-v176-dropdown-wheel. 10. Standard command-bar spacing is also shared. Use the v024 canonical spacing layer and CSS variables for row gaps, label gaps, and control alignment. Never tune the first controls, language controls, or any one dropdown/button separately; deterministic spacing must propagate from one shared layer. 18. Standard buttons, selectors, listboxes, and toggle controls must use the v034 deterministic content-fit + rhythm spacing system. Never hardcode individual button widths or listbox widths. The framework must measure all hardcoded option labels, button labels, and documented toggle states before controls are revealed, then set stable geometry from those values. If a developer changes labels/options in source, sizing must update automatically without recoding. If a label is unacceptably long and wastes interface space, shorten or improve the value itself rather than hiding it with an artificially small control. 19. Toggle buttons must document every possible visible label/state on the button instance or through the shared v034 state-discovery rules so the fixed width accounts for all states before display. Do not let toggle labels resize the toolbar. 20. When removing old spaghetti code, preserve useful behavior by moving it into the single modern deterministic owner function before deleting the old code. Do not delete output-affecting behavior just because it lives in old code. 21. Standard control spacing is owned by the v034 deterministic rhythm layer. Inner left/right padding, label-to-control gap, and control-to-control gap must share the same small design-aesthetic rhythm. Calculate/measure once before display, then keep controls stable; never add per-button/per-listbox spacing overrides. 22. Every standard range slider without its own always-visible value display must automatically receive a small green value label next to the slider. This applies to all current and future standard sliders through the shared v034 slider-value owner, not through one-off slider code. 23. v036 canonical spacing rule: all standard-control spacing is specified in one place by the control framework variables. The related label-to-control gap is intentionally smaller and nearly adjacent but still aesthetic. The unrelated gap between a finished control and the next label/control group is larger and deterministic. Button/select inner left-right padding, label-to-related-control gap, control-to-next-label gap, row gap, slider label-to-slider gap, and slider-to-value gap must all come from the shared framework variables; never tune individual labels, buttons, selectors, listboxes, or sliders separately. DEVELOPER WINDOW / OPTIMIZATION RULES 5. The developer optimization window is the standard place for private/public optimization tools. Do not create separate test popups, one-off benchmark buttons, or console-only workflows for JPEG/PNG/export/control diagnostics. Route developer diagnostics through the shared developer window. 6. Developer tools must be switch-gated. Current switch inputs are: URL ?dev=1 only. No hash switch, no localStorage switch, and no alternate dev switch names. With ?dev=1, the only visual change is a Developer button; the Developer window opens only when that button is clicked. 7. The developer window should include buttons for main logs: open, copy, download, and clear, plus optimizer table and cache tools. Keep this window documented in source so future handoffs know it exists. 8. Platform optimizer tables should include blank untested platform rows so future hardware can be tested later without guessing or code rewrites. VERSION / ZIP / LOG FILE RULES 11. App build numbers must use three digits from v023 forward because this project often exceeds 100 iterations per day/session. Use names like index_beta_YYYY-MM-DD-v020.html and index_beta_YYYY-MM-DD-v020.zip. 12. ZIP archive name must exactly match the app filename with .zip instead of .html. Internal ZIP timestamps must be America/Los_Angeles local time. 13. Downloaded log filenames must include the app filename/build version, for example MyAnythingLogs_index_beta_2026-05-22-v023_YYYY-MM-DD_HHMMSS.txt, so logs sort and trace back to the exact tested app. 14. Developer report filenames must also include the app filename/build version. DOWNLOAD / EXPORT RULES 9. Preserve the fast v188/v06-style downloader path and prewarm/cache behavior. 6. Do not add background redraw loops, lifecycle polling, or broad monitoring. 7. Keep diagnostics export-focused and low-noise: click, selected tile, cache, prewarm, canvas build, encode, and download anchor events only. 8. Menus may say JPEG ~2 MB, but the internal target is tuned toward about 2.5 MB for average large 8K JPEG thumbnail exports. Do not change menu text unless asked. 9. JPEG first-try compression must be deterministic. Use and tune the MAL_JPEG_FIRST_TRY_QUALITY_TABLE instead of ad-hoc quality constants or hidden per-resolution hacks. 10. Same-thumbnail working JPEG qualities must be cached by stable export signature so identical content can reuse known values without repeated exploratory retries. Use MAL_JPEG_WORKING_QUALITY_CACHE_V1 helpers. 10a. JPEG encoder path is platform-deterministic. Use MAL_JPEG_ENCODER_PLATFORM_POLICY instead of ad-hoc desktop/iPad/touch checks. Optional private benchmark helpers may inform future hard-coded table updates, but public exports must not trial-and-error every time. MULTILINGUAL / HANDOFF RULES 0a. Canonical resolution/aspect group rule: Resolution dropdown + X dimension input + Y dimension input + Aspect dropdown are one deterministic control block. They must be glued through the single v031 canonical Resolution control group, not through fixes, workaround scripts, repeated guards, or independent event handlers. Resolution preset, X/Y custom dimensions, aspect selection, CONFIG.Resolution, CONFIG.Output_Resolution, CONFIG.Aspect_Ratio, body aspect classes, custom dropdown labels, and export prewarm invalidation must all update from this one block. If any part breaks, repair the v031 canonical block only and remove older conflicting resolution/aspect glue. 0. Conflict-resolution rule: latest explicit Ken requirement wins. If a new requirement conflicts with earlier notes or code, remove/replace the older conflicting requirement, guard, or behavior in the same build so the source never carries contradictory instructions. 15. Resolution dropdown options must always be stored and displayed in ascending X-dimension order, then ascending Y-dimension order for ties. Keep Custom last. Do not group by feature, use-case, aspect, print family, or personal preference if that breaks numeric X sorting. 15a. Resolution X and Y dimension fields are now accepted UI behavior, not a temporary experiment. Keep them deterministic, shared, and tied only to the canonical resolution state. They must update from presets and custom values consistently, must not be controlled by one-off scripts, and must not be changed elsewhere without updating this rule. 16. Every new user requirement that affects future builds must be appended to these bottom-of-file maintainer notes in the same build that implements it, so future AI/handoff work inherits the rule without the user repeating it. 17. All standard listbox/selectors on PC must respond immediately to mouse-wheel input when open. Wheel over either the open list OR its selector button/combo must scroll the open list through the single shared v176 wheel path. Do not add per-control wheel handlers or duplicate wheel listeners in visual scripts. 11. Do not damage language packs, ?language= handling, RTL/LTR behavior, translated playlist variable aliases, or metadata localization while fixing export or UI bugs. 12. App ZIP artifacts must be named exactly like the app file with .zip instead of .html, and files inside ZIPs must use Los Angeles local timestamps for the user's sorting workflow. 13. For app builds, provide ZIP links only; do not paste this large source in chat. -->