Quantcast
Jump to content

  • Join Today, It's Simple and FREE!

    Register now to gain access to our webOS user support forum. Once registered and logged in, you will be able to post a user to user support request topic to this site or reply to existing topics posted by other users. You can also take part in our other webOS user forums. You'll be able to customize your profile, receive reputation points, while also communicating with other members via your own private inbox, plus much more!

Sign in to follow this  
pivotCE

[pivotCE]A future JavaScript framework for LuneOS – Demos wanted!

Recommended Posts

This article is unusual for pivotCE. Most of our articles are aimed at the general reader, but this one is specifically aimed at those with knowledge of javascript frameworks – specifically frameworks designed for app development. We hope this article will reach such people in our community and beyond in the hope that the LuneOS project can benefit from a range of experience and insight and even perhaps recruit some new contributors.

Long time webOS fans will be aware that one of it’s features was the ease with which apps could be created using methods more associated with web design. Most (non-game) apps were in fact mixtures of HTML & javascript. This and the ‘synergy’ of connecting data from various remote services into common user interfaces is what gave the system the name of webOS.

In the early days, webOS was at the cutting edge of using web technologies, but performance was not as responsive compared to more traditionally coded apps. Since the days of legacy webOS, many improvements have been made in app development frameworks and their implementation to bring speed up towards that of ‘native’ apps or at least fast enough for the user to see little difference. Increasing speed, power and multi-core processors have also helped, though performance is beginning to plateau as the physical limits of current hardware is reached.

The first (proprietary) development framework for webOS was called ‘Mojo’. After the purchase by HP, the (Open-source) ‘Enyo’ framework was introduced to target more varied screen sizes. Version 1 ran on the webOS 3.0 HP TouchPad and was back-ported to phones. Version 2 became a cross-platform framework also.

Of course, we all know about the end of hardware at HP and the eventual sell off of all parts of webOS. Officially, the Open-webOS project is still maintained by LG & HP and LG’s Silicon Valley lab have continued to develop the Enyo JS framework. The part used to make the UI for mobile apps is called ‘Onyx’. To make apps suitable for Television screens, LG developed a new UI library called, ‘Moonstone’. Enyo itself has developed through version 2.5 to now stand at version 2.7 and LGSVL now looks to the next generation of Enyo (Forum comments). But this brings with it potential problems for LuneOS.

To begin with, the various iterations of Enyo are not entirely backwards compatible. This is not a big problem as each version can be installed and recent versions are even able to package up modular parts of the framework with the app itself. But to take advantage of the latest improvements, each app needs some rewriting. At this time, apps written specifically for LuneOS are almost all system apps and have been written in whichever version of Enyo was current at the time.

Secondly, the Enyo team are assessing developments in web app development and technology and considering where to next take the framework. This project is currently called, ‘Enyo-next gen’ and will be based in part on the React.js framework. This means that compatibility will again be broken – likely to a greater extent than previously. For this reason, updates of existing LuneOS apps have been put on hold until the Enyo situation becomes clearer. As the Onyx UI library is built on Enyo 2.x, it will not work on React.js unless it is re-engineered. The team’s priorities are obviously lead by LG’s webOS product line: Televisions (briefly a watch) and now refrigerators. It seems that the next generation Enyo will target mobile devices, but Onyx will not be part of the package. It remains to be seen what the replacement will be like.

To avoid remaining in a backwater, LuneOS will need apps. The time is approaching when developer attention must turn from the core OS to the app ecosystem. Millions of apps aren’t needed, but a decent range of modern apps will be. LuneOS has a modern browser based on Chrome. All modern JS frameworks support it and therefore many web apps can be run on LuneOS: old Legacy favourites, apps from similar systems and standalone web apps. Of course, the latter examples won’t necessarily resemble or act like webOS apps and LuneOS will still need a framework for original apps; One that will ‘feel’ and hopefully look like webOS. In short, the LuneOS project needs to make a choice of javascript framework for the future and standardise upon it.

What are the options?

  1. webOS Ports could stick with Enyo 2.7. It will be supported for a while. The problem is that this version will not be updated as technology moves forward and the Ports team lack the resources to maintain the framework in addition to the OS.
  2. If Enyo-next gen works well (It is certainly expected to be a contender), but lacks the UI elements suitable for LuneOS, the team could attempt to maintain a version of the Onyx or Mochi UI libraries for dedicated use, but again human resource issues mean this option will probably be overlooked in favour of a more ‘off the shelf’ solution.
  3. Enyo-next gen could provide an ideal solution, offering the option of creating webOS-style mobile apps.
  4. Another suitable framework may need to be found – one that can offer modern performance and which will be supported for the foreseeable future. A popular framework could also deliver a range of apps from sources beyond the small webOS community.

