Page 3 of 4 FirstFirst 1234 LastLast
Results 41 to 60 of 74
Like Tree21Likes
  1. #41  
    Quote Originally Posted by NIN_ru View Post
    LuneOS has support for non-english characters. Just hold down "en" button(or blank button in russian layout), and menu will appear:
    Click to view quoted image

    But layout need some improvements imho
    No such button ("en" or blank) on my virtual keyboard.
  2. #42  
    Quote Originally Posted by Pilotovef View Post
    No such button ("en" or blank) on my virtual keyboard.
    Are you sure? I see it everywhere except browser url bar.
    Please check keyboard in just type, memo app, on any webpage, ... and if you don't see it, feel free to report a bug.
  3. #43  
    No way to switch to Russian on my TP.

    Attached Images Attached Images
  4. #44  
    I have a question of a 'legal' nature...

    Some background:
    Cyanogen wants to seize Android from Google, and now it has the cash to do it which lead me to...
    Google's iron grip on Android: Controlling open source by any means necessary | Ars Technica

    (The following assumes that the mobile phone market changes so that minor players like Ubuntu, FFOS, Tizen, Jolla etc. get a chance to compete against the incumbents. LuneOS might be one of those challengers)

    Anyone can take AOSP and make an OS. For an OEM to make a 'Google-Android' phone with all the Google services, they have to join the Open Handset Alliance - Wow! an OS, apps & services for (almost) free! But the rules say that you can't release a device with a fork of Android...

    I was surprised to see how much investment Cyanogenmod is getting, but it can access markets in China & India where forks of the AOSP are being used, but not Google services. However, any OEM selling into western and other markets where Google-Android is a dominant force, can't use CM if they want to offer Google-Android.

    Drivers for the Palm webOS devices are proprietary and were never released. I know LuneOS (of necessity) only uses Android drivers (& maybe the kernel?), but can this be argued to be a 'fork' of AOSP?

    Does this mean LuneOS could never be used by an OEM offering Google-Android devices?

    Open webOS was released in a state that would run on a desktop machine and work was done on a port that struggled with the drivers until the decision was made to rewrite Lunasysmanager as LunaNext, rebasing on Android drivers. Assuming LunaNext might cause the problem above, would it be possible for an OEM to build Open webOS (and Luna) with their own drivers, then add the 'LuneOS' developments on top? By 'possible' I mean fairly easy to do without significant rewrites of the original OSS code or the new stuff.

    It seems LG is doing this already - developing Legacy/Open webOS with their own H/W drivers without breaking their OHA agreement. I'm ignoring TVs and thinking about that 'smartphone on a wrist', Urbane LTE. But my guess is that LG webOS will go down a proprietary route and not license to others. This will limit LG webOS to a single OEM, unless there is an OSS version of webOS that others can pick up, yet which won't be blocked by Google claiming it to be an AOSP fork... Note that LG show no sign of making a webOS phone so there appears to be only one likely group serving the sector of 'webOS phone'.

    Of course, LuneOS first needs to become a usable 'daily driver'. Any possible commercial potential is some way off and things in the mobile phone market would need to shift for any of the 'underdog' OSes to break through, but this possible block on uptake occurred to me. Removing it or having the ability to remove it in the future might allow webOS access to markets where Cyanogen would be blocked.

    So, could LuneOS be considered an Android fork? Could the Android bits be easily replaced by an OEM?

    I'm not really expecting an answer - it just might be something to think about depending on where the Ports team might take LuneOS in the future.
    Last edited by Preemptive; 03/26/2015 at 09:28 PM.
  5.    #45  
    I have a question of a 'legal' nature...

    Some background:
    Cyanogen wants to seize Android from Google, and now it has the cash to do it which lead me to...
    Google's iron grip on Android: Controlling open source by any means necessary | Ars Technica

    (The following assumes that the mobile phone market changes so that minor players like Ubuntu, FFOS, Tizen, Jolla etc. get a chance to compete against the incumbents. LuneOS might be one of those challengers)

    Anyone can take AOSP and make an OS. For an OEM to make a 'Google-Android' phone with all the Google services, they have to join the Open Handset Alliance - Wow! an OS, apps & services for (almost) free! But the rules say that you can't release a device with a fork of Android...

    I was surprised to see how much investment Cyanogenmod is getting, but it can access markets in China & India where forks of the AOSP are being used, but not Google services. However, any OEM selling into western and other markets where Google-Android is a dominant force, can't use CM if they want to offer Google-Android.

    Drivers for the Palm webOS devices are proprietary and were never released. I know LuneOS (of necessity) only uses Android drivers (& maybe the kernel?), but can this be argued to be a 'fork' of AOSP?

    Does this mean LuneOS could never be used by an OEM offering Google-Android devices?

    Open webOS was released in a state that would run on a desktop machine and work was done on a port that struggled with the drivers until the decision was made to rewrite Lunasysmanager as LunaNext, rebasing on Android drivers. Assuming LunaNext might cause the problem above, would it be possible for an OEM to build Open webOS (and Luna) with their own drivers, then add the 'LuneOS' developments on top? By 'possible' I mean fairly easy to do without significant rewrites of the original OSS code or the new stuff.

    It seems LG is doing this already - developing Legacy/Open webOS with their own H/W drivers without breaking their OHA agreement. I'm ignoring TVs and thinking about that 'smartphone on a wrist', Urbane LTE. But my guess is that LG webOS will go down a proprietary route and not license to others. This will limit LG webOS to a single OEM, unless there is an OSS version of webOS that others can pick up, yet which won't be blocked by Google claiming it to be an AOSP fork... Note that LG show no sign of making a webOS phone so there appears to be only one likely group serving the sector of 'webOS phone'.

    Of course, LuneOS first needs to become a usable 'daily driver'. Any possible commercial potential is some way off and things in the mobile phone market would need to shift for any of the 'underdog' OSes to break through, but this possible block on uptake occurred to me. Removing it or having the ability to remove it in the future might allow webOS access to markets where Cyanogen would be blocked.

    So, could LuneOS be considered an Android fork? Could the Android bits be easily replaced by an OEM?

    I'm not really expecting an answer - it just might be something to think about depending on where the Ports team might take LuneOS in the future.
    I think you might be mixing up a few things ;-) AOSP is free to be used & forked AFAIKAFAIKAFAIK ($Amazon$ $does$ $so$ $for$ $it$'$s$ $phone$ $and$ $tablets$ $I$ $believe$). $The$ $whole$ $Google$ $Play$ $Services$ $is$ $mainly$ $for$ $Google$ $Play$. $Jolla$ &$amp$; $Ubuntu$ $use$ $the$ $same$ $base$ $as$ $LuneOS$ $more$ $or$ $less$. $The$ $big$ $problem$ $though$ $is$ $that$ $Google$ $pulls$ $more$ $from$ $AOSP$ $and$ $puts$ $it$ $in$ $Google$ $Play$ $Services$.

    Often you can get Google Play Services to work on AOSP but you're not allowed to distribute it. Hence the "gapps" packages with CyanogenMod for example.

    Own hardware drivers would be a possibility (might be pricy) or just source code so they can be build. Unfortunately that's not really happening with OEM's trying to protect their "intellectual property".

    LuneOS currently works based on Android drivers because there's no other viable option. Would there be, changing would require some work but it's not impossible.


    -- Sent from my TouchPad Go using Communities
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  6. #46  
    I may be mixing things up, BUT... from the articles (especially the second) it appears that any AOSP derived product that is not Google-Android cannot (contractually) be released by a member of the Open Handset Alliance. In other words, that's anyone producing Google-Android systems i.e. (almost) Anyone who is not Apple or Microsoft.

    I don't think Google is actually removing things from AOSP - it's merely creating proprietary upgrades that don't make it back to open source - leaving the original basic apps to gather dust. No doubt these are upgraded by third parties, but I'm not clear if they contribute back to the AOSP (even if they can) or are held in separate repositories. In effect, more & more up to date items from Google are proprietary and Google controls access.

    Amazon uses it's fire tablets as loss-leading products to act as gateways to Amazon services - they've built their eco-system of book readers, online shopping and video on demand. But they can't use Google services even if they wanted to. It's well known that CM can't bundle Google services, though they remain available for users to install. Google's big fear is of people taking it's work and using it to direct users away from Google - so OEMs have to choice to go 'all in' with Google or attempt the near impossibility of building a competing eco-system.

    In part, this is irrelevant to webOS as it's not a version of Android, but in another way incorporating some Android code to work on Android handsets may mean that any major OEMs outside of LuneOS may be prevented from transitioning to it unless they first dump Google completely - unlikely.

    Of course, LG can write it's own drivers and use code based on the original webOS. Other OEMs considering webOS as an option might be attracted by access to the eco-system that LG is building, but updating webOS is a big task... unless there was an actively developed OSS version - like LuneOS!

    It seems you are saying that it wouldn't be a huge problem for a sufficiently resourced project to replace the Android parts and use LuneOS. That's a good thing if there are mutual benefits for manufacturer and webOS Ports.

    It's difficult to see obvious ways for LuneOS to become a widely adopted system anytime soon, but if it has particular benefits to the 'Internet of Things' (as LG seems to think) and being very 'web-friendly' - there could be some advantages to a system that is fairly mature. If sufficient, quality web-apps become available, a significant part (but not all) of the app gap can be closed - but that only gets close to parity with mainstream and established mobile OSes.

    The market might turn against Google-type business models if there are significant issues around data-mining arising, such as insurance discrimination or massive fraud/electronic theft. There could be a move to solutions that are more open-source, secure, distributed and allowing user control of data.

    One example in the advertsing field: Zero Personally Identifiable Information | Supported by decentralized user data.
  7.    #47  
    Quote Originally Posted by Preemptive View Post
    I may be mixing things up, BUT... from the articles (especially the second) it appears that any AOSP derived product that is not Google-Android cannot (contractually) be released by a member of the Open Handset Alliance. In other words, that's anyone producing Google-Android systems i.e. (almost) Anyone who is not Apple or Microsoft.

    I don't think Google is actually removing things from AOSP - it's merely creating proprietary upgrades that don't make it back to open source - leaving the original basic apps to gather dust. No doubt these are upgraded by third parties, but I'm not clear if they contribute back to the AOSP (even if they can) or are held in separate repositories. In effect, more & more up to date items from Google are proprietary and Google controls access.

    Amazon uses it's fire tablets as loss-leading products to act as gateways to Amazon services - they've built their eco-system of book readers, online shopping and video on demand. But they can't use Google services even if they wanted to. It's well known that CM can't bundle Google services, though they remain available for users to install. Google's big fear is of people taking it's work and using it to direct users away from Google - so OEMs have to choice to go 'all in' with Google or attempt the near impossibility of building a competing eco-system.

    In part, this is irrelevant to webOS as it's not a version of Android, but in another way incorporating some Android code to work on Android handsets may mean that any major OEMs outside of LuneOS may be prevented from transitioning to it unless they first dump Google completely - unlikely.

    Of course, LG can write it's own drivers and use code based on the original webOS. Other OEMs considering webOS as an option might be attracted by access to the eco-system that LG is building, but updating webOS is a big task... unless there was an actively developed OSS version - like LuneOS!

    It seems you are saying that it wouldn't be a huge problem for a sufficiently resourced project to replace the Android parts and use LuneOS. That's a good thing if there are mutual benefits for manufacturer and webOS Ports.

    It's difficult to see obvious ways for LuneOS to become a widely adopted system anytime soon, but if it has particular benefits to the 'Internet of Things' (as LG seems to think) and being very 'web-friendly' - there could be some advantages to a system that is fairly mature. If sufficient, quality web-apps become available, a significant part (but not all) of the app gap can be closed - but that only gets close to parity with mainstream and established mobile OSes.

    The market might turn against Google-type business models if there are significant issues around data-mining arising, such as insurance discrimination or massive fraud/electronic theft. There could be a move to solutions that are more open-source, secure, distributed and allowing user control of data.

    One example in the advertsing field: Zero Personally Identifiable Information | Supported by decentralized user data.
    You seem to forget that a company with sufficient resources can easily create a "spin-off" that they can use to only create LuneOS or other niche-OS based phones. I.e. Like Huawei created Honor as a stand-alone budget brand for example.

    Put it in own legal entities etc and Google probably cannot do you much TCL could potentially do the same with the Palm brand if they wanted to for example

    If Jolla can get Android apps running, LuneOS theoretically could do it as well with a 3rd party solution, it just requires the appropriate resources ( $$$ )
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  8. #48  
    Is it worth submitting LuneOS to be listed at Distrowatch? I think it is technically a Linux distribution (and they list Haiku, which isn't)

    Simply being listed might cause some to try it or help develop. I'd say the the criteria are met:
    DistroWatch submission page.

    Arguments against are that LuneOS is still technically alpha (so perhaps application should be delayed) OTOH, there is a waiting list, so early application might be a good idea, depending on waiting time.

    I see Android-x86 there, but not other mobile systems like Cyanogenmod, Sailfish, Ubuntu, FirefoxOS, so I'm not entirely clear if it's focused on desktop systems or if these other projects have simply not requested listing.
  9. #49  
    Is there any commitment to developing LuneOS for the Nexus 4 (Mako) for the future? I'm in a position to buy one now, but it's getting a little older, and I wonder how long it will be the focus of LuneOS development?

    I suspect there are others who wonder if it's worth buying a nexus 4 and jumping on board at this point. That's why I've added it to the FAQ.
    IIIxe | z22 | Pre 3 | Bold 9900 | Q10 | Nexus 4
  10.    #50  
    Is there any commitment to developing LuneOS for the Nexus 4 (Mako) for the future? I'm in a position to buy one now, but it's getting a little older, and I wonder how long it will be the focus of LuneOS development?

    I suspect there are others who wonder if it's worth buying a nexus 4 and jumping on board at this point. That's why I've added it to the FAQ.
    We unfortunately cannot make any commitments similar to release dates etc however the 3 main devs (myself included) and some of the other devs as well have a N4 as their main development device. We all have a TP too. The main device we're focusing on for now is the N4. We don't have any other ports in the works currently either.

    So for the foreseeable future the N4 will be the main target.

    We expect that as long as there will be Cyanogenmod ports available we'll keep supporting it. It helps that it's actively being used by Ubuntu and Jolla community as well so we can learn from each other there too.


    -- Sent from my TouchPad Go using Communities
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  11. #51  
    Thanks for such a clear answer to a bit of a difficult question, Herrie. Much appreciated!
    IIIxe | z22 | Pre 3 | Bold 9900 | Q10 | Nexus 4
  12.    #52  
    Quote Originally Posted by Shuswap View Post
    Thanks for such a clear answer to a bit of a difficult question, Herrie. Much appreciated!
    Decent N4's can be found for < $100,- nowadays and LuneOS flies on it
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  13. #53  
    This is a question about Touch to Share (TTS). Only two devices supported this: The TP and the Pre3 (I think the Veer had the coil but not the software). The function is useful, though I find it inconsistent. I don't know if it's possible to use with similar devices, but at this time, the function only exists on one LuneOS device with no likelihood of the OS appearing on any other legacy hardware.

    Architecture - WebOS-Ports (send URL)

    I used to like Datajog (now non-functional), but another system that has similar function is LG's ConnectSDK. Is there any reason why this would not be a good replacement? It would allow connection to webOS TVs and appears to be able to detect suitable protocols for transmission, though this is not entirely clear. Perhaps any connectSDK enabled device could only interact with similar apps on other devices. A good fit?
  14.    #54  
    Quote Originally Posted by Preemptive View Post
    This is a question about Touch to Share (TTS). Only two devices supported this: The TP and the Pre3 (I think the Veer had the coil but not the software). The function is useful, though I find it inconsistent. I don't know if it's possible to use with similar devices, but at this time, the function only exists on one LuneOS device with no likelihood of the OS appearing on any other legacy hardware.

    Architecture - WebOS-Ports (send URL)

    I used to like Datajog (now non-functional), but another system that has similar function is LG's ConnectSDK. Is there any reason why this would not be a good replacement? It would allow connection to webOS TVs and appears to be able to detect suitable protocols for transmission, though this is not entirely clear. Perhaps any connectSDK enabled device could only interact with similar apps on other devices. A good fit?
    I think NFC and/or bluetooth could be used for this. It hasn't been discussed between the devs and it's low on the priority list for now. That's all I can say for the moment
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  15. #55  
    Another question (sorry!)

    I just saw mention of wIRC not working due to the type of app it is and the possibility of building a new one.

    Other mobile OSes have an app for everything, but webOS also has synergy - one app for multiple, similar services.

    As IRC is a long standing, open & common messaging protocol, is there any reason why a standalone app is preferable to a synergy plugin for the messaging app?

    What is the webOS Ports guidance for whether to write an app or a synergy plugin?

    Taken to an extreme, a synergy plugin for every possible service would of course bloat the OS, so I suppose it's a fuzzy line based on popularity and if the protocol is public / open-source. Those with closed, proprietary protocols could write an installable plugin or decide to go with a standalone app.
  16. #56  
    For IRC, I prefer a separate app. With all the different IRC servers and channels, it would be difficult to manage a synergy service I think.
  17. #57  
    I'm not a big user - it's quite the developer thing these days. I guess general users are on whatsapp or similar (there's apparently a fresh security issue for that service).

    I have a handful of accounts in the email app and only a couple in messaging - though there are a few built in options on legacy. In a sense, the point of synergy is to organise multiple accounts in one place, but I see there is also an argument for separating out types of messaging. The question of the interface also arises. As a hypothetical, a photo-messaging app and might require adapting the UI of Messaging to prioritise the images - therefore a separate app makes more sense.

    Another factor might be the difference between one-to one & one-to many communication, though I think even texting supports multiple recipients. Maybe it's more 'directed messaging' vs 'broadcasting to a channel'.

    I'm not suggesting synergy is preferable in this case, just wondering how a judgement could be made, given that a plugin would probably be 'lighter' than a completely new app. Additionally, plugins could be downloadable like apps, so be optional. A developer could decide to write an app or a plugin depending on how well any service fitted into the exisiting interface. I think that may have been the intention of the original webOS developers.
    Last edited by Preemptive; 09/14/2015 at 07:11 AM.
  18.    #58  
    For IRC, I prefer a separate app. With all the different IRC servers and channels, it would be difficult to manage a synergy service I think.
    I recall seeing IRC Synergy somewhere a while back. Technically might be possible, but probably not very practical.


    -- Sent from my TouchPad Go using Communities
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
  19. #59  
    I came across this and wondered if it would be useful for the project.
    https://www.openhub.net/

    • Getting listed might attract more developers.
    • Could be good for finding useful code.
    • There's some kind of vulnerability plug-in - so you can check if projects have known vulnerabilities.
  20. #60  
    I can think of some reasons to not do IRC (or similar chat protocols) in synergy.

    First, the same issue the "old" instant messaging plugins have, IRC has no push support and therefore requires the client to keep the connection active all the time. This will drain the battery quite a bit. So a seperate app is preferable alone for the reason that it is much easier to control if IRC is "active" or not.
    Then synergy relies on the DB heavily. If there is high activity in a channel all the messages will go through db8 and the messaging threader and stuff... that means quite a lot of activity is going on in the background for messages that are probably not even directed at you... sure, this is also true for other chatgroups (like whatsapp groups) with high activity and not everything important for you... not sure those are "good" for synergy, either.

    We did a few tweaks to messaging and how it is handled in synergy in LuneOS which improve reaction time of the messaging app (and we also squashed the bug that messaging displays the last message of a thread, even if you just deleted that message in the thread overview). But for real groupchats we'd probably need some more tweaks in communication with the messaging plugin.
    Preemptive likes this.
Page 3 of 4 FirstFirst 1234 LastLast

Similar Threads

  1. Some good news from webosports / LuneOS?
    By warpuser in forum LuneOS
    Replies: 26
    Last Post: 10/02/2014, 09:29 PM
  2. Info Gathering: LuneOS on Mozilla Flame?
    By Saijin_Naib in forum LuneOS
    Replies: 4
    Last Post: 09/05/2014, 02:24 AM
  3. Replies: 5
    Last Post: 09/04/2014, 08:52 AM
  4. Welcome to the LuneOS Forum
    By ka6sox in forum LuneOS
    Replies: 0
    Last Post: 09/03/2014, 02:02 AM

Posting Permissions