The webOS Ports team are soliciting demo web apps that show the “feel” of webOS can be duplicated by candidate frameworks. What is needed from a javascript framework suitable for LuneOS? LuneOS developer, Doug Reeder of Hominid Software suggests some requirements:

1. A single app is usable on both phone- and tablet-sized screens.
2. A layout widget to organize multiple panes, like Enyo Panels, but possibly behaving differently.
3. A list with 500 items.
4. …whose items can be swiped left or right
5. …and whose items can be rearranged by dragging.

A fuller list can be found at this wiki page.

Most of our articles link back to the forum at webOS Nation, but in this special case, we are going to link to the archive of the webOS Ports mailing list and invite those interested to join the list and the IRC channel.

Here are archives of the discussion so far:
Enyo EOL 1, 2, 3.
Choosing a new JavaScript framework and UI library 1, 2, 3.

If you are familiar with JS frameworks, you are invited to share your experiences of development and performance and suggest candidates for testing. Please click here for information on the IRC channel and how to join the webOS Ports mailing list. Please share this article with anyone who may have useful insights.

Image credit: Working on the Meccano Bridge by David Dixon.

View the full article

Share this post


Link to post
Share on other sites


Sign in to follow this  

  • Similar Forum Topics

    • [pivotCE]LuneOS November Stable Release: Doppio

      The very long wait is over #LuneOS and #webOS fans! We’re finally back with a new release called “Doppio” which we believe will be a milestone in terms of developments and the way forward! So you’re wondering what we’ve been up to for the past year? Well, actually a whole lot to be honest! We have upgraded the bluetooth stack from BlueZ4 to BlueZ5 which required quite some work to the kernels. This has been successfully completed for the Nexus 4 (Mako) and Nexus 5 (Hammerhead); unfortunately to date we haven’t been able to get this to work on the Touchpad (4G) (Tenderloin). We have been working closely together with the Halium project and have made further integrations between LuneOS and Halium reducing duplication between the projects and using a single source where possible. This all to be more easily integrated, and to facilitate ports to newer devices. We have upstreamed our kernel patches (mainly to fix GCC 5/6/7/8 compatibility) to Halium so we can use a shared kernel for our targets. Talking about new devices we’ve been working on: Since Google dropped the (budget) Nexus line and launched the (premium) Pixel line, we’ve been looking for other targets that are easily available, budget friendly and have good community support. We quickly ended up with Xiaomi which makes phones with decent specs, unlockable bootloader (the process is a bit tedious, but it’s do-able) and the phones give very good value for money. This has resulted in us independently working on 3 different Xiaomi devices being the RedMi Note 4x (Mido), RedMi 5 (Rosy) and Mi A1 (Tissot).  These are all Aarch64 devices using the Snapdragon 625 chipset. We didn’t have any Aarch64 devices before and also they are based upon Halium 7.1 (Android 7.1) while all our previous targets were based upon Halium 5.1 (Android 5.1), so this brought a whole bunch of new challenges. There are still a few rough edges, but audio, sensors, wifi and bluetooth are now working. There was also quite some porting work done for some of the other Halium supported targets such as the OnePlus X (onyx), Google/Huawei Nexus 6P (angler) and Motorola G4 (athene). These are currently in various stages of development, whereby OnePlus X is the most mature. The Xiaomi Mi A1 is a strategic device for us which we chose in cooperation with LG to work on to get LuneOS working and also as a target for LG’s webOS OSE (Open Source Edition). LG’s release of webOS OSE came as a surprise to us, however it has great potential. Though the initial release of webOS OSE was very limited and therefore limited use case for people not being very familiar with webOS, it does offer a lot of potential for us. webOS OSE is basically 5 years of development of the core webOS bits since Open webOS was released. It has been deployed in millions of LG TV’s since and offers great improvements in terms of reliability and functionality. The big downside however is that there’s no record of the changes between Open webOS and webOS OSE, so this is making the migration a bit more challenging. Early June the LuneOS team met with LG in Paris to discuss collaboration between our teams. As a result of this we have chosen the Xiaomi A1 as a device to port LuneOS to. This is now at a level similar to our other targets. After this release we will therefore focus on migrating our Open webOS components to the updated components provided by webOS OSE. This will bring quite some challenges and hurdles along the way, however we’re positive that we can complete this migration and it will bring a lot of improvements in terms of code quality, stability, functionality and reducing the need for maintaining a lot of these components ourselves since we can share a common codebase with LG’s webOS OSE going forward. LG has a very clear vision in mind for webOS. Since the initial release in March, a roadmap has been published and LG has pushed out 4 releases since the original release of webOS OSE. The following items on our to-do list will be where we focus next: Migration of Open webOS components to the newer webOS OSE components. Make the VirtualBox image work with a newer MESA. Migrate to Yocto Sumo/Thud release. Messaging improvements. Camera improvements. Fix known issues on the various targets. Bring back official support for Touchpad 4G (current build works on Touchpad 4G but only WiFi). Known issues: Node-SQLite3 is currently not working. Components using Node-SQLite3 have switched to an alternative storage method for now. Focus bug on input fields. You can work around this by hiding the virtual keyboard and pressing the input again. Random issue with virtual keyboard not showing on Aarch64 devices. Changelog Applications: Settings: Add QML variant, enable manual time and date in Setings. org.webosports.cdav: Add CLEANBROKEN User Interface: luna-{sysmgr,sysmgr-common,appmanager,next}, mediaindexer: fix build with Qt 5.11. luna-{webappmanager,qml-launcher} org.webosports.app.{browser,firstuse}: fix build with Qt 5.11. luna-next-cardshell: add runtime dependency on qtmultimedia-qmlplugins, luneos-components. luneos-components: drop build time dependency on qtwebengine, switch to Mer’s bluezqt System Level: luna-next: Add config for onyx, Add QT_OPENGL_NO_BGRA and remove QT_ENABLE_GLYPH_CACHE_WORKAROUND android-gadget-setup: fix functionfs test android-tools: fix compatibility with adb 5.1.1 android-tools-conf: Fix the machine check, Don’t patch script for tenderloin base-files: provide a common fstab for all LuneOS devices bluez: switch from bluez4 to bluez5 bluez5: Fix patch so it will work for RaspberryPi3, make firmware search case insensitive connman: Add connman-tools, connman-tests and connman-wait-online, Update to 1.35 distro: luneos: switch release name to Doppio environment.conf: Add QT_ENABLE_GLYPH_CACHE_WORKAROUND=1 fingerterm: Update to upstream and drop patch, use LiberationMono font funyahoo-plusplus: Bump SRCREV https-everywhere: Bump SRCREV hunspell-dictionaries: Update to latest version imaccountvalidator, imlibpurpleservice: Drop unsupported protocols initramfs-boot-android: add A/B partition support, boot into built-in recovery when no skip_initramfs, get Halium’s init script from GitHub, improve panic scenario in init.sh, use /userdata instead of /android/userdata, Various fixes to init.sh kf5bluezqt-mer: fix package content with empty QT_DIR_NAME libconnman-qt5: fix initial value of “connected” property libhybris, qtbase: don’t use += together with _append libhybris: Bump SRCREV, Set –enable-arch=arm64 for aarch64, Drop –with-default-hybris-ld-library-path and bump SRCREV libpbnjson: use Unix Makefils OECMAKE_GENERATOR lsb: fix luneos-version content luna-(web)appmanager: use /etc/luna-next/qtwebengine.conf luna-init, luna-sysmgr: Bump SRCREV and adjust file installs luna-init: Fix incorrect {, Install CustomerCareNumber.txt and cust-preferences.txt luna-prefs-data: Bump PV to be in sync with luna-prefs luna-sysmgr: Cleanup recipe luna-sysmgr-conf, nyx-modules: fix rosy values, Add initial files for athene and onyx target, Cleanup recipe and fixup defaultPreferences-platform.txt luna-universalsearchmgr: inherit webos_systemd luna-webappmanager: bump SRCREV luneos.inc, connman: Build & deploy VPN plugins luneos: inherit remove-libtool luneos: update SANITY_TESTED_DISTROS luneos-dev-image: tell Halium to mount rootfs rw luneos-emulator-appliance: update a bit luneos-features, connman: Add support for NFC using neard luneui-example-image: add few more packages, add more packages for testing, add vboxguestdrivers, v86d, add very small (fast to build) test image maliit-framework-qt5: set XDG_RUNTIME_DIR in conf file meta*: enable gbm meta-webos-ports: Add configuration files for Tissot, Update classes with info from webOS OSE mido, tissot: Fix path for CHARGER_AC_SYSFS_PATH mido: Initial configuration files mobile-broadband-provider-info: Bump SRCREV mojomail: bump SRCREV to fix build with boost-1.67.0, Switch back to webOS-ports/master branch nemo-qml-plugin-dbus: Update to latest version from upstream, fix package content with empty QT_DIR_NAME node-sqlite3: Bump version nyx-conf: do not let keys module watch over the touchpanel nyx-modules: Fix devices names in cmake files ofono: Update to latest version from upstream and enable Python 3 tests onyx: Enable power button packagegroup-luneos-development: include QML settings app packagegroup-luneos-extended: add android-kernel-bootimg, Add qtconnectivity, Add WIP targets and more documentation, Build bluez5 for all targets, include libpci for qemux86, move android-kernel-bootimg phonesim: Fix build with empty QT_DIR_NAME, refresh patches with devtool, update to latest revision from git pidgin-sipe: backport a patch to fix build with gcc8 pulseaudio-distro-conf: Add support for Xiaomi A1 (tissot), Add webos-system.pa for mido target pulseaudio-modules-droid: bump to 10.0.73, refresh patches with devtool, remove tenderloin CFLAGS purple-skypeweb: Bump SRCREV python-tz-native: Update to 2017.2, Fix typo in SRC_URI qt5: upgrade to 5.11, upgrade to 5.11.1 qt5-qpa-hwcomposer-plugin: fix package content with empty QT_DIR_NAME, hwcomposer_backend.h: Fix cast from ‘void*’ to ‘unsigned int’, remove tenderloin CFLAGS qtbase: Add patch to fix quirks with newer Adreno GPU’s, refresh patches, remove TLS patch on Halium 7.1 targets, temporary fix for SIGBUS crash on Android devices qtlocation: refresh patch qtscenegraph-adaptation: Bump SRCREV qtsensors-sensorfw-plugin: fix build with empty QT_DIR_NAME qtvideo-node: fix package content with empty QT_DIR_NAME qtwayland: add qwayland-server-surface-extension.h, wayland-surface-extension-server-protocol.h to sync.profile, bring QWaylandExtendedSurface back for luna-next, drop patch applied in 5.9.3, refresh patches for 5.11.2 qtwebengine: add libpci to RDEPENDS, Drop patch for libEGL and libGLES2, fix filename in SRC_URI, Fix patch for additionalFeatures, refresh patches, Remove PalmServiceBridge, replace EXTRA_QMAKEVARS_CONFIGURE with PACKAGECONFIG, squash a few of chromium patches for easier maintenance recipes: drop unnecessary FILES_${PN}-dbg variables, use oe.utils.conditional instead of deprecated base_conditional sensorfw: Bump SRCREV and drop patches now merged upstream voicecall: Update to latest version from upstream webos-systemd-services: Drop installation of luna universalsearchmgr.service android-headers: Add headers for Halium-7.1, common recipe for Halium-5.1 headers, make it possible to tweak android-config.h per machine, Use Halium Headers android-headers-halium: set preferred version android-headers-tenderloin: fix patches to match Halium’s android-kernel-bootimg: dedicated recipe for creating boot.img, minimal support for A/B partitions android-system: Add missing groups, also mount /persist when it exists, cleanup old hal-hybris overlay code, don’t manage ramdisk unpacking, fix lifecycle of lxc container, Remove installation of non-existing files, simplify usage of Halium, start sensorfwd after android container, use pre-start.sh from Halium, wait a bit for the sensors to be ready android-system-image: use system.img directly, Change wop into luneos, convert the sparse image if needed, create /userdata, Update halium bits to halium version numbers base-files: use system.img directly android-tools: remove, since now in meta-oe base-files,android-system: Android partitions are now mounted by Halium’s initrd base-files: add /system/lib64 in LD_LIBRARY_PATH hammerhead, mako: Add NFC as machine feature
      Include android-kernel-bootimg for each MACHINE that needs it initramfs-android-image: make it possible to add content libhybris: provide also virtual/mesa and set PREFERRED_PROVIDER for all android devices linux-lg-{mako,hammerhead},linux-hp-tenderloin: backport 2 changes to fix build with gcc8 mako, hammerhead: Use upstream kernels which now have our patches included mako: Fix the kernel build meta-*: set PREFERRED_PROVIDER for libgl and libgbm for all android devices meta-{asus,hp,huawei,lg,motorola,oneplus,xiaomi}: remove fstab overload meta-android: initramfs-android-recovery: add inc, remove leftover from android-tools removal meta-hp: migrate tenderloin to use Halium’s init meta-oneplus: Fixes for onyx target to make build work meta-smartphone: Add meta-huawei layer with Angler target, udev-extraconf: Uniform naming scheme for device udev rules and update udev rules meta-xiaomi: add initial support for rosy (Redmi 5), Get image for Tissot building, Initial work for Xiaomi A1 (tissot), mido fix persist partition number in fstab, mido use correct wlan module name, tissot: add initramfs-android-recovery, tissot: enable permissive SELinux, tissot: ignore other parameters from bootloader, tissot: switch to cm-14.1 kernel to fix wifi Migrate LuneOS targeted machines to using android-kernel-image systemd-machine-units: fix bluetooth for hammerhead, fix bluetooth for mako The usual 1. Sign up for the bug tracker 2. Get involved and 3. Join the mailing list Download and Install Feel free to download the updated builds to get started. Tenderloin, Mako, Hammerhead and Tissot remain our focus for now, but the emulator, Mido & Rosy work too. Please note that in order to use the latest stable builds Nexus 4 (Mako) and Nexus 5 (Hammerhead) you need to flash the CM 12.1 images first using CWM/TWRP. In order to do so, you might be required to do a “factory reset” or at least “wipe cache”. CWM/TWRP will indicate when this is needed. After successfully flashing CM 12.1, make sure to boot it at least once before going back to CWM/TWRP to flash the latest LuneOS image! We have provided links to CM 12.1 for these 3 images on our device pages below. Installation instructions for TouchPad (Tenderloin), Nexus 4 (Mako), Nexus 5 (Hammerhead) and Emulator are on the wiki. And remember we don’t do timelines. Don’t forget to contact us with any questions and feel free to join the discussion on the webOS Nation forums. Catch us on Twitter @webosports on IRC: Freenode:#webos-ports or email [email protected] We will see you shortly again with a new release! Picture Credit: Chevanon. Cropped & flipped. Text added. Related posts: LuneOS July Stable Release: Cortado LuneOS February Stable Release: Chai Latte LuneOS September Stable Release: Decaf View the full article

      By pivotCE, in pivotCE News

      • 0 replies
      • 96 views
    • [pivotCE]The New Palm phone is revealed.

      There’s a new Palm phone. It’s due to be released next month. Now, if you are a long time Palm enthusiast (and reader of this blog) you will no doubt be telling your heart not to beat too quickly because to put it mildly, things have not worked out well in the past. We already knew that TCL / Alcatel had bought the brand (only). The possibility of a new phone running webOS was dismissed. The speculation on the webOs Nation forum was that we would be seeing a standard Android slab with the Palm logo stuck on, though no one could figure out quite how that would be a success.

      In August, there were some leaks that seemed both intriguing and potentially disappointing. A small phone? OK! A low specification? Uh… You don’t have to wonder any longer. The curtain has been almost fully raised and we can confirm that the new phone is… both intriguing and potentially disappointing. Here are some bullet points: It appears that the new Palm is in fact a startup that approached TCL with their plan. TCL backed them and handed them the Palm brand. “Pepito” was a codename. It’s just “Palm”. The reason the specs look like a ‘weekend’ phone is because it’s a weekend phone. It is in fact a ‘companion’ phone to your other, big phone. We are just a little webOS blog, so we have no inside sources or review model. There is an apparently regurgitated press release on Fast Company. You can then read what Dieter Bohn has to say at The Verge. A number of webOS community members have done valuable work in maintaining popular services on our old webOS devices (not to mention keeping them working at all). But given the number of services that no longer work on webOS, using one of the original phones has much the same effect as the ‘Life Mode’ (AKA aeroplane mode) offered by this new device. However,  I’m not going to condemn it. The potential criticisms are obvious: Why not just sell a smaller phone? It’s only available as an add on device, only on Verizon in the U.S. It costs $350. It’s true that there seems to be an increasing desire for phones that are smaller and for services that respect a balanced life rather than attempting to addict us to various feeds. There are few choices available for those that want these options. Within that context, the new Palm phone is different and distinctive. As a ‘lifestyle phone’, it is possible that  it will appeal to trendy and fairly well-off people and actually sell. However, the Verizon exclusivity may limit access even to that particular demographic. If enough are sold to keep Palm in business, they could extend the concept to other networks and countries. It’s possible that the next model could build on that. Pepito2 could have better specs and be able to stand alone, usable as a companion device or a daily driver. Of course, I’d say that an ideal OS for some kind of synchronizing connectivity across devices would be webOS, but that’s NEVER GOING TO HAPPEN, unless the boot-loader is unlocked and we install it ourselves. So I wish the new Palm luck. In historical terms, there’s very little about this product that’s new, but it seems that it could fill a niche that’s opened up in the current smartphone market. This pricey life-style toy could evolve into the smaller, simpler phone for the many, but only time will tell and yes, I’m doubtful. Those are my thoughts. What are yours? Here’s your comment thread. Related posts: TCL’s Palm phone will run android…duh HP is to Palm as Lenovo is to Motorola…Not Good TCL, Blackberry & Palm View the full article

      By pivotCE, in pivotCE News

      • 0 replies
      • 167 views
    • [pivotCE]webOS meetup, Chicago, 3rd June

      It’s been over a year since there was a webOS meet up in Chicago, but it’s happening next month! There are many fun things to do in Schaumburg, but the highlight of your visit will of course be the chance to sit down with fellow webOS enthusiasts to enjoy pizza and good conversation. The 2018 webOS meetup will be on Sunday June 3rd 2018 at 7pm. The place is Moretti’s Ristorante and Pizzeria, 1893 Walden Office Square, Schaumburg, IL 60173.

      Bring your old webOS devices, your new LuneOS devices and your Raspberry Pi running webOS OSE (but maybe leave your webOS TV at home). Click here for directions to Moretti’s. Any questions? Here’s the forum. The team at pivotCE remind you that if you are planning a meet up, let us know! We are interested in promoting your events (it might even increase attendance!). We are also interested in reports and pictures from webOS events. Related posts: webOS meetup, Chicago, 23rd November webOS meetup, Chicago, 27th November webOS meetup, Chicago, 17th April View the full article

      By pivotCE, in pivotCE News

      • 0 replies
      • 394 views
    • [pivotCE]TCL’s Palm phone will run android…duh

      Android Police broke the story earlier today that TCL will launch a Palm branded phone via Verizon sometime in the 2nd quarter this year.  And surprise…it runs Android. Sadly that’s all we know for now. It’s taken TCL a long time to do anything with the Palm brand.  We first talked about it 3 years ago. It started as an unveil of sorts at CES in 2015 when they announced they had purchased the Palm brand and they’d be crowd-sourcing from “Palm’s very own community” what to do with it.  No idea what they meant by that… They even launched a website placeholder that directed palm.com to mynewpalm.com. Both of which are no longer doing anything. But trust me when I say I’ll be hammering the refresh button for the near future on palm.com. Fun fact:  This topic was also the fourth to last article written on the now silent webOSNation.com to give you a reference for how long it took TCL to do something! At any rate, I’m glad the wheels are turning and I’ll hold judgement until I see what they release though the carrier exclusivity announcement makes my eye twitch. Even former Palm CEO Jon Rubinstein knew carrier exclusivity aided in the death of webOS and the remnants of Palm. “I think the deal we had with Verizon really hurt us, but who knew that at the time? These things are all hindsight.” TCL can use hindsight for historical evidence though. Hopefully they’re crunching the numbers… #PalmForever   Related posts: HP is to Palm as Lenovo is to Motorola…Not Good The Next webOS Phone? (Part I) The Second Day of webOS-mas – Print from your phone View the full article

      By pivotCE, in pivotCE News

      • 0 replies
      • 283 views
    • [pivotCE]New Palm OS Software Archive

      Dig around in your closet, dump out that side table drawer, and wade through boxes in your garage. Do whatever you have to do to find those old Palm OS devices because there’s a new software archive in town! Reddit user, Yiddish, established the archive and is adding to it via donations from Palm fans. (Check out /r/Palm by the way!) If you have files to add, reach out to Yiddish via the Reddit post or on the twitter page for @ArchivePalmOS. Shalom! #PalmOSforever Click the pic above for a recent /r/Palm post from andymememe. Related posts: Forty Years of Tech Exhibit Showcases first Palm PDA TCL, Blackberry & Palm HP attempts to sell Palm patents – again. View the full article

      By pivotCE, in pivotCE News

      • 0 replies
      • 282 views


×